Controlling MCP Tools in Production
Tool descriptions help an agent choose an operation. Production safety comes from schemas, scopes, approvals, idempotency, and bounded execution.
Publishing an MCP tool turns a business operation into an interface an AI application can invoke. The tool name and description matter, but they are the smallest part of the production contract.
Classify the consequence
Read operations retrieve existing information. Write operations change business state. Financial operations create or move value. Administrative operations change access or policy. Treating these classes as equivalent makes later authorization work unnecessarily difficult.
A safe default is to allow narrow, scoped reads while requiring explicit review for write, financial, and administrative actions. Automation can expand after the operation has real production history and a clear owner.
Validate at both boundaries
Input JSON Schema constrains what the caller may submit. Output schema constrains what downstream clients can rely on. Validation should happen before execution and before returning a result. Free-form payloads move ambiguity into the most consequential part of the system.
Credentials should carry explicit scopes and allowed domains. A credential issued to check inventory should not silently inherit the ability to create orders. Keep authorization independent of whatever text the model placed in the request.
Design for retries and review
Agents, networks, and payment systems retry. Consequential operations need idempotency keys so a timeout does not create a duplicate booking or charge. Webhook executors need strict timeouts, response-size limits, and destination validation.
Approval records should capture the proposed input, tool version, requesting client, decision, decision-maker, and execution outcome. An approval button without that context is ceremony rather than control.
MCP makes tools discoverable and invocable. The surrounding gateway keeps them controllable.