Skip to main content
Glama

Every MCP

Search MCP servers

search_tools
Read-only

Search the public MCP server universe by what you want a server to do. Returns compact summaries; call get_server for a full record. Ordered by relevance, except that results with official_match true come first and results with has_public_source true come next. official_match is true when the server is published by the company the query names, and how a query names a company depends on query_class. query_class is named when the query names exactly one product we recognize (a search for it, a comparison, or a question whether a server for it exists) and we have matched that company to the publisher namespaces that are its own, by checking its own website: its web domain, such as com.stripe for stripe.com, or for some companies its account on a code host, such as io.github.getsentry. Otherwise query_class is discovery. On a named query only results under those namespaces can have official_match true; another publisher whose domain carries the same name never does. When the query is the product's name alone, ignoring the words mcp, server, official, the, a and an, up to three of the company's servers are counted among the closest matches, and every result under its namespaces has official_match true. When it has other words too, the same holds only for the company's servers already among the 100 closest matches by its words, or among the 5 closest by its meaning and within a cosine distance of 0.5 of it; the rest keep their place and have official_match false. On a discovery query, official_match is true when the query, ignoring the words mcp and server, is exactly the registered name of the domain a namespace names, such as linear for app.linear (linear.app), exactly one publisher namespace in the search index has a domain of that name, the server is under that namespace, and it is one of the three closest matches by relevance; code-host namespaces such as io.github.* and namespaces beneath a shared host such as workers.dev have no such name, and a server under that namespace that matches less closely keeps its place and has official_match false. On a discovery query the flag says only that the domain carries the name searched for, not who operates the server. The registry requires proof of control of a domain, or of a code-host account, to publish under it; we run no check of that control of our own. has_public_source is true when the record's repository URL is an owner/repo URL on github.com or gitlab.com that we link as source code, unless a check of GitHub within the last 7 days found that the github.com repository does not exist or is not public. No such check is made for gitlab.com. Within each group, a result whose publisher owns its GitHub repository, as checked within the last 7 days, moves up a little with the repository's stars, at most once per repository in a response, and moves down when the repository is archived. tool_count, tools_tokens_estimate and protocol_version come from the same check, are given only when it got the server's MCP answer within the last 7 days, and are null otherwise. tools_tokens_estimate is an estimate of the tokens the tool definitions take, counted with the o200k_base tokenizer. This data comes from the Official MCP Registry.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many servers to return. Default 10, maximum 50.
queryYesWhat the server should do, in words. A phrase works as well as a keyword.
filtersNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes far beyond the readOnlyHint annotation, explaining ordering rules, official_match and has_public_source semantics, freshness checks, nullability, and the registry data source. It discloses important behavioral caveats, such as the discovery-query official_match meaning and lack of GitLab verification.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and alternative, but it then becomes extremely long and dense with ranking edge cases. Much of the official_match and ordering detail is unlikely to be needed by an agent selecting or invoking the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining returned flags and fields, and it does so comprehensively. It covers official_match, has_public_source, sorting, tool_count, tools_tokens_estimate, protocol_version, and null cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is moderate at 67%, and the description adds substantial meaning about how query wording affects query_class, official_match, and ordering. It does not explain filters, transport, publisher, or has_remote beyond the schema, but the query parameter semantics are unusually well documented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource: searching the public MCP server universe by intended server behavior. It also distinguishes the result type from get_server by saying compact summaries are returned and get_server is needed for a full record.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear usage context: use free-form words for what the server should do, and call get_server when a full record is needed. It does not explicitly cover when to use get_install_config or when not to use this search, but the sibling routing for the main alternative is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources