What good MCP technical training actually covers

Nearly every MCP technical training we have seen ends where the interesting problems start. You install a filesystem server, you install a GitHub server, the agent lists your repos, everyone claps. Then the team goes back to work and hits the real questions. Which of our internal systems should an agent be able to reach. What happens when a tool returns 40,000 tokens of JSON. Who owns the credential.

Model Context Protocol is a wire format for exposing tools, resources, and prompts to a model. The protocol part is small and well documented. The engineering judgement around it is not.

Tool design is the whole game

A model does not read your API docs. It reads your tool names and descriptions, and that is the entire interface. We spend a full block on this because it is where most homegrown servers fail.

• One tool per user intent, not one tool per REST endpoint. find_open_incidents beats get plus a filter object the model has to construct.
• Return summaries with an identifier the model can drill into, rather than the full payload. A tool that dumps a 3,000-row table burns the context window and makes the next five turns worse.
• Write error messages for the model. "Missing required field: team_id. Call list_teams first." recovers. "400 Bad Request" does not.
• Make destructive tools obviously destructive in their name. The model reads the name more reliably than a warning buried in the description.

Transport, auth, and the boring operational stuff

Local servers over stdio are simple, run as the user, and inherit whatever that user can already do. Remote servers over HTTP need real authorization and real thinking about who is calling. Teams frequently prototype with stdio, ship with HTTP, and never revisit the assumption that the caller is trusted.

The practical checklist we hand out: scope tokens to the narrowest thing that works, never put a shared service account behind a server that multiple people drive, log every tool invocation with the caller identity, and set a hard timeout. On the client side, know how to inspect what is actually registered. In Claude Code, claude mcp list tells you what is connected, and the config file tells you what each server is allowed to do.

Where MCP is genuinely weak

Worth saying out loud in any training that wants to be believed. Tool descriptions coming from a third-party server are input to your model, so a compromised or careless server can steer an agent. Large numbers of connected servers degrade tool selection, and we have watched accuracy fall off well before anyone hit a documented limit. Debugging is still rough compared to a normal HTTP client. Budget for that.

None of this makes MCP a bad bet. It makes an unreviewed server a bad bet.

How to run this with your own team

Do not start with a generic curriculum. Pick two systems your engineers already lose time to, an internal service and a data source, and build servers for those during the session. People retain the pattern when the tool returns their own data. End the day with a written policy on who can add a server to the shared config and what review it needs before it lands.

We run this as a hands-on day with your repos and your systems, for groups small enough that everyone ships something. If that is the shape you need, get in touch.

If you want help putting this into practice, talk to us.