Make My API Work With Claude: The MCP Server Playbook

A support lead at a mid-sized SaaS company spends Tuesday morning fielding the same request from three different customers: "can I just ask your AI assistant to pull my invoice history instead of logging into the dashboard?" The answer, today, is no. Your API exists, your docs are solid, but Claude has no way to call it. Every customer who wants to work through their AI assistant instead of your UI is a customer quietly comparing you to a competitor who already shows up inside ChatGPT or Claude.

That gap has a cost. Sales teams lose deals to "AI-native" positioning even when the underlying product is equivalent. Support teams keep answering questions a connected assistant could resolve in one turn. Engineering teams get pulled into "can we just build this ourselves" conversations that eat two sprints and produce a fragile prototype nobody wants to maintain.

This guide covers what it actually takes to make your API work with Claude: what an MCP server is, how the build goes end to end, what it costs, and where teams get it wrong. If you want the productized version of this, see the Custom MCP Server offer from Bharat AI Saathi.

What Custom MCP Server actually does

The Model Context Protocol (MCP) is the open standard Anthropic introduced so that AI assistants like Claude, and increasingly tools like Cursor and ChatGPT, can call external systems in a structured, auditable way. An MCP server is the bridge: it takes your existing REST or GraphQL API and exposes a defined set of "tools" (think: get_invoice, create_ticket, list_shipments) with proper input/output schemas, so Claude can call them the same way it calls its own built-in tools.

A Custom MCP Server from Bharat AI Saathi is that bridge, built and hosted for you. In practice it means mapping 3 to 15 of your existing endpoints to named MCP tools, wiring authentication so each Claude session only sees what a given customer or API key is authorized to see, writing conformance tests so the server behaves the same way across Claude Desktop, Cursor, and ChatGPT clients, and deploying it somewhere reliable (typically Cloudflare Workers or a Docker container) rather than a laptop process. It also includes listing the server in the official MCP registry, so customers and partners can discover it without you emailing them a config file.

How it works, step by step

1. Kickoff call. We review your API docs, pick the 3-6 highest-value endpoints (billing lookups, order status, ticket creation are common starting points), and agree on which ones need write access versus read-only.
2. Auth design. We map your existing API-key or OAuth flow onto MCP's auth model, so a customer's Claude session inherits the same permissions their API key already has — no new privilege escalation surface.
3. Tool and schema definition. Each endpoint becomes a named tool with a JSON schema for inputs and outputs, so Claude knows exactly what arguments to pass and what shape of data comes back.
4. Server build. We implement the server in TypeScript or Python using the official MCP SDK, with streamable HTTP transport for cloud deployments (or stdio-only for the local tier).
5. Testing and rate limiting. Conformance tests run against the spec, plus basic rate limiting and logging so one runaway agent loop can't hammer your backend.
6. Deployment and registry listing. The server goes live on Cloudflare Workers or your Docker infrastructure, and we submit it to the official MCP registry with a README and ready-to-paste client configs for Claude, Cursor, and ChatGPT.
7. Daily operation. Customers or your own team connect their Claude client using the config we provide, and from that point on, natural-language requests turn into authenticated API calls.

Customer (in Claude Desktop): "What's the status of order 48213 and has it shipped yet?" Claude: calls get_order_status tool with order_id=48213 Agent (tool response): {"status": "shipped", "carrier": "UPS", "tracking": "1Z999AA1..."} Claude: "Order 48213 shipped via UPS. Tracking number is 1Z999AA10123456784, and it's currently in transit."

Before and after

What it costs and what is included

No lock-in: the code, configs, and registry listing are yours, and you can walk away from the care plan without losing the server. The payback logic is straightforward rather than dramatic — you are trading a recurring engineering distraction (support tickets, sales objections, one-off integration requests) for a fixed monthly line item, and in our experience that trade typically pays for itself once it removes even a few hours a month of internal back-and-forth.

Delivery timeline

Day 0: Kickoff

API docs review, endpoint selection, auth model confirmed, access credentials shared securely.

Days 1-7: Build

Tool and schema design, server implementation, auth wiring, and internal testing against your staging environment.

