Debugging with MCP + PostgreSQL

In this final step, you’ll learn how to expand GitHub Copilot’s capabilities beyond your editor and application runtime by using an MCP (Model Context Protocol) server. Specifically, you’ll use a PostgreSQL MCP server that allows Copilot to directly query your real application database.

Problem

Your task is to work with GitHub Copilot and a PostgreSQL MCP server to diagnose and fix a bug described in BUG_REPORT.md on the bug-3 branch. This bug involves data inconsistencies that show up in the Kanban board view. To fix it, you need to combine:

• multi-environment debugging

• database inspection

• logging

• and Copilot’s ability to reason across all of these

This step demonstrates how Copilot can become a cross-system debugging partner—not just a code assistant—when connected to data and services through MCP.

What You Need to Know

Why MCP Servers Matter for Debugging

MCP (Model Context Protocol) allows AI assistants to communicate with external tools and services through a uniform interface. By adding MCP providers, you allow Copilot to:

• read data external to your codebase

• run queries or fetch information from other systems (ex. PostgreSQL)

• reason about internal and external state together

• go beyond the static view of code and logs

This completely changes what an AI assistant can do.

With MCP in place, Copilot can debug using real data by performing structured queries directly against external systems. It can inspect remote services, access information that isn’t available from the code alone, and bridge the gaps between your application’s code, its supporting tools, and the runtime state across different services.

Today you’re using a Postgres MCP server, but in the future this could also include:

• Jira MCP → read tickets

• GitHub MCP → inspect pull requests and CI logs

• Figma MCP → fetch design assets

• Elasticsearch MCP → search logs or metrics

• Redis MCP → explore cache contents

MCP transforms Copilot from “an intelligent autocomplete” into a multi-system debugging agent.

Why Debugging with the Database Matters

Many real bugs originate from data, not code:

• unexpected values

• missing rows

• incorrect join tables

• inconsistent or malformed fields

• drift between application rules and stored state

Debugging with the database helps you answer questions logs cannot:

• “Does this data actually exist?”

• “Is the schema what we think it is?”

• “Are some rows missing fields?”

• “Are statuses or enums inconsistent?”

• “Is the UI reflecting the real data, or is something filtered incorrectly?”

• “Is the data correct but the query wrong?”

In this workshop’s scenario:

The Tasks page (/tasks) shows 30 tasks,
but the Kanban board (/board) only shows ~7.

This mismatch hints that:

• the data might be correct, but the query or filtering logic is wrong, or

• the data might itself be inconsistent, and only some tasks meet the board’s expectations.

With the PostgreSQL MCP server, Copilot can directly inspect the database to determine which is true.

How MCP Is Configured in This Project

The .vscode/mcp.json file includes configuration for a PostgreSQL MCP server that points to your running Postgres instance.

This setup allows Copilot to:

• list tables

• inspect schemas

• run queries (read-only unless instructed otherwise)

• examine the data behind your application state

The project has also switched from SQLite to PostgreSQL, so all app queries are now hitting a real database server.

You do not need to configure MCP yourself—it's already included in the project.

The Full-Stack Bug Scenario (BUG_REPORT.md)

This bug involves tasks disappearing from the Kanban board even though they exist in the database.

Key points:

• /tasks shows 30 tasks

• /board only shows ~7 tasks

• no errors appear in logs

• the issue is consistent

• likely caused by incorrect filtering or query logic

This is an ideal use case for database debugging.

Debugging Prompt Including DB Access

Here is the prompt Copilot will use:

You will run this via:

✏️ Hands-On Exploration

Follow the steps below to work with Copilot and the PostgreSQL MCP server to debug the issue.

1. Checkout out the bug-3 branch in TaskFlow

   1. Commit or reset any changes made by Copilot;

      1. Commit git add . && git commit -m “changes“

      2. Reset git reset --hard HEAD && git clean -fd

   2. Check out the new branch

      1. git switch bug-3

2. Reset the database npm run db:reset (or ask Copilot to do it)

3. Explore the bug in BUG_REPORT.md

   1. Replicate it in TaskFlow and make sure you understand what the problem is

4. Start the PostgreSQL MCP server

   1. Inside .vscode/mcp.json

   2. Open

      

       

5. Work with Copilot to investigate the database manually. You can prompt it directly:

   1. "Use the postgres mcp to tell me how many users are in the app and their emails."

   2. "List out all of the different status for the tasks"

   3. "Mark all tasks with high severity as Done."

6. Look over the debugging prompt .github/prompts/debug-with-logs.prompt.md

   1. A new section has been added for checking the database

7. Run the prompt

   1. "/debug-with-logs"

   2. Observe the output and how Copilot goes about fixing the bugs

   3. Pro Tip: Use a more advanced model to get better results

8. Verify the bug is fixed

   1. Manually run the TaskFlow app and inspect the Kanban board.

   2. Use the MCP to query the database and check the task statuses. If they are still inconsistent, have copilot update them directly inside the db.

Next Steps

You’ve now combined:

• full-stack debugging

• logging

• orchestration

• and database queries through an MCP server

This is the most complete and powerful debugging workflow available today using Copilot. In real development scenarios, this is the level where AI stops being a code assistant and becomes a system-wide debugging partner.

Continue to: Debugging Workshop | ConclusionPreview

Sources