Workshop tooling and replacement parts with landed USD pricing for US buyers. Duty, international shipping and clearance are included; dispatch within 48h, delivery 7-12 days, 14-day returns. 7 tools: search products, get product, quote an order from a plain-language need, create an order with a payment link, recommend the product for an answer page, buy by answer page, and check stock.
Scored across 7 tools
Most tools target clearly distinct steps: search_products (catalog lookup), quote_order (need-based pricing), get_product (record detail), check_stock (availability), and recommend_for_answer (page-specific pick). The one soft overlap is buy_by_answer vs create_order, which both produce a payment link and differ only in input shape (slug vs product id), so an agent may hesitate between them.
All seven tools are snake_case verb-first names (search_products, get_product, check_stock, create_order, quote_order, recommend_for_answer, buy_by_answer), which is highly predictable. Minor wrinkle: buy_by_answer and recommend_for_answer use a verb_by_noun form whose object ('answer') is not the resource actually acted on, slightly breaking the verb_noun readability.
Seven tools is well within the well-scoped range and each covers a distinct stage of the buy flow: discover, quote, inspect, check stock, recommend, and two checkout paths. Nothing appears redundant enough to remove, and nothing trivial is included just to inflate the count.
The pre-purchase side is solid (search, quote, detail, stock, recommendation, order creation), but the post-order lifecycle is missing: no get_order/order status, no cancel, and no return or refund tool despite the advertised 14-day returns. Agents can complete a purchase but hit a dead end afterward.
Order the product recommended by an answer page, in one step, by passing the page slug instead of a product id. Returns a payment link for the human to approve.
| Name | Required | Description | Default |
|---|---|---|---|
| qty | No | ||
| slug | Yes | ||
| buyer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the most important trait: it returns a payment link for a human to approve rather than charging directly. It does not say whether an order record is created immediately, what happens if the product is out of stock, or what permissions are required.
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 with no filler, and the one-step slug-based behavior plus the returned payment link are both front-loaded. Every clause carries 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?
Calling out the payment-link return value compensates well for the missing output schema, which is the biggest gap it could fill. However, with no annotations, an undocumented nested buyer object, and no stated interaction with stock or order creation, the definition is not complete for a purchasing action.
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 0% across three parameters, so the description must compensate. It explains only 'slug' (a page slug, not a product id); 'qty' and the nested 'buyer' object with email and country get no explanation at all, so the agent is guessing on the buyer identity shape.
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 concrete verb and resource: 'Order the product recommended by an answer page', and adds the key scoping distinction that it takes a page slug 'instead of a product id', which separates it from the generic create_order sibling. It stops short of naming the sibling explicitly, but an agent can still tell the two apart.
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 rather than stated: use this when you hold an answer-page slug rather than a product id. There is no explicit guidance on when not to use it, whether stock should be checked first (check_stock), or whether quote_order should precede it, leaving the agent to infer the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current availability for one SKU and its dispatch window.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden, and it discloses very little: "current" hints at a live lookup rather than a cache, but it never states that this is a read-only operation, what happens for an unknown or discontinued SKU, whether stock is per-warehouse, or what the dispatch window represents. For a tool with zero annotation coverage, this is a significant gap.
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?
It is a single short sentence with no filler, which is good, but it is a sentence fragment lacking a verb and reads as under-specified rather than deliberately terse. Nothing is front-loaded beyond the resource 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?
The tool is simple (one required param, no output schema, no nesting), but with no annotations and no schema descriptions the definition should at minimum state that it is read-only and clarify the dispatch-window output it advertises. It also omits any routing relative to get_product and search_products, leaving the agent to guess when this tool is the right call.
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 0% on the single product_id parameter, so the description must compensate. Saying "one SKU" does clarify that product_id is a single SKU identifier rather than a list or a free-text query, which is real added meaning, but it gives no format, source, or resolution guidance.
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?
"Current availability for one SKU and its dispatch window" identifies the resource (stock availability) and the scope (one SKU), plus a secondary output (dispatch window). However, it is a noun phrase with no verb, and it never distinguishes itself from siblings like get_product or search_products, so the agent must infer that this is the dedicated stock-lookup 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?
There is no when-to-use guidance at all — nothing says to call this instead of get_product, nor that it requires an already-known product_id (i.e., use search_products first to resolve one). The only implied guidance comes from the phrase "one SKU," which hints at single-item scope but states no alternative or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an order and get a payment link for the human to approve. Never charges a card on its own.
| Name | Required | Description | Default |
|---|---|---|---|
| qty | No | ||
| buyer | No | ||
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, and it does deliver one critical fact: the tool never charges a card itself and defers approval to a human. Beyond that it is silent on side effects that matter for an order-creating tool, including whether orders persist, how long the payment link stays valid, and whether repeated calls create duplicate orders.
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, both front-loaded with the critical constraint (payment link for human approval) sitting alongside the core action. Nothing is 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?
Given 0% schema coverage, a nested buyer object, and no output schema, the description is too thin for the tool's complexity: it never touches parameters, error/failure behavior, or what the returned link looks like. The human-approval guarantee is the only substantive behavioral coverage.
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 0%, so the description must compensate, and it does not: product_id, qty, and the nested buyer object (email, country) are never mentioned or explained. With a nested object and a default-behavior qty, the absence of any semantic guidance is a meaningful gap.
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+resource ("Create an order") and adds the outcome ("get a payment link"), so an agent knows exactly what the call produces. It does not, however, differentiate itself from the closely related siblings quote_order and buy_by_answer, which an agent could plausibly confuse with it.
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 "for the human to approve" implies the intended flow: use this when a human must confirm payment before anything is charged. That is useful implied guidance, but there are no explicit when-to-use/when-not rules and no naming of alternatives such as quote_order (for pricing) or buy_by_answer (for direct purchase).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full record for one SKU: price (landed), specs, weight, stock, delivery window.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose the returned content surface (landed price, specs, weight, stock, delivery window). It says nothing about what happens when the SKU is unknown, whether stock/delivery figures are live or cached, or any auth/permission requirement, which are meaningful gaps for an unannotated tool.
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 fragment that enumerates the payload with zero filler; the parenthetical "(landed)" is a useful disambiguation of price. It is terse to the point of being a fragment rather than a sentence, 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?
For a one-parameter read tool with no output schema, listing the returned fields is exactly the compensating detail an agent needs, so the core is covered. The remaining omissions (not-found behavior, freshness of stock and delivery data) are minor for a simple lookup.
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 0%, so the description must compensate for the single undocumented parameter. "One SKU" does convey that product_id is a SKU identifier rather than an internal row id or name, which is genuine added meaning, but it gives no format, example, or lookup guidance.
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?
"Full record for one SKU" states a specific retrieval resource with an explicit cardinality (one), and the field list (price landed, specs, weight, stock, delivery window) makes the scope concrete. It implicitly distinguishes itself from search_products (plural lookup) and check_stock (single-field check) via the word "Full", though it never names 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?
Usage is only implied: an agent can infer this is the single-product detail fetch rather than a search or a stock check. There is no explicit when-to-use statement, no named alternative, and no precondition such as "call search_products first to obtain product_id".
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a need + quantity into priced options. Use this when the human does not know the model number, only what they need it for and their budget.
| Name | Required | Description | Default |
|---|---|---|---|
| qty | No | ||
| need | Yes | ||
| ships_to | No | US | |
| budget_max | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It implies a non-mutating lookup by saying it returns "priced options," but says nothing about whether a quote is persisted, whether prices are live or indicative, currency assumptions, or how many options come back. For a tool with a required free-text need and defaults on qty/ships_to, this is 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?
Two short sentences, zero filler, with the purpose front-loaded and the usage condition immediately after. Nothing is repeated from 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?
For a 4-parameter tool with no annotations and no output schema, the description covers the core intent but leaves gaps: the shape of the returned "priced options" is undefined and ships_to is undocumented. Adequate to attempt a call, not enough to predict the result.
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 0%, so the description must compensate. It maps meaning onto need, qty and budget_max ("their budget"), but ships_to and its "US" default are never mentioned, and no format hints are given for need. Partial compensation only.
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?
"Turn a need + quantity into priced options" states a specific transformation (unstructured need -> priced options) rather than restating the name. It is distinguishable from get_product/search_products by framing the input as a need rather than an identifier, though it never names a sibling to contrast with.
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?
Gives an explicit trigger condition: use it when the human does not know the model number, only the need and budget. That is a real when-to-use rule. It stops short of naming the alternatives (search_products, recommend_for_answer) or stating when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given the slug of an answer page (e.g. 'tap-drill-size-chart'), return the one product we recommend for that exact question, with its landed price. Use this after quoting an answer page so the recommendation always matches the page.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It discloses the return shape (exactly one product plus landed price), which usefully signals a read-style lookup with no mutation. It says nothing about what happens when the slug is unknown, whether the card is cached, or any auth/latency characteristics.
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 tight sentences. The capability statement comes first and the workflow trigger second, with 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 one-parameter, no-output-schema lookup this is nearly sufficient: it describes the return value in lieu of an output schema and explains the slug. The remaining gap is miss/failure behavior, which an agent would need before calling.
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 0% and the single 'slug' property is bare, but the description compensates by clarifying that the slug identifies an answer page and giving a concrete format example ('tap-drill-size-chart'). That prevents confusion with a product slug, though other validation details are absent.
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: return the single recommended product (with landed price) for a given answer-page slug. It even disambiguates the resource as an 'answer page' rather than a product. It stops short of naming a sibling like get_product as the contrast case, so an agent must infer the boundary.
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?
Gives a clear trigger condition: 'Use this after quoting an answer page', which ties it to the quote_order workflow. It offers no explicit when-not conditions or named alternatives for the case where no quote was made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find workshop tooling and appliance replacement parts. Returns landed totals in USD including US duty, international shipping and customs clearance. Dispatch within 48h, delivery 7-12 days, 14-day returns.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | keyword, e.g. 'router bit set', 'cobalt drill', 'tap and die' | |
| limit | No | ||
| in_stock | No | ||
| ships_to | No | US, CA or GB | US |
| max_price | No | max landed total in USD | |
| min_price | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does add genuinely useful economics: prices are landed totals in USD including duty, international shipping, and customs clearance, plus dispatch in 48h, 7-12 day delivery, and 14-day returns. It does not disclose how results are ordered or ranked, whether an empty query returns everything (all 6 params are optional), or what a no-match response looks like.
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?
Three short sentences, purpose front-loaded, no filler or repetition. Some of the mercantile detail (48h dispatch, 7-12 days, 14-day returns) is retail copy that an agent rarely needs to select or invoke the tool, but it is compactly delivered.
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 6-parameter search tool with no annotations and no output schema, the description covers pricing and fulfillment semantics well but omits result shape, ranking, pagination, and zero-result behavior. An agent could call it correctly but cannot predict the response structure without trying.
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?
At 50% schema coverage over 6 parameters, the description compensates partially by defining what 'landed total' means, which directly clarifies max_price/min_price semantics beyond the schema's terse 'max landed total in USD'. It says nothing about q match behavior, limit/paging, in_stock defaulting, or ships_to constraints beyond what the schema already labels.
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 clear verb+resource with domain scope: 'Find workshop tooling and appliance replacement parts.' An agent knows exactly what kind of inventory is searchable, but the description never distinguishes this from siblings like recommend_for_answer, get_product, or check_stock, so the boundary is only implied by the name itself.
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 when-to-use guidance at all — nothing says whether to reach for this versus get_product (known item), check_stock (availability), or recommend_for_answer (guided discovery). The space is spent on shipping and returns copy instead of routing information, leaving alternative selection entirely to inference.
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.
buy_by_answercheck_stockcreate_orderget_productquote_orderrecommend_for_answersearch_products
Add one secure layer between your agents and this server.