DSPy Tool.from_mcp_tool with Sume hosted MCP: async notes

DSPy bridges MCP with dspy.Tool.from_mcp_tool(session, tool), which takes a live mcp.ClientSession and one tool from its tool list. For Sume, open a Streamable HTTP session to https://mcp.sume.com/mcp with your credential, list tools, and convert only the ones the program should call. DSPy's docs say the result is an async callable, so use acall, or enable async-to-sync conversion in a dspy.context.

DSPy's side is from its Tools docs; Sume's from MCP tools and gates and Jobs and results, all read on 2026-10-06. This post gives no code because the session-opening call depends on your MCP SDK version.

What does DSPy do with an error?

DSPy's docs say the wrapper raises when the MCP result has isError set, and that it accepts both the camelCase and snake_case result fields of the two MCP SDK generations. A Sume tool that is rejected, for example for a missing idempotency_key, comes back as an error result and so surfaces as an exception in your DSPy program. Catch it and fix the arguments rather than retrying blind.

Which Sume tools should I convert?

Converting a subset keeps a ReAct-style program from reasoning over the whole catalog, and keeps paid tools out of reach.

• mcp_health, tools_list and tools_schema for discovery, which are read-only.
• jobs_wait for results; it holds up to 55 seconds, so it needs a session read timeout above that.
• Paid create tools only with the agent instructed to send dry_run, idempotency_key and max_spend_usd.
• Skip write tools for a read-only research program.

Where do long jobs fit?

A DSPy step that calls jobs_wait should loop on wait_slice_expired with the same job ids. Never recreate a paid job because a step timed out: it keeps running and billing.