What's the best way to connect Claude to internal APIs?

The best default answer is: use MCP, with a thin internal “tool gateway” in front of your APIs. Anthropic’s recommended integration path for Claude is the Model Context Protocol (MCP), which Claude supports across Claude, Claude Desktop, Claude Code, and the Messages API. Anthropic specifically documents using the MCP connector in the Messages API to connect Claude to MCP servers. (docs.anthropic.com)

In practice, the strongest pattern is:

1. Do not expose raw internal APIs directly to Claude.
2. Wrap them in an MCP server you control.
3. Offer a small set of task-oriented tools rather than many low-level endpoints.
4. Put auth, authorization, logging, rate limits, and policy checks in that MCP layer. Anthropic’s docs on custom connectors emphasize that remote MCP servers can access and take action in external services, and recommend enabling only trusted connectors and only the specific tools needed. (support.anthropic.com)

Best architecture

Claude ↔ MCP server ↔ internal service gateway ↔ internal APIs

Why this is usually best:

• MCP is the native interface Anthropic is pushing for tool/data connectivity. (docs.anthropic.com)
• A gateway lets you normalize ugly internal APIs into clean tools Claude can reliably use.
• You can hide implementation details, enforce least privilege, and swap backend services later without changing the Claude-facing contract.
• Anthropic’s tool-design guidance favors clear, narrow, unambiguous tool descriptions, which maps better to curated actions than raw REST exposure. (support.anthropic.com)

How I’d design it

Build tools around user intents, for example:

• get_customer_summary(customer_id)
• search_incidents(service, severity, since)
• create_jira_ticket(title, description, priority)
• deploy_service(service, environment, version)
  instead of generic:
• GET /customers/:id
• POST /v2/query
• PATCH /tickets/:id

That approach tends to work better because Claude performs best with tools that have clear purpose, bounded scope, and predictable outputs. Anthropic’s guidance explicitly says tool descriptions should be narrow and unambiguous. (support.anthropic.com)

Security recommendations

If these are truly internal APIs, I’d strongly recommend:

• Short-lived user-scoped credentials from your MCP server to backend services
• Per-tool authorization checks
• Allowlisted actions only
• Human confirmation for destructive operations
• Structured audit logs for every tool call
• Redaction/minimization before sending sensitive fields back to Claude
• Environment separation between read-only and write tools

Anthropic warns that connectors can take action in connected services and that remote tools can change behavior over time, so trust boundaries and admin controls matter. (support.anthropic.com)

Remote vs local

If this is for a team or production workflow, prefer a remote MCP server over a local desktop-only integration. Anthropic documents remote MCP as the way to host connectors over the internet and use them across Claude surfaces; local MCP is better for single-user desktop workflows. (support.anthropic.com)

If you’re using the API, not claude.ai

Use the Messages API + MCP connector path, and keep your MCP server as the abstraction layer. Anthropic’s MCP docs explicitly mention MCP support in the Messages API. (docs.anthropic.com)

Practical rule of thumb

• Few internal systems, controlled environment, read-mostly: one MCP server is enough.
• Many internal systems: build a tool gateway MCP server that federates multiple backends.
• Sensitive or high-risk actions: split into read MCP and write MCP servers, with stricter approval on write tools.

My recommendation in one sentence

Best way: build a remote MCP server that exposes a small, curated, task-oriented set of tools backed by your internal APIs, with strong authz, logging, and approval controls. (support.anthropic.com)

If you want, I can sketch:

1. a reference architecture,
2. a sample MCP tool schema, or
3. a Node/Python starter for wrapping an internal REST API.