Skip to main content
Glama
ajbisht
by ajbisht

execute_code

Run TypeScript/JavaScript in an isolated sandbox to orchestrate MCP tools, filter intermediate data in memory, and return only final results to reduce token usage.

Instructions

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>;
  }
}

Input Schema

NameRequiredDescriptionDefault
codeYesAsync JavaScript/TypeScript snippet to execute (e.g. `const res = await mcp.my_tool(); return res.filter(...);`)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

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.

Deploy Server

Other Tools