Days 8-9: Conformance and hardening

Conformance tests against the MCP spec, rate limiting, logging, and a dry run with Claude Desktop, Cursor, and ChatGPT clients.

Day 10: Go-live

Deployment to production hosting, registry listing submitted, README and client configs delivered.

What you need to have ready

• API documentation (OpenAPI/Swagger spec if you have one, otherwise endpoint list with request/response examples)
• A staging or sandbox environment we can test against without touching production data
• Existing auth mechanism details (API keys, OAuth client credentials, or similar)
• A named technical contact who can approve the endpoint-to-tool mapping
• Any compliance requirements around what data can leave your infrastructure (relevant for regulated industries like fintech or healthcare-adjacent SaaS)
• Sign-off on which endpoints are read-only versus which allow writes

Doing it yourself vs done-for-you

The SDK is genuinely good and a capable team can build this in-house. The tradeoff is almost always time and ongoing attention, not capability.

Compliance and risk notes

• Scope each MCP tool to the same permissions the underlying API key already has — never grant a Claude session broader access than the credential behind it.
• If your API touches personal or financial data, confirm where the MCP server itself is hosted, since data residency requirements may dictate the deployment region.
• Log tool calls the same way you'd log API calls, since an AI-initiated write action still needs an audit trail.
• Review the usage policies of each AI platform (Anthropic, OpenAI, Cursor) your server will be listed for, as registry and client-configuration requirements can change.
• For write-enabled tools (creating tickets, modifying records), consider requiring explicit confirmation steps rather than silent execution, particularly for higher-risk actions.
• This guide is general information, not legal or compliance advice — check your specific regulatory obligations (GDPR, HIPAA-adjacent rules, etc.) with your own counsel before exposing regulated data through an AI assistant.

Mistakes buyers make

• Exposing every endpoint at once. Start with 3-6 high-value tools; a sprawling surface area is harder to test and harder for Claude to use well. Fix: prioritize the endpoints customers already ask about most.
• Skipping the registry listing. A working server nobody can find defeats the purpose. Fix: treat registry listing as part of launch, not an optional afterthought.
• Reusing a god-mode API key for the MCP server. This grants the AI client more access than intended. Fix: scope credentials per session or per customer, mirroring your existing API auth.
• No plan for API changes. Endpoints evolve, but nobody updates the MCP tool schema to match. Fix: fold this into a maintenance plan with a fixed cadence, like the 2 new tools/month care plan.
• Treating this as a one-off script instead of infrastructure. A local Node process on someone's laptop is not production hosting. Fix: deploy to a real hosting target (Cloudflare Workers, Docker) with monitoring from day one.

FAQ

Does this replace my existing API?

No. The MCP server sits in front of your existing API and translates AI assistant requests into calls against it. Your API, your data, your infrastructure stay exactly where they are.

Will this work with ChatGPT and Cursor too, or only Claude?

MCP is an open standard, so a properly built server works with any MCP-compatible client, including Claude Desktop, Cursor, and ChatGPT where supported. We test against all three before go-live.

What if my API doesn't have documentation?

We can work from a Postman collection, existing client SDK, or a walkthrough call with your engineering team. Documented endpoints speed up the build, but they aren't strictly required to start.

Can we start with read-only tools and add write access later?

Yes, and it's a common approach for teams cautious about AI-initiated changes to live data. Read-only tools ship first, and write-enabled tools can be added once you're comfortable with the pattern.

What happens if the MCP spec changes after launch?

The $349/month care plan covers spec-version updates as part of ongoing maintenance, so the server stays compatible with newer Claude, Cursor, and ChatGPT client versions without a separate project.

Is the $1,500 local tier enough for a small SaaS product?

If you don't need cloud hosting, OAuth, or a public registry listing — for example, an internal tool used only by your own team via Claude Desktop — the local/stdio-only tier is typically sufficient.

Next step

Email support@bharataisaathi.com or message us on WhatsApp with your API docs (or a Postman link) and the 3-6 endpoints you'd want exposed first.

See full scope and pricing on the Custom MCP Server page, and read how we work before kickoff.

We'll reply with a proposed tool mapping and timeline within one business day.