Image 1.0 and Video 1.0 are not on Sume's hosted MCP: what to call

If your agent looks for images_create or videos_create on https://mcp.sume.com/mcp, it will not find them. Sume Image 1.0 and Video 1.0 stay REST-only, so use the Developer API for them. On hosted MCP, router stills and clips are generate_image and generate_video.

Do not assume parity

The docs say hosted MCP tools wrap selected API capabilities and to rely on tools_list and tools_schema for the live contract. catalog_list may show HTTP capabilities with no MCP tool. Retired aliases map to the router tools: image-generations_create to generate_image, and video-router_create to generate_video.

How to check

Have the agent run the discovery tools before planning. This avoids a plan built around a tool that is not there.

• Call tools_list and look for the name.
• Call tools_schema with name: "generate_image" to see its contract.
• Omit payload.model to route to sume/auto, unless the user named a family.
• Add dry_run: true before a paid call, then submit with an idempotency_key.

When you do need Image 1.0 or Video 1.0

Call the Developer API from a script with an API key, and let the agent hand off the result by public id. Keep jobs per member in mind: for API keys, job visibility is per member, so a job created by one key's member may not be visible to another's session.

Prompting an agent correctly

Add one line to the agent's instructions: use only tools that tools_list shows, and never invent a tool name from the REST docs. Agents that read the Developer API pages may try images_create over MCP, get an unknown-tool error, and then loop. Naming the router tools in the instructions avoids that.

Higgsfield-style names

The docs also list names that do not exist on Sume's hosted MCP, such as workflow-instruction and model-explore tools from other products. Cutouts use rmbg_create, and social URL mirroring uses media-imports_create. If a prompt written for another MCP server mentions a tool you do not see, check the Sume inventory before assuming it is broken.

If you need to mix both worlds, run the REST calls from a script or workflow step that holds an API key, and let the MCP agent handle everything else. The agent can then read the resulting jobs through MCP by id, as long as it uses the same workspace; remember that for API keys, job visibility is per member. Plan this split early, since moving a flow between the two surfaces later means changing its auth as well.

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.