Skip to main content

Write, Generate or Host an MCP Server: Which to Choose

Short answer

Pick the option that gives the model the fewest tools that still cover your job, with names and descriptions you can keep stable. Write the server by hand when the job needs a handful of tools or custom logic. Generate one from an OpenAPI spec when the API is small enough that each operation should be a tool, and expect to edit the result. Use a vendor's official hosted server when the vendor publishes one that covers your task and you trust its publisher. Whichever you choose, read the tool list before you connect, because the model chooses between tools by their names and descriptions, not by your code.

Tested withMCP spec 2026-07-28FastMCP 4.1.1 (PyPI, checked 2026-10-20)MCP Registry (preview, checked 2026-10-20)Checked 20 Oct 2026

By Tony LewisHow we test these guides

Compare the three options​

Write it by handGenerate from OpenAPIUse the vendor's hosted server
Tool countYou decide how manyEvery endpoint becomes a tool by defaultSet by the vendor. You get the tools it offers
DescriptionsYou write each oneDepends on the spec. You can edit each component afterwardsWritten by the vendor. Read them before you connect
NamesYou choose themBuilt from each operationIdSet by the vendor
Auth to the serverYou build it. A remote server that uses the spec's OAuth flow must implement Protected Resource MetadataYou build it. The token in FastMCP's example covers calls to the upstream API, not your MCP endpointThe vendor handles it. You sign in as a user where the server supports OAuth
UpkeepYou maintain the code and the tool listRegenerate when the spec changes, then check that the names still matchThe vendor updates it. You follow what it announces
Wins whenThe job needs few tools, clear descriptions or custom logicThe API is small, and each operation maps to one action a model should takeThe vendor's server covers the job and you trust its publisher

Start with the tool list, not the API​

An API describes everything a developer might call. An MCP server describes what a model should do, and the model has to pick from that list on every request. FastMCP's OpenAPI documentation says that LLMs achieve significantly better performance with well-designed and curated MCP servers than with auto-converted OpenAPI servers, especially for complex APIs with many endpoints and parameters. That is the main reason to compare the options by tool count first.

Take an example. Suppose an orders API has 40 endpoints, and your assistant only needs to look up an order, check stock and start a refund. Generating from the spec gives the model 40 tools to choose between. A hand-written server with those three tools is smaller, and each description can say when to use it. The how many tools guide covers the limits that clients set.

Names matter too. Generated tool names come from each operationId. If the API team renames an operationId, the tool name changes, and any saved prompt or client setting that calls the tool by name breaks. The tool naming guide explains why stable names matter.

Decide in three questions​

  1. Does the vendor already run an official MCP server for this service? If it does and you're connecting rather than building, read the hosted section below and use it.
  2. Is the API described by an OpenAPI spec, and does each operation make sense as one action for a model? If it does, generate the server, then edit it.
  3. If neither applies, write the server by hand with the official SDK or FastMCP.

Generate, then edit​

If you generate a server, FastMCP gives you three ways to shape the result before clients see it:

  • Route maps decide what each route becomes. A route can become a tool, a resource or a resource template, or it can be excluded. The first map that matches a route wins.
  • mcp_names maps an operationId to a clearer tool name. The name you give is slugified and truncated.
  • mcp_component_fn runs after each component is created and can change it in place, for example to add instructions or tags.

Each of these is a rule you maintain. When the spec changes, regenerate and compare the new tool list with the old one before you publish it.

Choose a hosted server carefully​

The MCP Registry is the official metadata repository for publicly accessible MCP servers. Server names use reverse DNS, such as io.github.user/server-name, and the registry checks that the publisher controls the namespace through GitHub, DNS or an HTTP challenge before it accepts the listing. That check tells you who controls the name. It doesn't tell you what the code does.

The registry also says that it relies on package registries and downstream aggregators for security scanning, and that it doesn't support private servers. The registry is in preview, and breaking changes or data resets may happen before general availability. Before you connect a hosted server, read its tool list. This command lists the tools of a remote server without calling any of them:

npx @modelcontextprotocol/inspector@2.11.0 --cli https://example.com/mcp --method tools/list

If the server needs a token, the Inspector's --header option sends one with the request. The evaluate MCP servers guide has a checklist for the rest of the decision.

How to do each option​

  • Write it by hand. Build an MCP server uses the official SDKs in Python and TypeScript. FastMCP is a separate framework with its own guide.
  • Generate it. FastMCP's FastMCP.from_openapi() takes an OpenAPI document and an HTTP client. If you don't pass a client, FastMCP creates one with a 30-second timeout. The FastMCP OpenAPI docs cover authentication, timeouts and route maps.
  • Use a hosted server. Find it through the MCP Registry or the vendor's own documentation, check it with the Inspector command above, then connect it in your AI app. The connect guides show the setup for each app.

If you build a server by hand or generate one, test it with MCP Inspector in both protocol eras before you share it.

What changed recently​

  • The 2026-07-28 spec removes the initialize handshake. Every request carries its protocol version, and every server must implement server/discover. A generated server depends on the SDK it was built with, so check that it answers server/discover and works in both modern and legacy era runs of the Inspector.
  • The MCP Registry is in preview. Its own page warns that breaking changes or data resets may happen, so pin the versions of any server you depend on.

Common problems​

Every endpoint became a tool. FastMCP's default route map turns every route into a tool. Add a route map that excludes the routes you don't want, or merge the rest into fewer tools by hand.

A tool name changed after a spec update. The name comes from operationId. Pin the name with mcp_names, or rename the operationId in the spec only after you've checked which clients call it.

The hosted server works, but you don't know who runs it. A registry namespace shows who controls the name, and the registry doesn't scan the code. Check the publisher's own site and repository before you give the server access to your data.

FAQ​

Can I turn an OpenAPI spec into an MCP server?

Yes. FastMCP's from_openapi() method creates one, and by default each endpoint becomes a tool. FastMCP's own docs say curated servers usually perform better for complex APIs, so plan to edit the result before you share it.

Is there an official MCP server for my service?

Check the vendor's own documentation first, then search the MCP Registry. The registry lists publicly reachable servers and doesn't cover private ones.

Should I use a generated MCP server in production?

It depends on the API. Review the tool list, the names, the descriptions and the auth before you share the server. A generated server exposes what the spec describes, and that may include operations you don't want a model to call.

How many tools should a generated server have?

As few as the job needs. Exclude routes you don't need, merge operations that do the same job, and keep the rest. The how many tools guide explains the limits clients set.