An MCP connection is useful. A dependable business action needs a contract.

Publish business actions, not interface gestures

A tool named “click_button” or “navigate_screen” transfers interface complexity to the agent and exposes more freedom than the workflow requires. A business tool should describe the permitted outcome: retrieve a record, update approved attributes, create a transaction, or request a controlled status change.

The action name and description should make scope obvious. Input fields should use business identifiers and types rather than coordinates or presentation labels where possible. If the agent needs detailed screen knowledge to call the tool correctly, the contract has not fully separated the capability from its interface implementation.

Make the schema enforceable

• Require identifiers and values that determine the effect; do not rely on details hidden in conversational context.
• Constrain enumerations, formats, ranges, and optional fields according to the actual workflow.
• Reject unknown or ambiguous fields rather than guessing the caller’s intent.
• Carry a request or idempotency reference when replay could create a duplicate effect.
• Represent approval evidence or policy context explicitly when the operation requires it.
• Version meaningfully changed schemas and semantics instead of silently changing the behavior behind an existing tool.

Put authorization behind the tool boundary

Tool discovery is not permission to execute every operation. The server-side capability should authenticate the caller, authorize the action, and enforce record, field, value, role, or approval constraints before it reaches the application. Do not depend on a system prompt to preserve least privilege.

The identity used inside the legacy application also needs deliberate treatment. A shared session can obscure accountability; a broad role can make a narrow tool more powerful than its schema suggests. The action log should relate the requester, policy decision, application identity, inputs, outcome, and evidence at a level appropriate to the organization’s data rules.

Return errors an agent can handle safely

“Tool failed” is too vague for orchestration. Separate invalid input, missing record, conflicting state, policy denial, approval required, application unavailable, authentication expired, interface drift, and uncertain completion. Each category implies a different next step.

Retry guidance must reflect the business effect. A read may be safe to retry; a create operation may not be. When an application stops responding after submission, the tool should reconcile the source state before allowing another attempt. If reconciliation is impossible, return uncertainty and route to an operator.

Evidence belongs in the result

A successful response should contain facts that support the claimed business outcome, not merely a narrative that the interface sequence completed. Depending on the action, that can include a record key, the authoritative status, selected field read-backs, or a reference to an audit artifact.

Keep the result useful without overexposing data. Return only what the calling workflow needs, and protect logs, screenshots, and diagnostic traces according to their sensitivity. Evidence design is both a reliability decision and a data-minimization decision.

Test the contract against the supported environment

Conformance tests should cover the tool schema, policy decisions, application preconditions, successful effects, denied requests, duplicates, interrupted execution, and changed interface assumptions. Tie results to the application version, configuration, role, locale, and delivery environment actually tested.

Protocol compatibility is only one layer. A client may call the tool correctly while the underlying application workflow has drifted. Monitor and retest the end-to-end business action, especially before resuming writes after a relevant software change.

A tool review for buyers and platform teams

• Can a reviewer state exactly what business effect the tool can create?
• Are the schema and server-side checks sufficient without trusting prompt behavior?
• Does the permission granted in the source application exceed the tool’s advertised scope?
• Are failures structured enough to prevent unsafe retries?
• Does success include source-system evidence?
• Are version changes, conformance results, access reviews, and operational ownership visible?

Frequently asked questions

Does MCP make a legacy application reliable for agents?

No. MCP can standardize how a tool is exposed and called. Reliability still depends on the workflow adapter, controls, error semantics, verification, testing, and operation behind that tool.

Should one tool expose many application operations?

Prefer narrow operations with clear permissions and effects. A broad “use application” capability is harder to authorize, test, observe, and reason about safely.

Should screenshots be returned as proof?

A screenshot may support diagnosis, but it is not automatically authoritative business evidence. Prefer a source-system identifier, read-back, status, or other fact tied to the effect, and handle visual artifacts as sensitive data.

How should a tool handle interface drift?

It should stop when expected state cannot be established, identify the affected version or environment, and require relevant conformance tests before writes resume.

Can the same MCP tool serve several agent frameworks?

A stable protocol and business schema can reduce framework-specific integration work. Each caller still needs compatible authentication, authorization, result handling, and operational approval.