MCP vs Function Calling vs Plugins: What's the Difference (and Where DocStar Fits)

MCP, function calling and plugins all let an AI model use outside tools, but they work at different layers. Function calling is a model feature: your code tells one model which functions exist and runs them itself. Plugins are add-ons built for one specific assistant. MCP (Model Context Protocol) is an open standard: you publish one server, and any MCP-ready assistant can connect to it. With DocStar, your API docs become that MCP server, so one URL works in Claude, ChatGPT, Cursor, VS Code and other MCP-ready assistants.

This guide explains each approach in plain English, shows how they fit together, and then walks through how we at DocStar turn your documented API into an MCP server your users can add in one step, with your own coding agent doing most of the setup.

They are not rivals. MCP doesn't replace the model's ability to choose and call tools; it standardises where those tools come from, so you don't have to rebuild them for every assistant.

Function calling is how a model asks your code to do something. As OpenAI describes it in its docs (as of November 2026), tool calling is a multi-step conversation between your application and the model: you define functions with a JSON schema, the model replies with which function to call and its arguments, your application runs the code, and you send the result back.

That works well when you own the app and the model call. The catch: the function definitions live in your code. If a customer wants to use your product from their own Claude or Cursor, your functions aren't there.

Plugins and extensions package tools for a single assistant, in that assistant's own format. They can reach that assistant's users, but each new assistant means another build, another review and another thing to maintain.

The official MCP site defines it (as of November 2026) as "an open-source standard for connecting AI applications to external systems" and compares it to a USB-C port for AI apps. You run one MCP server that lists your tools; any MCP-ready assistant connects, discovers those tools and calls them. Write once, work everywhere.

For the full picture, read our guide What Is an MCP Server?, and for how MCP relates to the API underneath, see MCP vs API.

Whichever approach you choose, the model only uses your API well if every tool has a clear name, a description of when to use it, every parameter explained and a real example body. That is documentation work. Teams that hand-write function schemas for one app, a plugin manifest for another and an MCP server for a third end up maintaining the same API description three times.

DocStar takes a different route: your API docs are the source of truth, and the MCP server is built from them.

Every DocStar collection gets its own MCP server. What assistants can do depends on the collection type, according to our Build an MCP Server for Your App guide:

Only published content is visible. Drafts never reach your MCP server.

Add DocStar to Claude Code, Cursor, Codex or another assistant. Use DocStar from your assistant's connector directory if it's listed there; if not, add it as a custom remote MCP server with this URL:

https://mcp.docstar.io/mcp

The first time the assistant needs your workspace, you sign in to DocStar in your browser. There's no API key to copy, and the assistant works with the same workspaces and permissions you have. Full steps: Connect Your AI Assistant.

Open your API's repository in your coding agent and paste:

Use the DocStar MCP to turn my app's API into an MCP server. First read https://docstar.io/mcp/quickstart.md and follow it step by step. Read my latest code for the API, not an old OpenAPI file, and document each endpoint with a clear description and a full JSON body example.

From that one prompt, the agent:

• Reads your code and documents each endpoint in a DocStar API collection: purpose, parameters, a full JSON body example and responses.

• Gets your MCP URL. It looks like https://mcp.docstar.io/connector/your_collection_slug.

• Picks your main tools. By default, assistants reach your API through a general "call any API" tool that searches your docs, finds the endpoint and calls it. The agent gives up to 20 of your most important endpoints their own named tools, such as create_payment, so assistants pick them more reliably.

• Writes the skill, the short guide assistants read before using your API: what it's for, the usual order of calls, rules and limits.

• Adds instructions, short rules assistants get every time they connect, such as "Ask for the account id before creating an order" (under 2,000 characters).

It asks you before it changes or publishes anything, and its edits are saved as drafts, so nothing reaches your live docs until you say so.

[Screenshot: Coding agent showing its plan for the DocStar MCP server before making changes]

Your role is judgement, not typing:

• What stays private. Decide which endpoints to publish. Only published endpoints reach the MCP server.

• Tool names and descriptions. Skim the 20 named tools. Leave a description empty to follow the endpoint's docs, so the tool stays current when the docs change.

• Safety hints. Mark tools read-only, destructive, idempotent or open-world, so assistants know when to ask before running them.

• Sign-in. If your API needs a logged-in user, enter your OAuth app's authorization URL, token URL, client ID and secret, and a token validation URL in the MCP tab, then add the redirect URIs DocStar shows to your OAuth app. That's the one step only you can do. More in MCP Server Authentication Explained.

Then publish, and share the URL. Your users add it to Claude, ChatGPT, Cursor or VS Code and use your product in plain language. You can even serve it on your own domain, such as mcp.yourcompany.com.

An MCP server is only as good as the docs behind it, so make updates part of every code change.

Option A: GitHub Sync. Keep OpenAPI files in an api-docs/ folder and Markdown pages in docs/. On every push that changes them, a GitHub Action sends the changes to DocStar. Add DocStar's docstar.md guide to your repo and this line to your AGENTS.md, so your coding agent updates the API docs in the same change:

- Whenever any endpoint is added, changed, renamed or removed, read `docstar.md` in this repo and follow it to update `api-docs/` in the same change.

See GitHub Sync for the workflow file and secret.

Option B: ask your agent. After a change, prompt:

I just changed the refunds endpoints. Update their docs in our DocStar API collection with the DocStar MCP, keep the tools and skill in line, save as draft and show me what changed.

Because DocStar's generated skill and empty-description tools follow your docs, updating the docs updates what assistants see once you publish.

Everything above is also in the app. Open your API collection's settings, go to the MCP tab, copy the MCP server URL, pick your endpoint tools, write the skill and instructions, and set up sign-in. Your own app can still use function calling against the same documented API; MCP simply adds every other assistant.

• One source of truth. Your API docs, MCP server, and CLI commands all come from the same published collection.

• Agent-first setup. Your coding agent documents the API and configures the server; you review and publish.

• Safe by design. The agent asks first, edits start as drafts, and drafts never reach the MCP server.

• Real sign-in. Users call your API with their own account through OAuth, not shared keys.

• More than an MCP server. Help docs, FAQs, changelog and blog live in the same workspace, on your domain and brand.

Is MCP a replacement for function calling? No. Models still choose and call tools; MCP standardises how those tools are published, so one DocStar MCP server works in Claude, ChatGPT, Cursor, VS Code and other MCP-ready assistants.

Do I need to write MCP server code to use DocStar? No. Document your API in a DocStar collection, publish it, and DocStar gives that collection its own MCP server. Your coding agent can do the documenting for you.

How many tools can a DocStar MCP server have? You can give up to 20 published endpoints their own named tools. Every other published endpoint stays reachable through the general "call any API" tool.

Can users call my API as themselves? Yes. For API collections, add your OAuth app's details under Sign-in for API calls in the MCP tab. The first time an assistant calls your API, the user signs in with their own account.

Will my draft endpoints show up in assistants? No. Only published content is visible on your DocStar MCP server.

Turn your API docs into one MCP server that works in every assistant. Connect your coding agent to DocStar, paste the prompt above and review what it builds.

Get started free