MCP versus ad-hoc Claude tools: pick the contract, not the acronym

Model Context Protocol (MCP) is a standard way to expose tools and data to Claude. It is not, by itself, a production integration. The work that matters is the contract: which actions exist, who can call them, and what happens when they fail.

Teams stall when they treat MCP as a wrapper around an internal API. Claude then sees fifty overlapping endpoints, weak error messages and write paths with no review. That is how you get retries, missing fields and silent wrong updates. See why most Claude pilots never reach production.

What MCP is for

Use MCP when several clients need the same tools (Claude Desktop, Claude Code, an internal agent) and you want one permissioned server instead of three one-off schemas.

Skip a custom MCP server when a single application owns the loop and a tight tool schema in your own process is simpler to test. Protocol is optional. A good tool contract is not.

A production MCP server has four properties

1. Narrow actions. "Create a Jira ticket with these fields" beats "call Jira."
2. Explicit required fields. Claude should fail closed, not guess.
3. Human-readable errors. "Project KEY not found" is usable. A raw 500 is not.
4. A hard mutate boundary. Reads can be wide. Writes need allow-lists, audit logs and often a human checkpoint. That pairs with human-in-the-loop Claude agents.

How this shows up in an audit

We look at traces first. If the model is retrying the same tool with slightly different JSON, the schema is the bug. If it is calling a god-tool that can update any record, the permission model is the bug. MCP versus "plain tools" is rarely the deciding line.

If you are connecting Claude to Salesforce, SAP, Snowflake or an internal API, start from the tool schema design note, then decide whether MCP is the right transport. The MCP and Tool Integration engagement is the scoped version of that work.