Explore code-execution-with-MCP pattern for token-efficient tool responses

[czlonkowski]

Background

Anthropic published Code execution with MCP: Building more efficient agents describing a pattern where MCP servers expose a sandboxed code-execution surface and the model writes scripts that filter / transform tool output before any of it ever reaches the context window. The headline result is large reductions in context consumption on tool-heavy workflows.

Raised in #473 by @skyhi69 and revisited in #482 by @ArtemSultanov-PG. Both users are hitting context limits while building n8n workflows and explicitly asked whether n8n-mcp could adopt the pattern.

What we have today (for context)

Already built:

• get_node detail levels (minimal / standard / full) — ~200 / ~1-2k / ~3-8k tokens
• n8n_update_partial_workflow diff format — 18 operations, ~80-90% token saving on update turns
• The companion n8n-skills pack — skills load on demand instead of the system prompt

These cover the easy wins. Code-execution-with-MCP is the next tier and it's a meaningful build, not a tweak.

What this issue is for

A scoping spike, not an implementation commitment. I want to answer:

1. What would it cost to bolt a code-execution surface onto n8n-mcp? A safe sandbox (Deno permissions, isolated-vm, or a separate Docker container) is the hard part. What are the tradeoffs?
2. Which tool responses are the actual context hogs? Profile real sessions. get_node at full is the obvious suspect, but there may be others. Without data we'd be optimizing the wrong thing.
3. What would the user-facing API look like? Probably a new tool like execute_script({ code, inputs }) that runs against a snapshot of the database. Sketch the contract.
4. How does this interact with the skills pack? Skills already encode reusable patterns — could the code-execution surface be the runtime for skills, instead of a parallel system?
5. Security model. This is the showstopper if we get it wrong. What's the threat model — the model is already trusted to call destructive tools, so the surface area concern is more about resource abuse and sandbox escape than authorization.

Acceptance criteria for the spike

• [ ] Short design doc in docs/ covering the five questions above
• [ ] At least one prototype direction tried end-to-end (even a throwaway), so we have real numbers on the cost vs. the win
• [ ] Decision: build, defer, or skip (with reasoning)

Out of scope for the spike

• Any production implementation
• Backwards-compat shims or flag plumbing
• Documentation for end users (we don't know yet whether we're shipping)

References

• Anthropic post: https://www.anthropic.com/engineering/code-execution-with-mcp
• Discussions: #473, #482

Concieved by Romuald Członkowski — https://www.aiadvisors.pl/en

[github-actions[bot]]

🎯 Agentic Issue Triage

