Skip to main content
Glama
Sign In
nodejs-repl-mcp

nodejs-repl-mcp

by unfallenwill
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Evaluate code in session

exec

Evaluate JavaScript in a persistent Node.js REPL session that preserves state across calls, supports multi-line input and top-level await, returning results, console output, and errors.

Instructions

Evaluate JavaScript in a named REPL session with full node:repl semantics. Syntax-incomplete input is buffered and continues on the next exec (multi-line). Returns the inspected result, captured console output, and any error. State persists between execs.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "code": "<code>"
    },
    "name": "exec"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeYesJavaScript to evaluate (supports top-level await)
nameYesTarget session name

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are present, so the description carries the full behavioral burden. It discloses state persistence between execs, buffering of syntax-incomplete input across calls, and the return content (inspected result, console output, error). It omits minor details like the exact response structure or whether a missing session is auto-created, but the core execution semantics are transparent.

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?

Four short, information-dense sentences, each earning its place: the primary action and semantics, the buffering behavior, the return values, and state persistence. The most important fact (evaluate JavaScript in a named session) is front-loaded.

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

Completeness4/5

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

For a side-effecting, stateful execution tool with no annotations and no output schema, the description is largely complete: it covers return values, multi-line buffering, and persistence. It could be stronger by stating whether the session must already exist or whether exec auto-creates it, but overall an agent has enough to call and interpret the result correctly.

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 both parameters already have meaningful descriptions, so the baseline is 3. The description adds extra value by linking the name parameter to persistent session state and clarifying that code is evaluated with full node:repl multi-line semantics, which enriches the meaning of both parameters.

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 opens with a specific verb and resource: 'Evaluate JavaScript in a named REPL session.' It goes beyond a generic restatement by naming node:repl semantics and explicitly distinguishing the tool's behavior (evaluation with persistent state) from the session-management siblings like create_session or list_sessions, so an agent can tell it apart.

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

Usage Guidelines4/5

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

The tool's use case is explicit: evaluate JavaScript in an existing named session, with multi-line input continuing on subsequent exec calls. It does not explicitly name alternatives or exclusions, but the sibling set and the phrase 'named REPL session' make the division of responsibility clear: exec is for evaluation, while create_session/list_sessions/history handle session management.

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