Real world MCPs in GitHub Copilot Agent Mode

How much of building an application can you hand to Copilot while still deciding what it may execute? The progression starts with code completion: suggestions and whole functions appear as you type. Chat expands the scope to a prompt that generates or changes several files. Agent mode extends that interaction into a complete task, with the developer participating as the work proceeds.

In Jon Peck’s demonstration, that participation includes authorizing terminal actions and letting the agent read their results. The agent can then continue toward a larger goal, such as building a new application or refactoring an existing codebase. The working unit becomes the task and its feedback loop, rather than a single generated answer.

The first concrete example begins with a repository containing a README and no code. The README describes the application and its intended project structure, including environment configuration. It can also specify the database schema, API endpoints, and workflow diagrams. A model with vision can read a diagram supplied as an image; for a model without vision, Mermaid or another text diagram format keeps that information accessible.

With that specification in place, switch Copilot to agent mode, select a model, and request implementation. Peck uses prerecorded demonstrations because of unreliable connectivity. The agent builds the data models, creates app.py, and works on the frontend. When a Continue prompt appears, it is asking permission to interact with the terminal. After an approved command runs, the agent can read its output and react to failures.

Peck reports roughly eight minutes for this prerecorded README-to-app run. The result is a basic travel-reservation application in which he can make reservations and select rooms; styling is left for later iterations. That elapsed time describes this example, not a general benchmark for generating applications.

Model Context Protocol, or MCP, provides an open interface to external data, references, and advice. Authentication can make that information specific to a developer’s account. Peck points to the MCP servers repository as a place to discover integrations, and to his accompanying deck for the slides and embedded demonstrations.

The connection starts in the IDE. VS Code holds the server configuration, and Copilot uses the configured capabilities to select a suitable tool for a request. A local MCP server might query a database on the developer’s machine or call a web API. A remote server can perform its work in a protected environment and return results to the IDE.

The remote arrangement in the talk mentions SSE, or Server-Sent Events. In the historical MCP transport specification, this is a client–server transport: SSE carries server messages, while HTTP POST carries client messages. It is not a separate protocol for MCP servers to talk to one another.

Choose the integration from the task, not from the catalog. Here the application uses PostgreSQL, and the next task is to build tests using data from the local database as mock data. That makes database access useful before test generation begins.

The demonstrated setup follows a short sequence:

1. Find a PostgreSQL MCP server in the server collection. Use its manual installation instructions or its VS Code installation button.
2. Approve installation. In this recording, VS Code adds the configuration to settings.json.
3. Replace the default connection string with the actual database connection details. Peck’s local PostgreSQL instance is unauthenticated; he calls for proper authentication for a remote or production database.
4. Start the local MCP server from the configuration interface.
5. Open the tools menu in Copilot chat to inspect the available servers and enable or disable them.

Installing the configuration and starting the server are distinct steps: the running server is what makes the database connection available to the agent.

Peck found that implicit tool selection was inconsistent: Copilot sometimes inferred that it should use the PostgreSQL server and sometimes did not. His practical adjustment is to name the integration explicitly. The request is to use the Postgres MCP to retrieve database data and create mock.json as a reference for building tests.

Copilot asks permission before connecting. The particular PostgreSQL server used here is read-only, allowing database data to enter the IDE without intentionally mutating the database. That property belongs to this server, not to MCP in general. The matching archived PostgreSQL reference implementation documents SQL queries inside READ ONLY transactions; read-only query behavior is a mutation boundary, not a blanket security guarantee.

The extracted data lands in mock.json. Copilot then continues the ordinary agent workflow, using that file to build tests. Read-only database access still permits local file creation: the source database and the working repository are separate places where different operations are allowed.

The database interaction is a sequence of requests, not one opaque retrieval:

1. Copilot interprets the prompt and identifies the need for an MCP connection.
2. The developer grants permission, and Copilot calls the server.
3. The server exposes the database schema so the agent can understand what is available.
4. Successive requests identify the relevant tables and retrieve their data.
5. Copilot parses the responses, writes the requested files, and carries the returned information into the context for subsequent work.

Schema inspection comes before selecting and reading tables; the responses guide what the agent does next.

Expect to refine the request as that work unfolds. Peck recommends keeping reusable direction in README files, Copilot instructions, and prompt files that can be selected for particular tasks. Those artifacts preserve useful guidance across iterations instead of requiring the developer to reconstruct it in each chat message.

The next integration moves from database context to repository operations. The GitHub MCP server lets Copilot perform work that would otherwise require command-line operations or clicks on the website. Peck adds the server to VS Code, supplies a GitHub personal access token, and starts it so requests connect under his identity. The demonstrated credential is obscured. PAT authentication is the workflow shown here; current GitHub MCP documentation also provides OAuth options.

Before handing off the changes, make recurring expectations persistent. Peck uses .github/copilot-instructions.md for standards such as PEP 8, security checks on installed dependencies, and a changelog of the agent’s work. A compact instruction file expressing those practices could contain:

Follow PEP 8 for Python code.
Run a security check on dependencies you install.
Update the changelog with the changes you make.

The changelog supplements incremental Git commits with an explicit account of what changed at each step. In the demonstration, the agent updates that record before the repository handoff.

Now request the next complete task: use the GitHub MCP to commit the changes on a new branch and create a pull request. Copilot asks permission for the connection and repository operation. The visible approval is a pending action, not evidence of a completed PR: Peck describes the branch-and-PR flow but does not show it in full.

The demonstration stops at that repository handoff, without an application deployment walkthrough. Peck closes the prepared material by pointing back to the accompanying deck, whose final slide collects references for VS Code and MCP installation.

The closing question asks how IDE agent mode relates to the Copilot coding agent, which accepts assigned issues through GitHub’s web interface. Would the two become a unified product? Peck leaves that undecided. His contemporary explanation emphasizes different concerns for an individual developer working interactively and a team handing autonomous work to other developers for approval; it is not a commitment to a future product structure.

The background workflow begins by creating an issue and selecting Copilot as its assignee. Copilot performs agentic work asynchronously, exposes a session on GitHub that developers can inspect, and delivers its output through a pull request. The interaction moves from supervising work inside the IDE to reviewing work produced in the background.

MCP remains available in that arrangement. Peck points to the Copilot area of repository settings as the place to supply the background agent’s MCP configuration. External capabilities therefore accompany both workflows, while the place where the developer supervises and reviews the work changes.