Phase 4 · Months 3 to 5

Build tool servers with MCP

Why tools matter

Agents become useful when they can act, and that puts tool servers on the security and reliability boundary. The model can suggest an action. The tool server decides whether to validate it, authorise it, and run it, and the tool server owns idempotency, timeouts, audit logs, and side effects.

Learn MCP as a protocol

Learn MCP as a protocol. A config file shows you only how to install a server. Learn how clients and servers divide the work, how clients discover tools and resources, and how transports, schemas, authentication, and the connection lifecycle work. Have agents build both a client and a server. Then inspect the real messages and failure cases yourself. The MCP Inspector helps with this.

Design narrow tools

Make each tool narrow and give it a name that says what it does. Prefer create_pull_request(base, head, title, body) over run_shell(command). Validate every argument on the server. Sort tools into four risk levels: read, execute, write, and privileged. A privileged operation often needs a human approval token or its own service identity. Write tool output for a model to read: short, structured, and with errors that say what to do next.

Pass identity through every call

Pass the identity of the user or workload through every call. Use short-lived credentials with narrow scopes and explicit authorisation checks. Log who or what requested each action, the validated arguments, the side effect, and the result. Never let a model choose its own IAM role or skip a policy check because it claims the task is urgent.

Distribute servers to teams

An MCP server that nobody installs changes nothing. Learn how teams package MCP servers with shared skills and settings, for example as Claude Code plugins or managed settings, and how they version and update them safely. Staff platform roles ask you to drive adoption of internal MCP servers, and this is how that works in practice.

Build two MCP servers

Build an engineering server with the tools search_code, get_pr, get_build_status, get_logs, run_tests, create_branch, and open_pr. Add rate limits, audit logs, cancellation, structured errors, and permissions for each tool. Make destructive actions opt-in and require approval for them. Then build a server that gives other people's agents access to your product's main feature. That server is a real product feature as well as practice.

You are done when

You can design a tool API that an agent uses reliably, and explain where its trust boundary is. You can show that malformed or malicious model output cannot get past validation or authorisation. You can roll the server out to other people's agents.

Exit checklist