Find collector garage builders, car lifts and storage.
Scored across 6 tools
Each tool targets a distinct facet: detail lookup by slug (get_listing), free-text/faceted query (search_listings), and the supporting taxonomies (list_categories, list_places, list_sources) plus aggregate metadata (get_stats). The split between get_listing and search_listings is clear from their descriptions, and the three list_* tools operate on non-overlapping resources.
All six tools follow a strict verb_noun snake_case pattern: get_listing, get_stats, list_categories, list_places, list_sources, search_listings. Verb choice (get vs list vs search) is used consistently and meaningfully.
Six tools is a tight, well-scoped surface for a read-only directory API, with no redundant or filler entries. Every tool maps to a distinct query the domain needs.
The read-only lifecycle is well covered: detail lookup, faceted search, taxonomy listings, provenance, and stats. Minor gaps exist, such as no detail lookups for an individual category, place, or source, but agents can work around this via the count-bearing list tools.
Get one published garage specialist by its slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The listing slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the description's only added signal is 'published', hinting that unpublished records are not returned. It says nothing about not-found handling, error shape, or whether the record embeds related entities; for a simple read against a fully annotated tool that is adequate but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single ten-word sentence with the resource and lookup key front-loaded, and no hedging or filler. Nothing could be removed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read with full annotation coverage and no output schema, the core is present, but an agent still cannot tell what a 'garage specialist' returns, whether unpublished slugs 404 silently, or how this relates to search_listings/list_places. The definition is minimally viable rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single slug parameter already carries a pattern, length bounds, and a description. The phrase 'by its slug' restates the schema rather than adding format, source, or lookup-failure semantics, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get'), cardinality ('one'), and identifier ('by its slug'), and the word 'published' scopes the result set. The resource is described as 'garage specialist' while the tool is named get_listing and siblings use 'listings'/'places', so the vocabulary mismatch slightly blunts differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: you must already hold a slug, which selects this over the search/list siblings. There is no explicit 'use this when... instead of search_listings' statement, no note on what to do without a slug, and no exclusion for unpublished items beyond the adjective 'published'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the number of published garage specialists, places and categories, and when the data last changed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered structurally. The description adds valuable scope detail — the counts are of *published* specialists only, and a data-freshness field is returned — but says nothing about cost, caching, or timestamp format despite being the sole carrier of that information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the verb and enumerates exactly what is returned, with zero filler or redundant restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the necessary work of naming the return values (specialist/place/category counts plus last-changed). It falls just short of complete because the shape and type of the freshness value (timestamp vs relative age) is unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to convey; the baseline for a parameterless tool applies. Nothing in the schema is left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
A specific verb ('Get the number of') plus a precise resource set (published garage specialists, places, categories, plus last-changed timestamp), which implicitly separates it from the list_* siblings that return entities rather than counts. It never names a sibling explicitly, so differentiation is by inference rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the use of counts and freshness metadata suggests calling this instead of enumerating items, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. list_places or list_categories). An agent must infer the routing rule from the wording alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List categories with their garage specialist counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds that counts of garage specialists are attached to each category, which is useful context about the payload, but says nothing further about volume, ordering, or freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; every clause carries information. It is arguably slightly terse given there is no output schema, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should indicate what comes back, and it does (categories plus specialist counts). Combined with annotations covering safety and a zero-parameter schema, an agent has enough to call it correctly; only ordering or pagination behavior is unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4 and there are no parameter semantics for the description to compensate for. Nothing is missing on this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('categories') and adds what each entry includes ('garage specialist counts'). It doesn't explicitly differentiate from siblings, but the sibling names (get_listing, list_places, list_sources) target clearly different resources, so confusion risk is low.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: as a zero-parameter enumeration of categories, an agent can infer it is a browsing/lookup call. There is no explicit statement of when to prefer it over get_stats or get_listing, nor any precondition calls (e.g., whether categories feed into search_listings).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List countries, regions and cities that have garage specialists.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only the filtering semantic that results are restricted to places with specialists; it says nothing about result ordering, hierarchy, pagination, or size, which are the traits an agent would still need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence that front-loads the verb and resource with no filler. Nothing could be removed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description carries the burden of explaining the return shape, and it does not: it is unclear whether the response is a flat list of place names or a country→region→city hierarchy, nor whether counts or IDs accompany the names. That is the main gap for an agent that needs to reuse the values as filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly does not invent argument behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a specific resource (countries, regions and cities with garage specialists), which distinguishes it from the sibling listing/search tools that return actual listings. It stops short of naming any sibling alternative, but the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is a discovery/lookup tool for geographic filter values, likely a precursor to search_listings. There is no explicit statement of when to use it versus search_listings or get_stats, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List where the garage specialist data comes from, with the license and refresh of each source.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds useful context by naming the fields returned (license and refresh), but it does not describe result format, ordering, or completeness, and there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and resource, with no redundant or wasted language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list tool with annotations covering safety and no output schema, the description is mostly complete. It names the key return fields, but could have added a bit more about the shape or granularity of the returned source list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so parameter semantics are not a concern; baseline 4 applies. The description does not need to explain any inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: listing the sources behind the garage specialist data, including license and refresh details. It clearly distinguishes this from sibling tools like get_listing, get_stats, list_categories, list_places, and search_listings, though it does not explicitly say so.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: call this when provenance, licensing, or refresh cadence for the garage specialist data is needed. There is no explicit when-to-use guidance, no exclusions, and no mention of how this relates to the other list/get tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search published garage specialists by text, place and category.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search text, with at least one letter or digit. Matches name, categories, attributes, description and place. Typos fall back to close matches. | |
| city | No | City slug, from /places. | |
| sort | No | `relevance` needs `q` and is the default with it. `name` is the default without `q`. `recent` is newest first. | |
| limit | No | Items per page. | |
| cursor | No | `page.nextCursor` from the previous response. Opaque. Send the same filters and `limit`. | |
| region | No | Region slug, from /places. | |
| country | No | ISO 3166-1 alpha-2 country code, any case. A country the directory does not cover, as listed in /places, gives 400. | |
| category | No | Category slug, from /categories. A parent slug also matches its children. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so safety is covered. The description adds one genuinely useful behavioral fact — that only 'published' specialists are returned — but says nothing about typo fallback behavior, pagination, or what an empty result means, all of which the schema only partially covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with no filler or repetition. It is arguably too terse for an 8-parameter paginated search, but nothing in it is wasted, so it loses only a little.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description would be the place to signal that results are paginated via a cursor and that only published listings appear. It gestures at 'published' but leaves the return shape entirely undocumented for a fairly complex 8-param search operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is documented in detail (slug formats, cursor reuse, sort defaults). The description's 'text, place and category' phrase merely maps to the q/city-region-country/category groups and adds no format or interaction detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search') and resource ('published garage specialists') with the three axes of matching (text, place, category). It is clearly distinguishable from get_listing by the plural result-set framing, but it never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the mention of text/place/category searching, so an agent can infer this is the discovery entry point. However, there is no explicit guidance on when to prefer it over get_listing, nor any hint that list_places/list_categories exist to source the required slugs referenced in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_listingget_statslist_categorieslist_placeslist_sourcessearch_listingsFind self-storage near you: storage units, container parks and garages with sizes, prices and hours.
Add one secure layer between your agents and this server.
