Code execution and Code Mode

Some hosts do not hand every tool to the model. They convert the connector into a typed API, let the model write code against it, and run that code in a sandbox that calls the tools on its behalf. Cloudflare calls this Code Mode; Anthropic calls it code execution with MCP; libraries such as mcp-use expose the same idea.

The Sign Customiser server works with all of them without any special mode. It publishes ordinary MCP tools, and everything these runtimes need is in the tool metadata.

Why the schemas matter here

A host generating TypeScript from a connector can only generate what the server declared. A tool with a loose input schema becomes a function taking any, and a tool with no output schema becomes a function returning an opaque object, so the model writes code that compiles, looks right and is wrong at runtime.

Three things make generated code worth having, and every Sign Customiser tool declares all three:

• A complete input schema. Required arguments, enums, identifier types and bounds, so a generated signature is the real contract rather than a guess.
• A bounded output schema. Every tool returns structuredContent conforming to a declared output schema, so a generated return type is real and code can branch on fields instead of parsing prose.
• Typed errors. A failure is a structured error object with a stable code, the failing pointer where there is one, and a recovery sentence. Generated code can branch on the code rather than matching on a message.

The tool manifest is the same metadata as one file, if you would rather generate from a static artefact than from a live tools/list.

Cloudflare Agents

The Agents SDK fetches the connector’s tool schemas and generates a TypeScript API for the model. Connect it the way you would connect any remote MCP server with OAuth, at https://web.signcustomiser.com/mcp. Generated code calls connector methods through host-side RPC, so the access token stays in your host and never reaches the sandbox.

Two things are worth knowing before you scale this up:

• The generated declarations for the 39 curated tools fit comfortably in context. The advanced catalogue does not need generating at all, because search_operations is already the discovery step and returns schemas at call time.
• Cloudflare’s Code Mode packages are still marked experimental. Treat the runtime as an evolving dependency, not the stable part of your integration.

Anthropic code execution

Claude’s code execution loads MCP servers as importable modules and runs model-written TypeScript against them. The wins are the ones this connector is shaped for: intermediate results stay in the execution environment instead of being copied through the model, and a large list can be filtered before anything reaches the context window.

A practical example: list a store’s customisers, keep the inactive ones, and read each one’s pricing document. Through plain tool calls that is one call per customiser with every full result passing through the model. Through code execution it is one loop whose only output is the summary you asked for.

mcp-use and other client libraries

mcp-use connects to remote MCP servers and offers its own Code Mode. Nothing server-side is different; point it at the endpoint and complete the OAuth flow.

What the server does not do

It does not execute code you send it. There is no execute_code tool and no arbitrary-request tool. The advanced catalogue’s executors take an operation_id and typed arguments, never a URL and never a script, so the set of things a connection can reach is exactly the set of API operations its scopes allow.

Code Mode is therefore a client-side choice. If your host supports it, you get the context savings. If it does not, the same connector still works through ordinary tools/list and tools/call, and that is deliberate: a directory host is not required to execute code for this connector to be useful.

Practical limits

• Rate limits are per connection. Code that fans out across many customisers should expect 429 with a retry_after and back off rather than retry immediately.
• Writes still need their gates. confirm: true and an idempotency_key are required in generated code exactly as they are in a hand-written call. Generate the key once per intended change, not once per retry.
• Dry runs are cheap. A generated workflow that applies a change should rehearse it with dry_run: true first, and stop on the verdict, rather than discovering a validation failure halfway through a loop.