Find collector garage builders, car lifts and storage.
Scored across 11 tools
Each tool targets a distinct resource and action (course, listing, product, stats, places, sources), and the get_* vs list_* vs search_* split is clear. Minor friction: list_categories vs list_product_categories both read as generic 'categories', and the tools say 'listing' while descriptions call the entity 'garage specialist', which could momentarily confuse an agent.
Every tool follows the same snake_case verb_noun pattern: get_course/get_listing/get_product, list_courses/list_places/list_products, search_listings. No mixing of camelCase or alternative verb styles.
11 tools is a well-scoped set for a read-only directory covering specialists, courses, products, places, categories, sources and stats. Each tool covers a distinct slice of the surface with no filler.
The read-only browse/search lifecycle is thoroughly covered: lists, slug lookups, filtered search, place taxonomy and provenance. Gaps are minor — no single-category or single-place lookup, no text search for products, and no pagination/detail controls beyond what list/search imply.
Get one published academy course by its slug, with its objectives, lessons and FAQ. Exam questions and answers are never returned.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The course slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description still adds genuine value with the "published only" scope and the explicit exclusion "Exam questions and answers are never returned" — a meaningful data-boundary disclosure. It stops short of describing behavior on missing inputs or error outcomes.
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?
Two short sentences, front-loaded with the action and resource, followed immediately by the data-exclusion caveat. Nothing redundant or padded.
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 tool with full annotations and no output schema, the description adequately covers what is returned and what is deliberately withheld. The only gap is behavior for a nonexistent or unpublished slug, which an agent would want to know.
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% and the single slug parameter already carries a pattern, length bounds, and description. The description only restates lookup-by-slug and adds the published-only filter implication, which is close to the baseline for a fully documented schema.
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 and resource ("Get one published academy course by its slug") and even enumerates the payload contents (objectives, lessons, FAQ). The singular "one ... course" implicitly contrasts with the listing siblings such as list_courses, but no sibling is actually named, so it falls just short of a 5.
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?
The word "published" signals that only live courses are retrievable, which is a partial when-to-use constraint. There is no explicit guidance on when to prefer this over list_courses or a search sibling, nor what to expect for an unpublished or unknown slug.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 one affiliate product by its slug, with its page and outbound link.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The product slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new information by stating the response includes the product's page and outbound link, which matters because there is no output schema. It omits not-found behavior, which keeps it below 5.
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; the lookup key and the returned content are both stated in one pass.
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 tool with full annotation coverage and complete schema documentation, this is nearly sufficient. The only real gap is what happens when the slug does not resolve, which an agent would want to know.
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% and the single slug parameter carries its own description plus a pattern, so the schema does the heavy lifting. The description's 'by its slug' restates rather than extends that, matching the baseline 3.
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 and resource ('Get one affiliate product') and scopes it to a single-item lookup, which implicitly contrasts with the plural sibling list_products. It does not explicitly name the alternative tool, so it stops short of a 5.
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?
'by its slug' implies the precondition that the caller already has a slug, which is useful context for choosing this over list_products or search_listings. However, no explicit when-to-use/when-not statement or named alternative appears.
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 the published academy courses with their level, length, pass mark and certificate validity.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Only courses of this level. | |
| limit | No | Most courses to return. |
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 by structured data. The description adds two genuinely new facts beyond that: only published courses are returned, and each record includes level, length, pass mark and certificate validity. It does not mention ordering or what happens at the limit boundary, so it adds context without being rich.
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 sentence, front-loaded with the verb and scoped resource, then the returned fields. Every clause earns its place and there is no 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?
For a two-parameter, zero-required read tool with complete annotations, the definition covers scope (published only) and return fields, which matters because no output schema exists. The remaining gap is result ordering and whether the 50-item cap implies truncation, which an agent might want to know before listing.
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%, with the level enum and limit bounds (1-50, default 50) fully documented in the schema. The description's mention of 'level' marginally reinforces the filter but adds no syntax, default, or pagination semantics 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 (List) and a precisely scoped resource (published academy courses), plus the fields each result carries. It is clearly distinguishable from get_course (single item) and the unrelated list_* siblings, though no sibling is named 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 only implied: the agent can infer this is the browse-all path as opposed to get_course for a single course, and that the optional level parameter narrows results. There is no explicit 'use this when' or exclusion statement, and nothing about what to do if no courses match.
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 the product categories with their product counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, non-destructive and closed-world, so the safety profile is covered. The description's contribution beyond that is that results include product counts — useful, but no ordering, pagination, or empty-result behavior is disclosed.
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 with zero filler, and the key payload detail (counts) is front-loaded where the agent will read it.
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 listing tool with full annotation coverage, the description plus schema is enough to invoke it correctly. Minor gap: with no output schema, the exact return shape (field names, ordering) is only alluded to.
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 no parameters, so there is no parameter semantics to explain; the baseline for a zero-param tool 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 and resource ('List the product categories') plus a distinguishing payload detail (product counts). However, it does not differentiate itself from the sibling 'list_categories', leaving an agent to guess which category lister to call.
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?
There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The only implied cue is that this variant returns counts, which the agent must infer rather than being told.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the affiliate products, with the price each had on the day it was checked. Filter by product category.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | A product category slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is fully covered. The description adds one genuinely non-obvious data semantic — the price is a point-in-time snapshot from the day the product was checked, not a current price — but says nothing about result volume, ordering, or pagination.
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?
Two short sentences, zero filler, with the core action and the most decision-relevant detail (price snapshot semantics) front-loaded ahead of the filter note.
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-optional-param, read-only list tool with full schema coverage and annotations, the description is largely sufficient and even hints at the returned fields (product + price). The one gap is the absence of any output schema combined with no note on pagination or result limits.
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% and the single optional parameter carries its own type, slug pattern, and length bounds. The description only restates that the parameter filters by category, adding no syntax or behavior 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 and resource ("List the affiliate products") plus the returned payload (price as of the check date) and the filter dimension. It implicitly separates from get_product (single record) and list_categories, but never names a sibling, so the differentiation is left to inference.
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?
"Filter by product category" plus the optional parameter implies narrowing usage, but there is no explicit when-to-use guidance and no mention of when to prefer get_product, list_product_categories, or list_categories instead. Usage is implied rather than stated.
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_courseget_listingget_productget_statslist_categorieslist_courseslist_placeslist_product_categorieslist_productslist_sourcessearch_listingsFind home elevator dealers, installers and service firms.
Add one secure layer between your agents and this server.
