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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| extract_schemasC | Extract MCP tool definitions (ProducerSchemas) from server source code. Scans for server.tool() calls and parses their Zod schemas. |
| extract_fileB | Extract MCP tool definitions from a single TypeScript file. |
| trace_usageB | Trace how client code uses MCP tools. Finds callTool() invocations and tracks which properties are accessed on results. |
| trace_fileC | Trace MCP tool usage in a single TypeScript file. |
| compareC | Full analysis pipeline: extract producer schemas, trace consumer usage, and compare them to find mismatches. Returns a detailed report. |
| scaffold_consumerA | Generate consumer code from a producer schema. Creates TypeScript functions, React hooks, or Zustand actions that correctly call MCP tools. |
| scaffold_producerA | Generate producer schema stub from consumer usage. Creates MCP tool definition based on how client code calls it. |
| 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
Most tools have distinct purposes, but there is some overlap between 'trace_file' and 'trace_usage' that could cause confusion, as both involve tracing tool usage. However, 'trace_file' is file-specific while 'trace_usage' is broader, and descriptions help clarify this. Other tools like 'extract_file' vs. 'extract_schemas' are well-differentiated by scope.
All tool names follow a consistent snake_case pattern with clear verb_noun structures, such as 'comment_contract', 'compare', 'extract_file', and 'scaffold_consumer'. There are no deviations in naming conventions, making the set predictable and easy to understand.
With 11 tools, the count is well-scoped for a trace and contract validation server. Each tool serves a specific role in the workflow, from initialization ('init_project') to analysis ('compare') and scaffolding ('scaffold_consumer'), without feeling excessive or insufficient for the domain.
The tool set provides complete coverage for the trace and contract validation domain, including project setup ('init_project', 'get_project_status'), extraction ('extract_file', 'extract_schemas'), tracing ('trace_file', 'trace_usage'), analysis ('compare'), scaffolding ('scaffold_producer', 'scaffold_consumer'), documentation ('comment_contract'), and monitoring ('watch'). No obvious gaps exist in the lifecycle.