Working with agents and MCP servers

On Wednesday, August 11, the session moved from asking Copilot for code to letting it do work. The first course had introduced agent mode in the editor and the coding agent on GitHub.com. This session was about using them well: how to frame a task for an agent, how agents use tools, what the Model Context Protocol adds, how to keep an agent safe, and how to judge the result. Priya chose a modest task for the demonstration: add a closures section to the weekly summary email, the change the refactor in lesson 5 had prepared for. "Agents are good at well-defined chores," she said, "and bad at deciding what the chore should be. We decide; it does."

Ask, edit and agent: a quick recap

Editors such as VS Code offer chat in several modes. In ask mode, Copilot answers questions and suggests code that you copy or apply yourself. In edit mode, you choose files and Copilot proposes changes across them for you to review. In agent mode, Copilot plans the work, decides which files to read and change, runs tools such as the terminal or tests, looks at the results and keeps going until the task is done or it needs your input. Some editors also offer a plan mode, which produces a step-by-step plan for approval before any change is made. The coding agent, which recent GitHub documentation calls Copilot in the cloud, runs on GitHub.com: you assign it an issue or task, it works in a separate environment and returns its work as a branch and a pull request.

How an agent works

An agent is a loop around a model. The model is given the task, the context and a list of tools it may call, such as reading a file, searching the code, running a terminal command or calling a test runner. At each step it decides which tool to call; the client runs the tool and adds the result to the context; the model decides the next step. The loop ends when the model judges the task complete or when it needs a person. Everything from lesson 2 about context applies with extra force, because tool results can fill the context quickly, and everything from lesson 3 about instructions matters, because AGENTS.md tells the agent how to build and test and what "done" means.

Framing a task for an agent

A task for an agent needs everything a good prompt needs and three things more: a definition of done, the boundaries of what it may change, and how it should check its own work. Vague tasks produce sprawling changes. Priya wrote the closures task as she would for a new colleague.

Add a "Closures" section to the weekly summary email.

Context: trails/summary.py builds the email; closures are reports with
condition "closed" or "washout" in the last 7 days. See AGENTS.md for how to test.

Done means:
- A Closures section lists each closed trail with the date of the latest report.
- If there are no closures, the section is left out entirely.
- New tests cover: one closure, several closures, and none.
- All existing tests still pass. Do not modify existing test files.

Only change trails/summary.py, templates/summary.txt and add tests/test_closures.py.

The boundaries line, "only change these files", is often the most valuable. It keeps the diff reviewable and stops the agent from tidying unrelated code. The instruction not to modify existing tests protects against the failure mode from lesson 6, where an agent makes tests pass by changing them.

Choosing between the editor agent and the cloud agent is mostly about where the work should happen. Agent mode suits tasks you want to watch and steer, because it works in your own workspace and you see each step. The coding agent suits tasks you can describe fully in an issue and review later, because it works on its own branch while you do something else. Tidewater had the coding agent switched on only in trailcheck and open-trail-report, so for anything touching trail-notes, agent mode in the editor was the only option.

Approvals and the terminal

In the editor, agent mode asks for approval before running terminal commands unless you allow them, and you can review each proposed edit. It is tempting to approve everything to save time. Priya's rule was to approve read-only and test commands freely and to read anything that installs packages, deletes files, changes configuration or touches the network. Copilot CLI follows the same pattern in the terminal, asking before commands that change things. In the cloud, the coding agent works in its own environment, its pull requests are subject to the repository's rulesets, and a person must review and merge them.

The Model Context Protocol

The Model Context Protocol (MCP) is an open standard for connecting AI applications to data sources and tools. An MCP server is a small program that offers tools through the protocol, for example "search issues", "read a database table" or "open a web page in a browser". A client such as Copilot in VS Code, Copilot CLI or the cloud agent can connect to MCP servers and make their tools available to the model. That is how an agent can do more than edit files: it can look up an issue, query a test database or check a deployed page.

GitHub publishes the GitHub MCP server, which offers tools for repositories, issues, pull requests and more. It can be used remotely through Copilot Chat in VS Code without local setup, or run locally in any MCP-compatible editor, and Copilot CLI includes it. GitHub recommends enabling only the toolsets you need, which improves tool choice, reduces the context taken up by tool descriptions and limits what the agent can do. On GitHub.com, repository settings configure MCP servers for the cloud agent and code review; the GitHub MCP server and a Playwright browser server are configured by default there.

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": { "X-MCP-Toolsets": "issues,pull_requests" }
    }
  }
}

MCP policy and trust

An MCP server is code that runs with access to whatever it connects to, so choosing servers is a security decision. For organizations, the "MCP servers in Copilot" policy controls whether members with Business or Enterprise seats can use MCP at all, and GitHub documents it as disabled by default. It does not govern individual plans such as Free or Pro. GitHub also runs an MCP Registry, a curated list of partner and community servers, which was in public preview when the course was written.

Tidewater had decided in the first course to allow only the GitHub MCP server. Rosa enabled the policy for the organization on that basis, and the decision was written in the admin repository: no other servers without a review covering who publishes the server, what data it can reach, what credentials it needs and whether its tools can change anything. A server that only reads public documentation is low risk; a server that can write to a database is not.

Measuring agent work

Agent tasks use more AI credits than a single chat answer, because each step sends context and receives a response. Since June 2026 that usage draws on the organization's pooled credits, so Priya wanted a rough sense of cost before agent use became routine. The figures below are illustrative estimates for one task, not GitHub's published rates.

steps = [
    ("read summary.py and tests", 6000, 400),
    ("plan the change", 7500, 900),
    ("edit summary.py", 9000, 1500),
    ("write tests", 10500, 1800),
    ("run tests, read failure", 12000, 600),
    ("fix and rerun", 12500, 900),
]
total_in = sum(i for _, i, _ in steps)
total_out = sum(o for _, _, o in steps)
print("steps:", len(steps))
print("input tokens:", total_in)
print("output tokens:", total_out)
print("share of tokens that are input:", round(total_in / (total_in + total_out) * 100), "in 100")

steps: 6
input tokens: 57500
output tokens: 6100
share of tokens that are input: 90 in 100

The pattern matters more than the numbers: input grows at every step because the context accumulates, so long agent runs cost more than their output suggests. Keeping tasks small and context focused is the main lever, and it is the same advice that makes agents more accurate.

Reviewing what an agent did

The closures task finished in a few minutes. Copilot produced a diff touching the three allowed files and a new test file, and the tests passed. Priya reviewed it like any colleague's pull request, with one addition: she read the agent's session log, which shows the steps it took, the commands it ran and the files it read. The log showed it had considered changing the date helper from lesson 5 and decided not to, which was right. The review found one problem: the closures section sorted trails by name instead of by the date of the latest report, as the task said. A one-line follow-up fixed it. Lesson 9 covers reviewing AI-generated code in detail.