How to Turn Your API into an MCP Server Without Writing Server Code

More of your users now try your product from inside an AI assistant. They ask Claude, ChatGPT or Cursor to "create an invoice" or "send a test message" before they ever open your dashboard. If the assistant can't reach your API, it guesses, gives up, or suggests a product it can reach.

The fix is an MCP server for your API. This guide shows the two ways to get one, and how to have a working server in an afternoon without writing or hosting any server code.

The Model Context Protocol (MCP) is the open standard AI assistants use to discover and call outside tools. An MCP server for an API needs to:

1. Describe each action as a tool, with a name, a description and a schema for its inputs.
2. Authenticate as the user, so every call runs with that person's own permissions.
3. Make the real HTTP request and return the result to the assistant.
4. Stay in sync with your API as endpoints change.
5. Be hosted somewhere with a URL users can paste into their assistant.

New to MCP? Start with What Is an MCP Server?

You can write a server with an MCP SDK, define every tool by hand, add OAuth, deploy it and keep it updated whenever your API changes.

This makes sense when you need custom logic between the assistant and your API, such as combining several calls into one tool. The cost is a second codebase: every new endpoint, renamed field or auth change has to be made twice, once in the API and once in the MCP server.

Your API docs already contain everything an MCP server needs: endpoints, methods, parameters, body fields, auth headers and descriptions. If the docs are the source, the server can be generated from them and stays current every time you publish.

That is how DocStar works. Every published collection gets its own hosted MCP server. You write docs once and get:

• a public API docs site for humans,
• an MCP server AI assistants can use to search your docs and call your API,
• a CLI that turns each endpoint into a terminal command.

Create a collection of type API and choose its slug. The slug is permanent and becomes part of your MCP URL, so pick your product name, for example acme.

Use whatever you already have:

• An OpenAPI or Postman file. Import it into the collection.
• cURL commands. Paste them and DocStar fills in the method, URL, headers and body.
• Only code. Connect your coding agent to DocStar's own MCP server (https://mcp.docstar.io/mcp) and ask it to read your routes and document every public endpoint. It creates the pages and endpoints for you.

The assistant decides which tool to call from the words you write. For each endpoint:

• Name it verb-first, the way a user would ask: Create Order, List Invoices.
• Say when to use it and what it changes, including any required order ("call Create Cart first").
• Give a body example with every accepted field, and describe each field. Fields missing from the example are hard for an assistant to use.
• Add a sample success response and the common errors.
• Never put real keys or customer data in the docs.

Publish the module pages and endpoints. Unpublished endpoints don't appear in the MCP server.

Open the collection's MCP tab. Your server is already running at:

https://mcp.docstar.io/connector/acme

The tab also gives ready-made setup snippets. For Claude Code, for example:

claude mcp add --transport http acme https://mcp.docstar.io/connector/acme

If your API needs a user token, add your OAuth details (login URL, token URL, client ID and secret) in the MCP tab and add DocStar's callback URLs to your OAuth app. The first time an assistant calls your API, the user signs in, and their token is attached to every later call. The assistant never sees the credential.

API-key based? The server includes a key tool, so a user enters their key once instead of pasting it into prompts.

For private APIs, switch on Require sign-in when connecting so nobody can even search the docs without signing in. More in Securing Your DocStar MCP Server.

The generated server works out of the box. Four settings make it noticeably better:

• Dedicated tools. Give your 5 to 10 most-used endpoints their own named tools. Everything else stays reachable through the built-in API tools.
• The skill. Rewrite the generated quickstart with your product's main workflows and rules, such as "always confirm before deleting".
• Tool descriptions. Say what your product is and when to use each built-in tool.
• A custom domain. Serve the server from mcp.yourcompany.com.

Add the URL to Claude or Cursor and ask a real question in plain words: "show my last five orders" or "create a test customer named Jane". Watch which tool the assistant picks and which fields it sends. If it picks the wrong endpoint or misses a field, fix the description or the body example and publish again. There is nothing to redeploy.

Do I need an OpenAPI spec? No. You can import one, paste cURL commands, write endpoints in the editor or let a coding agent document them from your code.

Which assistants can use the server? Any client that supports remote MCP servers over HTTP, including Claude, Claude Code, Cursor, VS Code and ChatGPT where custom connectors are enabled. See How to Connect Your API to ChatGPT, Claude and Cursor.

Can the assistant change data? Only if you allow it. Reads and writes are separate tools, so clients that ask for approval on writes can let reads through. With sign-in, every call runs with the user's own permissions.

What happens when my API changes? Update the endpoint in DocStar and publish. The MCP server reads the published docs, so the change is live without a deploy.

Create a free DocStar collection, import your API and publish. Your MCP server is ready the moment you do.