Ts Meta

A Model Context Protocol (MCP) server that enables dynamic TypeScript scripting across multiple configured MCP servers.

Outcome!

It worked really well, auto-gen and tests working, but MCP does not provide a return structure definition. Therefor I cannot generate types for the return, as a result we are quite limited in terms of building a script that could cover nested or pipelined tool calls.

It was a fun project that I vibecoded during evening tv. But I suspect this is the end of the project because the structure is insufficient to detect all the required info.

If I wanted to keep going: On meta-server init I could try to run enough of the endpoints to auto detect the result. AND / OR I could store the results somewhere and have this MCP learn / update it's types over time based on results.

Purpose

This MCP acts as a meta-layer that:

• Aggregates tools from multiple configured MCP servers
• Generates TypeScript definitions for all available tools
• Executes user-provided TypeScript scripts that can invoke any configured tool
• Provides a unified interface for multi-MCP orchestration

Use Cases

• Compose complex workflows across multiple MCP servers
• Write reusable TypeScript scripts that leverage multiple tool ecosystems
• Dynamically discover and use tools without manual type definitions
• Enable LLMs to write and execute multi-tool scripts in a single operation

Architecture

Components

1. Config Manager: Loads and validates MCP server configurations
2. MCP Client Pool: Maintains connections to configured MCP servers
3. Spec Generator: Introspects tools and generates TypeScript definitions (using AWS Bedrock Claude if needed)
4. Script Executor: Compiles and runs user TypeScript scripts with tool access
5. Tool Proxy: Routes tool calls from scripts to appropriate MCP servers

Design Considerations

Tool Discovery

• On startup, connect to all configured MCP servers
• Query each server's available tools via MCP protocol
• Cache tool schemas for definition generation

TypeScript Definition Generation

• Convert MCP tool schemas to TypeScript interfaces
• Generate a unified module with all tool functions
• Use AWS Bedrock Claude for complex schema transformations if direct mapping fails
• Include JSDoc comments with tool descriptions

Script Execution Flow

1. Receive TypeScript script from run-script tool
2. Inject tool proxy functions matching generated definitions
3. Compile TypeScript to JavaScript (using ts-node or esbuild)
4. Execute default export function
5. Capture tool calls and route to appropriate MCP servers
6. Return results or error summary to caller

Error Handling

• Compilation errors: Return TypeScript diagnostics
• Runtime errors: Capture stack traces and context
• Tool invocation errors: Include MCP server responses
• Use Bedrock to summarize complex error chains into actionable feedback

Security

• Sandbox script execution (consider VM2 or isolated worker threads)
• Validate tool calls against known schemas
• Timeout protection for long-running scripts
• No filesystem or network access from scripts (only via MCP tools)

Implementation Task List

Phase 1: Core Infrastructure

• Initialize stdio MCP server boilerplate
• Install required dependencies
• Define configuration schema for MCP server list
• Implement MCP client connection manager
• Create tool discovery and caching system

Phase 2: Spec Generation

• Build MCP schema to TypeScript type converter
• Implement AWS Bedrock integration for complex schemas
• Create get-spec tool that returns TypeScript definitions
• Add caching and invalidation for generated specs

Phase 3: Script Execution

• Set up TypeScript compilation pipeline
• Create tool proxy injection system
• Implement run-script tool with script parameter
• Build tool call router to target MCP servers

Phase 4: Error Handling & Feedback

• Capture and format compilation errors
• Implement runtime error handling
• Integrate Bedrock for error summarization
• Add detailed logging and debugging output

Phase 5: Testing & Documentation

• Create example configurations
• Write sample TypeScript scripts
• Add integration tests with mock MCP servers
• Document configuration format and usage examples

Phase 6: Optimization

• Add connection pooling and reuse
• Implement spec caching strategies
• Optimize script compilation (incremental builds)
• Add performance monitoring

Configuration Format

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "..."
      }
    }
  }
}

Tools Provided

get-spec

Returns TypeScript definitions for all available tools from configured MCP servers.

Returns: String containing TypeScript module definition

run-script

Executes a TypeScript script with access to all configured tools.

Parameters:

• script: TypeScript code with default export function () => Promise<any>

Returns: Script execution result or error summary

Example Usage

// Script provided to run-script tool
export default async function() {
  // Tools are injected based on configured MCPs
  const files = await filesystem.listDirectory({ path: "/src" });
  const issues = await github.listIssues({ repo: "owner/repo" });
  
  return {
    fileCount: files.length,
    openIssues: issues.filter(i => i.state === "open").length
  };
}

Development

Install dependencies:

npm install

Build the server:

npm run build

For development with auto-rebuild:

npm run watch

Testing

Run the integration test suite:

npm test

The test suite includes:

1. Server startup and tool discovery
2. TypeScript spec generation from MCP tools
3. Script compilation and execution
4. Bedrock-powered script generation - AI writes and executes scripts using available tools

Prerequisites for Full Testing

AWS Bedrock Access (required for test 5):

1. Configure AWS credentials in ~/.aws/credentials
2. Enable Bedrock model access in AWS Console:
   • Navigate to AWS Bedrock → Model access
   • Request access to: Claude 3.5 Sonnet v2 (cross-region inference profile)
3. Ensure your AWS region supports Bedrock (e.g., us-east-1)

Without Bedrock access, test 5 will fail. Tests 1-4 will still pass and verify core functionality.

Usage

1. Create a configuration file mcp-config.json:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/tmp"]
    }
  }
}

2. Set the config path (optional, defaults to ./mcp-config.json):

export MCP_CONFIG_PATH=./mcp-config.json

3. Configure AWS credentials for Bedrock (optional, for error summarization):

export AWS_REGION=us-east-1
export AWS_ACCESS_KEY_ID=your-key
export AWS_SECRET_ACCESS_KEY=your-secret

4. Run the server:

node build/index.js

Or use with Claude Desktop by adding to your config:

{
  "mcpServers": {
    "ts-mcp-meta": {
      "command": "node",
      "args": ["/path/to/ts-mcp/build/index.js"],
      "env": {
        "MCP_CONFIG_PATH": "/path/to/mcp-config.json"
      }
    }
  }
}

Debugging

Since MCP servers communicate over stdio, debugging can be challenging. We recommend using the MCP Inspector:

npm run inspector

The Inspector will provide a URL to access debugging tools in your browser.

Dependencies

• @modelcontextprotocol/sdk: MCP protocol implementation
• typescript: TypeScript compiler
• @aws-sdk/client-bedrock-runtime: For AI-assisted spec generation
• esbuild: Script compilation
• zod: Configuration validation

Future Enhancements

• Persistent script library
• Script versioning and history
• Parallel tool execution
• Streaming results for long-running scripts
• Web-based script editor and debugger