Skip to main content
Glama

extract_file

Extract MCP tool definitions from TypeScript files to validate contracts and prevent runtime errors in data producer-consumer interactions.

Instructions

Extract MCP tool definitions from a single TypeScript file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filePathYesPath to a TypeScript file

Implementation Reference

  • Handles the 'extract_file' MCP tool call: parses input, invokes extractFromFile, and formats response with extracted schemas.
    case 'extract_file': {
      const input = ExtractFileInput.parse(args);
      log(`Extracting from file: ${input.filePath}`);
      
      const schemas = await extractFromFile(input.filePath);
      
      return {
        content: [
          {
            type: 'text',
            text: JSON.stringify({
              success: true,
              count: schemas.length,
              schemas,
            }, null, 2),
          },
        ],
      };
    }
  • Zod schema defining input validation for the extract_file tool (filePath parameter).
    const ExtractFileInput = z.object({
      filePath: z.string().describe('Path to a single TypeScript file to extract schemas from'),
    });
  • src/index.ts:143-153 (registration)
    Registers the extract_file tool in the MCP server's listTools response, providing name, description, and JSON schema.
    {
      name: 'extract_file',
      description: 'Extract MCP tool definitions from a single TypeScript file.',
      inputSchema: {
        type: 'object',
        properties: {
          filePath: { type: 'string', description: 'Path to a TypeScript file' },
        },
        required: ['filePath'],
      },
    },
  • Implements extractFromFile: determines language parser, extracts schemas from the target file by including only that file, and filters results.
    export async function extractFromFile(filePath: string, language?: string): Promise<ProducerSchema[]> {
      // For backward compatibility, default to TypeScript
      const lang = language || 'typescript';
    
      if (!hasParser(lang)) {
        throw new Error(
          `No parser available for language: ${lang}. Make sure to call bootstrapLanguageParsers() at startup.`
        );
      }
    
      const parser = getParser(lang);
    
      // Extract from the directory containing the file
      const rootDir = filePath.substring(0, filePath.lastIndexOf('/') || filePath.lastIndexOf('\\'));
      const fileName = filePath.substring((filePath.lastIndexOf('/') || filePath.lastIndexOf('\\')) + 1);
    
      const allSchemas = await parser.extractSchemas({
        rootDir: rootDir || '.',
        include: [fileName],
      });
    
      return allSchemas.filter(s => s.location.file === filePath);
    }
Behavior2/5

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

With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose error conditions (e.g., invalid file paths), output format, whether it's read-only or has side effects, performance characteristics, or any constraints. This leaves significant behavioral gaps for a tool that presumably parses and analyzes code.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a single-parameter tool with straightforward functionality.

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 tool that extracts structured definitions from code (a non-trivial operation), the description is incomplete. With no annotations and no output schema, it doesn't explain what the extracted definitions look like, error handling, or limitations. The context signals indicate moderate complexity (parsing TypeScript), but the description doesn't address this adequately.

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 the single parameter 'filePath' as 'Path to a TypeScript file'. The description adds no additional parameter semantics beyond implying the file must contain MCP tool definitions. Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose5/5

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

The description clearly states the specific action ('extract') and resource ('MCP tool definitions') with precise scope ('from a single TypeScript file'). It distinguishes from siblings like extract_schemas (which extracts schemas rather than tool definitions) and trace_file/trace_usage (which trace usage rather than extract definitions).

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 guidance is provided about when to use this tool versus alternatives. While the description implies it works on TypeScript files, it doesn't mention prerequisites (e.g., file must exist), exclusions (e.g., non-TypeScript files), or when to choose other extraction-related siblings like extract_schemas or trace_file.

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