MCP server design for business systems is an authority-design problem before it is a protocol-integration problem. The Model Context Protocol can let an AI host discover tools, resources, and prompts, but the existence of a tool does not make a proposed action appropriate. A production server must translate a user’s intent into a narrowly defined business operation, authenticate the actor, enforce tenant and record scope, validate current state, and return a result that can be reconciled. This guide focuses on those server-side obligations because model instructions and client interfaces cannot carry them safely on their own.
The design fits naturally with Edilec’s MCP architecture guide, agent tool-permissions guide, and AI agent workflow architecture. Read them together when deciding where protocol responsibility ends and business authority begins.
Start with an authority boundary
For each proposed tool, name the business outcome, user role, target system, input fields, side effects, data classification, and recovery path. Prefer task-shaped capabilities such as create_draft_case or lookup_permitted_order_status over a general database query or an unrestricted update endpoint. A narrow tool is easier to authorize, test, explain, and retire. It also gives the user interface a chance to show what will happen before work is committed. The server should treat model-produced parameters as untrusted input, even if a human asked for the task in ordinary language.
| Capability | Safer boundary | Evidence retained |
|---|---|---|
| Read a record | Scope to the requesting user and named record type. | Subject, permission decision, query, and result class. |
| Create a draft | Store as non-final with an owner and expiry. | Input source, generated fields, and reviewer changes. |
| Execute a change | Require policy checks and approval where needed. | Intent, approver, before and after state, and correlation ID. |
| Export data | Limit fields, recipient, volume, and time window. | Purpose, authorization, delivery, and revocation record. |
Carry real identity and context to the server
Do not rely on a model name, an API key shared by a whole product, or a text instruction as the authorization context. The server needs an authenticated principal, tenant or organization boundary, scopes, session or request context, and the policy version applied. It should validate token audience and expiry, derive permissions from the system of record, and avoid forwarding a powerful credential to downstream services when a narrower delegated token is possible. The protocol’s guidance on least-privilege scopes is useful, but a scope alone is not enough when a business rule depends on account status, time, amount, or separation of duties.
Validate inputs and constrain side effects
Define a schema for each argument, reject unexpected fields, constrain identifiers to the caller’s accessible scope, and make idempotency explicit for actions that may retry. Translate human language into a draft or structured preview before issuing an irreversible command. For financial, personnel, security, or customer-impacting changes, use confirmation that states the target and material effect in plain language. The OWASP Top 10 for LLM applications is relevant because indirect instructions can arrive through retrieved content, tools, or documents; server-side validation must remain effective even when an upstream prompt is manipulated.
| Control | Failure it addresses | Test case |
|---|---|---|
| Schema and allowlist | Invented or malformed parameters. | Model supplies an unrecognized field or identifier. |
| Policy decision point | Action outside role, amount, or time limits. | User requests a valid operation for an unauthorized account. |
| Idempotency key | Duplicate action after timeout or retry. | Same approved request is delivered twice. |
| Confirmation or approval | High-impact action based on ambiguous intent. | User changes target after preview but before execution. |
Make every material action reviewable
An audit event should join the user request, client, tool version, authorization decision, validated arguments or safe digest, downstream result, and final business record. Avoid treating full prompt logging as an audit strategy; it can create needless privacy exposure while still missing the actual state change. Provide operators with a way to find failed calls, policy denials, retries, and incomplete compensating actions. The NIST Secure Software Development Framework supports bringing secure-development practices into the lifecycle, including change review and response planning for the server and its dependencies.
- Expose task-shaped tools with a clear owner and a stated side effect.
- Authenticate the actual user or service and enforce the current business policy at execution.
- Treat all model-originated arguments as untrusted input.
- Preview or approve actions that can materially change a record or obligation.
- Join tool events to the resulting business record so investigations are possible.
Release tools as operational products
Finally, keep a current inventory of production endpoints, owners, scopes, dependencies, and approved clients. This inventory makes security review, customer support, and retirement work faster because the team can see what must change together. It also reveals when an experimental integration has become business-critical and needs stronger reliability and ownership than it received at its first release.
Before enabling a new client, verify that its product surface presents the same boundaries the server enforces. A clear confirmation, denied-state explanation, and link to the resulting business record reduce accidental misuse. The protocol connection may be technically correct while the surrounding experience still encourages a user to mistake a draft for a completed transaction. Review these human-facing details as part of integration acceptance, especially for tools that can communicate externally or alter shared records.
Document the human support route for every production tool. A sales or operations colleague should know whether they can retry, correct a field, wait for reconciliation, or contact a named owner when a request does not finish. Give support an authorized diagnostic view that reveals status and correlation identifiers without granting broad administrative access. This reduces pressure to bypass controls during a customer interaction and produces cleaner incident reports. It also turns tool failures into product feedback that can improve the contract, error wording, and recovery automation.
Treat tool descriptions and examples as part of the control surface. A vague description can encourage a client to use a capability for a purpose the business never intended, while an example that contains a real identifier or privileged shortcut can spread unsafe habits. Document the preconditions, expected errors, returned state, and whether a result is final or merely queued. Keep examples synthetic and test them against the authorization layer. A client should receive enough structured information to recover from a denial or partial result without being encouraged to retry blindly or probe for protected details.
Operational ownership includes capacity and dependency planning. Decide how many concurrent calls a tool can handle, which downstream systems impose rate limits, how timeouts are surfaced, and when a circuit breaker should stop an agent from adding load to a failing service. Monitor policy checks and business outcomes as well as HTTP status codes. A technically successful call that creates an invalid draft, or a denied call that leaves work stranded, is still an operational defect. This view helps teams prioritize reliability work that protects users rather than merely improving a service dashboard.
Version tool contracts, deprecate capabilities deliberately, and test client behavior against denied, delayed, partial, and duplicate outcomes. A new optional parameter can become a security problem if an old client silently interprets it differently. Stage changes with a limited audience, monitor policy denials and unexpected arguments, and keep a fast disable switch for a compromised or faulty integration. Review whether a tool remains necessary; unused tools increase discovery, maintenance, and authorization surface without improving the workflow.
Separate the protocol contract from the business contract
The MCP architecture documentation separates host, client, and server responsibilities. Use that separation deliberately. Protocol schemas describe how a capability is discovered and called; the business contract defines who may use it, against which records, in what state, with which side effects, and how failure is corrected. The tools specification also treats tool annotations as hints rather than a security boundary. A server should independently determine whether a read is sensitive, whether an action is destructive, and whether confirmation remains valid for the exact arguments received.
| Boundary | Server must verify | Unsafe shortcut |
|---|---|---|
| Identity | Authenticated user or workload and tenant | Trusting a name in the prompt |
| Audience | Token was issued for this resource server | Accepting a token meant for another API |
| Record scope | Actor can access the specific object now | Using a broad shared integration account |
| State | Version and prerequisites still match | Executing from stale conversational context |
| Effect | Allowed transition, idempotency, reconciliation | Assuming a successful HTTP response is enough |
Design authorization for delegated action
For remote HTTP servers, follow the current MCP authorization specification. It requires resource indicators and audience validation, forbids token passthrough, and builds on OAuth security practices including PKCE for authorization-code flows. Keep user delegation distinct from service credentials. A server-to-server job may use its own workload identity, but it must not silently impersonate a person. Scopes should describe coarse capability while application policy decides tenant, field, object, amount, and state boundaries.
Threat-model the connected system, not only the MCP endpoint
The official MCP security best-practices guide covers confused-deputy risks, token handling, scope minimization, and related attacks. Extend that model through every downstream dependency. A harmless-looking search tool can aggregate confidential records; a draft tool can trigger an email or workflow; a retry can duplicate an order. Test prompt injection, malicious tool metadata, cross-tenant identifiers, expired consent, state changes between confirmation and execution, oversized result sets, partial downstream completion, and replay. The server should fail closed while returning enough structured detail for a legitimate client to guide recovery.
Key takeaways
- MCP servers should expose bounded business capabilities, not ambient system access.
- Transport authorization must be joined to current application-level policy.
- Validation, idempotency, and review are server responsibilities, not prompt instructions.
- Audit records should explain the real business effect without retaining unnecessary data.
- Versioning and a disable path keep integrations manageable as clients evolve.
Frequently asked questions
Are read-only tools harmless?
No. A read-only tool may reveal confidential records, enable inference across many small results, or expose data to an untrusted context. Apply user, tenant, field, volume, and purpose boundaries to reads just as carefully as to writes, and ensure retrieved results cannot be reused beyond the authorized task.
Can an agent approve its own tool action?
For low-impact, preauthorized actions, a policy may allow automatic execution after server-side validation. For material actions, the same system should not both generate the request and supply the independent approval. Use a person, a separate rule, or a system-of-record condition that is not controlled by the conversational context.
Conclusion
A trustworthy MCP server exposes less authority than its underlying systems, not more. Shape tools around bounded business tasks, carry real identity, enforce current policy and state, and make every material effect reviewable and recoverable. The protocol enables interoperability; disciplined server design makes that interoperability safe enough for business use.