MCP servers in production: authorization, retries and testing

A production MCP server needs a small, explicit tool contract, authorization outside the model, safe retry behavior and tests against its intended clients. Protocol compatibility alone does not establish a secure integration.

What does MCP standardize?

MCP defines a protocol through which clients discover and use capabilities such as tools and resources. Choose and test an explicit protocol version. A server must still implement its upstream integrations, access rules and operational behavior.

How should authorization work?

Validate that incoming access tokens are intended for the MCP server. Do not forward a client token unchanged to a downstream API. The MCP security guidance explains token passthrough and confused-deputy risks.

Choose delegated user credentials or service credentials according to the upstream API and permission model. A shared service account is not a universal solution. Enforce tenant and user authorization on every operation, including resource reads.

What should happen when a write is retried?

Use an idempotency mechanism at the system that owns the mutation. Persist enough state to distinguish a retry from a new action. If a timeout leaves the outcome uncertain, expose a status lookup instead of blindly repeating the write.

Three illustrative connector tests

• CRM: a user cannot read or update another tenant’s record.
• Document search: retrieval respects document permissions before returning passages.
• Scheduling: a repeated booking request creates at most one booking.

These are test scenarios, not claims about Oviompt client deployments.

What to test before release

Test malformed arguments, revoked credentials, duplicate requests, upstream timeouts, rate limits and tool output containing hostile instructions. Keep secrets out of logs, record attributable actions and verify client behavior for asynchronous work. The appropriate tool count and timeout depend on the workflow; there is no universal three-to-seven-tool rule.

Published by Oviompt, a software product studio. This is editorial guidance; examples are illustrative unless evidence is identified. Editorial standards and corrections.