Reuse integrations and own specialized contracts

Learning objective

Choose maintained community MCP servers for standard integrations and custom servers for team-specific contracts.

Core idea

Start with an existing maintained MCP server when the requirement is a standard integration such as searching issues, retrieving documents, or reading service records. Build a custom server when the required contract is specific to your team’s workflow and cannot be represented faithfully by an existing integration’s operations.

The decision turns on the executable contract, not the service’s brand or the server’s tool count. A community server can expose the standard service correctly yet lack a team-specific approval operation. A custom server can encode that operation clearly yet create unnecessary work if its only purpose is to reproduce a standard search interface.

“Maintained” is a property you must verify for the candidate you plan to deploy. Neither inclusion in an example nor a recognizable server name establishes its maintenance, trustworthiness, permissions, or fitness for your workflow.

How it works

Find a candidate and verify its real interface

Anthropic points readers to reviewed connectors in the Anthropic Directory. The Claude Code MCP documentation says remote servers listed there use the same MCP infrastructure and can be added with claude mcp add.

For a standard issue-tracker requirement, begin with a candidate’s documented endpoint or startup command. Decide whether it is a remote HTTP server or a local stdio process. Claude Code configures a remote HTTP endpoint with claude mcp add --transport http, while a stdio entry specifies command and args for the process to run.

A local process executes on the client machine. A remote endpoint receives requests and returns evidence. Assess the actual implementation and destination before connecting either one. Anthropic explicitly warns that servers fetching external content can expose a workflow to prompt injection. A “read-only” intended use is not proof that all returned text is trustworthy instruction.

Apply the scope and credential choices from 2.4.1 and 2.4.2 after selecting the candidate. Putting an unverified server into project scope distributes its configuration; it does not perform a trust review or turn that integration into an approved dependency.

Compare capability contracts rather than feature labels

Inspect the operations returned by tools/list, including name, description, and inputSchema. Where the tool provides an outputSchema, compare the declared output with the evidence your workflow needs. An integration described as “Jira support” might still lack the particular fields or actions your assignment requires.

Use representative requests to distinguish standard service operations from team-specific contracts. For example, searching an issue by its terms and reading its discussion are standard integration requirements. “Close this incident only after the release owner approves the linked fix and the affected customer cases are reconciled” is a team-specific contract spanning policy and evidence.

The latter does not automatically require rebuilding the whole service integration. You can preserve the standard server for standard reads and create a focused custom operation for the team-specific action. See 2.1.3 for operation granularity and 1.4.2 for deterministic checks before sensitive execution.

If a community tool provides the necessary data but the agent selects it poorly, repair configuration, server instructions, or tool descriptions as appropriate; see 2.4.4. Tool misrouting is different from a missing service capability.

Place specialized behavior in an enforceable operation

A custom MCP server should expose a contract that means something in the team’s domain. Its tool description explains when to call it; inputSchema defines the required inputs; implementation checks establish whether the action is permitted; its result preserves evidence of what happened.

For the incident example, a custom operation could accept an incident_id and obtain authoritative approval evidence before invoking the underlying service action. That field and operation are illustrative team choices, not MCP-defined or Anthropic-provided names. Keep model-supplied identifiers separate from the authoritative state the implementation verifies. The model’s assurance that an approval exists is not the approval check.

MCP annotations can describe tool behavior, but the protocol tells clients to treat annotations as untrusted unless they come from a trusted server. They are not a substitute for the operation’s checks. Likewise, TypeScript allowedTools or Python allowed_tools can pre-approve calls in the Agent SDK but do not establish the business rule’s truth.

A focused custom operation can consolidate a workflow that would otherwise require the model to coordinate many small service calls. Anthropic’s engineering guidance recommends shaping tools around useful tasks, making inputs and outputs explicit, and measuring their behavior with evaluations. Keep that consolidation tied to a real contract; avoid a generic dispatcher whose many unrelated responsibilities obscure selection.

Choose the custom server’s hosting mechanism

Claude Code connects to custom remote HTTP or local stdio servers through the same MCP configuration surfaces as other servers. If you are building an Agent SDK application, you can also create an in-process SDK MCP server. Define tools with TypeScript tool() or Python @tool, then wrap them with TypeScript createSdkMcpServer() or Python create_sdk_mcp_server(). Pass the server through TypeScript mcpServers or Python mcp_servers. That choice attaches the tools to the host application’s process and lifecycle instead of launching a separate server.

The host boundary matters: only an SDK host application can register a "type": "sdk" server. Claude Code skips that entry in .mcp.json or ~/.claude.json and reports that only an SDK host can register it. A custom tool working in an SDK application is not automatically installable in terminal Claude Code by copying that entry into a project file.

For a team that needs both terminal and automated workflows, choose a server mechanism both consumers can use or deliberately provide different host integrations for the same domain contract. Verify the capability through each consumer’s connection status and actual tool calls rather than assuming compatible JSON keys guarantee compatible lifecycle behavior.

Key distinctions and trade-offs

Standard service integration versus team policy: The requirement, not the service, decides:

Discovery versus adoption: A reviewed connector listing helps find a candidate. The chosen version, destination, authentication, tool contract, and observed behavior determine whether it fits your deployment.

Protocol server versus in-process SDK server: HTTP and stdio configurations support separate server connections. type: "sdk" requires an SDK host and is skipped by terminal Claude Code configuration.

Reusing a suitable maintained server avoids duplicating standard behavior. Custom ownership buys control over a specialized contract, but you also own its implementation, documentation, and continued compatibility.

Architecture / decision scenario

A developer productivity team needs issue search for code review and a special incident-close workflow. It evaluates an existing issue integration for searching, reading discussions, and returning source identifiers. Those standard operations satisfy the review use case, so the team retains the existing server rather than recreating them.

The incident-close requirement includes team-specific approval and reconciliation checks. The team exposes one custom action whose implementation obtains that evidence and refuses execution when it is absent. The standard integration remains useful for ordinary reads; its general close operation is not presented as implementing the specialized contract.

The team wants both Claude Code and an automated SDK worker to invoke the custom operation, so it chooses a compatible HTTP or stdio server. If it instead selects an in-process SDK server, it records that terminal Claude Code cannot register it through type: "sdk". Evaluation inspects the selected calls and results for both standard retrieval and the custom rejection path, rather than celebrating that the servers merely connected.

Common exam traps

• Building a custom server solely because the integration is important.
• Assuming every community server with a service name exposes the needed contract.
• Treating Directory inclusion as proof of every deployment requirement.
• Replacing business-rule enforcement with descriptions or permission pre-approval.
• Copying an in-process SDK server configuration into terminal Claude Code.

Where the exam guide differs

What to remember

Reuse a verified maintained integration for standard service capabilities. Own a custom server when the team’s contract requires operations the available integrations do not faithfully provide. Check descriptions, schemas, implementation behavior, trust, and host compatibility before deciding that either option meets the workflow.

Knowledge check

References

• Anthropic, Connect Claude Code to tools via MCP
• Anthropic, Connect to external tools with MCP
• Model Context Protocol, Tools, protocol revision 2026-07-28
• Anthropic, Writing effective tools for agents
• Anthropic, Give Claude custom tools
• Model Context Protocol, Key Changes, protocol revision 2026-07-28
• Anthropic, Claude Certified Architect – Foundations Exam Guide