Skip to main content
Glama
ajbisht
by ajbisht

OpenCodeMode (MCP)


Table of Contents


Related MCP server: MCP Code Mode

Overview

OpenCodeMode is an open-source, vendor-agnostic implementation of the Code Mode pattern for the Model Context Protocol (MCP).

Instead of forcing your AI Agent to execute individual JSON-RPC tool calls across multiple round-trips—flooding the context window with raw schemas and bloated intermediate responses—OpenCodeMode collapses all downstream tools into one single tool (execute_code).

The agent writes a concise TypeScript snippet against generated .d.ts definitions. That code executes inside a hardened, isolated sandbox (Deno or Node.js Worker), joins and filters data in memory, and returns only the final answer to the LLM in 1 single turn.

Deploy Anywhere: Designed for any platform—Cloud (AWS, GCP, Azure), On-Premises, Hybrid, Kubernetes, Docker, or local machines.


The Problem: Why Traditional MCP Breaks at Scale

When connecting enterprise agents to modern hubs (Jira, ServiceNow, GitHub, AWS, Postgres, Jenkins, etc.), standard MCP architectures hit three massive bottlenecks:

TRADITIONAL MCP: 7 TURNS, 4,344 TOKENS, 12.6 SECONDS
LLM  <-- (350 tokens of JSON schemas) -----------------------------> Agent
Turn 1: LLM calls db.list_users()     --> 100 raw JSON records (3,900 tokens) enters context!
Turn 2: LLM calls jira.get_issue(#1)  --> raw issue payload enters context
Turn 3: LLM calls jira.get_issue(#2)  --> raw issue payload enters context
...
Turn 7: LLM finally returns answer    --> 12.6s elapsed, context bloated, high API cost!
  1. Schema Context Exhaustion: Dumps dozens or hundreds of JSON schemas into the system prompt on every request (costing 40,000 to 100,000+ tokens before the user even types a word).

  2. Intermediate Data Pollution: In multi-step workflows, large intermediate payloads (e.g. 5 MB build logs, 500-row SQL dumps, raw API JSON) are echoed back and forth through the model context.

  3. Turn-by-Turn Latency: 10 tool calls require 10 back-and-forth LLM inference round-trips (~30 to 60 seconds).

  4. Tool Call Limit Crashing: LLMs routinely hit maximum step limits (e.g., 25–50 iterations) when doing repetitive loops or bulk processing.


The Solution: OpenCodeMode Architecture

OpenCodeMode sits as an intelligent gateway layer between the AI Agent and your MCP servers:

OPENCODEMODE: 1 TURN, 602 TOKENS, 1.8 SECONDS
LLM  <-- (250 tokens of compact .d.ts types) ------------------------> Agent
Turn 1: LLM writes ONE TypeScript script:
        "const users = await mcp.postgres.list_users();
         const target = users.filter(u => u.rating >= 4.7);
         for (const u of target) await mcp.bonus.award({ id: u.id });
         return target.map(u => u.name);"
               │
               ▼ (Executes locally in secure Sandbox in 40ms)
        Sandboxed RAM filters 100 records in memory.
        Downstream tools called via fast local IPC.
               │
               ▼
LLM  <-- Returns clean 3-line result array --------------------------> Done in 1 Turn!

End-to-End Request Flow

As shown in the architecture diagram, the lifecycle of a user request proceeds through these 15 steps:

[Developer/User] ──(1) Natural Language──► [Customer App / IDE]
                                                    │
                                         (2) HTTPS Request (AuthN/Rate Limit)
                                                    ▼
                                          [customer-api Gateway]
                                                    │
                                         (3) Forward Context & Task
                                                    ▼
                                         [coordinator-agent]
                                           │              │
                   (4) Request Plan / Code │              │ (6) Optional Specialist
                                           ▼              ▼     Agents (worklist, policy)
                                     [External LLM]       │ (7) Return Results
                                           │              │
                   (5) Plan / Code Script  │              ▼
                                           ▼     (8) Calls execute_code()
                                         [OPEN-CODE-MODE GATEWAY]
                                           │  ├── 1. Single Tool: execute_code()
                                           │  ├── 2. Isolated Sandbox (No Net/No ENV)
                                           │  └── 3. Routing & Tool Bridge
                                           │
                                         (9) Routes to Downstream Servers
                                           ▼
                    ┌──────────────────────┬──────────────────────┐
                    ▼                      ▼                      ▼
           [mcp-worklist-server]    [mcp-hr-server]       [mcp-email-server]
                    │                      │                      │
             (10) API Calls         (10) API Calls         (10) API Calls
                    ▼                      ▼                      ▼
             [Git / Worklist]        [HR System]            [Email System]
                    │                      │                      │
             (11) Raw Results Trapped in Sandbox RAM (Only Filtered Summary Returns)
                    │
                    ▼
          [coordinator-agent] ──(12) Final LLM Call──► [External LLM]
                    │                                         │
                    │ ◄───────────(13) Final Answer───────────┘
                    │
          (14) Stream Final Response
                    ▼
          [customer-api] ──(15) Stream Response to User──► [Developer / IDE]
  1. User asks coding task: Request originates from Web UI, IDE, or chat app.

  2. HTTPS Request: Passes through customer-api for authentication, rate limiting, and trace generation.

  3. Forward Context: API sends user prompt and workspace context to the coordinator-agent.

  4. Request Plan / Code: Coordinator calls the External LLM (Claude, GPT, Gemini).

  5. LLM Returns Script: The LLM inspects compact .d.ts declarations and writes a single TypeScript orchestration snippet.

  6. Optional Specialist Agents: If needed, coordinator queries domain specialist agents (worklist, policy, notification).

  7. Specialists Return Results: Context is consolidated at the coordinator.

  8. Calls execute_code: Coordinator invokes OpenCodeMode's execute_code tool with the snippet.

  9. Spoke Routing: OpenCodeMode's IPC bridge routes tool calls to target MCP servers (Worklist, HR, Email).

  10. Downstream Execution: MCP servers invoke external enterprise APIs and databases.

  11. In-Memory Filtering: Thousands of raw JSON records are processed in sandbox RAM; only filtered results return.

  12. Coordinator Calls LLM for Synthesis: Sends filtered observations to LLM for final formatting.

  13. Final Answer: External LLM returns concise answer.

  14. Coordinator Streams Response: Formatted output sent back to customer-api.

  15. Delivery: Result streamed back to developer in 1 single conversational turn.


Cloudflare Code Mode vs. OpenCodeMode: What We Changed

The pioneering idea of "Code Mode" was published by Cloudflare's AI team and Cloudflare Agents.

While Cloudflare demonstrated the power of the concept, their implementation was designed specifically for Cloudflare's proprietary cloud ecosystem. OpenCodeMode is built from the ground up as a universal, self-hosted, enterprise-grade open-source solution:

Feature / Dimension

Cloudflare Code Mode

OpenCodeMode (This Repo)

Vendor Independence

Locked to Cloudflare Workers & Cloudflare Workers AI.

100% Vendor-Agnostic. Runs on your laptop, Docker, Kubernetes, AWS, GCP, Azure, or bare metal.

Runtime Requirements

Requires Cloudflare account, wrangler, and dynamic code evaluation flags.

Runs on Node.js (>=18) with automatic Deno sandbox detection or Node Worker Thread fallback.

Multi-Spoke Hub

Primarily wraps tools known to the specific worker script.

Multi-Spoke Hub (codemode.config.json): Seamlessly wraps any arbitrary MCP servers (Jira, GitHub, ServiceNow, Postgres) with automatic namespacing (mcp.jira.*, mcp.github.*).

Configuration Standard

Custom code configuration.

Industry-Standard mcpServers format with automatic environment variable expansion (${TOKEN}).

Zero-Config CLI

N/A (Cloudflare Worker script).

Instant CLI with --wrap "<cmd>" or --config <path> to wrap any server in 5 seconds.

Security Isolation

Relies on Cloudflare V8 worker isolate runtime.

Multi-layer sandbox enforcement: Process-level --no-net, --no-env, --no-read, --no-write, 128MB RAM caps, and hard 15s watchdog timers.

Client Compatibility

Custom agent integration.

Native MCP protocol compliance: Works out-of-the-box with Claude Desktop, Cursor, Antigravity, VS Code, and any MCP client.


Performance & Token Benchmark

We conducted a verified, reproducible benchmark comparing Traditional MCP tool calling against OpenCodeMode executing an audit over 100 customer records and triggering automated fraud flagging:

Metric

Traditional MCP

OpenCodeMode

Improvement

Tool Schema Tokens

349 tokens

255 tokens

-26.9%

Intermediate Data in Context

3,943 tokens

0 tokens (processed in RAM)

100% saved

Total Context Window Used

4,344 tokens

602 tokens

-86.1% less tokens

Inference Turns (Round Trips)

7 turns

1 turn

-86% fewer turns

End-to-End Latency

~12.6s

~1.8s

6.8x FASTER

Sandbox Execution Time

N/A

46 ms

Sub-millisecond local IPC

To run this benchmark live on your machine:

npm run benchmark

Installation & Quickstart

Prerequisites

  • Node.js: v18.0.0 or higher (v20+ or v24 recommended)

  • Optional (Recommended): Deno for OS-level subprocess sandboxing (OpenCodeMode automatically falls back to hardened Node Worker Threads if Deno is not installed).

1. Clone & Build

git clone https://github.com/your-org/open-codemode.git
cd open-codemode
npm install
npm run build

2. Verify Your Setup

# Run the 19 automated unit & integration test suites
npm test

# Run security sandbox regression attacks
npm run test:security

3. Docker Deployment (Optional)

You can also run OpenCodeMode as a hardened Docker container with bundled Deno sandbox isolation:

# Build the Docker image
docker build -t open-codemode-mcp .

# Run with your codemode.config.json mounted
docker run -i --rm -v $(pwd)/codemode.config.json:/app/codemode.config.json open-codemode-mcp

Configuration: Connecting Your MCP Servers

OpenCodeMode works with any MCP server. You don't need to write code to connect your tools—just specify them using one of the three modes below.

Mode 1: Multi-Spoke Hub (codemode.config.json)

Connect multiple MCP servers (Jira, GitHub, Postgres, AWS, ServiceNow) simultaneously into a unified sandbox.

Generate a starter configuration file:

node dist/cli.js --init

Or create codemode.config.json in your project root:

{
  "$schema": "https://json.schemastore.org/mcp-config.json",
  "mcpServers": {
    "jira": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-e", "JIRA_API_TOKEN", "mcp/jira"],
      "env": {
        "JIRA_API_TOKEN": "${JIRA_API_TOKEN}"
      }
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "postgres": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://${DB_USER}:${DB_PASS}@localhost:5432/mydb"
      ]
    },
    "aws": {
      "command": "python",
      "args": ["-m", "mcp_server_aws"]
    }
  },
  "executionOptions": {
    "timeoutMs": 15000,
    "memoryLimitMb": 128
  }
}

