Gemini CLI MCP servers not loading in an untrusted workspace

Gemini CLI v0.59.0 filters mcpServers in restricted mode. If Sume is missing in an untrusted folder, trust is the cause; then tell it from an OAuth issue.

4 min readSume
All posts

If Sume's MCP server does not load in Gemini CLI, check whether the folder is trusted before you touch the Sume config. Gemini CLI v0.59.0 (2026-09-08) fails closed on workspace trust and filters mcpServers in restricted mode, so a server defined for a folder you have not trusted is simply not loaded, however correct the URL is.

That is Gemini CLI behavior, taken from its changelog read 2026-09-29; the changelog gives no more detail, so follow Gemini CLI's own documentation for how to trust a folder. The Sume side is short and is below.

How do I tell trust from a Sume problem?

Two different failures look alike from the chat window: the server never appears, or it appears and then a call is refused. Only the second one involves Sume.

Symptom, likely owner and next step, read 2026-09-29.
SymptomOwnerNext step
Sume server never shows up in an untrusted folderGemini CLI workspace trust (v0.59.0 filters mcpServers in restricted mode)Trust the folder, then start a new session
Server loads but sign-in never completesOAuth login for the configured server nameRun the client's OAuth login for that server
Server loads, read calls work, a write is refusedSume OAuth scope: mcp:read onlyGrant Write at consent, or use an API-key session

What should the Sume server entry point at?

Sume's quickstart says to point a streamable HTTP MCP server at https://mcp.sume.com/mcp and to run that client's OAuth login for the configured server name. The client should discover Sume protected-resource metadata from the MCP endpoint and send you to https://mcp.sume.com/oauth/authorize, which continues to https://mcp.sume.com/oauth/consent.

How do I confirm it loaded after trusting the folder?

Ask the agent to call a read-only tool. The quickstart's verify step uses tools_list, which lists every tool visible to the session, and mcp_health, which confirms the endpoint, auth source and safety posture. If tools_list answers, trust and sign-in are both fine.

Call the Sume MCP tool tools_list and summarize the available tools. Live ids
use underscores (tools_list, generate_image). Dotted aliases also work.

Why can a write call fail after everything loads?

Default hosted OAuth grants read-only access (mcp:read). Write tools such as jobs_cancel or assets_create, and paid tools such as generate_image, return insufficient_scope until you grant mcp:write on consent, use an API-key remote MCP session, or use the Developer API. See OAuth and API keys.

Does Sume need any change for a trusted folder?

No. The Sume side of the setup does not depend on the folder: the same https://mcp.sume.com/mcp entry and the same OAuth login apply wherever the client runs. Once trust lets the entry load, follow the documented read-only playbook: connect with OAuth, leave Write off unless you need mutations, call mcp_health, and confirm authenticated.auth_source is mcp_oauth.

Then call tools_list and keep only the read_only tools in mind while Write is off. If Write was off, stop before mutating tools, because they return insufficient_scope.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume