The LLM Subcontractor: Inside askgrokmcp

How a minimalist Node.js server uses the Model Context Protocol to let Anthropic's Claude outsource reasoning and image generation to xAI's Grok.

6 min read • View on GitHub • More from marceloceccon

A mechanical arm hands a clipboard to a robotic courier in a 1920s newsroom, representing Claude delegating tasks to Grok. — The subcontractor pattern allows a host AI model to dynamically dispatch specialized tasks to a secondary model.

Key Takeaways

The project demonstrates a recursive reasoning loop where one AI agent acts as a manager and delegates specialized tasks to a rival model.
Dynamic discovery logic allows the server to probe xAI for capabilities, gracefully degrading from frontier models to faster fallbacks based on API access.
A strict local filesystem sandbox prevents the image generation model from executing path traversal attacks on the host machine.
While the MCP ecosystem trends toward compiled Go binaries, askgrokmcp utilizes native ESM Node.js for rapid iteration and zero-build deployment.

Hiring a Rival AI

Anthropic's Claude Code is a powerful terminal agent, but it lacks native image generation and relies entirely on its own internal reasoning. The askgrokmcp project introduces a subcontractor pattern. Through the Model Context Protocol (MCP), it allows Claude to dynamically hire a rival AI (xAI's Grok) to generate images via the Aurora model or perform secondary reasoning tasks.

The Node.js server exposes three primary tools over stdio: ask_grok, generate_image, and list_models. When Claude hits a limitation, it formats a JSON-RPC request to the MCP server. The server translates the request to the xAI API, waits for the result, and returns the data back to Claude.

The recursive reasoning loop and tool execution path over MCP.

Frontier vs. Fallback

Instead of hardcoding model strings, the server implements dynamic discovery. At startup, it pings the xAI models endpoint. It attempts to load the frontier grok-4.20-0309-reasoning model first. If the user's API key lacks beta access, it gracefully degrades to grok-3-fast.

This logic is paired with an exponential backoff routine designed to survive transient API rate limits. AI APIs are prone to 429 status codes and timeouts. By handling retries at the server level, Claude does not abandon its task due to a temporary network blip.

Sandboxing the Aurora Model

When Grok's Aurora model generates an image, the MCP server must save it to the user's local disk. This creates a significant security risk. If an AI can generate files, it must be heavily restricted from overwriting system binaries or SSH keys.

The code uses Node's path.resolve and isAbsolute functions to enforce a strict SAFE_WRITE_BASE_DIR. This prevents path traversal attacks, ensuring that the cloud model can only write files into a designated sandbox directory.

A mechanical arm reaches into a vault but is stopped by a painted boundary line labeled SAFE_WRITE_BASE_DIR. — Visualizing the filesystem sandbox that prevents path traversal attacks.

The Runtime Trade-off

The broader MCP ecosystem is rapidly adopting Go for server development. Go compiles to a single binary with zero runtime dependencies and idles at a fraction of the memory footprint of a Node.js process.

An MCP server written in Go compiles to one binary. No runtime dependencies, no`node_modules`, no version conflicts. Users download the binary and point their AI client at it. That is the entire setup process.

thelacanians, Author · How to Build MCP Servers in Go

However, askgrokmcp opts for native ESM Node.js. This minimalist utility pattern avoids the complexity of a build step entirely. By publishing directly to NPM, the author trades memory efficiency for extreme iteration speed and native access to the rich Node.js filesystem API.

Feature	Go MCP Servers	askgrokmcp (Node.js)
Distribution	Single Binary	NPM Package
Idle Memory	~10-15 MB	~50+ MB
Build Step	Compiled	None (Native ESM)
Filesystem Access	os package	node:fs/promises