Justify MCP with reusable service capabilities

Learning objective

Choose MCP when discoverable, reusable tool and resource contracts justify its transport, authorization, and operational overhead, including maintained versus custom servers and local stdio versus remote Streamable HTTP.

Core idea

For an architect operating shared integrations, MCP earns its place when compatible consumers can reuse a capability contract instead of maintaining separate host adapters. Knowing how to configure a server or attach a resource is the starting point; the Professional decision is whether the resulting shared dependency is worth operating.

Count consumers, required capabilities, and accountable owners before choosing a transport. A server with many tools has little value if the consuming host cannot use the required resource contract or if no team owns its availability. A server with three well-defined operations can be valuable when several applications depend on the same meaning and authorization behavior.

How it works

Price the reusable contract

Describe the shared capability in domain terms, then verify it through the intended hosts. For example, a policy-information server might expose a known catalog as a resource and a parameterized search as a tool. After a server connects, Claude Code sends discovery requests such as tools/list, prompts/list, and resources/list. Reuse is useful only if each host can discover the capability, obtain the necessary context, and interpret failures consistently.

Do not measure this benefit by the number of duplicated schemas alone. Compare the cost of changing a backend field across separate adapters with the cost of releasing and supporting one shared server. Include testing against host versions, credential handling, incident response, and the blast radius of an incompatible change. These are ownership consequences of introducing the server, rather than fixed prices imposed by MCP.

Keep catalog discovery distinct from workflow authorization. A host learning that a tool exists has not established that the caller can execute it. Likewise, a resource contract supplies context; it does not confer authority to act on the information. Detailed catalog-loading strategy belongs in subsection 3.8.

Choose the runtime boundary

The MCP transport specification distinguishes stdio from Streamable HTTP. With stdio, messages travel over the standard streams of a client-launched subprocess. This fits a capability that must run next to a local workspace and whose process lifecycle the host can own. You still need a controlled executable, dependencies, and environment on every machine that launches it.

With Streamable HTTP, each message is an HTTP POST to an MCP endpoint, with a JSON response or request-scoped server-sent event stream. A remote deployment lets multiple consumers reach an operated service. It also creates endpoint availability, network access, authorization, and deployment responsibilities. It does not make the capability stateless at the business level merely because the protocol removes session state.

Claude Code configures remote HTTP through claude mcp add --transport http and local processes through --transport stdio.

Choose local stdio when locality is required and the client can operate the process. Choose remote Streamable HTTP when consumers need a shared network capability and an owner can operate that endpoint. Avoid deploying a remote service solely to replace a function used by one application.

Separate authorization from transport connectivity

MCP authorization is optional. For HTTP transports, implementations supporting authorization should follow the specification’s authorization flow. Stdio implementations should instead retrieve credentials from their environment. Therefore, “it uses HTTP” does not establish that OAuth is configured, and “it runs locally” does not establish that its environment is appropriately scoped.

Use the remote OAuth review in 3.2.4 to assess the caller and backend credentials, then assign an integration owner for credential rotation and incident investigation.

This is a reason to evaluate a maintained server’s security behavior, not merely its tool names. A custom server gives you implementation control while transferring ongoing security and compatibility work to your team.

Check the Claude connection surface

The Claude Messages API MCP connector is a particular host-side feature, not the whole protocol. Its documented beta header is anthropic-beta: mcp-client-2025-11-20. It supports tool calls, requires a publicly exposed server with an HTTPS URL, and cannot directly connect to local stdio servers. It is not covered by zero data retention arrangements.

Include operation of the mcp_toolset allowlist from 3.1.2 and the application-owned authorization_token lifecycle from 3.2.4 in the client’s maintenance budget.

The connector documentation lists beta support for the Claude API, Claude Platform on AWS, and Microsoft Foundry. That list is not a statement of universal MCP availability on every deployment platform. A design requiring resources or local access needs an appropriate client path rather than assuming this connector supplies it.

Key distinctions and trade-offs

Evaluate maintained and custom servers against the same acceptance criteria:

Verify maintenance for the candidate version, then decide whether your team can support its release and host-compatibility obligations.

Architecture / decision scenario

A healthcare network has six internal assistants that need approved policy search and a policy catalog. Its two-person platform team can support one shared service, but cannot maintain six host-specific adapters. Policy updates must become usable within fifteen minutes.

The architect evaluates a maintained remote server against a custom implementation. The maintained server meets the search contract but omits the authoritative policy-version field, and its supported configuration cannot supply it. The team chooses a focused custom server over the existing policy service because accepting unversioned results would violate the freshness requirement. The platform owner accepts maintenance of those narrow operations rather than reproducing the maintained server’s unrelated features.

The chosen deployment uses remote Streamable HTTP because all six hosts need a common network service. Local stdio would distribute process and credential maintenance across the host fleet. The platform owner accepts endpoint operations and tests the required freshness through each host’s actual resource path.

A proposed Messages API connector alone fails acceptance because this workflow requires resources as well as tools. For staff using Claude Code, the team attaches the catalog through an @server:protocol://resource/path resource reference; automated consumers must demonstrate their own supported resource path before admission. The platform owner verifies access decisions and supports those client paths. Security separately reviews retention and credentials before sensitive data is admitted. MCP wins through shared semantics and sustainable ownership, not through the protocol label.

Common exam traps

• Treating successful connection as proof of the required resource support.
• Assuming remote MCP always has OAuth configured.
• Passing a backend token through without checking its intended audience.
• Choosing a custom server without an internal maintainer and release process.
• Choosing stdio without accepting per-host process and environment maintenance.
• Treating the beta Messages API connector as a universal MCP client.

Where the exam guide differs

What to remember

Choose MCP when reusable capabilities save more integration work than the server and client paths cost to operate. Verify maintained candidates before building custom ones, place the process where its consumers need it, and test authorization and host capability separately from connectivity.

Knowledge check

References

• Anthropic, Connect Claude Code to tools via MCP
• Anthropic, MCP connector
• Model Context Protocol, Transports, protocol revision 2026-07-28
• Model Context Protocol, Authorization, protocol revision 2026-07-28
• Model Context Protocol, Security best practices, protocol revision 2026-07-28
• Model Context Protocol, Key Changes, protocol revision 2026-07-28
• Anthropic, Claude Certified Architect – Professional Exam Guide