Skip to main content

​
Why is search mode the default?

In full mode, the agent loads every tool’s schema on every turn. With a large catalog, that fills the agent’s context window before it has done any work, and the client must expose every tool whether the agent needs it or not. Search mode keeps the agent’s working set fixed at five small tools. The agent searches for and loads only the schemas it actually needs, one task at a time. When a client asks you to approve each tool by name, search mode asks once per runner — once for reads, once for writes — rather than once per tool. The tradeoff is an extra search step; the gain is that context size stays constant as your catalog grows. Use full mode when your client’s permission rules or hooks match tool names, since in search mode every call goes through a runner and a per-tool rule no longer fires.

​
Does search mode change which tools I can call?

No. Search mode reaches exactly the tools full mode lists for you. A call you could not make in full mode is refused in search mode too — the same permission check, credential, and rate limit apply.

​
Does search mode support prompts and resources?

Yes. Prompts and resources work the same as in full mode. Search mode changes only how the client discovers tools, not what the gateway supports.

​
Can the catalog be out of date?

Yes, briefly. The catalog search can trail a server that just changed. When you must know exactly what is callable right now, use mcp__describe_tools directly against a named server, or tools/list in full mode. A match in search results never grants permission to run a tool.

​
What if search doesn’t find the right tool?

Search matches your query against each tool’s name, description, and server name using full-text search, not a language model, so it matches words not meaning. If a search misses, rephrase with words the tool’s description is likely to use, or use mcp__describe_tools to list a server’s tools directly by passing the server name.

​
Why does a Store catalog card show a status instead of a setup form?

Some Store catalog cards (Store > MCPs > All MCPs) show a setup status instead of a form. Amplitude, Datadog, and Mixpanel show Connection support needs an update while a compatibility update is pending. Zendesk shows Zendesk server address not confirmed. Select View setup status on the card to see what to do next.

​
Where can I find each vendor’s endpoint and setup details?

MCP integration templates lists each vendor’s endpoint, the inputs it needs, and how it signs in. Some servers need an administrator to register the vendor’s OAuth client first.

​
Glean or Zendesk server shows unavailable after setup

Glean and Zendesk can restrict access by network. If Atlan Trident reports the server as unavailable with a correct address, ask the vendor’s administrator to allow connections from Atlan Trident.

​
How much is the gateway used, and is that growing?

Open MCP Gateway studio and go to Overview. The 14-day call chart and 7-day totals (calls, sessions, questions to users) show volume at a glance.

​
Which tools do agents rely on most?

Overview > Most-called tools ranks tools by call count across the selected workspace.

​
What did agents do on a specific MCP server?

Go to Tool calls and filter by that server. You’ll see every call agents made on it, with the tool, the reason given, the outcome, and the duration.

​
Why did an agent call a write tool?

Tool calls > Why column shows the rationale the agent provided before making the call.

​
Which calls failed, and where?

Filter Tool calls to Failed. The page shows the failure count, median and p95 durations, and which tools and servers had the most failures.

​
Why did a call fail with “Not in the catalogue”?

Open the failed call and choose Check on the server name. Either the server added the tool after its last catalog refresh — an editor of its workspace can refresh its tools — or the tool name is wrong and the call suggests the closest match.

​
What did one agent do, step by step?

Go to Sessions, find the session by objective or caller, and open it. Calls appear in the order the agent made them, with each tool, rationale, and outcome.

​
Which questions did a server ask a person?

Open the session in Sessions. Questions the gateway relayed to the person appear under Questions to the user.

​
Which server is slow?

Filter Tool calls by that server. The Median and p95 columns show how long calls took, and Atlan’s share shows how much of that the gateway added.

​
Which vendors do people call directly, outside the gateway?

Go to Reports > Shadow AI, also linked from a server’s activity as See MCP usage in Reporting. It counts direct calls it treats as sensitive.

​
Which vendors are new, and which are growing?

In Reports > Shadow AI, look under Change since the previous period. Pick New (first called in this date range) or Growing (calls at least doubled from the baseline). The filter appears only when both periods were read in full — if it’s missing, pick a shorter range.

​
Why do calls fail, and who is making them?

Go to Reports > MCP usage > Failures and callers. Why calls fail groups failures by cause, server, or tool. People and agents breaks down callers by type (people, agents, service accounts, actions) with each one’s failure rate.