mcp_health, health_service or health_v1: which Sume ping to call
Three read-only Sume checks answer three questions: mcp_health for your session and tools, health_v1 for the /v1 API path, health_service for plain liveness.
Use mcp_health when the question is about your session: auth, exposed tools and safety posture. Use health_v1 when product calls on the /v1 path fail. Use health_service only for a quick liveness check of the API process. All three are read-only and none of them spends credits or creates a job.
What each one answers
The quickstart lists mcp_health as the first call to make after connecting. It confirms the endpoint, the auth source and the safety posture.
| Tool | Checks | Reach for it when |
|---|---|---|
| mcp_health | This MCP endpoint: transport, API version, credential shape, safety posture, tool names exposed to the session | Tools look missing, or you are unsure which login the session uses |
| health_v1 | The versioned API at GET /v1/health | Creates, catalog or jobs fail and you suspect the /v1 path |
| health_service | The unversioned API at GET /health | You only need to know the process is up |
What none of them tell you
A health tool is not a substitute for reading a tool's own error. Sume's server instructions say that one failed tool call is not a sign the server is down: retry that call once and report that tool's error. Do not tell a user the server is disconnected because one call failed.
They also do not answer money questions. Use balance_get for the wallet and usage_get for spend. And they do not list product capabilities; catalog_list does that.
- Sume's own tool notes add one rule of order: if the API is up but MCP misbehaves, go to
mcp_health; if product calls fail with version errors, tryhealth_v1. Preferhealth_v1overhealth_servicewhen debugging/v1tool paths. - Tools missing under OAuth: call
mcp_health, then remember that a session with onlymcp:readsees read-only tools. - API up but MCP misbehaving:
mcp_health. - Product calls failing with version-style errors:
health_v1.
The tradeoff
Three pings sounds like one too many, but they test different layers: the MCP session, the versioned API and the bare process. Calling all three on every failure just adds noise. Start with mcp_health, because most 'broken' reports are an auth or scope question, and move to the others only if it looks healthy and the product call still fails.
Sources
Related posts
More in Developers
- Sume MCP OAuth: the consent page is on mcp.sume.com, not app
A Sume MCP client OAuth flow goes /oauth/authorize then /oauth/consent on the MCP host. Do not send users to app.sume.com; here is what the flow checks.
- MCP server for video editing: which tools can an agent call?
An agent can trim, strip audio, filter and compose clips through Sume's remote MCP endpoint. Here are the tool names, order of calls, and what each step costs.
- MiniMax H3 on Sume: 9 images, 3 videos, 3 audio, 12 in total check
On Sume, minimax-h3 and minimax-h3-max take at most 9 reference images, 3 videos and 3 audio clips, 12 in all, and audio cannot be alone. Check it in Python.
- Music-only Short: Timeline silence mode with a soundtrack bed
Build a Short with no voice: audio mode silence plus a soundtrack. The bed plays alone at the default -16 dB with no amix loss. Fields, limits, tail rule.
Written by Sume