← All articles

How to Connect Claude to Any API with MCP: Complete Guide

July 1, 2026·32 min read·MCPForge

How to Connect Claude to Any API with MCP: Complete Guide

Connecting Claude to an external API is much easier today than it was just a year ago.

Before the Model Context Protocol (MCP), every AI application required its own custom integration. If you wanted Claude to interact with GitHub, Slack, Stripe, your CRM, or an internal company API, you had to define tool schemas manually, implement function calling, maintain authentication, and repeat the process for every AI client.

MCP changes that completely.

Instead of building custom integrations for every model, you expose your API once through an MCP server. Any compatible AI client—including Claude Code, Claude Desktop, Cursor, and the Claude API MCP Connector—can automatically discover and use your API through the same standardized protocol.

This guide walks through the complete process of connecting any REST API to Claude using MCP.

By the end you'll understand:

  • when you need MCP
  • how the architecture works
  • how to expose an existing API
  • how to generate an MCP server automatically
  • how to build one yourself
  • how to connect Claude
  • how to test everything
  • how to deploy it securely in production

Want to analyze your API security?

Import your OpenAPI spec and generate a Security Report automatically.

This is the same workflow used whether you're exposing:

  • GitHub
  • Slack
  • Stripe
  • Xero
  • HubSpot
  • Jira
  • Notion
  • an internal company API
  • or your own SaaS platform.

What You'll Build

By the end of this guide you'll have:

✅ Claude connected to your API

✅ an MCP Server exposing your API

✅ authentication configured

✅ production-ready architecture

✅ tested integration

✅ deployment checklist

The workflow works equally well for:

  • GitHub
  • Slack
  • Stripe
  • HubSpot
  • Xero
  • Internal APIs
  • Custom SaaS products

The Big Picture

text
REST API

↓

OpenAPI

↓

MCP Server

↓

Claude

↓

User

Before diving into implementation, it's important to understand the overall architecture.

Many developers initially assume Claude connects directly to their API.

It doesn't.

Instead, Claude communicates with an MCP server, and the MCP server becomes the secure bridge between Claude and your backend services.


