Find the team for your wine room.
Scored across 6 tools
Each tool has a clearly distinct purpose: retrieving one listing, searching listings, listing categories, listing places, listing sources, or retrieving stats. There is no meaningful overlap between search_listings and get_listing, and the list_* tools target separate resource types.
All names follow a consistent snake_case verb_noun pattern using clear verbs: get_, list_, and search_. Singular versus plural nouns are used appropriately for single-item versus collection operations.
Six tools is well-scoped for a read-only directory of wine cellar specialists. Each tool covers a distinct access pattern without unnecessary bloat.
The surface covers discovery, search, individual retrieval, taxonomy listings, sources, and stats, which is strong for a read-only directory. Minor gaps include no dedicated get_category or get_place detail tool, though list_* tools likely make those workable.
Get one published wine cellar 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?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior. The description adds the useful constraint that only published listings are returned and that the result is singular, but it does not cover not-found behavior or return details.
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?
The description is a single efficient sentence with no redundant or filler content. The key scoping details are front-loaded.
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 simple one-parameter read tool with rich annotations and no output schema, the description is nearly complete. It could mention not-found behavior, but the essential retrieval contract is clear.
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 input schema has 100% description coverage for the single slug parameter, and the description only restates that lookup is by slug. With the schema already defining format constraints, the description adds no additional parameter semantics.
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), resource (one published wine cellar specialist), and lookup key (by its slug). It clearly distinguishes the single-item retrieval from sibling listing/search tools.
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 phrase 'by its slug' implies the tool should be used when a known slug is available, but it does not explicitly name when to use this instead of search_listings or list_* alternatives. No exclusions or prerequisites are stated.
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 wine cellar 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 behavior. The description adds that counts are for 'published' data and reports a last-changed freshness marker, but it does not detail response shape or auth/rate-limit behavior. With rich annotations, this is adequate added context.
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; it covers all stated outputs without repetition.
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 stats endpoint with rich annotations, the description gives the metrics and freshness scope needed to call it. It could be more precise about the exact response structure or whether 'published' applies to all listed entities, but no output schema exists to carry that detail.
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?
There are no parameters; schema coverage is 100% and no parameter semantics are needed. The baseline for zero-parameter tools is 4.
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') and concrete return metrics: counts of published specialists, places and categories plus a last-changed timestamp. This clearly differs from list/search siblings by returning aggregates rather than records, though it does not explicitly name those siblings.
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?
No when-to-use or when-not-to-use guidance is given, and no alternative tool is named. An agent must infer that this is for aggregate counts/last-updated metadata rather than listing categories or places.
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 wine cellar 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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the agent knows this is a safe, repeatable internal read. The description adds that results carry aggregated specialist counts, which is genuinely useful context beyond the annotations, but says nothing about ordering, completeness of the enumeration, or how the counts are computed.
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 zero filler, and the returned payload element is front-loaded rather than buried. Every word earns its place.
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 with full annotation coverage and no output schema, the description covers what the agent needs to select and call it. The only residual gap is whether the returned category list is exhaustive or ordered, which the agent may care about when presenting results.
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 the schema is fully self-describing. The description correctly adds no parameter noise, since there is nothing to disambiguate.
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 categories') plus the distinguishing payload element ('wine cellar specialist counts'). It is clear and distinguishable in practice from list_places and list_sources, though the description never names those siblings or states the contrast 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?
There is no explicit when-to-use statement, no prerequisites, and no mention of alternatives such as get_stats or list_places. Usage is only implied by the verb 'List' on a zero-parameter tool, which keeps the risk low but leaves routing to inference.
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 wine cellar 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 no extra behavioral context (e.g., result ordering, completeness, or whether the list is static or dynamically derived from listings).
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 waste. The resource and the qualifying condition are stated immediately.
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 enumeration with no output schema, the description conveys enough to call it and understand what it returns. A brief note on whether results are static or derived from live listings would make it 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?
The tool has zero parameters, so there is nothing to disambiguate; baseline for a no-param tool is 4. The description correctly implies the output shape (a flat enumeration of places) without needing parameter detail.
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 concrete resources (countries, regions, cities), plus the filtering condition (have wine cellar specialists). It is clearly distinguishable from siblings like search_listings or get_listing, though it doesn't explicitly contrast itself with them.
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?
No explicit when-to-use or when-not-to-use guidance, and no named alternatives. Usage is implied: an agent can infer this is a facet/enumeration lookup for discovering place values, but the description doesn't say so.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List where the wine cellar 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 declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that each source includes license and refresh information, but does not discuss auth, rate limits, pagination, or empty-result behavior; with annotations covering safety, this is modest added context.
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?
The description is a single front-loaded sentence with no repetition or wasted words. It states the resource and the notable return fields immediately.
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 metadata tool, the description conveys both purpose and key return content (license and refresh per source). Without an output schema the exact return shape is unspecified, but that is a minor gap for such a simple tool.
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?
There are zero input parameters, so the rubric baseline is 4. The empty schema is fully consistent with the description and there is nothing further to document.
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?
Specific verb 'List' and resource 'sources' plus scope 'where the wine cellar specialist data comes from' and included fields 'license and refresh' make the purpose unambiguous. It clearly distinguishes this provenance-list tool from siblings like get_listing, list_categories, list_places, and search_listings.
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 description implies use for inspecting data provenance, licensing, and refresh metadata, but gives no explicit when-to-use, when-not, or named alternatives. The agent can infer the context, but guidance is not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search published wine cellar 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?
The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety behavior is covered. The description adds the useful scope detail that only 'published' specialists are searched, but it does not add pagination, result-format, auth, or rate-limit context beyond what the schema implies.
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?
The description is a single front-loaded sentence with no filler or repetition. Its brevity is appropriate for a tool whose parameters are fully documented in the schema.
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?
The core search behavior is clear, and the rich schema plus annotations cover filters and safety. However, with no output schema, the description does not explain what a result or page contains, and pagination is only implied through the cursor parameter in the schema.
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 the schema carries parameter documentation. The description only indicates text, place, and category filtering; it adds no syntax or meaning for sort, limit, or cursor beyond what the schema already states.
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, resource, and search facets: 'Search published wine cellar specialists by text, place and category.' This distinguishes it from retrieval sibling get_listing and list-style siblings such as list_places and list_categories.
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 or when-not-to-use guidance and no named alternatives. It does not mention using get_listing for detail or list_places/list_categories to obtain slugs, even though the schema references /places and /categories.
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_listingsWine cellar manager: bottles, racks, drink windows, pairings and a shared wine registry.
Add one secure layer between your agents and this server.