Then run OpenCodeMode:

# Auto-loads codemode.config.json in the current working directory
node dist/cli.js

# Or specify a custom config file path
node dist/cli.js --config /path/to/my-config.json

Security Note: Environment variables (like ${GITHUB_TOKEN}) are expanded at runtime on the host machine. No credentials are ever passed into the sandbox.


Mode 2: Instant Single-Server Wrapper (--wrap)

If you just want to wrap a single MCP server on the fly without creating a configuration file:

# Wrap a PostgreSQL MCP server
node dist/cli.js --wrap "npx -y @modelcontextprotocol/server-postgres postgresql://localhost/mydb"

# Wrap an in-memory MCP server
node dist/cli.js --wrap "npx -y @modelcontextprotocol/server-memory"

# Wrap a custom Python MCP server
node dist/cli.js --wrap "python -m my_mcp_server"

Mode 3: Embedded TypeScript Library

You can import OpenCodeMode directly into your own TypeScript / JavaScript agent backend:

import { CodeModeServer, DownstreamClient, MultiDownstreamClient } from "open-codemode";

// Connect to downstream spokes
const downstream = new MultiDownstreamClient({
  jira: { command: "docker", args: ["run", "-i", "--rm", "mcp/jira"] },
  github: { command: "npx", args: ["-y", "@modelcontextprotocol/server-github"] }
});
await downstream.connect();

