What the Model Context Protocol is, briefly
The Model Context Protocol (MCP) is an open protocol through which AI applications discover and call tools. An MCP server lists its tools, each with a name, a description and a JSON Schema for its inputs; an agent in a client such as a coding assistant or chat app picks a tool and calls it. For an API, the MCP server is often a thin layer that turns those tool calls into API requests, frequently through the same SDK your human callers use.
1. Tool definitions replace the docs page
A developer reads your reference docs once and writes code. An agent reads your tool definitions every time it decides what to do, and it chooses based on names and descriptions alone. That changes what “good” means:
- Names and descriptions are the interface. “list_invoices: List a customer's invoices, newest first; use status to filter unpaid ones” gets called correctly. “getV2InvoicesCollection” gets guessed at.
- Fewer, task-shaped tools beat one tool per endpoint. Hundreds of near-identical tools crowd the agent's context and lead to wrong choices. Group or leave out operations agents shouldn't need.
- Input schemas do the job types did. Enums, required fields and formats in the schema stop bad calls before they reach your API, the way a compiler does for a developer.
2. Scoped credentials, not shared keys
The quickest way to connect an agent is to paste a long-lived API key into its configuration. It is also the riskiest: the agent can do everything the key can, for as long as the key lives, and nobody can tell its calls from anyone else's. Better patterns give each agent session short-lived credentials scoped to the task (read invoices, not issue refunds), issued through an OAuth flow or a broker rather than copied by hand. MCP defines authorization for its HTTP transport; how narrowly you scope what an agent gets is still your design.
3. Identity: who is the agent acting for?
When a developer's code calls your API, the API key usually tells you which customer or service it is. When an agent calls, the useful answer is a person: the employee who asked the agent to act. Without that link, a shared service account makes every action anonymous. Tie agent sessions to the identities your organisation already manages, so permissions follow the person and end when their access does.
4. Audit: can you reconstruct what happened?
Agents act quickly and in volume, and they sometimes act wrongly. You need a record of every tool call: which tool, with what inputs, on whose behalf, allowed or denied, and what came back. Send it to the logging and monitoring you already run, so an odd call raises the same alarms as any other incident.
Which SDK qualities still matter
All of them, but for different reasons:
| Criterion | Why it matters more with agents |
|---|---|
| Typing | Precise types become precise tool input schemas, which keep the agent's calls valid. |
| Auth handling | Token refresh and scoped credentials must work without a person in the loop. |
| Retries | Agents call in bursts; backoff in the client keeps a rate limit from becoming a retry storm. |
| Pagination | An agent that sees only the first page answers confidently from partial data. |
| Error handling | Clear errors let the agent correct its call instead of trying again blindly. |
| MCP readiness | Whether the approach gives you an MCP server from the same source, or leaves it to you. |
A checklist for agent-ready APIs
- Tool names and descriptions written for a model choosing between them, not generated from operation IDs alone.
- A curated tool set: only the operations agents should use, grouped by task.
- Input schemas with enums, required fields and formats.
- Short-lived, task-scoped credentials for each agent session, never a shared long-lived key.
- Every call attributable to a person through your identity provider.
- Every tool call logged, allowed or denied, in the monitoring you already run.
Compare approaches for agents
Run Hand-written SDK vs MCP server, or add MCP readiness to any matchup in the comparison tool.