Skip to main content
Glama

extract_schemas

Extract MCP tool definitions from server source code by scanning for tool calls and parsing their Zod schemas to analyze server capabilities.

Instructions

Extract MCP tool definitions (ProducerSchemas) from server source code. Scans for server.tool() calls and parses their Zod schemas.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rootDirYesRoot directory of MCP server source code
includeNoGlob patterns to include
excludeNoGlob patterns to exclude

Implementation Reference

  • The main execution handler for the 'extract_schemas' tool. It validates input with Zod, invokes extractProducerSchemas on the specified directory, and returns the extracted ProducerSchemas as JSON.
    case 'extract_schemas': {
      const input = ExtractSchemasInput.parse(args);
      log(`Extracting schemas from: ${input.rootDir}`);
      
      const schemas = await extractProducerSchemas({
        rootDir: input.rootDir,
        include: input.include,
        exclude: input.exclude,
      });
      
      log(`Found ${schemas.length} tool definitions`);
      
      return {
        content: [
          {
            type: 'text',
            text: JSON.stringify({
              success: true,
              count: schemas.length,
              schemas,
            }, null, 2),
          },
        ],
      };
    }
  • Zod schema for validating the input parameters to the extract_schemas tool (rootDir, include globs, exclude globs).
    const ExtractSchemasInput = z.object({
      rootDir: z.string().describe('Root directory of MCP server source code'),
      include: z.array(z.string()).optional().describe('Glob patterns to include (default: **/*.ts)'),
      exclude: z.array(z.string()).optional().describe('Glob patterns to exclude (default: node_modules, dist)'),
    });
  • src/index.ts:130-142 (registration)
    Registration of the extract_schemas tool in the ListTools response, defining its name, description, and JSON input schema.
    {
      name: 'extract_schemas',
      description: 'Extract MCP tool definitions (ProducerSchemas) from server source code. Scans for server.tool() calls and parses their Zod schemas.',
      inputSchema: {
        type: 'object',
        properties: {
          rootDir: { type: 'string', description: 'Root directory of MCP server source code' },
          include: { type: 'array', items: { type: 'string' }, description: 'Glob patterns to include' },
          exclude: { type: 'array', items: { type: 'string' }, description: 'Glob patterns to exclude' },
        },
        required: ['rootDir'],
      },
    },
  • Helper function extractProducerSchemas that wraps language-specific parsers. Defaults to TypeScript parser and delegates the extraction.
    export async function extractProducerSchemas(
      options: ExtractorOptions
    ): Promise<ProducerSchema[]> {
      // For backward compatibility, default to TypeScript
      const language = options.language || 'typescript';
    
      // Get parser from registry
      if (!hasParser(language)) {
        throw new Error(
          `No parser available for language: ${language}. Make sure to call bootstrapLanguageParsers() at startup.`
        );
      }
    
      const parser = getParser(language);
    
      return parser.extractSchemas({
        rootDir: options.rootDir,
        include: options.include,
        exclude: options.exclude,
      });
    }
  • Core TypeScript parser implementation for extractSchemas. Uses ts-morph to scan files for server.tool() calls, parse Zod schemas into JSON Schema, and collect ProducerSchema objects.
    async extractSchemas(options: ExtractOptions): Promise<ProducerSchema[]> {
      console.log(`[TypeScript] Scanning: ${options.rootDir}`);
    
      const project = new Project({
        tsConfigFilePath: undefined,
        skipAddingFilesFromTsConfig: true,
      });
    
      // Add source files
      const patterns = options.include || this.filePatterns;
      const excludePatterns = options.exclude || ['**/node_modules/**', '**/dist/**'];
    
      project.addSourceFilesAtPaths(
        patterns.map(p => `${options.rootDir}/${p}`)
      );
    
      const schemas: ProducerSchema[] = [];
    
      for (const sourceFile of project.getSourceFiles()) {
        const filePath = sourceFile.getFilePath();
    
        // Skip excluded patterns
        if (excludePatterns.some(pattern => filePath.includes(pattern.replace('**/', '')))) {
          continue;
        }
    
        // Find all server.tool() calls
        const toolCalls = this.findToolCalls(sourceFile);
    
        for (const toolCall of toolCalls) {
          const schema = this.parseToolCall(toolCall, filePath);
          if (schema) {
            schemas.push(schema);
          }
        }
      }
    
      console.log(`[TypeScript] Found ${schemas.length} tool definitions`);
      return schemas;
    }
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 of behavioral disclosure. It mentions scanning and parsing actions but doesn't describe what happens during execution: whether it's read-only, if it modifies files, error handling, performance characteristics, or output format. For a tool with 3 parameters and no annotations, this leaves significant behavioral gaps.

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?

The description is appropriately concise with two sentences that directly state the tool's function. It's front-loaded with the core purpose and avoids unnecessary details. However, it could be slightly more structured by explicitly separating purpose from method.

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?

Given the tool has 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the extracted schemas look like, how they're returned, error conditions, or typical use cases. For a tool performing code analysis with multiple configuration options, more context is needed to guide effective usage.

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 description coverage is 100%, so the schema already documents all parameters (rootDir, include, exclude) with descriptions. The description adds no additional parameter semantics beyond implying source code scanning context. It doesn't explain parameter interactions, default behaviors, or examples. Baseline 3 is appropriate when schema does the heavy lifting.

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?

The description clearly states the tool's purpose: 'Extract MCP tool definitions (ProducerSchemas) from server source code' with specific verbs 'scans' and 'parses'. It identifies the resource (server source code) and method (scanning for server.tool() calls). However, it doesn't explicitly differentiate from sibling tools like 'extract_file' or 'trace_file' that might also work with source code.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'extract_file' (which might extract files rather than schemas) or 'trace_file' (which might trace usage). There's no context about prerequisites, when this extraction is needed, or what scenarios warrant its use over other tools.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Mnehmos/trace-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server