OpenAI Agents SDK MCP server: Sume and the 5-second timeout

Connect the OpenAI Agents SDK to Sume's hosted MCP server with an API key, and raise the 5-second client timeouts above jobs_wait's 55 seconds.

5 min readSume
All posts

To use Sume's hosted MCP server from the OpenAI Agents SDK, open an MCPServerStreamableHttp connection to https://mcp.sume.com/mcp with your Sume API key in an Authorization: Bearer header, and raise client_session_timeout_seconds and the timeout param from their 5-second defaults to more than 55 seconds (this post uses 60), because Sume's jobs_wait can hold one call for up to 55 seconds.

The SDK settings come from OpenAI's MCP guide and MCP servers reference; the Sume side comes from OAuth and API keys, MCP tools and gates, and Jobs and results, all read on 2026-09-27. Sume has no official Agents SDK integration: this is the SDK's own MCP client talking to Sume's hosted server. Sume's basics page says hosted MCP still works but is not part of the primary path today.

Why do Sume tool calls fail after 5 seconds?

MCPServerStreamableHttp sets client_session_timeout_seconds, the MCP ClientSession read timeout, to 5 by default, and its timeout param, the timeout for the HTTP request, also defaults to 5 seconds. Some Sume tools hold the request open by design. On remote MCP, jobs_wait takes a timeout_seconds that defaults to 50 and is capped at 55, and a wait is one HTTP request held open for the whole slice. A script_run is bounded by its own timeout_seconds of 5 to 55. With the SDK defaults, the client gives up after 5 seconds, while a wait on an unfinished job holds for 50 or 55.

Stopping on your side does not stop the job. When a wait is cut off, the caller gets no tool result while the job keeps running and billing, and a client-side timeout does not cancel it. The fix is a longer client timeout, not a second submit.

How do I connect the Agents SDK to Sume?

Point the streamable HTTP client at Sume's production URL, pass the key as a header, and allow only the tools the agent needs:

  • Send Authorization: Bearer $SUME_API_KEY or x-api-key. Sume's docs recommend OAuth for interactive clients and call API-key remote MCP the other path, for automation that does not speak OAuth. An API-key session sees the full hosted tool set, paid tools included.
  • OpenAI's guide says to keep access tokens in authorization fields or headers rather than URLs, and its own example reads the token from an environment variable.
  • create_static_tool_filter(allowed_tool_names=[...]) exposes only the tools you list.
  • Omit payload.model in generate_video to route to sume/auto.
  • Every write and paid tool needs an idempotency_key; dry_run=true previews admission and cost without submitting the job, and max_spend_usd caps a call only when you pass it. Safe automation for AI agents that call paid APIs covers these gates.
import asyncio, os
from agents import Agent, Runner
from agents.mcp import MCPServerStreamableHttp, create_static_tool_filter

async def main() -> None:
    async with MCPServerStreamableHttp(
        name="sume",
        params={
            "url": "https://mcp.sume.com/mcp",
            "headers": {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"},
            "timeout": 60,
        },
        client_session_timeout_seconds=60,
        tool_filter=create_static_tool_filter(
            allowed_tool_names=["tools_schema", "generate_video", "jobs_wait", "jobs_result"]
        ),
    ) as sume:
        agent = Agent(
            name="Video producer",
            instructions="Call generate_video with dry_run=true first. Wait with jobs_wait; never resubmit.",
            mcp_servers=[sume],
        )
        print((await Runner.run(agent, "Preview a 5-second 9:16 clip of a desk lamp.")).final_output)

asyncio.run(main())

Which settings should I change for Sume?

Four constructor settings decide whether long Sume calls survive, which tools the model sees, and how failed calls repeat. The SDK's own guide says to use MCPServerStreamableHttp when you want to manage the network connection yourself, so all four live in your process:

From OpenAI's MCP servers reference and Sume's Jobs and results and MCP tools and gates, read 2026-09-27. The suggested values are this post's, derived from the 55-second cap.
SettingSDK defaultSuggested for SumeWhy
client_session_timeout_seconds5Above 55 (60 in the example)A jobs_wait slice holds up to 55 seconds, or 50 when timeout_seconds is omitted.
params["timeout"]5 secondsAbove 55 (60 in the example)A wait is one HTTP request held open for the whole slice.
tool_filterNoneAn allow-listAn API-key session can see write and paid tools.
max_retry_attemptsNo retriesOptionalRetries repeat call_tool. Sume's required idempotency_key is a stable key for transport and dedup, so keep it the same for the same job.

What should the agent do when a wait ends before the job?

Say it in the agent's instructions: on wait_slice_expired, call jobs_wait again with the same ids and never resubmit the paid create, and treat a 524, 522, 523, or 525 on jobs_wait as a transport failure, not a job outcome. MCP tool call timeouts on long-running video jobs covers batch waits and the rest of the wait contract.

Should I use HostedMCPTool instead?

HostedMCPTool pushes the whole tool round-trip into OpenAI's infrastructure: the Responses API lists and calls the server's tools on the model's behalf, without a callback to your Python process, and the SDK's client-side tool guardrails do not apply to it. Sume's authentication docs say to keep API keys on trusted servers, CI secret stores, or local developer machines. With MCPServerStreamableHttp, your own process makes every Sume call and holds the key and the tool filter.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume