Skip to main content
Glama
johannschiffer

FastMCP Forge

by johannschiffer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

fastmcp-forge

PyPI version CI License: MIT Python 3.10+ MCP Compliant

FastMCP Forge is a zero-dependency Python framework, CLI project scaffolder, and MCP server for building and testing Model Context Protocol (2024-11-05) servers over stdio or authenticated SSE transports.

Features

  • @app.tool Decorator & Schema Inference: Introspects function signatures (including Optional[T], list[T], dict[K, V], and from __future__ import annotations) into JSON Schema definitions.

  • Built-in MCP Server & CLI Scaffolder: Run fastmcp-forge new <name> from the terminal or connect fastmcp-forge directly to an MCP client to call scaffold_project and validate_project.

  • Authenticated SSE Transport Handler: Constant-time API key and Bearer token verification (hmac.compare_digest), bounded session tracking with TTL expiration, and token-bucket rate limiting.

Related MCP server: mcpserve

Quickstart

1. Run as an MCP Server (uvx)

{
  "mcpServers": {
    "fastmcp-forge": {
      "command": "uvx",
      "args": ["fastmcp-forge", "serve"]
    }
  }
}

Note: When invoked over a non-TTY pipe (uvx fastmcp-forge with no subcommand), fastmcp-forge automatically enters stdio MCP server mode.

Built-in MCP Tools

Tool

Description

scaffold_project

Generate a complete FastMCP server directory (server.py, tests/test_server.py, pyproject.toml, README.md, requirements.txt).

validate_project

Parse and verify an existing FastMCP project directory for syntax and structure.

2. CLI Project Scaffolder

pip install fastmcp-forge
fastmcp-forge new analytics-mcp
fastmcp-forge validate ./analytics-mcp

3. Build a Custom Server in Python

from fastmcp_forge.server import FastMCP

app = FastMCP(name="math-mcp", version="2.0.1")


@app.tool(description="Multiply two numbers")
def multiply(a: float, b: float) -> float:
    return a * b


if __name__ == "__main__":
    app.run()

Genesis MCP Ecosystem

Module

Description

Repository

CrawlEngine MCP

HTTP web extraction to clean Markdown, JSON-LD parsing, and proxy rotation

GitHub

BrowserBridge MCP

Lightweight HTTP/DOM session automation with SHA-256 action receipts

GitHub

PgSafe MCP

Read-only PostgreSQL/SQLite query guard, PII masking, and dry-run mutations

GitHub

OmniBridge MCP

Multi-channel notification bus with SQLite retry queue

GitHub

SysFlow MCP

Linux systemd inspection, confined log tailing, and port auditing

GitHub

FastMCP Forge

Zero-dependency FastMCP framework, CLI scaffolder, and SSE middleware

GitHub

Support

If you find this project useful, you can support maintenance on Ko-fi.

License

MIT (c) 2026 Johann Schiffer

Available Tools

2 tools
scaffold_projectC

Scaffold a new FastMCP server project with tests and configuration

NameRequiredDescriptionDefault
target_dirNoParameter target_dir
project_nameYesParameter project_name

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It never discloses that this is a write operation creating files on disk, whether an existing directory is overwritten or errors out, whether network access is needed to fetch templates, or what the tool returns on success.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with zero filler. It is efficient, though the brevity reflects under-specification rather than tight editing of rich content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a file-creating mutation tool with no annotations, no output schema, and placeholder parameter docs, the description omits the essentials: output location defaults, overwrite/failure behavior, and generated project structure. An agent has to guess before calling it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is nominally 100%, so the baseline is 3, but the schema descriptions are bare placeholders ('Parameter target_dir'), meaning the description adds nothing about what target_dir defaults to or how project_name is used in generated files.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ('Scaffold') plus a concrete resource ('a new FastMCP server project') and the artifacts produced (tests, configuration). It implicitly contrasts with the sibling validate_project, but never names or explicitly distinguishes itself from it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No statement of when to use this versus validate_project, no prerequisites stated (e.g. whether target_dir must exist or be empty), and no guidance on what to do after scaffolding. Usage must be inferred entirely from the tool name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_projectB

Validate an existing FastMCP project directory for syntax and structure

NameRequiredDescriptionDefault
project_dirYesParameter project_dir

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full behavioral burden. It discloses what is checked (syntax and structure) but not whether the tool is read-only, whether it mutates or writes any files, what it returns on success/failure, or whether it requires dependencies to be installed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single efficient sentence with no filler, and the key qualifier ('existing') is front-loaded. It is appropriately sized, if slightly thin.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, no-output-schema tool this is close to adequate, but with no annotations an agent still cannot tell whether the call is safe/read-only or what a failure result looks like.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema technically has 100% coverage, but the parameter description is a placeholder ('Parameter project_dir'). The tool description does add meaning by establishing that project_dir is an existing FastMCP project directory, not an arbitrary path, which is the baseline expectation at high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb (validate) and object (an existing FastMCP project directory) plus the dimensions checked (syntax and structure). The word 'existing' implicitly separates it from the scaffold_project sibling, though it never names that sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Existing' implies this runs after a project has been created, which hints at its place relative to scaffold_project, but there is no explicit statement of when to use this versus scaffolding or re-running validation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv2.0.1
    • First observedscaffold_project
    • First observedvalidate_project
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.3/5.0

Scored across 2 tools

Disambiguation5/5

The two tools perform clearly opposite-lifecycle actions: scaffold_project creates a new project, validate_project checks an existing one. There is no realistic way to confuse them, and both descriptions state the target resource explicitly.

Naming Consistency5/5

Both names follow a clean verb_noun snake_case pattern (scaffold_project, validate_project). The convention is uniform with no deviations.

Tool Count3/5

Two tools is thin for a server whose scope is the full FastMCP project lifecycle; it sits at the borderline where each tool is essential but the surface feels minimal. A handful more operations (e.g. add a tool, run tests) would make the set feel complete rather than a pair of one-off utilities.

Completeness3/5

Creation and validation are covered, but there is no way to modify an existing scaffold, inspect a project, or run/test it — an agent that scaffolds, edits, and then needs to regenerate or verify a broken project hits a dead end beyond a single validate call. Notable lifecycle gaps remain.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • nbmcp

    rum1887
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables building lightweight MCP servers where Rust handles transport, routing, and schema validation while Python defines tool behavior using type hints, with support for stdio and HTTP transports.
    MIT

  • mcpserve

    AmirNaghibi
    A
    license
    Not graded
    quality
    B
    maintenance
    A minimal, decorator-based framework for building MCP servers in Python with zero dependencies. It enables you to define tools and resources via simple decorators, handling JSON-RPC protocol, type inference, and stdio transport automatically.
    MIT

  • cli2mcp

    yulinlina
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables turning any command-line tool into an MCP server with auto-generated JSON schema, supporting stdio, timeouts, and stderr capture.
    MIT

  • mcp-agent-kit

    hummbl-dev
    A
    license
    A
    quality
    B
    maintenance
    Enables building and running zero-dependency MCP servers with automatic JSON Schema generation, exposing Python tools to Claude Desktop, Cursor, and autonomous agent fleets.
    2
    Apache 2.0