MCP, function calling and plugins are different layers, not rivals

Three terms, three layers

When an AI assistant books a meeting, looks up an order or files a ticket, it is using a tool outside the model itself. Three terms come up constantly for how that happens: function calling, plugins and MCP, short for Model Context Protocol. As dev.to reported in a post from the DocStar blog, they are often treated as competing options when they actually sit at different layers.

The simplest split is by who does the wiring. With function calling, you do it inside your own app. With plugins, you do it in the format of one particular assistant. With MCP, you publish a server once and each assistant connects to it on its own.

How each one works

Function calling is a feature of a model's programming interface. Per the post's reading of OpenAI's docs, it is a back-and-forth between your application and the model. You describe your functions in a structured format called a JSON schema. The model replies by naming which function it wants and with what inputs. Your code runs it and sends the result back.

That suits an AI feature inside a product you control. The limit is that the function descriptions sit in your own codebase. A customer using your product from their own assistant, such as Claude or Cursor, won't find them there.

Plugins and extensions bundle tools for a single assistant in that assistant's own format. They can reach that assistant's users. But every extra assistant means another build, another review and more upkeep.

MCP is an open standard for linking AI apps to outside systems. The official site compares it to a USB-C port for AI. You run one server that lists your tools. Any MCP-ready assistant can connect, see what is on offer and call it.

They stack rather than compete

The post's central point is that MCP does not replace a model's ability to pick and call tools. It standardises where the tools are published. Your own app can keep using function calling against the same underlying API, while MCP lets other people's assistants reach it too.

The author also argues that the hard part is the same whichever route you take: describing each tool well. A model only uses your API properly if every tool has a clear name, a note on when to use it, explained parameters and a realistic example request. That is documentation work, not plumbing.

The practical cost, as the post tells it, is duplication. Teams that keep separate descriptions for their own app, for one assistant's plugin and for an MCP server end up maintaining the same API description in several places.

Where DocStar comes in

DocStar's pitch is to make your API documentation the single source of truth and generate the MCP server from it. According to the post, you connect a coding agent such as Claude Code or Cursor to DocStar, paste one prompt, and the agent reads your code and documents each endpoint. It then sets up the server's tools, a short guide for assistants and a set of standing instructions.

By default, assistants reach your API through a general tool that searches the docs and calls the right endpoint. Up to 20 important endpoints can get their own named tools, which the post says helps assistants pick them more reliably. The post says the agent asks before changing anything and saves edits as drafts, and only published content reaches the server.

Humans keep the judgement calls: which endpoints to publish, how tools are labelled (for example read-only or destructive), and sign-in. If your API needs a logged-in user, the post says you supply your OAuth app's details, so users call it with their own accounts rather than shared keys.

Read it as a primer, with caution

The explainer is useful for the conceptual split. But DocStar wrote it to promote DocStar, and we have not verified its claims about the product. The feature list, the setup steps and the claim that one URL works across several assistants come from the vendor.

The takeaway that holds up regardless is the layering. When a company says its product works with AI, ask which of the three it means, and what that route can reach with your data. Function calling stays inside one app. A plugin is tied to one assistant. An MCP server can be reached by many assistants at once, which is convenient but also means more places that can connect to it.