Radar

An optional discovery mode that keeps large Gateways context-efficient by letting agents search for tools instead of loading them all up front.

Radar is an optional discovery mode for MCP Gateways with large tool libraries. Instead of handing your AI agent every tool definition from every connected server at once, Radar exposes a small set of built-in tools that let the agent search for the capability it needs and call it on demand. The starting tool list stays short no matter how many servers or tools sit behind the Gateway.

Radar is a per-Gateway choice, not a separate product. A Gateway either serves its full tool list on the standard /mcp endpoint or serves the discovery tools on a /radar endpoint. Everything else about the Gateway (apps, credentials, policy, monitoring) is the same either way.

Radar changes how tools are discovered, not who can access them. The same credentials, policy, and monitoring that apply to the standard endpoint apply to every call Radar dispatches.

Why teams use Radar

Every tool definition you expose to a model costs context tokens, and agents make worse choices when forced to pick from dozens or hundreds of options at once. Radar keeps the initial tool list small by replacing a Gateway’s full inventory with:

• Three built-in discovery tools (radar_search, radar_execute_tool, and radar_manage_cache).
• Any tools the agent has already discovered and used, which stay directly callable.

A Gateway with hundreds of tools behind it can start a conversation with only a handful of tool definitions in context.

Radar works best on Gateways with a large or varied tool library. For a small, focused Gateway with only a handful of tools, the standard /mcp endpoint is simpler and just as effective.

How it works

When a client connects to a Radar Gateway, tools/list returns only:

1. The three Radar tools.
2. Tools the agent has previously discovered and hasn’t lost from its personal memory (see Discovered-tool memory).

The Gateway’s full, fixed tool list is never sent. The agent asks for what it needs:

1. The agent calls radar_search with a natural-language description of the task.
2. Radar returns full definitions for the closest-matching tools.
3. The agent calls radar_execute_tool to run one of those tools, which dispatches to the MCP server that owns it.
4. A successful call adds the tool to the agent’s discovered-tool memory, so it shows up directly in tools/list next time without another search.

View the full diagram ↗

Enable Radar

Radar is toggled with the Use Radar switch when creating or editing a Gateway.

1. Open the Gateway editor

   Create a new Gateway or edit an existing one. See Gateway/Deployment Creation and Editing a Gateway.

2. Turn on Use Radar

   Flip the Use Radar switch. Every connection URL and client install snippet for that Gateway (Cursor, Claude Desktop, Claude Code, and others) then points at the Gateway’s /radar endpoint instead of /mcp.

3. Reconnect your clients

   Reconnect any client using the updated URL. If you wire up a client manually, the only difference between the two modes is the endpoint:

   Standard: https://mcp-gateway.airia.com/gateway/{gateway-id}/mcp
   Radar:    https://mcp-gateway.airia.com/gateway/{gateway-id}/radar
   

When a Gateway you’re creating or editing exposes more than 50 tools, Airia suggests turning on Radar with a dismissible banner. You’re always free to keep the full tool list instead.

The discovery tools

radar_search

Searches every tool available on the Gateway using a natural-language description of what you’re trying to do, and returns full tool definitions (name, description, and input schema) for the closest matches.

Parameter	Type	Required	Default	Description
query	string	Yes	N/A	Natural-language description of the capability you’re looking for, for example “find bugs assigned to me in Jira.”
max_results	integer	No	5	Maximum number of tools to return.
min_relevance	number	No	0.5	Minimum relevance score (0–1) a tool must meet to be included.

If nothing meets the relevance threshold, radar_search does not error. It returns a normal response indicating no tools were found, so the agent can try a different phrasing.

radar_execute_tool

Runs a tool that was returned by radar_search. This step exists because tools found through search usually aren’t part of the agent’s initial callable tool list. radar_execute_tool dispatches the call to whichever MCP server owns that tool and returns its normal result.

Parameter	Type	Required	Description
tool_name	string	Yes	The exact name of the tool, as returned by radar_search.
arguments	object	No	Arguments to pass to the tool, matching its input schema.

Executing a tool this way also reinforces it in the agent’s discovered-tool memory for direct reuse later in the session.

radar_manage_cache

Lets the agent inspect and curate its own discovered-tool memory.

Action	Description
list	Lists every cached tool, along with whether it’s pinned, how many times it’s been used, and when it was last used.
pin	Protects specific tools from being dropped from memory, regardless of how long it’s been since they were used.
unpin	Removes pin protection from specific tools.
remove	Drops specific tools from memory.
clear	Empties the cache. Set include_pinned: true to also remove pinned tools; otherwise pinned tools are kept.

Discovered-tool memory

Radar remembers which tools an agent has successfully used, so it doesn’t re-run radar_search for the same capability every time. Once a tool is discovered and called successfully, it’s added to a memory scoped to you and that Gateway, and it appears directly in tools/list on future requests without another search.

• Memory persists between sessions. Closing and reopening a conversation doesn’t reset it.
• By default, up to 20 tools stay in memory at once. When memory is full, the least valuable tool is dropped to make room for a new discovery.
• Up to 5 tools can be pinned at a time (via radar_manage_cache) to guarantee they’re never evicted, no matter how little they’re used.

Reconnecting integrations through Radar

If one of your connected apps needs attention (credentials were never set up, or an existing connection expired or was revoked), Radar still surfaces it. A radar_search result for that app includes a tool that walks you through reconnecting rather than failing outright. Agents using Radar can guide you through fixing a broken connection instead of reporting a dead end.

When to use Radar

Scenario	Recommendation
Gateway exposes 50+ tools	Enable Radar
Gateway spans several unrelated apps or domains	Enable Radar
Small, focused Gateway (a handful of tools, single purpose)	Standard /mcp is simpler
You want every tool visible to the agent up front	Standard /mcp

Troubleshooting

radar_search returns no tools

Symptoms: A search comes back with no matches, even though you expect the capability to exist behind the Gateway.

Cause: No tool met the min_relevance threshold for that phrasing.

Fix: Rephrase the query to describe the task more directly, raise max_results, or lower min_relevance.

A tool I used earlier is gone from the tool list

Symptoms: A tool that was directly callable earlier no longer appears in tools/list and has to be searched for again.

Cause: Discovered-tool memory holds up to 20 tools. When it fills, the least valuable tool is evicted.

Fix: Pin the tools you rely on with radar_manage_cache (up to 5) so they’re never dropped.

Related Resources

Gateway/Deployment Creation

Create a Gateway and choose whether to enable Radar

Editing a Gateway

Toggle Radar on an existing Gateway

Server Management

Approve which servers your organization can use

MCP Monitoring

Inspect tool calls, denials, and errors