code-mode-alchemy-mcp

execute

Run JavaScript against Alchemy's blockchain APIs to query NFTs, token balances, and transactions via REST or JSON-RPC requests in a sandbox.

Instructions

Execute JavaScript code against Alchemy's APIs. The sandbox provides:

request(url, params?, options?) — GET/REST endpoint; {apiKey} and {network} in URLs are auto-replaced
fetch — raw fetch for custom requests (use for JSON-RPC POST calls)
ALCHEMY_API_KEY — the configured API key string
ALCHEMY_NETWORK — current network (default: eth-mainnet)
console.log() — captured and returned in logs

REST example:

const data = await request(
  "https://{network}.g.alchemy.com/nft/v3/{apiKey}/getNFTsForOwner",
  { owner: "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045", withMetadata: false }
);
return data;

JSON-RPC example:

const res = await fetch(
  `https://{network}.g.alchemy.com/v2/${ALCHEMY_API_KEY}`.replace("{network}", ALCHEMY_NETWORK),
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method: "alchemy_getTokenBalances", params: ["0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"] })
  }
);
return await res.json();

Input Schema

TableJSON Schema

Name	Required	Description	Default
`code`	Yes	JavaScript code to execute. Use return to send back results.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 13, 2026

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the full disclosure burden. It does valuable work by documenting sandbox globals, auto-substitution of {apiKey}/{network}, and that console.log is captured. However, for arbitrary code execution it omits critical traits: whether mutating requests are possible/permitted, execution timeouts, rate limits, and error behavior. These gaps matter for a tool that can issue arbitrary network calls.

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?

Front-loaded with the purpose, then a tight bulleted inventory of sandbox capabilities, then two minimal-but-complete examples. The length is earned: each example teaches a distinct calling convention (REST via request vs JSON-RPC via fetch), and there is no filler.

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?

With no annotations and no output schema, the description must explain results, and it does: `return` sends back data and console.log is captured in logs. Combined with the runnable examples this is close to complete, though timeout/error semantics and any permission boundaries remain unspecified.

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 description coverage is 100% and there is a single parameter, so the baseline is 3. The description adds real value beyond the schema by demonstrating via two complete code samples how the `code` string is structured and how `return` propagates results, which clarifies the contract more concretely than the schema's one-liner.

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 concrete verb (execute) and resource (JavaScript code against Alchemy's APIs) and immediately delineates the sandbox surface. The purpose is unambiguous, but the description never acknowledges or differentiates from the sibling `search` tool, so it falls short of the 5 threshold which requires sibling distinction.

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?

Usage guidance is implied rather than stated: the contrast between `request` (GET/REST) and `fetch` (raw, use for JSON-RPC POST) tells the agent how to use primitives within the sandbox, but nothing says when to reach for `execute` over `search`. The escape-hatch nature is inferable but never explicit.

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

executeA
searchA