MCP progressive discovery: Sume tools_list, then tools_schema
For a large MCP tool set, list first and fetch one contract second. Sume has tools_list for visible tools and tools_schema for a single tool by name.
Sume already supports a two-step pattern for a large tool set: call tools_list to see every tool visible in the session with safety metadata, then call tools_schema with a name to fetch one contract. That is a manual form of what the MCP roadmap calls progressive discovery.
The roadmap text is from the MCP roadmap (last updated 2026-08-22), read 2026-10-01. Sume facts are from MCP tools and gates.
What does the roadmap say?
It says servers need more options to guide clients through large sets of tools, resources and other primitives, and starts a dedicated effort around progressive discovery. It is a direction, not a finished spec, so treat the Sume tools below as the current behavior.
Which Sume tools are for discovery?
| Tool | Purpose |
|---|---|
tools_list | List every tool visible in this session, with safety metadata |
tools_schema | Fetch one tool contract by name |
mcp_health | Endpoint readiness, auth source and safety posture |
Why does the list depend on the session?
Visibility follows scope. Hosted MCP defaults to read-only visibility under OAuth mcp:read; mutating and paid tools stay hidden until the session has mcp:write or an API key. So tools_list for a read-only token is shorter than for an API key.
How should an agent use the two steps?
Have it list once, pick the tool it needs, then fetch only that schema. The docs give an example instruction: call tools_schema with name generate_image and explain idempotency_key and dry_run before submitting any paid generation. Before an expensive burst, prefer generation_admission_preview or dry_run. Client-side tool search is a related idea; see tool search with a long Sume tool list.
Sources
Related posts
More in Developers
- MCP standardized error handling: Sume's named outcomes
MCP has no single error standard across surfaces yet. Here is how Sume's named outcomes map to retry, re-auth, or stop in a hosted MCP client.
- MCP sub-agent with narrower authority: a read-only Sume token
Give a sub-agent a Sume token granted only mcp:read and it sees read-only tools, so it can inspect jobs and assets but never submit a paid generation.
- MCP workload identity federation: Sume takes code grant only
MCP's roadmap names Workload Identity Federation. Sume's hosted MCP advertises only the authorization_code grant, so headless workloads use an API key.
- Modal 150-second web timeout and 303 redirect: Sume polling
Modal web endpoints return a 303 redirect after 150 seconds. Sume returns 202 with status_url and result_url, so a client polls and follows no redirects.
Written by Sume