Swap the LLM behind your MCP client: do Sume's gates change?

No. Sume's hosted MCP gates do not depend on which language model drives the client. They depend on the auth the session holds and on arguments in the call. Swapping a client from one model to another, for example to Claude Haiku 5.5 or GLM 5.3 Flash, leaves visibility, idempotency_key, and max_spend_usd exactly as they were.

Where the gates live

The MCP tools and gates page lists them. Under OAuth mcp:read, hosted MCP gives read-only visibility and hides tools that change data and paid tools. With mcp:write or an API key you see the full set. Paid and write tools require idempotency_key. max_spend_usd is optional and enforced only when provided. There is no mcp:paid scope.

What a new model can change

A different model changes how well the client plans, how many tool calls it makes, and how much prompt it carries. Those affect cost and speed. They do not change which tools are listed or what a call requires. A model that is more eager to call tools can reach the gate more often, and the gate behaves the same.

Model names also do not carry over. GLM 5.3 Flash's docs, read 2026-10-08, describe function calling and JSON structured output but do not mention MCP. That says nothing about Sume's server; it means your client, not the model vendor, supplies the MCP transport. Check that your client speaks MCP before you point a new model at it.

Practical rules

The points that matter here, in the order you will hit them:

• Start every new model on a read-only OAuth session and call tools_list.
• Grant mcp:write only for the run that must spend.
• Make the client send max_spend_usd on paid calls when you want a cap, since Sume does not apply one on its own.
• Never paste signed URLs, OAuth tokens, or API keys into agent logs; the safe-automation page lists them as unsafe.

Which models Sume lists is separate

This post is about MCP clients. Which model runs inside Sume's own agent is a different question. The Agent Completions model field accepts only sume-agent, so a client model choice never reaches it.

A test plan for a model swap

Before you move production traffic to a new model, run the same small task on both. First, call mcp_health and check that authenticated.auth_source shows what you expect. Second, call tools_list and compare the lists. Third, ask each model to price a paid call with dry_run=true and compare the estimates, which come from Sume and not from the model. Fourth, count tool calls per task. If the new model makes twice as many, your per-task cost has doubled even though the gates are identical.

Finally, remember that reads are not free of cost at the client end. Each tools_list result costs prompt tokens in whatever model reads it. A listing of the full hosted inventory is long, so call tools_schema for the one tool you need instead of keeping every contract in context.