```text
                    User
                      │
                      ▼
                  Claude
                      │
              Model Context Protocol
                      │
                      ▼
                MCP Server
                      │
        Authentication & Validation
                      │
                      ▼
              Your Existing API
                      │
                      ▼
        Database / SaaS / Internal System

The MCP server has four primary responsibilities:

  1. expose Tools, Resources and Prompts
  2. authenticate requests
  3. call your existing API
  4. return structured responses to Claude

Claude never needs to understand your API directly.

Instead, it discovers available capabilities automatically using the Model Context Protocol.


When Should You Use MCP?

Not every API integration requires MCP.

A useful rule is:

One AI application → Tool Calling may be enough.

Multiple AI clients → Use MCP.

For example:

✅ Internal CRM used by Claude Code

✅ Cursor

✅ Claude Desktop

✅ Claude API

Build once with MCP.

Every client can reuse the same integration.

Without MCP you'd maintain four different integrations.

That's exactly the problem MCP was designed to solve.


Step 1 — Decide Which Type of API You Have

Almost every project falls into one of three categories.

Option A — Public REST API

Examples:

  • GitHub
  • Slack
  • Stripe
  • Xero
  • HubSpot
  • Jira

These are usually the easiest.

Most already expose OpenAPI documentation.


Option B — Internal Company API

Examples:

  • ERP
  • CRM
  • HR systems
  • warehouse software
  • inventory systems

Usually protected behind authentication.

Excellent MCP candidates.


Option C — Custom Backend

Your own:

  • Next.js backend

  • Express API

  • FastAPI

  • NestJS

  • Go

  • .NET

If it exposes HTTP endpoints, you can wrap it with MCP.


Step 2 — Choose the Right Approach

There are three approaches.

Option 1 — An MCP Server Already Exists ⭐

This is the easiest option.

Search whether someone has already built one.

Examples include:

  • GitHub MCP
  • Slack MCP
  • Xero MCP
  • Linear MCP
  • Google Drive MCP

Simply configure authentication and connect Claude.

No custom development required.


Option 2 — Generate an MCP Server from OpenAPI ⭐⭐⭐

If your API already has an OpenAPI specification, you can generate an MCP server automatically.

This is usually the fastest approach.

Typical workflow:


OpenAPI Specification

↓

OpenAPI → MCP Generator

↓

Generated MCP Server

↓

Claude

This eliminates hundreds of lines of repetitive code while keeping the API definition as the single source of truth.

If you're starting with OpenAPI, see:

OpenAPI to MCP: Complete Guide


Option 3 — Build Your Own MCP Server ⭐⭐⭐⭐

If your API is proprietary or requires custom business logic, build an MCP server yourself.

You'll define:

  • Tools

  • Resources

  • Prompts

  • authentication

  • API client

  • response mapping

  • error handling

Although this requires more work, it gives you complete control over the integration.


Step 3 — Generate or Build Your MCP Server

Once you've decided how you want to expose your API, the next step is creating the MCP server itself.

There are two common approaches.


Generate from OpenAPI

If your API already provides an OpenAPI specification, this is usually the fastest and easiest option.

Instead of manually writing MCP Tools, you can generate a working MCP server directly from the API specification.

The workflow looks like this:

text
Existing REST API
        │
        ▼
 OpenAPI Specification
        │
        ▼
 OpenAPI → MCP Generator
        │
        ▼
 Generated MCP Server
        │
        ▼
 Claude

This approach has several advantages:

  • significantly less manual development
  • consistent Tool definitions
  • automatic parameter validation
  • one source of truth for your API
  • faster maintenance as the API evolves

If you're starting with an OpenAPI specification, see our complete guide:

OpenAPI to MCP: Complete Guide


Build a Custom MCP Server

Sometimes automatic generation isn't enough.

Examples include:

  • proprietary authentication
  • complex business rules
  • multiple APIs combined into one interface
  • legacy systems
  • custom workflows

In those situations, you'll build an MCP server manually.

A typical project structure looks like this:

text
src/
 ├── server.ts
 ├── tools/
 ├── resources/
 ├── prompts/
 ├── auth/
 ├── services/
 ├── clients/
 ├── config/
 └── utils/

Each Tool becomes a thin layer that validates the request, calls your existing API, and returns structured results back to Claude.

Keeping business logic inside your existing API rather than inside MCP makes long-term maintenance much easier.


Step 4 — Connect Your API

Now it's time to connect your backend.

The MCP server does not replace your API.

Instead, it acts as a lightweight adapter between Claude and the existing application.

A typical request flow looks like this:

text
User
 │
 ▼
Claude
 │
 ▼
MCP Tool
 │
 ▼
Authentication
 │
 ▼
REST API
 │
 ▼
Business Logic
 │
 ▼
Database

This architecture keeps responsibilities separated:

Claude decides what to do.

The MCP server validates how to call the API.

Your backend decides whether the operation is allowed.

This separation improves maintainability and reduces the amount of AI-specific code inside your production systems.


Step 5 — Configure Authentication

Authentication is often the biggest difference between a proof of concept and a production deployment.

Choose an authentication strategy that matches your API.

Common options include:

  • API Keys
  • OAuth 2.0
  • Bearer Tokens
  • JWT
  • Session Cookies
  • mTLS (enterprise environments)

Never expose credentials directly to Claude.

Instead:

  • store secrets securely
  • authenticate inside the MCP server
  • inject credentials when calling the API
  • validate every request
  • return sanitized responses

Think of the MCP server as a secure gateway—not simply a proxy.


Step 6 — Expose Useful Tools

A common mistake is exposing every API endpoint.

More Tools does not automatically create a better AI experience.

Instead, expose high-value operations.

For example, instead of:

GET /users/123
PATCH /users/123
POST /users
DELETE /users

Expose Tools like:

  • Find Customer
  • Create Customer
  • Update Customer
  • Suspend Customer

These Tools are easier for Claude to understand because they represent business actions rather than raw HTTP endpoints.

Well-designed Tool descriptions also improve tool selection accuracy and reduce hallucinated tool calls.


Step 7 — Connect Claude

After your MCP server is running, connecting Claude becomes straightforward.

Depending on your workflow, you can connect:

Claude Code

Ideal for:

  • software development
  • DevOps
  • engineering workflows
  • local development

Claude Code automatically discovers available MCP Tools after the server is configured.


Claude Desktop

Useful for:

  • personal assistants
  • internal tools
  • document workflows
  • knowledge assistants

Configuration is typically done through the MCP server configuration file.


Claude API (MCP Connector)

If you're building your own AI application on top of the Claude API, Anthropic's MCP Connector allows your application to communicate with external MCP servers without implementing vendor-specific integrations.

This enables a single MCP server to be reused across multiple AI experiences.


Step 8 — Test Everything

Never connect Claude directly to an untested MCP server.

Before using it in production, validate:

  • authentication
  • initialization
  • tools/list
  • resources/list
  • prompts/list
  • Tool execution
  • error handling
  • latency
  • JSON-RPC responses

A recommended testing workflow is:

text
Start MCP Server
        │
        ▼
Run MCP Inspector
        │
        ▼
Discover Tools
        │
        ▼
Execute Test Calls
        │
        ▼
Validate Responses
        │
        ▼
Connect Claude

Testing independently makes debugging much easier because you can separate protocol issues from client configuration problems.

For a detailed walkthrough, see:

MCP Inspector: Complete Guide

Test a Local MCP Server

Test MCP Server Online


Step 9 — Deploy Your MCP Server

Once everything works locally, it's time to deploy the MCP server.

The deployment strategy depends on your infrastructure, but the overall architecture remains the same.

text
Claude
      │
      ▼
 HTTPS
      │
      ▼
Production MCP Server
      │
      ▼
Authentication Layer
      │
      ▼
REST API
      │
      ▼
Database / SaaS

The MCP server should remain as lightweight as possible.

Avoid moving business logic into the MCP layer.

Instead:

  • keep validation inside the API
  • keep authorization inside the API
  • keep business rules inside the API
  • let the MCP server focus on exposing Tools, Resources, and Prompts

This makes upgrades much easier while reducing the risk of inconsistent behavior across applications.


Step 10 — Production Best Practices

A proof of concept is easy.

A production-ready MCP server requires additional engineering.

Below are the practices followed by most successful deployments.


Use HTTPS Everywhere

Never expose an MCP server over unsecured HTTP.

Always terminate TLS before traffic reaches the server.

For internet-facing deployments:

  • HTTPS only
  • valid certificates
  • HSTS where appropriate

Protecting transport security is the first layer of defense.


Keep Authentication Inside the MCP Server

Claude should never receive permanent API credentials.

Instead:

  • authenticate users
  • store secrets securely
  • inject credentials when calling the API
  • rotate credentials regularly

The MCP server becomes the trusted execution layer between Claude and the backend.


Design Small, Focused Tools

Large Tools that perform many unrelated actions are difficult for AI models to understand.

Prefer:

✅ Create Invoice

✅ Get Customer

✅ Search Orders

Instead of:

❌ ERP Tool

Well-scoped Tools improve reliability, reduce ambiguity, and help Claude choose the correct action. The MCP specification emphasizes clear tool definitions and schemas because models rely on those descriptions when selecting and invoking tools.


Return Structured Responses

Avoid returning large blocks of formatted text.

Instead, return structured JSON whenever possible.

Good:

json
{
  "customerId": 123,
  "name": "John Smith",
  "status": "Active"
}

Less helpful:

Customer John Smith is active.

Structured data gives Claude more flexibility when reasoning, summarizing, or combining results with other tools.


Keep Business Logic Outside MCP

One of the biggest architectural mistakes is treating the MCP server as a second backend.

Instead:

Claude

↓

MCP

↓

Existing API

↓

Business Logic

↓

Database

The MCP server should orchestrate requests—not duplicate your application's domain logic.


Log Everything

Production deployments should include structured logging.

Capture:

  • incoming tool requests
  • execution time
  • API latency
  • authentication failures
  • validation errors
  • external API failures

Structured logs make debugging dramatically easier when multiple AI clients share the same MCP server.


Monitor Health

Every production deployment should expose health information.

Monitor:

  • uptime
  • latency
  • error rate
  • authentication failures
  • API availability
  • dependency failures

Health monitoring often detects infrastructure issues long before users notice them.


Common Mistakes

After reviewing dozens of production MCP implementations, the same mistakes appear repeatedly.


Exposing Every API Endpoint

An API with 250 endpoints does not require 250 MCP Tools.

Expose only the capabilities Claude actually needs.

Quality is more important than quantity.


Skipping Authentication

Some developers rely solely on network security.

Instead:

  • authenticate every request
  • validate authorization
  • verify permissions
  • reject unauthorized calls

Never assume internal networks are automatically trusted.


Poor Tool Descriptions

Tool descriptions are part of the interface that AI models use to decide which Tool to call.

Descriptions should explain:

  • purpose
  • inputs
  • outputs
  • limitations
  • expected behavior

Research has shown that clearer tool descriptions improve tool selection and overall agent performance, although overly verbose descriptions can increase token usage.


Mixing Business Logic Into MCP

Keep the MCP layer thin.

If business rules change, you should only update the existing API—not every AI integration.


No Testing

Never deploy without validating:

  • initialize
  • tools/list
  • resources/list
  • prompts/list
  • Tool execution
  • authentication
  • error handling

Testing before deployment prevents most production incidents.


Architecture Checklist

Before connecting Claude, verify:

✅ HTTPS enabled

✅ Authentication configured

✅ Secrets stored securely

✅ Tools documented

✅ Resources exposed where appropriate

✅ Prompts available where useful

✅ Tool descriptions reviewed

✅ Health endpoint available

✅ Rate limiting configured

✅ Monitoring enabled

✅ Production testing completed

✅ Structured logging enabled

✅ Timeouts configured

✅ Retries implemented


Final Thoughts

Connecting Claude to an API no longer requires building custom integrations for every AI application.

By placing an MCP server between Claude and your existing backend, you create a reusable integration layer that any MCP-compatible client can use. Instead of maintaining separate integrations for each AI tool, you expose your capabilities once through the Model Context Protocol and reuse them across development environments, desktop applications, and API-based workflows.

Whether you're integrating GitHub, Slack, Stripe, HubSpot, an internal CRM, or your own SaaS platform, the overall workflow remains the same:

  1. Understand your API.
  2. Choose the right MCP strategy.
  3. Build or generate the MCP server.
  4. Connect Claude.
  5. Test thoroughly.
  6. Deploy securely.
  7. Monitor continuously.

Following these steps results in integrations that are easier to maintain, more portable across AI clients, and significantly simpler to scale as your ecosystem grows.


Official References

This guide is based on the official Anthropic documentation, the Model Context Protocol specification, and related engineering resources.



Ready to Connect Your API?

Whether you're exposing a public SaaS platform, an internal business system, or your own application, the same production principles apply:

  • Build once.
  • Expose a clean MCP interface.
  • Test thoroughly.
  • Secure authentication.
  • Monitor continuously.

If you've already built an MCP server, verify it before deploying to production with Verify Any MCP Server, or explore the Production MCP Server Templates in the MCPForge Code Hub to accelerate your next integration.

Frequently Asked Questions

Can Claude connect to any API?

Yes. Claude can interact with virtually any REST, GraphQL, or custom API by using the Model Context Protocol (MCP). Instead of integrating each API directly into every AI client, developers expose the API through an MCP server that Claude can discover and use.

Do I need to build an MCP server myself?

Not necessarily. If an official or community MCP server already exists, you can use it directly. Otherwise, you can generate one from an OpenAPI specification or build a custom MCP server for proprietary APIs.

What APIs can Claude access through MCP?

Claude can work with business APIs, SaaS platforms, internal company services, databases, developer tools, CRM systems, accounting software, cloud platforms, and virtually any API that can be exposed through an MCP server.

Can I connect Claude to my own internal API?

Yes. Many organizations use MCP to expose private APIs securely without modifying Claude itself. The MCP server becomes the secure bridge between Claude and your internal infrastructure.

Do I need OpenAPI?

No. OpenAPI is recommended because it enables automatic MCP server generation, but it is not required. Custom MCP servers can wrap any existing API regardless of whether an OpenAPI specification exists.

Does Claude call my API directly?

No. Claude communicates with an MCP server. The MCP server authenticates requests, calls your API, validates responses, and returns structured data back to Claude through the Model Context Protocol.

Which Claude products support MCP?

MCP is supported across Claude Desktop, Claude Code, and Anthropic's MCP connector for the Claude API. Support may vary depending on deployment model and authentication method.

How do I test an MCP server before connecting Claude?

Validate authentication, JSON-RPC communication, tool discovery, resources, prompts, and tool execution using MCP Inspector or an MCP testing tool before exposing the server to production users.

Is MCP better than calling the Claude API with tools?

It depends on the architecture. If only one application needs access to a few functions, direct tool use may be simpler. If multiple AI clients should share the same API integration, MCP provides a reusable, standardized interface.

Is MCP suitable for production?

Yes. With proper authentication, authorization, monitoring, logging, testing, and governance, MCP is designed for production integrations across enterprise systems.

Check your MCP security posture

Generate a Security Score, detect risky tools, and review permissions before exposing APIs to AI agents.

Related Articles

What Is Model Context Protocol (MCP)?

OpenAPI to MCP: Complete Guide

How to Connect Claude to Any API Using MCP

Coming soon

GitHub MCP Server Explained

Coming soon