claude mcp list and get: check the Sume server before you prompt

To check Sume from Claude Code, run claude mcp list for the health of every server, claude mcp get sume for that one entry, and then ask the agent to call Sume's mcp_health tool. The first two prove Claude Code can see and reach the server; the third proves Sume accepted your credential and tells you what the session may do.

The commands are from Claude Code's MCP docs (read 2026-10-02); the Sume tool is described in the MCP quickstart.

What do claude mcp list and get show?

claude mcp list prints every configured MCP server with its health status. claude mcp get <name> prints the details of one server. Inside a session, /mcp opens a panel with the same servers, their tools, and options to authenticate, reconnect, disable or clear authentication. The panel marks each server as Connected, Needs authentication or Failed to connect, and shows a tool count next to connected servers; it also flags a server that advertises a tools capability but exposes no tools.

A small safety note from the changelog: 2.1.285 fixed claude mcp list and claude mcp get printing line breaks and terminal escape sequences that came from server names and values (changelog, read 2026-10-02). If you are on an older build and you copy a server from someone else's config, that is a reason to update.

What should I see for Sume at each step?

A healthy Sume entry reads as connected in claude mcp list after you sign in. If it says it needs authentication, run claude mcp login sume, which opens the browser flow described in OAuth and API keys: Claude Code discovers the protected-resource metadata, sends you to the MCP host, and you accept the Read permission, optionally turning Write on.

Then call mcp_health. Sume's playbook says to confirm that authenticated.auth_source is mcp_oauth when you connected through OAuth. If you used an API key instead, the source will differ, and the key gives the full tool set. After that, tools_list shows what the session can use. With read-only OAuth you will see read-only tools and no paid ones.

Which failures does each step catch?

If step 1 shows failure, the problem is before authentication: a wrong URL, a network block, or a transient first-connect failure (Claude Code now retries remote servers whose first connect fails transiently in headless mode, per the 2.1.287 notes). If step 1 passes and step 3 fails, it is a credential or consent issue. If step 4 shows fewer tools than you expect, check the OAuth scope: read-only sessions hide mutating and paid tools, and a call to one returns insufficient_scope.

One trap is worth naming: claude mcp add can report success in a sandbox where the config was not written. A claude mcp get sume right after the add catches that in a second. See the related post on verifying with mcp_health.

claude mcp list
claude mcp get sume
# then in the session:
# Call the mcp_health tool on the sume server and report authenticated.auth_source

What does this not tell me?

None of these checks proves a paid call will succeed. Wallet balance, queue capacity and the admission preview are separate; use balance_get and generation_admission_preview before a large run, and dry_run on the paid tool itself. Health also does not say anything about job progress, which you read with jobs_status or jobs_wait.

When should I re-run the checks?

Run them after any change that touches the connection: a new Claude Code version, a changed .mcp.json, a rotated API key, or a switch between OAuth and a key. They are cheap, they are all read-only, and they spend nothing. /mcp reconnect all inside a session retries servers that failed or need authentication if you want to nudge a stuck connection before checking again.

If you are scripting a check for a team, keep it to the first three rungs of the ladder, which need no model call, and leave mcp_health for a quick prompt in a real session. The tool call goes through your model and your permission rules, so it also confirms that Claude is allowed to call Sume tools at all. Teams that restrict MCP tools with allow or ask rules often discover at this step that the rule, not Sume, is what blocks the call.