MCP server for AI: the operator control test

An MCP server for AI should make business access easier to control, not simply give an agent more things it can touch.

The official Model Context Protocol introduction describes MCP as an open standard for connecting AI applications to external systems. The protocol can connect an AI client to files, databases, search tools, calendars, workflows, and other systems. The published MCP specification defines the contract those clients and servers share. That is useful, but it is not the buying decision.

The buying decision is whether the server creates a trustworthy boundary between an AI request and a business consequence.

I learned the broader lesson on a build where source dates arrived in several incompatible formats. I could connect the systems, but I could not safely automate the next action because the workflow could not reliably interpret the record. The connector was not the hard part. The data contract, ownership, and stop condition were.

After building more than 500 production-grade workflows, my opinion is firm: capability without control is not automation an operator can trust.

Start with one operating promise

Do not begin by asking how many tools an MCP server can expose.

Begin with one business promise. For example:

• A service manager can ask for every overdue work order and receive a reconciled answer from the system of record.
• A sales operator can prepare a follow-up from the full customer history without allowing the agent to send it.
• A recruiter can search approved candidate records without exposing compensation or identity fields that are irrelevant to the task.
• A finance manager can assemble an invoice exception packet without granting authority to approve payment.
• An executive can request a weekly operating brief with links back to the underlying records.

One promise forces the business to define the user, source of truth, required fields, allowed actions, expected evidence, exception owner, and completion test.

I use an operations scan to find that first promise before deciding whether MCP is even the right layer. If only one application needs one narrow function, direct function calling may be simpler. My MCP versus REST versus function calling decision frame explains where each interface earns its overhead.

Treat the server as a permission boundary

The official MCP server concepts separate server capabilities into tools, resources, and prompts. Tools can perform actions, resources provide contextual data, and prompts provide reusable interaction patterns.

For an operator, that should translate into four authority lanes:

1. Read. Retrieve only the records and fields required for the promise.
2. Prepare. Summarize evidence, calculate options, or assemble a draft without changing the source.
3. Approve. Present a consequential action to the person or policy that owns the decision.
4. Commit. Write, send, delete, spend, schedule, or change an authoritative record only after the authority rule is satisfied.

These lanes should not share one oversized credential. A read-only reporting agent does not need the same rights as a workflow that creates records. A draft assistant does not need permission to send a message. A search tool does not need access to every field in the database.

My rule is to start with read and prepare. Add commit authority one action at a time, only after the business can identify the actor, preserve the request, confirm the result, and recover from uncertainty.

This is also why a custom MCP server is worth building only in specific conditions. A custom layer earns its cost when private systems, unusual permissions, shared clients, or detailed audit requirements make a generic connector too broad or too weak.

Define record authority before tool schemas

A technically valid tool call can still create a bad business outcome.

Before naming tools, I map the records:

• Which system owns customer identity?
• Which system owns the current deal stage?
• Which record owns approval status?
• Which timestamp proves a message was actually sent?
• Which identifier prevents duplicate creation?
• Which source wins when two systems disagree?
• Which evidence proves the action reached the destination?

Then I design the tool contract around that authority.

A create_customer tool is dangerous if the business cannot say whether the CRM, billing platform, or product database owns the customer. A send_follow_up tool is incomplete if acceptance by an email API is treated as delivery. A close_work_order tool is untrustworthy if it cannot preserve who authorized closure and what evidence was attached.

This is business process architecture for an AI agent, not just an integration exercise. The server should make the operating contract visible in its inputs, outputs, permissions, and errors.

Buy the smallest useful surface

An MCP directory can make a large tool catalog feel like progress. It is usually the opposite.

Every exposed tool expands the test surface. Every write action creates another path for bad identity, missing context, duplicate work, or unclear authority. Every extra resource can expose data the agent does not need.

I would rather ship five narrow tools with clear business meanings than fifty generic endpoints.

A useful first server might expose:

• search_accounts with tenant and field restrictions.
• get_account_history with source links and freshness metadata.
• prepare_follow_up that returns a draft and missing evidence.
• list_open_exceptions with owner and age.
• request_follow_up_approval that records intent but does not send.

