Claude Code MCP_TOOL_TIMEOUT and the timeout field for Sume jobs_wait

Claude Code's MCP_TOOL_TIMEOUT is a wall-clock limit per tool call, and the docs give a default of about 28 hours when it is unset. That is far above Sume's 55-second jobs_wait cap, so a call that the edge drops can look hung for a very long time. Set a timeout of 90,000 ms on the Sume entry in .mcp.json.

Entry

The quickstart in the Sume docs adds the server with claude mcp add --transport http sume https://mcp.sume.com/mcp and then claude mcp login sume. The project file form carries the timeout.

{
  "mcpServers": {
    "sume": {
      "type": "http",
      "url": "https://mcp.sume.com/mcp",
      "timeout": 90000
    }
  }
}

Why 90 seconds

A single jobs_wait slice is 50 seconds by default and 55 at most. 90 seconds leaves room for the network and for a batch jobs_result, and still reports a dead call in about a minute and a half. script_run accepts timeout_seconds from 5 to 55, so it fits under the same limit.

Agent rule

Add one line to your project instructions: on wait_slice_expired or a 5xx transport error from jobs_wait, wait again on the same ids or read jobs_status once, and never resubmit a paid create.

Where to put the file

A project-level .mcp.json applies to everyone who opens that repository, which is the right place for a shared timeout. Keep any credential out of it. If you use OAuth, the token lives in Claude Code's own store after claude mcp login sume, so the file holds only the URL and the timeout.

Checking the setting works

Ask the agent to run a wait on a job that is still queued and watch that it comes back in about 50 seconds with wait_slice_expired, then repeats. If it hangs well past a minute and a half, the client limit fired, which tells you the edge dropped the call. The correct recovery is still to wait again on the same id, not to start the work over. Setting the environment variable instead of the file gives one limit for all servers, which is why the per-server field is the better fit here.

One more detail: the startup limit and the tool limit are different settings. MCP_TIMEOUT governs how long Claude Code waits for a server to start, and has no effect on a running wait. If the Sume server is slow to connect on a poor network, raise that one, and leave the per-server tool timeout alone. Keep both values written in the repository README, so teammates do not change one while debugging the other. When you must pick a single number, choose the one that matches the longest server-side hold you use, plus a margin of about half a minute.

Before you rely on this setup, run a short acceptance test with a read-only credential. Connect, call mcp_health, call tools_list, and read one job with jobs_status. Record the tool count you see, so you can notice later if a credential change alters it. Then repeat the test after any config edit. A five-minute test like this catches most wiring mistakes before they cost money, and it gives you a baseline to compare against when something behaves differently next week.