Search current disc golf retailer inventory across 50+ shops by mould, weight, colour, plastic, country and price, with currency conversion and direct retailer links.
Scored across 1 tool
With only a single tool, there is no possibility of tool-to-tool confusion or misselection. The purpose of find_retailer_stock is unambiguous.
The lone tool uses a clear verb_noun snake_case pattern (find_retailer_stock), which is a clean, predictable convention. Consistency cannot be violated with a single tool.
A single tool for a whole domain is borderline thin, even though it packs many features (filtering, forex, weight/color matching). A few supporting tools would be expected for a retail-finder server.
The one tool covers searching stock but leaves notable gaps: no way to list supported retailers, countries, molds, or retrieve a single product's details. Agents hit dead ends for anything outside a direct stock search.
Search live retail inventory, prices, and stock availability for a disc golf mold across verified international and regional disc golf retailers. Supports country-specific filtering, automatic forex conversion to local currency, exact/range weight matching, color matching, and partner retailer routing.
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Color preference to filter by (e.g. 'white', 'blue', 'pink', 'glow'). Case-insensitive substring match. | |
| limit | No | Maximum number of retailer offers to return (1..25, default 10). | |
| plastic | No | Plastic grade or blend to filter by (e.g. 'champion', 'star', 'halo', 'z-line', 'neutron'). | |
| disc_slug | Yes | Canonical disc slug (e.g. 'innova-teebird', 'discraft-buzzz', 'axiom-crave'). | |
| weight_max | No | Maximum weight in grams (e.g. 175). | |
| weight_min | No | Minimum weight in grams (e.g. 165). | |
| country_code | No | ISO 3166-1 alpha-2 country code to localize search and currency (e.g. 'GB' for United Kingdom, 'US' for United States, 'SE' for Sweden, 'DE' for Germany). Defaults to 'GB'. | GB |
| weight_grams | No | Target disc weight in grams (e.g. 169). Matches exact weights and standard ranges encompassing this weight (e.g. 165-169g). | |
| in_stock_only | No | Filter to items with confirmed in-stock availability. Defaults to true. | |
| affiliate_only | No | Filter exclusively to GolfWithDiscs partner retailers. Defaults to false. | |
| strict_variants | No | If true, excludes offers where weight or color is unspecified/uncataloged by the retailer. Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses useful traits — live pricing, automatic forex conversion, partner retailer routing — but says nothing about data freshness, rate limits, failure modes when a mold is not carried, or result ordering.
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 dense sentences with the core action front-loaded and capabilities enumerated afterward. Slightly list-like, but every clause maps to a real capability and 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?
For an 11-parameter, read-only search with no output schema and no annotations, the description covers the tool's breadth well: data source, currency handling, filtering dimensions, and partner routing. It stops short of describing the shape of returned offers or empty-result behavior.
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 each parameter is already documented, so the baseline is 3. The description echoes the schema's matching semantics (exact/range weight matching, color matching, country-specific filtering) and adds the forex-conversion behavior tied to country_code, but adds little beyond that.
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) plus resources (live retail inventory, prices, stock availability) and scope (disc golf mold across verified international/regional retailers). An agent immediately knows this is a cross-retailer availability lookup rather than a catalog or price-history tool.
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 capability list (country filtering, weight/color matching, partner routing), so an agent can infer when the tool fits, but there is no explicit when-to-use/when-not guidance and no siblings to compare against. Adequate but thin on decision criteria.
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.
find_retailer_stock
