Claude programmatic tool calling skips MCP connector tools: Sume fix
Claude's programmatic tool calling cannot call tools from the MCP connector. Sume's script_run runs the loop on the server instead, with a call journal.
Claude's programmatic tool calling cannot call tools that arrive through the MCP connector. Anthropic's documentation, read on 2026-10-04, lists tools provided by an MCP connector, along with the computer and browser toolsets, as not callable programmatically. If you point Claude at Sume's hosted MCP server (https://mcp.sume.com/mcp) through the connector, your fan-out loop of 12 image calls still runs as 12 separate model-visible tool calls.
The workaround is a tool that does the loop on the server side. Sume ships one: script_run, a hosted MCP tool that runs a short JavaScript program next to Sume's other tools and returns a single value.
What does Anthropic say about the limit?
In Programmatic tool calling, the feature is generally available and needs the code execution tool, version code_execution_20260120 or later. Claude writes Python in that sandbox and calls your tools as async functions, using asyncio.gather for fan-out. The same page says its fit is strongest for fan-out across many items and for large results, and weakest for strictly sequential workflows and for a few small calls.
The MCP connector page says the connector supports tool calls only from the MCP specification and wants a public HTTPS server. Put the two pages together and the result is a gap: the connector is the easy way to reach a hosted MCP server, and programmatic calling is the way to batch, but they do not combine.
How does script_run close the gap?
Sume's MCP tools and gates page describes script_run as programmatic tool calling on the Sume side. The script body is plain JavaScript, up to 64 KB, with no imports, no network and no timers. Inside it, sume.call(name, arguments) or sume.tools.<name>(arguments) runs any listed tool with the same gates, redaction and errors as a direct call.
To the connector, script_run is one ordinary tool call. Claude sees one request and one result: the returned value, a calls[] journal of every inner call, and the child jobs[] to pass to jobs_wait.
What are the limits?
| Limit | Value |
|---|---|
| Run time | timeout_seconds 5 to 55, default 45 |
| Calls per run | max_calls default 32, ceiling 64 |
| Paid calls per run | max_paid_calls default 16, ceiling 32 |
| Concurrency | 4 calls in flight, 8 call starts per second |
| Guest memory | 64 MB |
| Refused inside a script | discovery tools and script_run itself |
What should I watch for?
Each paid create inside a script needs its own distinct idempotency_key, for example a prefix plus the loop index. A budget stop ends the run with script_timeout, script_call_budget_exceeded, script_paid_budget_exceeded or script_tool_forbidden, and calls[] and jobs[] stay complete either way.
Do not wait on a render inside the script. Submit the creates, return their job ids, and call jobs_wait afterwards, which holds up to 55 seconds per call and takes up to 20 ids. The MCP overview explains how the tools fit together.
Sources
Related posts
More in Developers
- Sonnet 5.5 on Bedrock has no strict tools: check Sume calls first
Anthropic says strict tool use is unavailable for Claude Sonnet 5.5 on Amazon Bedrock. Validate arguments yourself and use Sume dry_run before paid calls.
- Sonnet 5.5 strict tool schema for a capped Sume Agent Completion
Sonnet 5.5 rejects forced tool_choice, so use auto plus strict: true. A tool schema that makes generation_spend_cap_usd mandatory for Sume Agent Completions.
- Cloudflare AI Search bills from Nov 1: split retrieval from renders
Cloudflare's October 1 changelog makes AI Search GA with usage billing from November 1, 2026. How to keep retrieval costs separate from Sume render costs.
- Cloudflare Sandbox SDK 1.0: run the Sume SDK inside one
The @sume-com/sdk has no runtime dependencies and needs only fetch and WebCrypto, so it can run in a sandbox. Pass the key as an env var, server-side only.
Written by Sume