Skip to main content
Glama

Search tools

search_tools
Read-onlyIdempotent

Find AI and software tools tracked on usedby by name, other product name, or what they do (category, topic or task, in English, French, Spanish, German or Portuguese, e.g. 'CRM', 'contract management', 'gestion des contrats'), with how many companies publicly use each.

Input Schema

NameRequiredDescriptionDefault
limitNoRows to list (default 25, max 100). MCP may return fewer rows to fit its response budget; follow pagination.nextOffset and snapshot.
queryYesTool name, category or task, e.g. 'cursor', 'coding', 'customer support', 'contract management'.

Output Schema

NameRequiredDescriptionDefault
errorNoSet when the input matched nothing, was invalid, or the answer could not be returned.
notesNoHow to read this answer.
queryNoThe text searched.
toolsNoMatching tools, with their public customer counts.
sourceYesThe usedby page to cite: quote with a link to source.url.
messageNoWhat went wrong, with the next step, when error is set.
truncatedNoMore matches exist than listed.
suggestionsNoClose matches to ask again with, when error is not_found.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / limit / description
      Previous value: -"Rows to list (default 25, max 100). The usedby page has the full list."New value: +"Rows to list (default 25, max 100). MCP may return fewer rows to fit its response budget; follow pagination.nextOffset and snapshot."
    • changedOutput schema / properties / error / description
      Previous value: -"Set only when the input matched nothing or was invalid."New value: +"Set when the input matched nothing, was invalid, or the answer could not be returned."
  2. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"Tool name or category, e.g. 'cursor', 'coding', 'customer support'."New value: +"Tool name, category or task, e.g. 'cursor', 'coding', 'customer support', 'contract management'."
  3. Changed1 schema field changed
    • addedOutput schema / properties / tools / items / properties / match
      Added value: +{
      +  "description": "How the tool matched: name (or another name of the product), topic (category, family or tag), close (a near spelling: check it).",
      +  "enum": [
      +    "name",
      +    "topic",
      +    "close"
      +  ],
      +  "type": "string"
      +}
  4. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds behavior beyond that: queries are matched across five natural languages and results include public company-usage counts, which tells the agent how the matching and payload actually behave. Pagination/row-budget behavior is left to the schema rather than elaborated.

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

Conciseness4/5

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

A single sentence with the verb and resource front-loaded, and the parenthetical example list earns its place by showing multilingual query shapes. It is dense though — the trailing 'with how many companies publicly use each' could be its own clause for readability.

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

Completeness4/5

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

With an output schema present and both parameters fully documented, the description covers what remains: what the tool searches over, what languages it accepts, and that results carry public-usage counts. The main missing piece is decision guidance against the five sibling tools.

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 100%, so the baseline is 3, but the description genuinely broadens the 'query' semantics beyond the schema's 'Tool name, category or task' by adding matching on 'other product name' and explicit multilingual support with concrete examples. It says nothing about 'limit' beyond what the schema already documents.

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

Purpose4/5

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

States a specific verb and resource ('Find AI and software tools tracked on usedby') plus the matching dimensions (name, other product name, category/topic/task) and that results carry company usage counts. It doesn't distinguish itself from siblings like shortlist_tools or who_uses, so an agent can't tell from the text alone why it would pick this over those.

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

Usage Guidelines3/5

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

Usage is only implied by the phrasing — you search when you need to locate a tool by name or capability. There is no explicit when-to-use/when-not, no mention of alternatives such as who_uses (for usage data on a known tool) or shortlist_tools, and no prerequisites stated.

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