Built-in Discovery Tools
When you enable the MCP Gateway on a ToolSet, the deployed MCP Server automatically exposes five built-in discovery tools that AI agents can use to find, inspect, and invoke any tool in the Gateway catalog at runtime. These tools sit alongside your ToolSet's regular tools and require no additional configuration on the client side -- any MCP-compatible agent that connects to the server discovers them through tools/list like any other tool.
Why Discovery Tools?
A Gateway-enabled ToolSet can aggregate tools from multiple external MCP servers and many Nexla connectors. Listing every one of these tools to an AI agent on each request would quickly overwhelm the agent's context window, slow down tool selection, and make even simple prompts harder for the model to reason about.
The discovery tools solve this by giving the agent a small, fixed surface for tool discovery. Instead of seeing the entire catalog up front, the agent searches the catalog when it needs to, inspects the specific tool it intends to call, and then invokes it -- all without leaving the MCP session.
When They Appear
The discovery tools are exposed automatically by any MCP Server backed by a Gateway-enabled ToolSet. If you have not enabled the Gateway on a ToolSet, only the ToolSet's regular tools are listed.
The discovery tools never replace your ToolSet's regular tools. Both appear together in tools/list, and agents can call either kind in the same session.
The Five Discovery Tools
| Tool | What It Does |
|---|---|
search_tools | Finds tools in the Gateway catalog by keyword or natural-language description. |
describe_tool | Returns the full schema and usage hints for a specific tool the agent plans to call. |
call_tool | Executes a Gateway tool with the parameters the agent provides. |
list_nexla_vendors_with_available_credentials | Lists the Nexla vendor credentials available to the caller, so the agent can scope its search to vendors it can already authenticate against. |
create_nexla_credential | Returns an auto-generated link that lets the user securely create and save a new credential on Nexla when a tool requires one the caller does not yet have. |
For the full input and output schemas, see the Gateway Meta-Tools API reference.
How an Agent Uses Them
A typical agent interaction follows a discover-then-execute pattern:
- Check available credentials -- The agent calls
list_nexla_vendors_with_available_credentialsto learn which vendors it can use. This step is optional but reduces the chance of hitting a credential prompt mid-execution. - Search the catalog -- The agent calls
search_toolswith a natural-language description of what it needs (for example, "list customers from our Shopify store"). The Gateway returns the most relevant matches, ranked by semantic similarity when available. - Inspect the chosen tool -- The agent calls
describe_toolwith the exact tool name from the search results to see the input schema and any vendor or server context. - Execute the tool -- The agent calls
call_toolwith the tool name and the parameters it derived from the schema. The Gateway resolves the appropriate credential or connects to the registered external MCP server, runs the tool, and returns the result.
If at any point the agent needs a credential that does not exist, it can call create_nexla_credential to receive a secure link that the end user can follow to create one on Nexla.
Working with Credentials Through Discovery
Some Gateway tools are backed by Nexla connectors and need a credential to run. The discovery tools surface this requirement to the agent so it never has to handle secrets directly:
describe_toolflags vendor-backed tools by including acredential_infoblock that names the vendor whose credential the Gateway will resolve at runtime.call_toolreturns acredential_requiredresponse if the caller has no usable credential, along with a link to create one. The tool result itself contains no secrets.create_nexla_credentialreturns an auto-generated link to the Nexla credential-creation flow for a specific vendor. The credential is created securely on Nexla -- the link is the only artifact the agent ever sees. Once the user finishes creating the credential, the agent can retry the originalcall_toolinvocation and the Gateway will use the new credential automatically.
Credentials are never returned to the agent or surfaced through any MCP response. The agent only ever sees a link to the Nexla credential UI -- secrets remain inside Nexla's secure vault at all times.
Tools from External MCP Servers
For tools synced from a registered external MCP server, describe_tool includes a server_info block identifying the source server. When the agent invokes the tool through call_tool, the Gateway opens a short-lived session to that external server, runs the tool, and returns the result. The agent itself does not need to know about the external server -- it sees the tool as a uniform Gateway tool.
For details on registering external MCP servers and managing what gets synced, see Register External MCP Servers.
Name Collisions
If you create a ToolSet tool whose name matches one of the discovery tools (for example, a tool literally named search_tools), your tool takes precedence and the matching discovery tool is omitted from tools/list for that ToolSet. To keep the discovery experience intact, avoid using these names for your own tools:
search_toolsdescribe_toolcall_toollist_nexla_vendors_with_available_credentialscreate_nexla_credential
Next Steps
- Gateway Meta-Tools API reference -- Full input and output schemas for each discovery tool, plus JSON-RPC request and response examples.
- Register External MCP Servers -- Add third-party MCP servers to the Gateway so their tools become available to the discovery flow.
- MCP Protocol -- The underlying protocol agents use to call discovery tools.