Trace MCP
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 |
|---|---|
| extract_schemasA | Extract API schemas from source code. Supports: MCP tools (Zod), OpenAPI/Swagger specs, GraphQL SDL, tRPC routers, REST endpoints (Express/Fastify), gRPC/Protobuf services, Python (FastAPI/Flask decorators), Go (Gin/Chi handlers), and SQL DDL (CREATE TABLE, CREATE TYPE). Auto-detects format from file contents. |
| extract_fileA | Extract API schemas from a single file. Supports TypeScript, Python, Go, Protobuf, GraphQL SDL, OpenAPI JSON/YAML, and SQL DDL. |
| trace_usageA | Trace how client code calls APIs. Detects: MCP callTool(), fetch/axios HTTP calls, Apollo Client hooks (useQuery/useMutation), Python requests/aiohttp/httpx, and tracks property access patterns on responses. |
| trace_fileA | Trace API usage in a single file. Detects HTTP calls, GraphQL queries, MCP tool calls, and response property access. |
| compareB | Full contract validation: extract producer schemas, trace consumer usage, compare for mismatches. Works across languages (TS↔Python, Go↔TS, etc.) and protocols (REST, GraphQL, gRPC, MCP). |
| scaffold_consumerB | Generate type-safe client code from API schemas. Creates TypeScript functions, React hooks, or Zustand actions with full type inference. |
| scaffold_producerC | Generate API stubs from client usage patterns. Infers schema from how client code calls the API. |
| comment_contractC | Add cross-reference comments to validated producer/consumer pairs. Documents the contract relationship in both files. |
| init_projectA | Initialize a trace project with .trace-mcp config directory. Creates project structure for watch mode and caching. |
| watchA | Watch project files for changes and auto-revalidate contracts. Actions: start (begin watching), stop (end watching), status (check state), poll (get pending events). |
| get_project_statusB | Get the status of a trace project including config, cache state, and last validation result. |
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 11 tools
Tools are mostly distinct, but pairs like trace_file/trace_usage and extract_file/extract_schemas have overlapping purposes. Descriptions clarify the scope difference (single file vs. general), so ambiguity is low.
All tool names follow a consistent verb_noun snake_case pattern (e.g., extract_file, trace_usage, init_project), making it easy to infer functionality.
With 11 tools, the server covers extraction, tracing, validation, scaffolding, and project management without being bloated. The scope is well-defined.
The tool surface covers the full workflow: project init, schema extraction, usage tracing, contract comparison, cross-referencing comments, scaffolding, and watching. No obvious gaps for the intended domain.