DEV Community

Tang Weigang
Tang Weigang

Posted on

FastMCP Makes MCP Easy. The First Risk Is Exposing Too Much.

#opensource

FastMCP is attractive because the first working server can be tiny. Write a Python function, add @mcp.tool, and the function becomes something an MCP client can discover and call. For teams wiring tools into Claude Code, Codex, Cursor, Aider, or an internal agent host, that is a useful shortcut.

It is also the first boundary. Once a FastMCP server is connected to a real host, you are no longer just wrapping a convenient function. You are exposing action surfaces to a model: files, network calls, internal APIs, database access, OAuth tokens, or team scripts that were never designed for model-driven input.

Doramagic project page: https://doramagic.ai/en/projects/fastmcp/

Doramagic manual: https://doramagic.ai/en/projects/fastmcp/manual/

Upstream project: https://github.com/PrefectHQ/fastmcp

FastMCP is about tool exposure, not better chat

The upstream README shows the appeal in a small example:

from fastmcp import FastMCP

mcp = FastMCP("Demo")

@mcp.tool
def add(a: int, b: int) -> int:
    """Add two numbers"""
    return a + b

if __name__ == "__main__":
    mcp.run()
Enter fullscreen mode Exit fullscreen mode

The important part is not the add function. It is the bridge from ordinary Python code into MCP tool registration, schema, description, and runtime behavior.

FastMCP also spans three surfaces:

  • servers that expose tools, resources, and prompts;
  • clients that connect to local or remote MCP servers;
  • apps that let tools render interactive UI inside a conversation.

That means the first implementation question is not "can I make a demo?" The better question is "which capability am I exposing, and what should an AI host be allowed to do with it?"

The common mistake: treating fast registration as low risk

uv pip install fastmcp or pip install fastmcp is an install step. It is not operational proof.

Before wiring a FastMCP server into an agent host, check the shape of the tools:

  • Is the tool read-only?
  • Can model-supplied arguments become paths, SQL, shell commands, or URLs?
  • Does the function read environment variables, config files, or a user directory by default?
  • Which tool, resource, and prompt names will the client see?
  • Are errors diagnostic without leaking tokens, internal paths, connection strings, or stack traces?
  • Is the server running through stdio, local HTTP, remote HTTP, or a proxy?
  • If auth is present, are rejected requests still observable in the way you expect?

FastMCP makes the happy path short. That is exactly why the first verification pass should be deliberately boring.

A safer first connection

Start with one harmless tool. A small add(a, b) function or a read from a fixed fixture is enough. The goal is to verify tool discovery, parameter schema, invocation, and output.

Then classify every next tool before exposing it:

  • read-only;
  • writes local state;
  • calls external services;
  • touches credentials;
  • can execute user-controlled input.

Do not expose all classes at once. Let the host see read-only tools first, and verify that it does not invent permission to widen the scope.

Write down the transport before testing real work. A stdio server, local HTTP server, remote HTTP server, and proxy all have different logging, auth, and network boundaries.

Test error behavior early. Pass a bad argument and inspect what the model sees. A useful error should explain the failure without dumping private paths, secrets, or low-level stack traces.

Only then attach real tools. At that point, record the tool list, argument boundaries, credential source, rollback path, and verification command. Without that record, "the MCP server works" is too vague to trust.

What to load into an AI coding host

When giving FastMCP context to Claude Code, Codex, Cursor, or Aider, do not hand over a generic project summary. Give the host a contract:

  • Upstream docs are the source of truth for API details.
  • Doramagic provides the context pack, boundary notes, pitfall log, smoke check, and failure check.
  • The first run must use a temporary directory or temporary host configuration.
  • List tools before calling tools.
  • Ask before file writes, network access, shell execution, browser use, credentials, or remote API calls.
  • Any claim of success must include the tool list, host config location, launch command, and verification output.

That keeps the host from confusing a clean demo with a trusted internal tool surface.

When FastMCP is the right choice

FastMCP is a strong fit when you already know the Python capabilities you want to expose and need MCP schema, client behavior, transport, auth, or app surfaces to become reliable quickly.

It is probably too early when you only have a one-off script idea. Define the function, inputs, outputs, side effects, and rollback first. Then use FastMCP to package that capability as an MCP surface.

The practical test is simple: if you can answer what the tool can do, what it must not do, who can call it, how failure is proven, and how access is revoked, FastMCP can speed you up. If not, it will mostly speed up confusion.

Top comments (0)