OpenAI Agents SDK 0.23 MCP listing limits and Sume tools

openai-agents-python 0.23 adds configurable MCP listing page limits. What that means for Sume's hosted MCP, where the tool list depends on your OAuth scope.

4 min readSume
All posts

The 0.23.0 release of openai-agents-python added configurable page limits for MCP listing, so you can bound how much of a server's tool catalog the SDK pulls in. For Sume's hosted MCP the practical advice is short: the number of tools you see depends on your session's scope, Sume's docs do not describe pagination for tools_list, and tools_schema lets you fetch one tool contract at a time instead of loading everything.

This post covers what the release notes say, what decides the size of Sume's tool list, and how to keep an agent's context small whichever page limit you pick.

What the release notes say

Only two facts from the releases page are used here. The rest of the SDK's behavior is documented by OpenAI, not by Sume.

openai-agents-python releases (read 2026-10-03)
ReleaseWhat the page lists
v0.23.0Configurable MCP listing page limits
v0.23.1First PyPI publish of the 0.23 series

What decides the size of Sume's tool list

Hosted Sume MCP lives at https://mcp.sume.com/mcp. What a session can list is set by how it authenticated, not by a client-side limit. Under OAuth the default grant is mcp:read, which shows read-only tools; turning Write on at consent adds mcp:write and the mutating and paid tools. An API key session sees the full hosted tool set.

Session auth and visible tools, from the MCP tools and gates docs (read 2026-10-03)
Session authWhat `tools_list` shows
OAuth mcp:read onlyRead-only tools; mutating and paid calls return insufficient_scope
OAuth mcp:read plus mcp:writeFull hosted tool set
API keyFull hosted tool set

Do not depend on a page size

The Sume docs say to discover the live contract with tools_list and tools_schema and not to assume parity with the HTTP API. They do not state a page size or a cursor for tools_list. If you set a small listing limit in the SDK and your tool filter then hides a tool you expected, treat that as a client configuration question first, and confirm by calling tools_list directly from a read-only tool.

The inventory itself is grouped by purpose: meta and health, account and catalog, jobs, assets, image, video and audio generation, avatars, crawl, and media inspect, import, captions and timeline. A typical media agent needs only a handful of them, which is the better reason to cap what you load.

Keep the working set small

Load a short allow-list and let the agent fetch the rest on demand. A reasonable starting set is the discovery tools, the job tools, and the one or two generation tools the task needs.

  • Always loaded: tools_list, tools_schema, jobs_status, jobs_wait, jobs_result.
  • Loaded per task: generate_image for stills, generate_video for clips, tts_create for narration.
  • Left out unless asked: crawl tools, avatar tools, and anything that needs mcp:write when the session is read-only.
Before calling any paid Sume tool:
1. Call tools_schema with the tool name and read idempotency_key and dry_run.
2. Call the tool with dry_run=true and report the estimate.
3. Only after the user confirms, call it again with a fresh idempotency_key.
4. Poll with jobs_wait using the same job ids; never resubmit a paid create.

Checklist

Before shipping an agent that uses a page limit with Sume:

  • Connect with OAuth for interactive use, and check mcp_health shows the auth source you expect.
  • Confirm the tool you need is in the visible list for that scope before blaming the limit.
  • Send a stable idempotency_key on every write or paid call; it is required.
  • Use dry_run=true or generation_admission_preview before the first paid submit.
  • Read the SDK's own docs for the exact setting name; this post does not restate it.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume