Background / Motivation:

We are building an integration between our API gateway—which manages a large and dynamic set of HTTP APIs (with detailed OpenAPI/Swagger metadata)—and the Model Context Protocol (MCP) ecosystem. Our goal is to automatically register all these APIs as MCP Tools, so LLMs or other MCP clients can discover and invoke them, without requiring manual code for every endpoint.

Current Limitation and Problems:

• FastMCP currently only allows tool registration via decorators (e.g. @server.tool(...)), which expects a Python function per tool.

• The schema for each tool's parameters (inputSchema) is implicitly inferred from the function signature, and there is no supported way to explicitly set or override the full inputSchema at registration time.

• If an API has many parameters (with type, description, default, enum, etc.), all that detail is lost unless you generate a matching function signature. Even then, the description for each parameter cannot be preserved, as Python functions do not natively support such metadata.

Integration Challenge:

• For API gateways and similar dynamic platforms, it is infeasible to generate a new Python function for every API, every time the set changes. We attempted to work around this by dynamically generating functions and registering them as tools.

• Even with dynamic code generation, the SDK only infers parameter names and types, but drops important fields like description.

• We tried post-processing (patching) the registered tools' inputSchema field, but in FastMCP this is not always possible or reliable:

  • The internal tool_manager or equivalent registry is not always accessible at registration time.

  • Service lifecycle and asynchronous initialization make it difficult (or impossible) to guarantee access to the real Tool objects for patching.

  • This adds operational complexity and risk, especially across different FastMCP versions or deployments.

Why This Matters:

• The lack of description (and other schema metadata) means LLMs and clients cannot prompt users correctly or generate valid parameter values.

• The current approach is fragile, difficult to maintain, and cannot guarantee correctness as the underlying SDK evolves.

Feature Request / Proposal:

Please support explicit setting of the full inputSchema when registering a tool (e.g., via a keyword argument on the registration/decorator function, or by allowing direct registration of Tool objects).

If this is supported, platforms like API gateways could immediately and robustly expose all their APIs as MCP Tools, using existing OpenAPI/Swagger metadata for parameter names, types, descriptions, and examples.

This would make it vastly easier for enterprise systems to onboard MCP and LLM toolchains, and would avoid all the fragile “dynamic function generation” and post-processing hacks described above.

Request for Guidance:

If there already exists a robust and officially supported method to register a tool with a fully custom inputSchema (with all field descriptions, enums, etc.), please point us to the relevant documentation or example. We have not found such a mechanism in the SDK or documentation so far.

Summary:

• Without direct inputSchema registration, integration is fragile and potentially unmaintainable.

• With it, API gateways and similar systems can instantly enable MCP support at scale, fully leveraging their existing schema metadata.

Thank you for your work on MCP—and for considering this feature request!