Search sports nutrition in Russia, compare live prices and create Capital Health cart links.
Scored across 6 tools
Most tools have clearly distinct purposes: searching, reading details, suggesting analogs, listing regions/goals, and creating cart links. Some minor overlap exists between product_analogs and the similar-item suggestions in products_search, but descriptions clarify their intended use.
All names use snake_case and are readable, but they mix noun-style names like catalog_goals and product_details with verb-inclusive names like cart_link_create and products_search. The pattern is not fully consistent, though still predictable.
Six tools is a well-scoped set for a product catalog and cart-link service. Each tool addresses a distinct step in the workflow without unnecessary redundancy.
The set covers the main catalog workflow: region selection, search, details, analogs, approved goals, and cart-link creation. Minor gaps like explicit category/brand browsing exist, but the search tool can compensate and checkout is intentionally left to the merchant site.
Create a shareable product-selection link valid for 24 hours from creation. Link expiry does not lock prices; use current merchant catalog prices in RUB. This does not change a personal cart, place an order or pay. Use only items and quantities approved by the user. Never request names, phone numbers or addresses; checkout happens on the merchant site.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ||
| products | Yes | ||
| region_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the burden. It discloses side effects (creates a link, does not change cart/order/pay), the 24-hour expiry, the fact that expiry does not lock prices, and the privacy rule about not requesting personal data. This goes well beyond the minimal 'create a link' statement, despite not detailing internal persistence or response format.
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?
Four sentences, all purposeful. The main purpose is front-loaded, followed by expiry/pricing behavior, non-effects, and safety guidelines. No filler or redundancy.
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 description covers safety, expiry, pricing, and what the tool does not do, which is essential for correct invocation. However, it omits explanation of the required 'region_id' parameter and provides no hint about the output/return value. Given there is no output schema, a brief mention of the response would improve completeness, but the description is adequate for a safe, non-destructive link creation task.
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 3 undocumented parameters. It only indirectly references products and quantities ('product-selection', 'items and quantities approved'), but does not explain 'country' or 'region_id' at all. This is a significant gap for a tool that requires three parameters with no schema descriptions.
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 and resource ('Create a shareable product-selection link') and clearly distinguishes the tool from siblings by adding the 24-hour validity and clarifying that it does not place orders or pay. The purpose is unmistakable and does not depend on the schema.
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 provides explicit usage context: the link is for sharing a product selection, prices come from the current catalog, and checkout happens off-site. It also gives clear behavioral constraints ('Use only items and quantities approved by the user', 'Never request names, phone numbers or addresses'). It does not name alternative tools, but none of the siblings appear to serve a similar cart-link function, so this is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active, merchant-approved catalog goals. Use goals only when requested. Not medical advice.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the scope filter 'active, merchant-approved', which is useful, but it does not describe return format, pagination, or other behavior beyond the list itself.
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 short and front-loaded with the main action. The 'Not medical advice' sentence is tangential but does not significantly hurt clarity; three sentences are still concise.
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?
This is a simple read-only tool with one constrained parameter, and the annotations and schema cover safety and input. The description supplies the tool's purpose and a usage condition, which is largely sufficient even without an output 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 0%, so the description was expected to compensate, but it never mentions the 'country' parameter. The schema's required const 'RU' is clear on its own, but the description adds no meaning about how or why the parameter affects results.
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 a specific resource ('active, merchant-approved catalog goals'), which clearly distinguishes it from sibling tools like products_search or delivery_regions. An agent can tell exactly what this tool returns.
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?
'Use goals only when requested' is an explicit condition for when to invoke the tool. It does not name alternative tools, but it provides clear context and a when-not-to-use signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List supported Russian delivery regions. Ask the user to select a region before selecting products.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| country | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral context that the tool is meant to be used before product selection, which is useful. However, it doesn't disclose details like whether the list is static or dynamic, or whether it requires any authentication, but the annotations carry most of the burden.
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 sentences, no wasted words. The core purpose is front-loaded, and the usage instruction is concise. Every sentence 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 simple list tool with read-only annotations, the description is mostly complete. The main gap is the undocumented 'query' parameter, which could affect how the agent calls the tool. The output schema is absent, but for a list tool the return format is likely obvious. The usage instruction adds conversational context that helps the agent.
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 parameters. The description mentions 'Russian delivery regions' which implies the country parameter is RU, but it doesn't explain the 'query' parameter at all. The schema shows query is optional with a maxLength of 80, but the description gives no hint about what query does (e.g., filtering regions by name). This is a 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 clearly states the tool lists supported Russian delivery regions, which is a specific verb and resource. It distinguishes itself from sibling tools like products_search and product_details by focusing on delivery regions rather than products. However, it doesn't explicitly name a sibling alternative, so it doesn't fully differentiate from potential region-related 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 description provides explicit usage guidance: 'Ask the user to select a region before selecting products.' This tells the agent when to use the tool in a conversation flow. It doesn't mention when not to use it or name alternatives, but the context is clear enough for a list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest available products with the same catalog type or category. These are not medically interchangeable. Ask before replacing an item.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| country | Yes | ||
| region_id | Yes | ||
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond annotations by noting that results are 'not medically interchangeable' and that the user must be consulted before replacement, which prevents misuse. It does not describe output structure or ordering, keeping it at a 3.
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 three short sentences with the purpose front-loaded. Every sentence earns its place: the primary function, the safety caveat about non-interchangeability, and the instruction to ask before replacing. There is no filler or redundancy.
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 has four parameters, all undocumented in the schema, and no output schema, but the description does not explain how results are generated, what 'available' means, how limit applies, or the relationship between product_id, region_id, and country. The caveats are useful, but operational details essential for calling the tool correctly are missing.
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, but it provides no explicit meaning for any parameter. 'Same catalog type or category' only faintly suggests that product_id is the reference item; country, region_id, and limit are entirely unexplained. The tool has three UUID parameters and a limit that an agent cannot confidently populate based on this definition.
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 ('Suggest') and resource ('available products with the same catalog type or category'). It clearly differentiates from sibling tools like product_details and products_search by focusing on analog/similar products rather than general search or single-product lookup, though it doesn't explicitly name those alternatives.
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 conveys a clear use case: finding alternative products of the same catalog type or category. It also provides a behavioral instruction ('Ask before replacing an item') that implies the agent should get user consent before acting. However, it does not explicitly say when to avoid this tool or name alternatives such as products_search, so the guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one available product and manufacturer information for a selected Russian delivery region. Price comes from the current merchant catalog in RUB. Unavailable products return no details and may suggest similar available items.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ||
| region_id | Yes | ||
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent safety, and the description adds useful behavioral context: price source and currency from the current merchant catalog in RUB, plus the edge-case behavior that unavailable products return no details and may suggest similar items. This goes beyond what the annotations alone provide.
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 sentences, front-loaded with the main action and resource, then efficient supporting detail. Every clause adds value, with no repetition of schema or annotation 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 simple read tool with full annotations and no output schema, the description covers the main purpose, region scope, price source, and unavailable-product behavior. It could be slightly richer by referencing how to obtain valid region IDs, but nothing critical is missing for an agent to make a correct 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?
The schema has 0% description coverage, so the description must carry parameter meaning. It does map region_id to 'selected Russian delivery region' and product_id to 'one available product', and 'Russian' aligns with country=RU. However, it does not elaborate on UUID semantics or required relationships beyond that minimal mapping.
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 (Read), a clear resource (product and manufacturer information), and a scoping condition (selected Russian delivery region). This distinguishes it from sibling tools like products_search and product_analogs, making the tool's role immediately identifiable.
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 gives clear context for when to use the tool: when you need details for one specific product in a specific Russian delivery region. It does not explicitly name alternatives or state when not to use it, but the purpose is specific enough that an agent can infer the right context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search available products by text, brand, form, price and optional approved goal. Prices come from the current merchant catalog in RUB; never invent or override prices. Similar available items may be suggested for an exact unavailable name or SKU. Never substitute without user confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | ||
| page | No | ||
| sort | No | name | |
| brand | No | ||
| limit | No | ||
| query | No | ||
| country | Yes | ||
| goal_code | No | ||
| max_price | No | ||
| min_price | No | ||
| region_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable behavioral context: prices must come from the current merchant catalog in RUB and must not be invented or overridden, and similar items may be suggested but substitution requires user confirmation. These details go beyond the annotations and inform the agent of important constraints.
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 three concise sentences, front-loaded with the core purpose. Each sentence earns its place: the first states the action and filters, the second sets price authority, the third covers suggestion behavior and user confirmation. No fluff or 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 search tool with 11 parameters, no output schema, and 0% schema description coverage, the description covers key behaviors but omits details like pagination (page, limit), sorting (sort), and the fixed country (RU). It also doesn't explain what an 'approved goal' is or how to use region_id. The tool's complexity is moderate, and the description is adequate but leaves gaps in parameter usage and response format.
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 parameter meaning. It lists the main filter dimensions (text, brand, form, price, optional approved goal) which map to query, brand, form, min_price/max_price, and goal_code. However, it does not explain page, sort, limit, country, or region_id, nor does it clarify how 'price' is applied (range vs exact). It adds some meaning beyond the schema (e.g., price authenticity) but is not comprehensive for all 11 parameters.
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 clear verb ('Search') and resource ('available products') with specific filter dimensions (text, brand, form, price, optional approved goal). It distinguishes itself from siblings like product_analogs (which finds alternatives) and product_details (which retrieves details) by focusing on search. The mention of suggesting similar items for unavailable names also hints at its scope, but the primary purpose 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?
The description gives clear context on when the tool is used (searching products) and includes a behavior about not substituting without user confirmation. However, it does not explicitly contrast with sibling tools like product_analogs, which might also handle similar item suggestions. There are no explicit exclusions or conditions for when not to use this tool, leaving some ambiguity for an agent choosing among siblings.
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.
cart_link_createcatalog_goalsdelivery_regionsproduct_analogsproduct_detailsproducts_searchSupplement prices, price history, SupplementScore ratings & verified discount codes (NL/BE/DE/FR/ES)
Evidence-ranked supplement data: search, compare, price history, goal recs. No API key.
Food and nutrition data: search, macros, and comparisons
Search 160k+ Russian B2B products from 8,900+ verified manufacturers (EN/RU).
Add one secure layer between your agents and this server.
