MCP Servers and Tool Calling for Real Developer Products
Tool calling becomes backend engineering as soon as a model can read private data or trigger a real action.
Treat the model as an untrusted caller
A model can choose a tool and construct arguments, but it should not choose its own authority. Identity and permission context come from the host application. The tool server validates both the caller and the requested resource before doing any work.
Prompt injection changes intent; it must not change access. If a document tells the model to fetch another tenant's records, the tool should reject the call for the same reason a normal API would.
A boring tool contract is a good contract
I prefer narrow names and typed arguments: getBookingStatus with a booking ID is easier to secure and observe than runQuery with an arbitrary string. The response is structured, bounded, and explicit about partial or stale data.
Errors also need stable categories. Not found, permission denied, invalid input, dependency timeout, and retryable failure lead the model toward different next actions. A prose exception forces it to guess.
Read tools and write tools deserve different treatment. A refund, deployment, message send, or destructive update should expose a preview or confirmation boundary rather than relying on the model to infer when approval is needed.
One tool call in production
Consider a tool that checks an airline booking. The host authenticates the employee, the server verifies that the employee can access the booking's tenant, and the adapter calls the relevant provider with a timeout. The result includes normalized state, provider time, and a correlation ID; sensitive provider payloads stay in protected logs.
If the provider times out, the tool reports uncertainty instead of translating it into booking not found. That distinction prevents an agent from recommending a destructive follow-up based on missing data.
Observe decisions, not private reasoning
For every call I want tool name, authenticated actor, tenant, sanitized arguments, duration, result class, and correlation ID. Secrets and unrestricted record bodies do not belong in the audit log.
Latency compounds when an agent calls several tools. Independent reads can run in parallel, while dependent writes remain ordered. Timeouts and result-size limits keep one slow integration from consuming the whole interaction budget.
The MCP layer is successful when it looks like a well-run API surface: small contracts, explicit authority, predictable errors, and enough evidence to investigate what happened.