FastMCP Forge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scaffold_projectC | Scaffold a new FastMCP server project with tests and configuration |
| validate_projectB | Validate an existing FastMCP project directory for syntax and structure |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
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.
Both names follow a clean verb_noun snake_case pattern (scaffold_project, validate_project). The convention is uniform with no deviations.
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.
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.