Skip to main content
Glama

ExtensionDash

find_listing

Turn an extension's NAME into the store id every other tool asks for.

Start here whenever you were handed a name rather than an id or a store URL, which is what a person will normally give you. Matching is approximate: case, punctuation, word order and a missing word are all tolerated, so "image search anywhere" finds "Reverse Image Search Anywhere".

This reads names already stored here. It is not a store search and reports no ranking -- for where an extension actually places on a term, use search_store. It starts no fetch, so it never returns "pending" and spends none of the store-egress budget; like every call here it is logged and counts against the rate limit.

Every match carries cached. true means get_store_listing can serve that extension's page from cache right now, with no account.

false says one thing only: this locale has no fresh guest-readable cache. For a guest that is a refusal. Signed in, the next call may answer "pending" while it fetches, or hand back older data marked stale while it refreshes, or report a recent fetch failure with no listing at all -- so read the status you get rather than assuming which of those it will be.

cached is a promise about ONE locale -- the one you pass here, "en" by default -- because a Chrome listing read in German needs two fetches, English structure plus German copy. Ask with the locale you intend to read in, or the answer is about a different call than the one you make.

Two extensions can share a name, so matches carry publisher to tell them apart when the store recorded one.

A name too long to match in full is refused rather than trimmed, because trimming would report the words it dropped as matched.

No match means this app has never seen that name -- guessing another spelling will not help. Use search_store if what you have is really a search phrase; otherwise ask the person you are working for for the extension's store URL or id, and pass that to get_store_listing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesThe extension's name as you were given it, e.g. "Reverse Image Search Anywhere".
limitNoMost matches to return, best first. Defaults to 10.
storeNoRestrict to one store. Both are searched when omitted.
localeNoWhich locale `cached` should answer for. Defaults to "en". Does not change which names match.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

No annotations, so the description carries the full burden and does so: it states no fetch occurs, no egress budget is spent, the call is logged and rate-limited, long names are refused rather than trimmed, and it deeply qualifies the `cached` flag's meaning for guests vs. signed-in users including the 'pending'/stale/failure possibilities.

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?

Purpose and the name-vs-id trigger are front-loaded, and each paragraph covers a distinct concern (matching tolerance, scope vs. search_store, cost/logging, `cached` semantics, locale, ambiguity, refusal). It is long and somewhat essayistic, but almost every sentence carries non-redundant operational detail rather than padding.

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 and no annotations, the description still tells the agent what comes back (`cached`, `publisher`, ranked matches) and how to interpret each, plus the failure and refusal modes. Nothing needed to invoke or interpret the call is missing.

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 adds real semantics beyond the schema: it explains that `cached` answers for exactly one locale because a Chrome listing in German needs two fetches, and warns to pass the locale you intend to read in — meaning the schema text alone ('Does not change which names match') doesn't convey.

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?

Opens with a precise verb+resource+transformation: 'Turn an extension's NAME into the store id every other tool asks for.' It explicitly distinguishes itself from search_store ('It is not a store search') and positions itself relative to get_store_listing, so an agent can route correctly without opening the schema.

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

Usage Guidelines5/5

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

Gives an explicit trigger ('Start here whenever you were handed a name rather than an id or a store URL'), names the alternatives and when to prefer them ('Use search_store if what you have is really a search phrase'), and prescribes a fallback when nothing matches (ask for the URL/id and pass to get_store_listing).

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