Sume MCP first call: mcp_health must say mcp_oauth, then tools_list

The two-call check

After you add the Sume connector, the first call is mcp_health, and you should look for authenticated.auth_source equal to mcp_oauth. The second call is tools_list. If both look right, the connection, the sign-in and the scope are all working, and nothing has been spent yet.

The docs recommend this order as a first playbook because it separates three failures that otherwise look alike: a bad URL, a failed sign-in and a grant that is narrower than you meant.

How to read each result

The table lists what each outcome points to, as of 2026-10-08.

What the scopes mean here

OAuth issues mcp:read, which is required, and mcp:write, which is an opt-in toggle on the consent page. There is no mcp:paid scope. With Write off you get the read-only tools, and the write and paid tools are not listed.

An API key sent as a Bearer token or as x-api-key gives the full tool set, and then auth_source will name that path, not mcp_oauth. If you expected OAuth and see something else, an old key in your client config may be taking over.

After the check

Use tools_schema to read the argument shape of a tool before calling it. Write and paid tools need an idempotency_key; dry_run and max_spend_usd are optional guards. Call generation_admission_preview when you want to know whether a paid request would be admitted.

Keep the URL exact. Sume's production connector is https://mcp.sume.com/mcp. A host with dev in it is internal, and the Studio Agent is a separate product, not this connector.

• Call 1: mcp_health, expect mcp_oauth.
• Call 2: tools_list, compare with the table in the docs.
• Call 3: account_me or catalog_list, a cheap read.

Why not skip straight to creating

It is tempting to test a connector with a real generation. That puts money behind the first call and mixes three questions into one failure. A health call and a list call cost nothing and each answers one question. If you later see insufficient_scope, you will already know whether the session was OAuth and which tools it had.

Also remember that tool ids use underscores. Dotted forms are canonicalized, so either spelling resolves, but your logs will show the underscore name.

• Do not rely on a model to guess tool names; read tools_list.
• Run the check again after every reconnect, since the toggle on the consent page can change between sessions.

Keep a written record

Document the decision in the repository next to the code that makes the call, so the next engineer sees why the choice was made and which docs page it came from. Re-read that page when you upgrade a client or change a key, since gates and limits are the parts most likely to differ from what you remember.

A short note of the date you last verified the behaviour, such as 2026-10-08, is enough for a reviewer to know how fresh the claim is.