Notice what is missing: a generic database query tool, a universal HTTP request tool, and a broad update_record tool. Those abstractions are convenient for builders and difficult for operators to govern.

The same separation appears in my skills, tools, and MCP framework. Judgment belongs in an explicit playbook. Deterministic actions belong in narrow tools. Shared access belongs in MCP when multiple clients need the same contract.

Make identity and evidence first-class outputs

A useful response should preserve enough evidence for a person or downstream workflow to make a decision.

For every material tool call, I want:

• The authenticated user, service, or agent identity.
• The organization or tenant boundary.
• The exact tool and version used.
• The requested action and normalized inputs.
• The source records consulted.
• The permission decision and reason.
• The attempted outcome.
• The confirmed business outcome, if known.
• The exception or reconciliation state, if not known.
• A correlation identifier that connects the request, logs, and destination record.

Do not confuse a successful protocol response with a successful business outcome. A tool can return success while a downstream system delays, rejects, or fails to persist the action. The server needs a way to verify or reconcile what actually happened.

I also want human-readable errors. "Permission denied: invoice approval requires a finance owner" is useful. "Internal server error" is not. The agent needs a safe next move, and the operator needs to know where the process stopped.

Drill the uncertain write

The most important test is not the happy path. It is an uncertain write.

I run this drill before a server receives meaningful production authority:

1. Send a known test request through the intended AI client.
2. Preserve the authenticated identity, inputs, and source evidence.
3. Interrupt the destination after the request leaves the server.
4. Confirm the server does not report a business outcome it cannot prove.
5. Restore the dependency.
6. Reconcile the intended action against the destination record.
7. Replay only if reconciliation proves the action did not happen.
8. Confirm that one record, one message, or one work item exists.
9. Confirm the operator can see the full chain without reading raw infrastructure logs.

Then I repeat the drill with expired credentials, revoked access, a duplicate request, stale source data, an unavailable approver, and a destination that accepts the request but does not create the expected record.

If the team cannot recover one controlled failure, the server is not ready for broader authority.

Keep ownership with the business

The business should own the accounts, code, data, credentials, permission rules, logs, documentation, and deployment path.

That does not mean every operator needs to understand the protocol implementation. It means the business can inspect what the server exposes, revoke access, rotate credentials, export evidence, stop consequential actions, and move the system without waiting on a vendor ticket.

I apply the same operator ownership test to every AI agent. A public repository is not enough. Real ownership includes identity, data boundaries, operational visibility, recovery, and the ability to replace a component without losing the business process.

For teams that need a private, reusable access layer, custom MCP server development should begin with that ownership model. The protocol is the interface. The operating contract is the product.

Use an operator scorecard

I would review an MCP server with a compact scorecard:

• Percentage of calls tied to an authenticated human, service, or agent identity.
• Percentage of tools using the minimum required permission.
• Read, prepare, approve, and commit actions by tool.
• Denied actions and the policy that stopped them.
• Duplicate and uncertain writes.
• Reconciliation success and recovery time.
• Stale, missing, or conflicting source records.
• Exceptions with no named owner.
• Tools unused for 30 days that can be removed.
• Business promises completed, not just tool calls processed.

The last line matters most. Tool volume is activity. A completed operating promise is value.

When not to hire us or build an MCP server for AI

I recommend against hiring us for an MCP build when direct function calling solves one narrow application need, or when the business cannot define record authority and exception ownership.

I would not build one yet when:

• One application needs one narrow tool and direct function calling is enough.
• The business cannot identify its source of truth.
• Nobody owns permissions or exceptions.
• The desired tools are generic shortcuts around existing security controls.
• The team wants write access before proving read and preparation paths.
• There is no way to confirm or reconcile consequential actions.
• A maintained server already covers the use case with acceptable permissions.
• The business cannot operate, inspect, or stop the deployment after handoff.

An MCP server for AI is valuable when it turns shared access into a controlled, reusable business capability. Start with one promise. Expose the smallest useful surface. Separate preparation from authority. Preserve identity and evidence. Prove recovery before expanding.

That is how I judge whether the server belongs in an operating system, or whether it is only another interesting connector.