// Create upstream Code Mode server
const server = new CodeModeServer({
  downstreamClient: downstream,
  executionOptions: { timeoutMs: 15000, memoryLimitMb: 128 }
});

await server.start();

How the LLM Orchestrates Tools in 1 Turn

When the AI Agent connects to OpenCodeMode, it receives a single tool: execute_code. All tools from your configured servers are automatically compiled into clean TypeScript namespaces:

declare namespace mcp {
  namespace jira {
    /** Search Jira tickets with JQL */
    function search_issues(args: { jql: string }): Promise<any>;
    /** Update issue status */
    function update_issue(args: { id: string; status: string }): Promise<any>;
  }

  namespace github {
    /** Get pull request details */
    function get_pr(args: { prNumber: number }): Promise<any>;
  }

  namespace postgres {
    /** Execute SQL query */
    function query(args: { sql: string }): Promise<any>;
  }
}

The LLM writes standard async TypeScript to orchestrate across spokes:

// Script written by the LLM:
const openTickets = await mcp.jira.search_issues({ jql: "status = 'Review' AND priority = 'High'" });

const results = [];
for (const ticket of openTickets) {
  // Query downstream GitHub spoke
  const pr = await mcp.github.get_pr({ prNumber: ticket.pr_id });
  
  // In-memory logic: only act if PR is approved and merged
  if (pr.merged) {
    await mcp.jira.update_issue({ id: ticket.id, status: "Done" });
    results.push({ ticket: ticket.key, title: ticket.summary, pr: pr.title });
  }
}