This is a well-defined research spike by the repo owner exploring the [code-execution-with-MCP]((www.anthropic.com/redacted) pattern to reduce context-window consumption in tool-heavy workflows. It has clear acceptance criteria (design doc + prototype + decision) and is explicitly not an implementation commitment.

No duplicate open issues found. Referenced discussions #473 and #482 are closed and serve as the user-demand motivation.

📋 Issue Classification

Attribute	Value
Type	Research spike / architectural exploration
Component	MCP server, new execution surface
Priority	Medium — real user pain (context limits), but spike-scoped, no production pressure
Reporter	Repo owner
Existing label	enhancement ✅

🔍 Technical Context

The Anthropic pattern works by giving the model a sandboxed JS/Python runtime as an MCP tool. Instead of receiving raw, verbose tool output into the context window, the model writes a small filter/transform script that runs server-side, and only the reduced result is returned. The win is proportional to how "wide" the raw tool output is — which maps directly to n8n-mcp's get_node at full detail level and any list-style responses.

Existing mitigations already in place:

• get_node detail levels (minimal ~200 tokens, full ~3-8k tokens)
• n8n_update_partial_workflow diff format (80-90% token saving on updates)
• n8n-skills pack (load-on-demand patterns)

The gap: none of these help when the model genuinely needs full node detail but only for a subset of properties. That's where a code-execution surface would shine.

🧪 Suggested Investigation Approach

Step 1 — Profile before optimizing Instrument a sample session (build a workflow with 5+ nodes using get_node at full) and log token counts per tool call. This gives real data for the "which calls are context hogs" question without guessing.

Step 2 — Sandbox evaluation matrix

Option	Pros	Cons
Deno (Deno.permissions)	First-class permission model, fast cold start	Requires Deno runtime installed
isolated-vm (npm)	Pure Node.js, no extra runtime, V8 isolates	Maintained but complex API, no stdlib
vm2 / vm built-in	Zero deps	vm is not a security sandbox; vm2 is archived/broken
Docker sidecar	Strong isolation	Latency, infra complexity, not viable for Claude Desktop users
quickjs-emscripten	Sandboxed, WASM-based, zero native deps	Limited stdlib, higher overhead than isolated-vm

Recommended prototype path: isolated-vm for the Node.js build target (matches the existing runtime), with a Deno-compatible variant as a stretch goal. Docker should be out-of-scope for the spike given the Claude Desktop deployment target.

Step 3 — Sketch the tool contract

// Proposed MCP tool signature
execute_script({
  code: string,          // JS snippet, receives `input` variable
  inputs: Record<string, unknown>,  // tool outputs to pass in
  timeout_ms?: number    // default 2000
}): { result: unknown, elapsed_ms: number }

The model would call get_node({ type: "...", detail: "full" }) internally (server-side), pass the result as input, and run a filter like input.properties.filter(p => p.name === "url") — only the reduced result returns to the context.

Step 4 — Skills pack integration question The n8n-skills pack currently encodes patterns as static text loaded on demand. A code-execution surface could instead let skills be executable: a skill calls execute_script with the pattern logic, producing a ready-to-use node config. This would be a meaningful architectural simplification if the security story is sound. Worth a short design note in the spike doc.

🔐 Security Considerations

The threat model here is narrower than typical code execution because:

1. The model is already trusted to call destructive n8n API tools (create/delete workflows, credentials)
2. The execution is server-side within the MCP server process, not in n8n itself

Primary risks to address in the spike:

• CPU/memory exhaustion — enforce timeout_ms and heap limits in the isolate
• File system access — must be fully blocked; no fs, no require/import of native modules
• Network access — block all outbound; the script should only operate on the passed inputs object
• Prototype pollution / sandbox escape — test against known isolated-vm escape patterns; stay current on CVEs

The spike doc should explicitly record the decision on whether the runtime is considered a trust boundary (i.e., does a malicious prompt leading to execute_script call constitute a meaningful escalation beyond what's already possible via existing tools).

✅ Spike Checklist

• [ ] Profile 3-5 representative sessions to identify top-5 context-consuming tool calls and their token counts
• [ ] Evaluate isolated-vm vs Deno: install, hello-world filter script, latency benchmark, CVE history review
• [ ] Draft execute_script tool contract (inputs, outputs, error shape, timeout behavior)
• [ ] Prototype: wire isolated-vm into the MCP server as a hidden/experimental tool, run one real end-to-end session
• [ ] Document token savings observed vs baseline (quantify the win)
• [ ] Write design doc in docs/code-execution-spike.md answering the 5 questions from the issue
• [ ] Record decision: build / defer / skip with explicit reasoning

🔗 Reference Links

• [Anthropic: Code execution with MCP]((www.anthropic.com/redacted)
• isolated-vm npm package — V8 isolates for Node.js
• quickjs-emscripten — WASM-sandboxed QuickJS
• [Deno permissions model]((docs.deno.com/redacted) — reference for permission design
• [MCP specification — Tools]((spec.modelcontextprotocol.io/redacted) — for shaping the new tool correctly
• Related discussions: #473, #482

Generated by Agentic Triage for issue #716 · ● 245.3K · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/issue-triage.md@13377ddf7e35c2b6e47aa58f45acb228fba902c8