MCP, the sockets of the harness

MCP — the Model Context Protocol — is how an agent reaches a real system without you writing an integration. A server exposes tools, resources, and prompts; the agent calls them. If instructions are the harness’s rules and agents are its roles, MCP servers are its sockets: the places where the editor plugs into the outside world.

The anatomy

Servers are declared in a workspace .vscode/mcp.json under the servers key — not mcpServers, which is a different tool’s shape and will silently do nothing.^⊙ Types are stdio for local processes and http for remote endpoints, the latter supporting OAuth including enterprise-managed sign-in. Here is the harness config:

// The Demo Harness — drewbreyer.com/harness — starter file, as of 2026-07-06
{
  "servers": {
    "microsoft-learn": { "type": "http", "url": "https://learn.microsoft.com/api/mcp" },
    "github":          { "type": "http", "url": "https://api.githubcopilot.com/mcp/" },
    "playwright":      { "type": "stdio", "command": "npx", "args": ["@playwright/mcp@latest"] },
    "dataverse":       { "type": "http", "url": "https://yourorg.crm.dynamics.com/api/mcp" }
  }
}

Three of these you can wire in minutes. The Microsoft Learn server is remote and needs no authentication at all^⊙ . The GitHub server is remote and uses a one-time OAuth sign-in in the editor — no personal access token to mint or leak.^⊙ The Playwright server runs locally over stdio and downloads its browser on first use.^⊙ The fourth, Dataverse, waits until Part III, and its placeholder org URL must be replaced before it does anything.

Keep the menus small

An agent with forty tools chooses badly. Tool sets let you group tools so an agent is pointed at a small, relevant menu^⊙ — the librarian sees documentation tools, the operator sees the environment, and neither is tempted by the other’s. Scoping tools is not bureaucracy; it is how you keep an agent’s behavior legible.

Hooks, with caveats

Hooks are in preview. They gate lifecycle events — among them PreToolUse and PostToolUse — so you can run something before or after a tool call.^⊙ A customer-facing harness wants an audit trail, so the pack ships a hook that logs every tool invocation to a file:

{
  "hooks": {
    "PostToolUse": [
      {
        "run": "jq -c '{ts: now, tool: .tool_name, input: .tool_input}' >> .harness-log.jsonl"
      }
    ]
  }
}

It degrades gracefully: delete it and nothing else breaks. That is the right posture for a preview feature you are leaning on — useful, labeled, and optional.

In the field

Create .vscode/mcp.json with the three no-Dataverse servers and let VS Code start them. Ask an agent to look something up through the Learn server. If your laptop is org-managed and a server will not start, that is its own lesson: note which governance setting is blocking it, and move on.

Part I is done

You have a workbench: a repo, an instruction stack, prompt files and a skill, the first agent, and the sockets. The customer does not exist yet. In Part II, the engagement begins, and the harness goes to work.