// Return only the clean, final report
return results;

How to Connect to Any IDE or Agent

OpenCodeMode runs as a standard MCP server communicating over stdio. It can be added to any MCP-compliant tool or agent in seconds.

1. Claude Desktop

Add to your claude_desktop_config.json:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "opencode-hub": {
      "command": "node",
      "args": [
        "C:/path/to/open-codemode/dist/cli.js",
        "--config",
        "C:/path/to/open-codemode/codemode.config.json"
      ]
    }
  }
}

2. Cursor & Windsurf

Add to .cursor/mcp.json in your workspace or global settings:

{
  "mcpServers": {
    "opencode-hub": {
      "command": "node",
      "args": [
        "/path/to/open-codemode/dist/cli.js",
        "--config",
        "/path/to/open-codemode/codemode.config.json"
      ]
    }
  }
}

3. Google Antigravity & Gemini CLI

Add to mcp_config.json:

{
  "mcpServers": {
    "open-codemode": {
      "command": "node",
      "args": [
        "/path/to/open-codemode/dist/cli.js",
        "--config",
        "/path/to/open-codemode/codemode.config.json"
      ]
    }
  }
}

4. VS Code (Cline / Roo Code)

In your Cline / Roo Code MCP Settings:

{
  "mcpServers": {
    "opencode": {
      "command": "node",
      "args": [
        "/path/to/open-codemode/dist/cli.js",
        "--config",
        "/path/to/open-codemode/codemode.config.json"
      ]
    }
  }
}

5. Custom Multi-Agent Frameworks (LangGraph, CrewAI, AutoGen)

Connect any agent worker via stdio or import OpenCodeMode as a Node.js library directly into your agent runner:

# Python LangGraph / CrewAI example invoking OpenCodeMode CLI over stdio:
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

server_params = StdioServerParameters(
    command="node",
    args=["/path/to/open-codemode/dist/cli.js", "--config", "/path/to/codemode.config.json"]
)

Security Model & Sandboxing

Because OpenCodeMode executes LLM-generated code, security and isolation are primary engineering requirements.

+-------------------------------------------------------------+
| HOST PROCESS (Node.js)                                      |
| * Stores API keys, database credentials, host tokens        |
| * Speaks to upstream Agent and downstream MCP servers       |
| * Validates & sanitizes all IPC messages                    |
+------------------------------+------------------------------+
                               | IPC Channel (Line JSON-RPC)
                               v
+-------------------------------------------------------------+
| HARDENED SANDBOX (Deno / Worker)                            |
| 🔒 NO NETWORK:      --no-net (cannot make outbound fetch)   |
| 🔒 NO FILESYSTEM:   --no-read --no-write (cannot read disk) |
| 🔒 NO ENV SECRETS:  --no-env (cannot read process.env)      |
| 🔒 MEMORY CEILING:  128 MB max V8 heap space                |
| 🔒 HARD WATCHDOG:   15,000 ms kill timer terminates hangs   |
+-------------------------------------------------------------+

Threat Vector

Mitigation Strategy

Sandbox Breakout

Process-level isolation via Deno or dedicated Worker threads with empty prototypes.

Data Exfiltration

Sandbox launched with --no-net. Network sockets and fetch calls are blocked.

Filesystem Tampering

Sandbox launched with --no-read and --no-write. Host disk cannot be inspected.

Credential Theft

Sandbox launched with empty env: {}. Host credentials never enter sandbox memory.

Denial of Service (Infinite Loops)

Hard 15-second watchdog timer terminates and reaps child processes that exceed runtime limits.

Memory Exhaustion (OOM)

Hard V8 old space ceiling (--v8-flags=--max-old-space-size=128).


Running Benchmarks & Automated Tests

OpenCodeMode enforces strict testing standards:

# 1. Run all unit & integration test suites
npm test

# 2. Run security boundary & attack tests
npm run test:security

# 3. Run the head-to-head performance benchmark
npm run benchmark

# 4. Run vulnerability scan (Guaranteed 0 CVEs)
npm audit

Test Suite Summary:

▶ OpenCodeMode End-to-End Integration (2 tests)
▶ IpcBridge (3 tests)
▶ Multi-Spoke Configuration & Loading (2 tests)
▶ Multi-Spoke Type Generator (1 test)
▶ MultiDownstreamClient & Sandbox Execution (2 tests)
▶ Sandbox Security & Execution Tests (6 tests)
▶ TypeGenerator (3 tests)

✔ 19 tests passed, 0 failed (1.8s)
✔ 0 vulnerabilities found

License

This project is licensed under the MIT License. Feel free to use it in your commercial or open-source AI agent applications.

Available Tools

2 tools
execute_codeA

Execute TypeScript/JavaScript code inside an isolated sandbox to orchestrate tools and filter data. Intermediate data stays in memory; return only the final result to save tokens.

Available APIs on the global mcp object:

/**
 * OpenCodeMode Injected API
 * Every function executes through the secure IPC bridge to the downstream MCP server.
 * Intermediate data stays inside sandbox memory; return only the desired result.
 */
declare namespace mcp {
  namespace demo {
    /**
     * Returns company employees with their department, salary, and performance ratings
     * @param args.department Optional filter by department (e.g. 'Engineering', 'Sales', 'Product')
     */
    function list_employees(args?: {
        department?: string;
      }): Promise<any>;
    /**
     * Awards an annual performance bonus to an employee
     * @param args.employeeId Employee ID (e.g. EMP-01)
     * @param args.amount Bonus amount in USD
     */
    function award_bonus(args: {
        employeeId: string;
        amount: number;
      }): Promise<any>;
  }
}
NameRequiredDescriptionDefault
codeYesAsync JavaScript/TypeScript snippet to execute (e.g. `const res = await mcp.my_tool(); return res.filter(...);`)

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does meaningful work: it discloses that execution is sandboxed, that intermediates stay in memory rather than being returned, and that every injected function goes through a 'secure IPC bridge to the downstream MCP server' — which tells the agent side effects (like award_bonus) are real, not simulated. It still omits execution limits, timeout behavior, and error semantics for a tool that runs arbitrary code.

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 first two sentences are front-loaded and high-value, stating capability and the token-saving rationale before any detail. The large fenced TypeScript block is long but earns its place since it is the only source of truth about available APIs; it could be trimmed of the redundant doc comment restating 'Intermediate data stays inside sandbox memory'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-complexity code-execution tool with no annotations and no output schema, the description covers the API surface and return philosophy well but leaves the failure surface undefined: no timeout, memory cap, network restrictions, error propagation model, or whether a non-returning snippet throws. An agent can write a call but cannot predict what happens when the code fails or hangs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and there is only one parameter, so the baseline would be 3; the description exceeds that by inlining the TypeScript declarations for the `mcp` global, which is the single most important semantic detail about what the `code` string may reference. The JSDoc on list_employees and award_bonus documents argument shapes and even example values ('EMP-01', 'Engineering') that the input schema cannot express.

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?

States a specific verb and resource — 'Execute TypeScript/JavaScript code inside an isolated sandbox' — and immediately narrows the intended role to 'orchestrate tools and filter data'. This is unmistakably distinct from the sibling get_tool_types, which by name only enumerates types, so the agent can tell the two apart without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'to orchestrate tools and filter data' plus 'return only the final result to save tokens' implies that this tool is for multi-step orchestration where intermediate payloads would otherwise flood context. However, it never states when not to use it (e.g., a single direct tool call) and never mentions the sibling get_tool_types as a discovery step before writing code. Usage is implied rather than routed.

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

get_tool_typesA

Returns the complete TypeScript declaration file (.d.ts) describing all available downstream tools.

NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior3/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; it does disclose the return payload (a full .d.ts), which is genuinely useful since there is no output schema. It does not state that the call is read-only/no-side-effect, nor whether the declaration file is large or complete enough to rely on.

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?

A single sentence with no filler, and the key information (what is returned and its format) is front-loaded. Nothing redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-param tool with no annotations and no output schema, describing the return as a .d.ts is the essential piece and it is present. What is missing is the connective tissue: that this output is meant to inform subsequent execute_code calls, and any note on size, staleness, or scope of 'downstream tools'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the schema is an empty object and no parameter prose is needed.

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?

States a specific verb and resource: returns the complete TypeScript declaration file (.d.ts) covering all downstream tools. That is concrete enough to distinguish it from the only sibling, execute_code, though it never names that sibling or frames itself as a discovery step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use statement or exclusion versus execute_code; the usage is only implied by the word 'downstream tools'. An agent can infer this is a discovery/introspection call, but nothing tells it whether to call this first, when to skip it, or how the output relates to execute_code.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedexecute_code
    • First observedget_tool_types

TDQS

A3.9/5.0

Scored across 2 tools

Disambiguation5/5

The two tools are clearly distinct: execute_code runs TypeScript/JavaScript in a sandbox, while get_tool_types returns the downstream TypeScript declarations. An agent can easily tell which tool to use for execution versus discovery.

Naming Consistency5/5

Both names follow a consistent snake_case verb_noun pattern: execute_code and get_tool_types. There is no mixing of conventions or vague naming.

Tool Count4/5

Two tools is minimal, but for a meta-execution server this surface is well-scoped: one tool discovers downstream APIs and the other executes code against them. It is slightly thin by typical MCP standards but reasonable for the stated purpose.

Completeness4/5

The pair covers the core lifecycle of discovering downstream tool types and executing orchestration code against them. Minor gaps exist around richer discovery or validation, but the essential workflow has no dead ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    A
    quality
    Not graded
    maintenance
    Enables execution of TypeScript code to call MCP tools instead of direct tool calls, reducing token usage by up to 98% while orchestrating complex multi-tool workflows through secure sandboxed code execution.
    1
    -
  • F
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to write and execute Python code in an isolated sandbox that can orchestrate multiple MCP tool calls, reducing context window bloat and improving efficiency for complex workflows.
    23
    -
  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to compose MCP tool calls into Unix-style pipelines, executing complex workflows server-side and returning only the final result.
    22
    Apache 2.0
  • F
    license
    Not graded
    quality
    C
    maintenance
    Enables MCP tool calls with strict schema validation and stdio isolation, while providing a security gateway for tool-level authorization, streaming PII redaction, and model failover routing.
    -