Webotee Amazon Product Research
Server Quality Checklist
Latest release: v1.1.1
- Disambiguation4/5
Most tools have clearly distinct purposes detailed in descriptions. However, some overlap exists between brand-level competitive tools (e.g., brand_under_attack vs brand_buybox_trajectory) and between watchlist_diff and watchlist_delta, which could cause agent confusion despite being technically different.
Naming Consistency4/5Tool names consistently use lowercase with underscores and often start with a domain noun (asin_, brand_, operator_, category_, watchlist_). However, there is a mix of imperative verbs (find_, filter_, search_, evaluate_, set_) and descriptive nouns, creating minor inconsistency while remaining readable.
Tool Count3/5With 72 tools, the count is well beyond the typical well-scoped range. However, the server's broad domain (Amazon product research, sourcing, watchlisting, cross-marketplace) justifies the number, though it may overwhelm agents that need to select the right tool among many.
Completeness5/5The tool surface is exceptionally comprehensive, covering search, asin/brand/operator analysis, buybox history, profit calculation, category metrics, watchlisting, playbooks, cross-marketplace comparison, MAP violations, risk assessment, and sourcing opportunities. No obvious gaps for the stated purpose.
Average 4/5 across 72 of 72 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 12 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds little behavioral detail beyond the purpose. It does not explain how results are sorted, default limits, or other behavior, leaving the agent to guess.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a front-loaded purpose. No fluff, but it could be improved by adding a brief note on ordering or defaults without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 19 parameters and no output schema, the description is insufficient. It does not explain what 'biggest recent growth' means, default returned count, or how to interpret results, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 26% schema description coverage, the description fails to compensate for the many undocumented parameters. It provides no parameter-level guidance, making it hard for the agent to use filters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds brands in a category with the biggest recent growth in seller count and observations, and provides example user queries. However, it does not explicitly differentiate from similar sibling tools like 'brands_gaining_sellers'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives example queries and specifies 'any category-scoped growth question', indicating when to use it. However, it lacks guidance on when not to use it or alternatives, leaving boundaries unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only. The description adds that results are ordered by retreat magnitude, but does not disclose output format, pagination, or limits. Some behavioral context is added, but not extensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 3 sentences, front-loads the main purpose, and avoids unnecessary detail. It is well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters, no output schema, and many sibling tools, the description is too brief. It lacks information on output format, filtering options, and how to interpret results, making it incomplete for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 27% of parameters have schema descriptions, and the tool description does not provide additional parameter documentation. It fails to compensate for the low schema coverage, leaving many parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds categories with net Amazon brand exits over 90 days and gives example user queries. However, it does not differentiate from similar sibling tools like category_new_entrants or category_undercompeted_brands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides example queries for when to use it but does not specify when not to use it or mention alternative tools, which are abundant among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds that results are ranked by brand count and buybox days, which is helpful. No additional behavioral traits (e.g., rate limits, data freshness) are disclosed. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus query examples. It front-loads the core purpose. However, it could be slightly more structured (e.g., bullet points for parameters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, but the description explains the return structure (categories ranked by metrics). With 11 parameters, low schema coverage, and no output schema, the description is moderately complete but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 27%. The description mentions key metrics but does not explain the meaning of many parameters (e.g., limit, category_name_contains, min/max fields). It adds minimal value beyond the parameter names and brief schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows categories dominated by an operator, ranked by brand count and buybox days. Example queries are provided. However, it does not explicitly differentiate from similar sibling tools like 'operator_top_brands' or 'operator_brands_by_competition'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage examples and query patterns, but lacks guidance on when not to use this tool or mentions of alternative tools for related questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no safety concerns. Description adds context on the metric computation and purpose but does not disclose return format, pagination, or any behavioral quirks beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, efficiently front-loading purpose, then usage, then sort. No fluff, though slightly more structure (e.g., listing all parameters) could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 18 parameters, no output schema, and many sibling tools, the description lacks details on return values (fields returned) and does not cover the extensive filtering options. It leaves the agent guessing about output structure and full capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, but description explains only a few key parameters (fba_share_op, fba_share_value, sort_by, marketplace) with examples. Many filtering parameters (min_sourcing_score, limit, brand_contains, etc.) are left unexplained, failing to compensate for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns brands based on FBA buybox share threshold, including the formula and examples. It implicitly distinguishes from sibling 'filter_operators_by_fba_share' by focusing on brands, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete usage examples: 'use fba_share < 40 to find FBM-heavy brands' and 'fba_share > 80 for FBA-dominated brands'. Also mentions sort options. Lacks explicit alternatives or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description correctly implies a read-only operation. However, the description does not add further behavioral context such as what 'active' means, data freshness, pagination, or limits. With annotations covering safety, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loading the core action and following with usage cues. It avoids fluff, though a more structured breakdown (e.g., separating purpose from examples) could improve clarity for agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 18 parameters, no output schema, and no description of return format or behavior, the description is insufficient. It does not explain what 'active' means, whether results are aggregated or per-product, or how violations are calculated. The tool is complex, but the description offers minimal completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 18 parameters with only 39% description coverage, yet the tool description adds zero information about any parameter. This is a critical gap; the description must compensate for low schema coverage but fails entirely, leaving agents blind to parameter meaning beyond schema labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows 'active MAP violations' with a specific verb ('Show') and resource. It also provides example user queries, making purpose unmistakable and distinct from the long list of sibling tools, none of which focus on MAP violations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists example queries that trigger this tool ('MAP violations', 'who is selling below MAP', etc.), offering clear context for when to use it. However, it does not mention when not to use it or suggest alternative tools, which would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds context about the filtering logic (delta vs category, default threshold) which is helpful but not extensive. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Core purpose and metric are clear, but the tool has 13 parameters and no output schema. The description does not explain the shape of the results or how the multiple optional filters interact, leaving some ambiguity for complete usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 62%, between the 50-80% range. The description only explains two parameters (min_delta_pp and category) implicitly, leaving many others (e.g., scope, marketplace, brand filters) unexplained. It does not adequately compensate for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool finds brands with high seller churn relative to category, specifying the metric and threshold. It uses a specific verb ('find') and resource ('brands'), but does not explicitly distinguish from siblings like 'brands_gaining_sellers'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides explicit usage hints ('Use when the user asks about...') that guide typical queries. However, it does not mention when not to use the tool or suggest alternatives from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds useful output context (fields returned) but does not clarify how 'last check' is determined or any pagination/rate limits. The behavioral traits beyond read-only are minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with purpose, followed by output summary and usage triggers. Highly efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 21 parameters and no output schema, the description lacks details about delta definition, 'last check' semantics, and comprehensive return structure. While it covers core purpose and usage, it is not fully complete for complex filtering scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 29%, and the description does not explain the many undocumented parameters. It focuses on output rather than input semantics, leaving agents with little guidance on how to filter or set parameters beyond the few with schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows changes on the user's sourcing watchlist since last check, with specific output fields (score delta, product identity, fulfillment). It is distinct from sibling watchlist tools like watchlist_list or watchlist_stats, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit query triggers ('what changed on my watchlist', 'watchlist updates', 'any changes this week'), giving clear context for when to use. However, it does not mention when not to use or suggest alternatives like watchlist_diff.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true. The description adds that it returns weekly data for a trailing window, but does not disclose limits (e.g., max 52 weeks from schema), behavior for insufficient data, or how filtering parameters affect results. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with key purpose and output, followed by example queries. Every sentence adds value, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good annotations, the tool has 16 parameters and no output schema. The description provides minimal behavioral context (trailing window, weekly seller counts) but omits explanation of filtering parameters (e.g., trend_in, min_seller_count_change_pct) and the structure of the return data. This leaves agents underinformed for correctly invoking the tool or interpreting results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 38% (most parameters lack descriptions). The description adds no parameter-specific information beyond what the schema provides, failing to compensate for the low coverage. Only 'brand', 'since_weeks', and 'marketplace_id' are somewhat explained in the schema; the many filter parameters are opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows buybox concentration change over time, specifies the output (weekly seller counts and observed buybox days), and provides example queries that distinguish it from siblings like brand_under_attack or find_deconcentrating_brands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases and example queries ('is this brand getting more competitive', 'concentration trend for Nike'), guiding when to invoke. It does not explicitly state when not to use or offer alternatives, but the context is clear enough for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true. Description adds critical context about it being an observation signal, not confirmed market entry, and warns about sparse re-sampling. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loads action and nuance. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core purpose and key nuance, but with 17 parameters and no output schema, the description does not explain filtering options or return format, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 35% schema description coverage, the description adds minimal parameter context beyond mentioning an optional category filter. Does not compensate for the many undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds brands that recently gained newly-observed sellers, using specific verb 'Find' and resource. It distinguishes from siblings by focusing on brands gaining sellers, but does not explicitly differentiate from similar tools like 'find_new_operators'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit example queries and usage contexts (e.g., 'brands gaining sellers in [category]', 'brands under hijacker pressure'). However, no alternatives or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the readOnlyHint annotation, indicating a read operation, but adds no additional behavioral context such as rate limits or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a usage clause, very concise and front-loaded with key purpose and examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 14 parameters, no output schema, and minimal parameter explanations, the description lacks completeness for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, and the description does not explain the majority of parameters. It only mentions category, price tier, and competition level, which are not explicit parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find brands similar to a given brand by category, price tier, and competition level' and provides explicit example queries, making purpose unambiguous. It distinguishes from sibling tools by focusing on brand lookalikes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use it via example queries like 'brands like Nike', but does not mention when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint true, and the description details the output (control posture, HHI, etc.) beyond annotations. Doesn't mention error handling or rate limits, but sufficient for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and uses three sentences to cover key points. It could be slightly more structured (e.g., separating output list from usage), but is efficient and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description explains the return structure (brand-level metrics and top 10 ASINs with details) comprehensively. For a tool with 27 params, it covers the essentials, though parameter explanations are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22%, yet the description does not elaborate on parameter meanings beyond the schema. Most parameters (e.g., min_composite_score, max_velocity) are left unexplained, failing to compensate for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Evaluate a brand for portfolio inclusion' and lists specific metrics returned, making the purpose distinct. However, it does not explicitly differentiate from sibling tools like 'brand_similar' or 'brand_buybox_trajectory', so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete examples of user queries ('is this worth carrying?', 'how does this brand look?') that trigger this tool. Missing explicit exclusion guidance or alternatives, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by explaining methodology (coverage-robust, not inflated), limitations (not provably first-to-market), return fields, and the role of since_days. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loading the main purpose and methodology. Each sentence adds value, and the length is appropriate for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return fields (first_observed, n_asins_on_brand, still_active). It covers methodology, limitations, use cases, and filters, providing sufficient context for a complex tool with 15 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, so the description must compensate. It lists filter parameters and adds context like operator exact case-insensitivity and the bounding role of since_days. However, it does not provide detailed semantics for all 15 parameters, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: identifying operators newly observed on a brand in a recent window. It uses specific verbs and defines the resource (operators on a brand). While it doesn't explicitly differentiate from siblings like find_new_operators, the brand-level focus is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases ('who's new on <brand>', 'who's newly showing up on my brand', 'recent sellers on <brand>'), but does not mention when not to use the tool or suggest alternatives. Lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a read-only operation. The description adds no further behavioral details like rate limits, authorization, or output behavior, which is adequate but not excellent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus usage examples. Every sentence serves a purpose, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (19), no output schema, and low schema coverage, the description is too brief. It does not explain output order, pagination, or filter interactions, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 21% schema coverage, many parameters lack descriptions. The tool description does not elaborate on any parameter, relying solely on the sparse schema. This fails to add meaning beyond the schema for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds sellers expanding into new brands, with specific verb and resource. It provides example queries distinguishing it from sibling tools like operator_new_brands and brands_gaining_sellers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when the user asks...' with multiple examples and clarifies it's for cross-cutting queries without a specific seller. Lacks explicit when-not-to-use but provides strong usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, which is consistent with the description describing a search operation. The description does not provide additional behavioral details beyond what annotations already convey, such as rate limits or data freshness, so it does not add significant transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (3 sentences) and front-loaded with purpose, followed by use-case examples and expected output format. Every sentence adds value, no redundancy, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a good high-level overview and mentions output fields, but with 30 parameters and no output schema, it lacks details on many parameters and does not explicitly exclude alternative tools. For its complexity, it is adequate but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for several key parameters (e.g., max/min retail price, category, brand, exclude filters) beyond the schema, but 30 parameters exist with only 23% schema coverage. Many parameters (like min_velocity_score, scope, product_title_contains) are not explained in the description, so it only partially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds top sourcing-pick ASINs across the entire catalog with optional filters, and provides example user queries. It distinguishes from siblings by specifying it is for cross-cutting questions without a named entity, but could more explicitly differentiate from similar tools like find_sourcing_opportunities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context for when to use the tool ('when user asks top sourcing picks...') and implies not for named entities. However, it does not explicitly list when not to use or provide direct comparisons to alternatives, limiting its guidance among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true. The description adds context about the operator graph and ranking, but does not disclose additional behavioral traits like pagination or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) and front-loaded with purpose and usage examples. Every sentence adds value without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters and no output schema, the description lacks details on return format, pagination, or how results are ranked. It covers the core idea but is incomplete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema description coverage, the description does not explain most parameters beyond the target brand. It fails to compensate for the lack of schema descriptions for 12 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds brands sharing operators with a target brand and ranks them, with specific example queries like 'what brands are in X's network?' This distinguishes it from siblings like brand_similar or operator_brands_by_competition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit example queries for when to use the tool (e.g., 'who else do Ninja's sellers carry?'). However, it does not explicitly state when not to use it or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description only needs to add context. It adds that the tool 'Returns the top matching products ranked by relevance' with specific fields. This is helpful but does not go beyond what annotations already imply for safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of about four sentences, with the main action front-loaded. It is efficient, though could be slightly more structured (e.g., bullet points for filters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 19 parameters and no output schema, the description provides a basic understanding of what the tool returns and which filters are available. However, it lacks details on default behavior, edge cases, and does not list all possible filter fields. It is adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (21%), so the description must compensate. It lists many optional filters (product_brand, min/max_price, etc.) but not all 19 parameters. It adds meaning to the required 'keywords' parameter and some others, but the coverage is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Free-text keyword search over Amazon product titles + descriptions.' It specifies the resource (Amazon products), the action (search), and scope (titles + descriptions). It also distinguishes from searching by brand, category, or ASIN, which sets it apart from siblings like shopping_search or asin_buybox_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when the user names a PRODUCT TYPE or keywords... rather than a specific brand, category, or ASIN.' It provides clear context for when to use this tool, though it could improve by naming specific alternative tools for other cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, consistent with the tool's read-only nature. The description adds behavioral details: it returns matching ASINs with scores, product identity, and fulfillment info. No mention of limitations or side effects, but annotations cover safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences and front-loads the primary purpose. However, it could be more structured to list behavior and output clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 19 parameters, no output schema, and only 26% parameter description coverage, the description is insufficient. It does not explain how natural-language resolution works, how filtering applies, or the full return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 26%. The description does not explain the numerous filter parameters (limit, min_composite_score, etc.) beyond mentioning brand and asin. Users lack guidance on how to use many parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: resolving natural-language watchlist requests into concrete ASINs. It provides specific examples ('watch this brand', 'alert me when X loses a seller') and distinguishes it from sibling watchlist tools that handle direct addition or removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool ('Use when the user says... any watchlist-creation intent'). It offers clear context for usage but does not mention when not to use it or suggest alternatives like watchlist_add for direct ASIN additions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds that the tool shows changes and that it requires a baseline (set by watchlist_add), enhancing transparency. However, it does not disclose behaviors like pagination, data volume limits, or authentication requirements, which would be useful for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three sentences and a usage tip, all front-loaded with the core purpose. Every sentence adds value: purpose, output details, example queries, and a note about the baseline. There is no redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (24 parameters, no output schema, many siblings), the description covers the core purpose and output fields but lacks details on the return format, pagination, and how the numerous filter parameters interact. The baseline concept is mentioned but not fully explained. It is adequate for basic use but could be more complete to handle complex filtering scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at only 25%, the description should compensate by explaining the numerous filter parameters. While the description mentions the output fields (new sellers, score moves, product identity, fulfillment), it does not elaborate on how the input parameters (e.g., min_new_sellers, product_brand_contains) affect the results. The overall context helps but does not provide sufficient parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Show what changed on a saved tracking list versus its captured baseline', specifying the verb 'show', the resource 'tracking list', and the action 'diff against baseline'. It also details the output (new sellers, score moves, product identity, fulfillment) and provides example user queries, distinguishing it from related tools like watchlist_add.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context with example queries ('what changed on <list>', 'any updates on my watchlist') and directs the user to an alternative tool ('Re-run watchlist_add to reset the baseline'). It does not explicitly state when not to use this tool, but the examples adequately guide the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=false in annotations, the agent already knows the tool is not read-only. The description adds the 'LIVE' and 'on-demand' qualifiers, implying a real-time API call with potential cost or rate limits. It does not explicitly disclose side effects like query limits or costs, but the annotations already carry the primary behavioral signal, so a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and efficiently front-loads the purpose, data returned, and usage context. The first sentence is somewhat long (49 words) but no unnecessary repetition. It is structured logically: what it does, when to use, constraints. Slight verbosity prevents a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description details the return data comprehensively (title, price, offers, sellers, historical intelligence, fulfillment). It also states constraints (US only, single ASIN). Missing operational details like error handling or rate limits, but the context provided is sufficient for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters (asin and marketplace_id). The description reinforces these by stating 'one ASIN per call' and 'Amazon US only,' but does not add new meaning beyond the schema. Baseline score of 3 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'pull' and clearly defines the resource as a single Amazon ASIN with live data. It explicitly lists the included data (title, price, offers, sellers, historical intelligence) and distinguishes itself from pre-collected datasets, making it distinct from sibling tools like asin_buybox_history or asin_profit_calc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use when the user gives a specific ASIN and wants its CURRENT/today's data rather than the pre-collected dataset.' It gives example queries and constraints (Amazon US only, one ASIN per call). However, it does not mention alternative sibling tools by name, so guidance on when not to use 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds value by specifying that it returns week-over-week deltas, which is behavioral context beyond the annotation. It does not mention any destructive actions, confirming the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states purpose and outputs, second gives usage context. No fluff, front-loaded with essential information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 30 parameters and no output schema, the description only outlines three output fields (top sellers, top brands, deltas) and does not explain the filtering parameters or which inputs are required (e.g., category_root_id or brand is implied but not explicit). For a complex tool with many options, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 10% (3 of 30 parameters have descriptions). The description does not explain the meaning or usage of most parameters, including required context like brand or category_root_id. It only hints at needing a brand or category root but doesn't specify which parameters to use. With such low schema coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool maps competitive landscape for a brand or category root, specifying exact outputs: top 10 sellers by buybox days, top 10 brands by HHI, and week-over-week deltas. It also provides example queries ('who's winning this category?'), making the purpose distinct from siblings like brand_buybox_trajectory or operator_concentration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool with example questions ('who's winning this category?', 'who controls the buybox here?'), which is strong usage guidance. It does not mention when not to use it or alternatives, but the clear context suffices for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, consistent with description. Description adds interpretation of FBA share (0-100 percentage) and threshold meaning. Missing details like default sort order, limit, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff. Purpose is front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 20 parameters and no output schema, the description covers the essential filtering logic but omits sorting, limit, and other filter fields. Adequate for core use but not fully complete for power users.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 30% schema coverage, description adds value for core parameters (fba_share_op, fba_share_value, brand) by providing examples and context. However, many optional parameters remain unexplained, which is a gap given low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns operators filtered by FBA buybox share threshold. It provides specific use cases (FBM-leaning vs FBA-heavy flippers), distinguishing it from sibling tools like operator_brands_by_competition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage scenarios given: 'Use fba_share < 50 ... or fba_share > 80 ...' and optional brand filter. Does not explicitly exclude alternatives, but context is sufficient for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds context that results are either gated/exclusive or operator-acquired brands, which provides insight into the nature of the output beyond the read-only flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines the core function, second gives usage examples. Every sentence is essential and no waste. Front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should hint at return format. It does not. With 13 parameters and complex filtering, the description is minimal but adequate given schema and annotations. Lacks clarity on output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 62%, so baseline is 3. The description does not add any parameter-level information beyond the schema. It does not compensate for the undocumented parameters like limit, brand_contains, or min_control_score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds brands with a single operator controlling 100% buybox days, and gives example user queries. However, it does not explicitly differentiate from sibling tools like brand_buybox_trajectory or brand_under_attack.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific example user queries ('brands with one seller', 'exclusive brands', etc.) and states when to use it. It lacks explicit exclusions or alternative tool suggestions, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, which is consistent with the description. The description adds behavioral detail about the output (viability qualifier, risks, validation steps) and states it provides 'honest' sourcing advice, not get-rich-quick promises. This goes beyond the annotation by describing the nature and tone of the results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the core purpose and then details the output. It is reasonably concise for the amount of information conveyed, though it could be slightly tighter. Every sentence adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (diagnosing business model, returning a detailed assessment) and no output schema, the description covers the key aspects: input, process, and output format (viability qualifier, risks, etc.). It lacks specifics on data freshness or exact JSON structure but is sufficient for an agent to understand what the tool does and what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters (asin and marketplace_id). The description mentions 'Given an Amazon ASIN' but does not add significant new meaning beyond what the schema provides. Baseline of 3 is appropriate as the description does not compensate for missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: given an ASIN, diagnose business model, find supplier matches, and return a sourcing read with viability qualifier, differentiation, economics, risks, and validation steps. It distinguishes itself from siblings like 'evaluate_asin_sourcing' or 'alibaba_supplier_search' by emphasizing an honest, comprehensive lead generation output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an ASIN is available and a detailed sourcing analysis is needed, but it does not explicitly state when to use this tool versus alternatives (e.g., 'evaluate_asin_sourcing' or 'search_products'). No guidance on when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, so no destructive behavior is expected. The description does not contradict and adds context on output (product details and metrics). It does not elaborate on other behavioral aspects like rate limits or data freshness, but with annotations covering safety, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and packs all essential information: output type, metrics, product details, and use cases. No redundant words; each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description adequately explains return fields (metrics, product brand/title/price/fulfillment). It lacks details on error handling or behavior when marketplace_id is omitted, but the default and description cover the common case. Overall sufficient for a recommendation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; only marketplace_id has a description in the schema. The tool description does not add any detail for the asin parameter, nor does it expand on marketplace_id beyond what the schema provides. It misses an opportunity to clarify parameter usage, especially for asin.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool recommends ungate/arbitrage/avoid for an ASIN, with a 3-bullet rationale citing specific metrics. It differentiates from siblings like evaluate_asin_sourcing by focusing on gating and pricing advice, and includes explicit use cases ('should I try to ungate this?' / 'how should I price this?').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases for the tool, indicating when to use it. However, it does not mention alternatives or when not to use it, nor does it compare to sibling tools. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating safe read-only operation. The description adds context that the tool returns brands ranked by competition level. It does not disclose potential rate limits, error handling, or authentication needs, but given the annotation, the description adds sufficient behavioral clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence followed by example queries. It is front-loaded with the core purpose and avoids unnecessary words, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 14 parameters and no output schema, the description lacks important details: no explanation of the return format (e.g., fields in results), no error handling or edge case guidance, and insufficient differentiation from sibling tools like 'brands_gaining_sellers' or 'find_undercompeted_brands'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, meaning many parameters lack descriptions. The tool description does not explain individual parameters beyond the general purpose. It does not compensate for the low coverage, leaving many filter parameters (e.g., brand_contains, min_competitor_count) unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: given operator names, return brands ranked by competition. It includes specific example queries, which cover the tool's scope and distinguish it from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use examples (e.g., 'which brands sold by these operators have the least competition'). It does not explicitly state when not to use or suggest alternatives, but the examples offer strong guidance for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is clear. The description adds the velocity metric definition (brand_velocity_90d_units_day) but does not describe output ordering, pagination, or whether results are sorted descending. This leaves some behavioral ambiguity given the 'top' semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly written: two sentences plus a usage clause. It front-loads the primary purpose, then lists key filters, and ends with concrete use cue. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 22 parameters and many sibling tools, the description omits the output format (e.g., sorted by velocity descending) and lacks clarification on how 'top' is determined. It also does not mention result limits beyond the schema default. Given the tool's complexity, this leaves the agent with missing context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 41%, so the description bears extra responsibility. It explains the meaning of core parameters (scope, category, min_velocity, exclude flags) and clarifies scope values, but does not describe many optional filters like brand_contains, revenue ranges, or churn metrics. The description adds value but doesn't fully compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds top brands by 90-day unit velocity and provides concrete example user queries. It distinguishes from sibling tools by focusing on velocity-based ranking, which is not implied by sibling names like 'finder_undercompeted_brands' or 'brands_gaining_sellers'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists trigger phrases and specific guidance for setting scope='tracked' when the user says 'my brands'. While it doesn't mention when not to use this tool, the clear user intent mapping provides strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description adds detail about what each comparable includes: 'product brand, title, price (or price range) and fulfillment (FBA/FBM/AMZ + amz/fba pct).' This gives valuable output context beyond the readonly fact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—two sentences—with the first sentence stating the purpose and criteria, and the second listing output fields. It is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 19 parameters and no output schema, the description gives a basic overview of the tool's functionality and output, but does not explain how parameters interact (e.g., whether filters are combined, how limit works, or how marketplace_id affects results). It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 32%, meaning most parameters lack descriptions. The description mentions filtering by 'brand, price band, and seller count' which maps to a few parameters, but does not explain the many other optional filters like limit, min_days_observed, or buybox_seller_contains. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find ASINs similar to a given ASIN by brand, price band, and seller count.' It lists specific user queries that trigger its use, distinguishing it from sibling tools like asin_buybox_history or asin_profit_calc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: 'Use when the user asks ASINs like this one, similar products, comparable ASINs, what else is like B08N5WRWNW, or any ASIN-level lookalike question.' It provides clear context, though it doesn't discuss alternatives or 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds context about return fields (brand, title, price, fulfillment) but does not disclose additional behavioral traits like API calls or estimation methodology. With annotations present, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no wasted words. The first sentence states the primary purpose, and the second adds use case examples and return information. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no output schema, the description provides sufficient context by listing return fields (brand, title, price, fulfillment). It does not explain the profit calculation formula, but for an agent, the description is complete enough to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add extra meaning beyond what the schema already provides for parameters (asin, target_margin_pct, cogs, marketplace_id). The description focuses on output rather than parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates profit margin for an ASIN, with specific verb 'estimate' and resource 'ASIN'. It provides example queries like 'can I make money on this ASIN' and differentiates from siblings like asin_buybox_history or asin_comparables by focusing on profitability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases ('can I make money on this ASIN', 'profit calculator', etc.) and mentions when to use it. It does not exclude alternatives, but with many sibling tools, the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that the tool lists 'saved' authorized sellers, indicating it returns existing data. The annotation readOnlyHint=true already signals a safe read operation. No further behavioral details (e.g., pagination, authorization) are provided, but this is adequate for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the action, the second gives usage examples. No extraneous information; front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple 3-parameter tool with readOnlyHint and no output schema, the description covers the purpose and typical usage scenarios. It could optionally mention that it returns a list of seller names, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema alone documents all parameters' meanings. The description does not add any parameter-level details beyond what is in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'List' and the resource 'saved authorized sellers for a brand'. It provides concrete user query examples ('who are my authorized sellers for X'), clearly distinguishing it from sibling tools like authorized_seller_set (write) and unauthorized_sellers (different set).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit usage cues: 'Use when the user asks...' with three example queries. While it does not state when not to use, the examples clearly delineate the tool's purpose, making it easy for an agent to match.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, consistent with write operation described. Description doesn't add behavioral details beyond basic mutation, such as overwrite behavior or side effects. Adequate but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no wasted words. Every sentence adds value: what it does, prerequisite, and example usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with no output schema, description covers purpose, prerequisite, and parameter tips. Missing response info, but with 100% schema coverage, it's nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 3 params. Description adds minimal extra meaning: only 'exactly as they appear on Amazon' for sellers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Save' and the resource 'authorized sellers for a brand', with context of making unauthorized seller detection possible. This differentiates from sibling 'authorized_seller_list' which lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: 'these are my authorized sellers for X', 'add Y', 'set my brand's approved resellers'. Mentions prerequisite that brand must be tracked. Lacks explicit when-not but covers key scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and description adds behavioral details: output includes brand, title, price/price range, and fulfillment info (FBA/FBM/AMZ + percentages). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with clear, front-loaded purpose and usage examples. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 26 parameters and no output schema, the description explains output fields but omits pagination, ordering, or default behavior. Adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 31%. The description mentions key output fields but does not explain many filtering parameters (e.g., first_seen_from, last_seen_to, fulfillment percentages). Insufficient compensation for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool shows new ASINs for a brand, with specific user query examples like 'new products for Nike' and 'recently added ASINs'. It differentiates from sibling tools that focus on other brand metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use the tool with example queries. Does not provide exclusions or alternatives, but context is clear for common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds value by specifying return fields (seller count, ASIN count, buybox days, control score) and per-marketplace behavior, confirming it is a safe query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and returns, followed by usage examples. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core purpose and return fields, but lacks details on threshold parameters (min/max) and explanation of control score. No output schema, so description could provide more completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'brand' described). The description does not explain the other 9 parameters (marketplace_id_in, min/max counts, etc.), leaving the agent without guidance on filtering options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks brand presence on Amazon US, UK, and Walmart, and lists specific return metrics. It distinguishes from siblings by focusing on multi-marketplace brand presence, with explicit user query examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit example user queries ('does this brand sell on Walmart', 'cross-marketplace presence for Nike'), making it clear when to use. No when-not-to-use guidance, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and description adds that results are ranked by revenue, includes product brand/title/price/fulfillment. Describes fallback behavior when no authorized list set. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose, then output details, then prerequisite and examples. Slightly verbose but well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 26 parameters and no output schema, the description adequately covers the core function, output fields, and prerequisite. Does not explain all filter combinations but sufficient for an alert tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 27%, but description does not explain any parameters beyond what is already in the schema. It mentions the 'brand' parameter implicitly but does not add detail for the many filter parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Find') and clearly states the resource (ASINs where brand lost buy box), ranking by revenue at stake. It differentiates from siblings like authorized_seller_set and operator_buybox_losses by focusing on brand-owned ASINs and requiring authorized list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit example queries ('where am I losing the buy box') and mentions prerequisite (save authorized list). Lacks explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description mainly adds content details (list of metric groups) rather than behavioral traits. It does not disclose pagination, performance, or rate limits, which is acceptable given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two front-loaded sentences cover purpose and supported queries, followed by a bullet list of metric groups. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates well by enumerating the metric groups (demand, competition, Amazon presence, etc.) and providing example use cases. It covers what the tool returns but could be slightly more precise about the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional semantics beyond the schema; it lists the returned metrics but not parameter-specific details like mutual exclusivity of category_id and category_name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'full metric set for ONE category', differentiating from sibling tools by specifying single-category scope and any depth, including a concrete example like 'Terrariums'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases ('show me the metrics/stats for category X', 'how big is the X category') that guide the agent on when to invoke this tool, but does not mention when not to use it or directly compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds valuable behavioral context: it's an observation signal, not a confirmed first-ever entry, due to sparse re-sampling. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences cover purpose, clarification, and usage examples. Front-loaded with the key action and limitation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 17 parameters but no output schema. The description explains the core concept and limitation, but does not describe the return format or how to interpret results. Given the complexity, more guidance on output would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 35% (6 of 17 parameters have descriptions). The description does not provide additional meaning for the undocumented parameters (e.g., brand_contains, min_seller_count). It hints at date-related parameters but does not compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds brands newly observed in a category within a date window, with specific verb and resource. It distinguishes from siblings by explaining it's an observation signal and provides example user queries that clarify usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit example queries (e.g., 'new brands in Electronics') and a warning about the limitation of sparse sampling. It does not explicitly list when not to use or name alternatives, but the examples sufficiently guide typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool compares first and second halves of a window (via 'since_weeks'), indicating temporal analysis. The readOnlyHint annotation is already present, and the description adds context about the business implication (opportunity for new entrants). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences cover purpose and usage triggers. No redundant words. Each part is essential: first defines the action, second provides invocation cues.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers overall purpose and when to use, but given 16 parameters and no output schema, more detail on default behavior, parameter interactions, and expected output would improve invocation accuracy. Adequate for a read tool but could be richer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 4 of 16 parameters are described in the schema (25% coverage). The tool description does not add any parameter explanations beyond what's in the schema. Key parameters like min_old_seller_count, min_control_score, etc., lack documentation, making it hard for agents to set them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific verb 'find' and clear resource 'brands where buybox concentration dropped'. Includes concrete example queries covering synonyms like 'brands losing control', making purpose unmistakable. Differentiates from siblings by focusing on concentration drop rather than seller count growth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists user query patterns that should trigger this tool ('brands losing control', 'deconcentrating brands', etc.). No explicit exclusions or alternatives, but the examples effectively guide when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. Description adds 'churn signal' context implying comparison over time. No contradictions; additional behavioral context is minimal but sufficient given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and usage hints. No wasteful text; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and usage but omits output format, pagination, and filter behavior. With 10 parameters and no output schema, more detail on limit and filtering semantics would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, but tool description does not add any parameter-level details. Undocumented params like limit, brand_contains, last_seen_week_to, first_seen_from/to are left unexplained, forcing reliance on schema which is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Show brands an operator recently stopped selling' with specific verb and resource. Distinguishes from sibling tools like operator_new_brands by focusing on lost brands. Includes example queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use with example queries ('what brands did this seller drop', 'operator churn'). Lacks guidance on when not to use or alternatives, but positive guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false (write), and the description confirms it sets a schedule. It does not mention potential effects like overwriting an existing schedule, whether the playbook must already exist, or any permissions needed. Adequate but lacks detail on side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second provides usage examples. No wasted words. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with two parameters and no output schema, the description is largely complete. It covers purpose, schedule options, and usage scenarios. Minor gaps: no mention of required playbook existence or behavior when switching to manual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains the 'schedule' parameter's enum values via user intent examples, but does not describe the 'name' parameter at all, leaving it to inference from sibling tools. Partial coverage; could be improved by naming the playbook as identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb ('Set') and resource ('how often a saved playbook runs automatically'), listing the three schedule options (manual, daily, weekly). Distinguishes from sibling tools like 'playbook_run_now' (one-time run) and 'playbook_create' (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete user phrases ('run this weekly', 'schedule my playbook daily', 'stop the automatic runs') that map to the schedule values, giving clear usage context. Could be improved by explicitly contrasting with sibling tools like 'playbook_run_now' for one-time execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and description confirms no side effects. Adds useful behavioral detail about returned fields (name, type, item count, baseline). Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no extraneous content. First sentence describes output; second provides usage examples. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Good for a read-only list tool with optional filters. Covers purpose and usage well. No output schema, so description could mention the exact fields returned, but it names the key fields. Acceptable completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60% (2 of 5 parameters lack descriptions). The tool description does not add any parameter information. Schema does most of the work, so baseline 3 is appropriate; description could have clarified filter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: lists saved tracking lists with specific attributes (name, type, item count, baseline). Example user queries like 'what am I tracking' make purpose obvious. Does not explicitly differentiate from sibling watchlist tools, but context is sufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use with example queries: 'Use when the user asks...'. Provides clear context for invocation. No mention of when not to use or alternatives, but guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so no contradiction. The description adds that it returns a snapshot when ready, implying polling behavior. However, it does not detail error handling or edge cases like invalid job_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with purpose. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has few parameters, no output schema, and read-only annotations. The description explains purpose, when to use, and what the response contains. A minor gap is the lack of return format details, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds little beyond restating that job_id is the ASIN. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'check', resource 'status of a live Amazon refresh for an ASIN', and output 'current snapshot'. It distinguishes from sibling tools by specifying the context of a live refresh kicked off for an ASIN.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: 'Use after a tool says a live refresh is collecting.' It does not mention when not to use or alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The disclosure of return values (per-week breakdown, monthly seller count series, seller_trend label, product details) adds useful context beyond the readOnlyHint annotation. It does not mention rate limits or data freshness, but the behavioral description is consistent with a read-only tool and provides meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense but somewhat lengthy. It front-loads the core purpose and then details return values and use cases. Every sentence adds value, though slight tightening could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 27 parameters and no output schema, the description provides a strong overview of the main outputs and usage context. It covers the essential return structure and common query intents, but could be more complete by addressing more filter parameters or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 30%, so the description must compensate. It explains the key parameters (asin, since_weeks, marketplace_id) and describes derived output fields not in the schema (e.g., seller_count_monthly, seller_trend). However, many filter parameters remain undocumented in both schema and description, limiting the value added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows which sellers have been winning the buybox for an ASIN over time and how the competing-seller pool changes month over month. It uses specific verbs and resources, and the detailed example queries effectively distinguish it from sibling tools like brand_buybox_trajectory or buybox_loss_alert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases with example user queries, such as 'who has been winning buybox on this ASIN' or 'is the seller pool stable or volatile'. It does not mention when not to use the tool or explicitly name alternatives, but the context is sufficiently clear for an agent to understand applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool's read-only nature is known. The description adds behavioral context: returns categories/subcategories only, never brands, ranked by private-label winnability using 2-year marketplace data. It does not contradict annotations. However, it lacks details on rate limits, pagination, or data freshness beyond what is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: starts with a bold key phrase, then explains purpose, followed by usage guidance and sibling exclusion. It is not excessively long and each sentence adds value. Minor improvement could be more brevity in listing example queries.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 21 parameters, no output schema, and minimal annotations, the description covers purpose and usage well but does not describe the output format or how to interpret results (e.g., ranking criteria, data fields returned). For a tool of this complexity, more detail on return values would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 43%, meaning many parameters lack descriptions in the schema. The description adds context for a few parameters (e.g., default price range 20-70, unhappy_shoppers bias) but does not elaborate on the majority of the 21 parameters. For a tool with low schema coverage, the description should compensate more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds underserved niches (real subcategories) with genuine demand and room to compete, ranked by private-label winnability from 2-year marketplace data. It distinguishes from sibling tools that return brands, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'This is the RIGHT tool for ANY niche-discovery question' and lists example queries. It also provides clear when-not-to-use guidance by naming sibling tools category_undercompeted_brands and find_undercompeted_brands that return brands instead. Additionally, it explains how to handle user-provided department names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds that the label is heuristic, not legal, and explains input signals (cross-brand data). This provides useful behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) with a clear front-loaded purpose, usage examples, and a caveat. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema, and the description does not specify the return format or structure. While it describes the logic and categories, an agent might benefit from knowing what fields are returned (e.g., operator name, label, confidence?).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no further parameter details. A score of 3 is appropriate as the schema already documents both parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool labels operators into specific categories (amazon, brand-direct, etc.) and provides example user queries. It distinguishes this classifier from sibling tools like operator_brands_by_competition or operator_buybox_losses by focusing on classification rather than other metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool with example queries. It does not list alternative tools or when not to use it, but the context is clear enough for selection among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds marketplace scope (Amazon US/UK), return format, and filter behavior. No contradictions; useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently conveys purpose, usage, and parameters. It is front-loaded with the core function. Could benefit from bullet points for filters, but not excessively long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains the return values (HHI, label, top operators). It covers marketplaces and filter details. Leaves minor gaps (e.g., error handling, exact response structure) but is largely sufficient for a 12-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 42% (low). The description explains several filters (min/max HHI, operator, operator_contains, share_pct, listings_controlled) beyond the schema. However, it does not cover all 12 parameters (e.g., limit is omitted), so it provides partial but meaningful improvement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes HHI concentration across ASINs or a brand's catalog, revealing operator control of listings. It specifies the returned data (HHI, label, top operators) and differentiates from sibling tools like operator_category_dominance by focusing on concentration index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (private-label fragmentation checks) and mentions optional filters. It does not explicitly name alternatives or when-not-to-use, but the context is sufficiently clear for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, confirming no side effects. The description adds behavioral context by specifying 'recently started selling' and implying a time-bound query. It does not contradict annotations. For a read-only tool, this is sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence followed by example queries. Every piece of text is purposeful, with no redundancy. It front-loads the core action and then provides usage context, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters and no output schema. The description states 'Show brands' but does not explain the output structure (e.g., what fields are returned, pagination). For a tool of moderate complexity, additional context about the response format would improve completeness. The description is adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 63% description coverage, with some parameters like 'brand_contains' and 'first_seen_to' lacking descriptions. The tool description does not add parameter details beyond the schema, e.g., it doesn't clarify the meaning of 'brand_contains' or 'limit'. While the examples hint at usage, the description does not fully compensate for schema gaps. A score of 3 is appropriate given moderate coverage and no additional clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Show brands an operator recently started selling.' It provides specific example queries that differentiate it from sibling tools like 'operator_lost_brands' or 'brand_new_asins'. The verb 'show' and resource 'brands an operator recently started selling' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides multiple example user queries, effectively guiding the agent on when to invoke this tool (e.g., 'what new brands did this seller pick up'). However, it does not explicitly state when NOT to use it or mention alternative tools for similar tasks, such as 'operator_new_on_brand' or 'operator_lost_brands'. The context is clear but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the return values: composite risk score (0-100), recent MAP violation events (≤10 with details), unauthorized seller list (≤10), and recommended actions (1-3). It also notes the lookback window for MAP events defaults to 30 days. The annotation readOnlyHint: true confirms it is a safe read operation, and the description adds behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus a use-case snippet, efficiently conveying the tool's purpose and what it returns. It could be slightly more structured, but overall it is well-sized and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (24 parameters, no output schema), the description covers the core returns but does not explain how to use the many filter parameters. The use-case snippet helps but is insufficient for complete guidance. The agent may struggle with advanced filtering without more parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 24 parameters and only 33% schema description coverage, the description does not compensate. It mentions asin, brand, and days in context, but many filter parameters (e.g., min_count, buybox_seller, product_brand_contains) lack explanation. The description provides no additional semantics for the majority of parameters, relying on the schema which is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it assesses risk and protection for an ASIN or brand, returning a composite score, MAP violations, unauthorized sellers, and recommendations. It provides specific use-case prompts like 'flag risk events on my brand' or 'is this ASIN risky?', distinguishing it from sibling tools that focus on individual aspects (e.g., map_violations_today, unauthorized_sellers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives example prompts for when to use the tool, such as 'flag risk events on my brand' or 'is this ASIN risky?', which provides clear context. However, it does not explicitly mention when not to use it or contrast with sibling tools like map_violations_today or unauthorized_sellers that might be more specific for certain queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds behavioral context: sellers are classified, and if an authorized_seller_set is saved, unauthorized sellers are flagged. It does not contradict annotations, and provides useful conditional behavior that goes beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the main action and purpose. Every sentence adds value, though it is slightly lengthy. It could be slightly more concise, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 17 parameters and no output schema, the description is somewhat complete in explaining what it does and when to use it. However, it lacks details about return format, pagination, or how results are presented, which would be helpful for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 35% (most parameters lack descriptions). The tool description does not compensate by explaining parameters beyond brand and authorized_sellers. With 17 parameters and low coverage, the agent needs more parameter guidance in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists sellers winning a brand's buy box, classified by type, and flags unauthorized sellers if an authorized list is saved. The verb 'list' and resource 'brand buy box sellers' are specific, and it distinguishes from siblings like authorized_seller_list and authorized_seller_set by focusing on buy-box winners and classification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use when the user asks...' with example queries covering brand buy-box protection questions. It also explains conditional behavior when an authorized list is saved, helping the agent choose between this tool and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true. The description adds detail on return values (per-ASIN fields and top-level summary) and confirms no side effects. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the key purpose, then logically structured with return details and example uses. While verbose, every sentence adds value and it remains focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 20 parameters and no output schema, the description adequately explains the tool's output (per-ASIN fields and summary). It could specify the exact return structure, but the provided information is sufficient for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, so the schema partially documents parameters. The description does not add parameter-specific details beyond the schema. It provides overall context but doesn't compensate for the undocumented half.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: a bulk report of key Amazon stats for the user's entire watchlist in one call. It uses strong verbs like 'BULK report' and explicitly distinguishes from per-ASIN tools, preventing looping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance, explicitly advising against looping per-ASIN tools and listing example queries. It does not explicitly mention when not to use it, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating safe read operation. The description adds behavioral context: explains the use of brand-level first-seen, which is stable under scraper-coverage growth, and notes it is not inflated like per-ASIN counts. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose and methodology, technical nuance, and usage examples. No fluff, front-loaded with primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich schema descriptions and annotations, the description covers key aspects. It could optionally mention the output format (e.g., threat levels), but absence of output schema makes it acceptable. Provides sufficient context for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The tool description does not add further parameter-specific meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: detecting if a brand is under competitive attack using new-entrant rate and buy-box churn. It also provides example user queries, distinguishing it from sibling tools like brand_buybox_trajectory or brands_gaining_sellers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use the tool via example user queries ('use when the user asks...'). It explains the methodology (brand-level first-seen) implying why this tool is better than per-ASIN alternatives, but does not explicitly state when not to use it or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true. Description adds behavioral detail by specifying that the tool returns a per-signal pass/fail breakdown and a Strong/Moderate/Weak verdict. No contradiction between description and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single paragraph with purpose front-loaded. Sentences are functional and concise, though slightly verbose in listing example queries. No wasted words overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return structure (per-signal pass/fail and verdict) and the evaluation factors (Amazon footprint, seller fragmentation, demand, price band). Covers all needed context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. Description repeats the schema's parameter descriptions without adding new meaning. Per guidelines, baseline is 3 when coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'assess' and the resource 'category or niche' (any depth). Provides example queries that map to user intent, and distinguishes from siblings like evaluate_asin_sourcing and evaluate_brand.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description includes explicit use cases such as 'is X winnable for private label' and 'should I private-label X'. While it does not explicitly state when not to use or list alternatives, the examples provide clear context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the read-only nature is clear. The description adds value by explaining the return fields (est_units_30d, est_revenue_30d, asin count, buybox days) and the estimation methodology (weighted by buy-box share). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences that front-load the main purpose, provide concrete usage examples, and include an alternative tool reference. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the primary use case and return fields, it does not explain the many filter parameters (e.g., brand_contains, range filters). With no output schema, more detail on the response structure or pagination would help. Adequate for basic queries but incomplete for advanced filtering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (29%) with only 4 of 14 parameters described in the schema. The description does not elaborate on undocumented parameters like min_asin_count, brand_contains, or range filters. It only mentions the sort default (est_sales). This fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows brands an operator sells most by estimated sales, with explicit example queries like 'what brands does this seller sell the most of'. It distinguishes itself from sibling tool operator_brands_by_competition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use (brand-level drill-down by sales) and when not (brand competition, directing to operator_brands_by_competition). It also provides specific query examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so the tool is a write operation. The description adds context about what the playbook consists of (template, scope, steps) and how it is structured. It does not mention overwrite behavior or permissions, but overall adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and includes usage hints and examples. It is slightly dense but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers main usage, it omits constraints like mutual exclusivity of template_key and steps, and does not mention output (e.g., playbook ID). For a tool with nested objects and no output schema, more detail would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the relationship between template_key and steps, the role of scope, and providing an example. It goes beyond listing enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves a reusable research workflow (playbook) that can be re-run or scheduled. It distinguishes from sibling tools like playbook_list, playbook_run_now, and playbook_schedule by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool (when user says 'save this as a weekly check', etc.) and provides context for using templates vs custom steps. However, it does not explicitly exclude scenarios or compare to all siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds value by specifying return fields (name, schedule, last run, templates), which is beyond the annotation. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by usage examples. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately explains return content. Parameters are well-covered in schema. For a simple list tool, this provides sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (80%), so baseline is 3. Description does not restate or add meaning to parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists saved playbooks and built-in templates with specific fields (name, schedule, last run). It uses a specific verb 'list' and distinguishes from sibling tools like playbook_create and playbook_run_now.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states user intents that trigger this tool: 'what playbooks do I have', 'show my saved workflows', 'what automations are set up'. Does not mention when not to use, but the examples are clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: specifies the underlying API (Serper) and output fields (title, link, snippet). Annotations already indicate read-only. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no fluff. Front-loads the core purpose and then provides usage guidance. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description still clarifies return format (title+link+snippet). Use cases are specified. Sufficient for a simple search tool with well-documented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions. Description does not add extra meaning beyond what the schema provides. Baseline 3 due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool searches the web via Google/Serper, returns title+link+snippet, and provides specific use cases. Distinct from sibling tools focused on Amazon/operator data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use for supplier/wholesale/distributor research and review-gap articles. Does not explicitly state when not to use, but sibling list implies it's for non-Amazon web searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral traits beyond annotations: returns matched pairs with specific fields, includes a coarse profitability check, and notes data source (mv_product_identity). Consistent with readOnlyHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise (4 sentences), well-structured with front-loaded purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters and no output schema, the description adequately explains the output structure and data returned. Could elaborate on delta percentage calculation or profitability threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (27%), but the description adds context by explaining the tool's filtering logic and output fields. However, many filter parameters (e.g., min_amazon_price, product_title_contains) are not individually described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb ('pricing comparison'), resources ('Cross-marketplace Amazon vs Walmart'), and distinguishes from siblings by specifying matched pairs from mv_product_identity. Tailored for arbitrage/sourcing questions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases ('Use for arbitrage / sourcing questions') and example query ('cheaper on Walmart?') but does not explicitly mention when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (not read-only). The description describes a live price check, which is a read operation, but no destructive behavior is mentioned. It adds transparency about the source (Webotee's Amazon buy-box anchor) and output details (price, class, spread, durability, fulfillment info). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of about six sentences, front-loaded with the main purpose. It is reasonably concise with no redundant information, though it could be more structured (e.g., bullet points for modes). Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (17 parameters, no output schema, many siblings), the description covers the essential aspects: purpose, input requirements, modes, and output components (price, class, spread, durability, Amazon anchor). It does not fully describe all parameters or edge cases, but it is sufficient for the primary use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 65% (11 of 17 params described). The description adds meaning beyond the schema by explaining identifier options (asin, upc, gtin, title+brand) and mode functionality. It highlights key parameters but does not cover all 17; however, it provides enough context for the main usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find where one product sits across the open web — a live cross-retailer price check'. It specifies the action (find), resource (product across web), and scope (one product per call). This distinguishes it from sibling tools that focus on brands, operators, categories, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains required inputs ('Give ONE identifier and a mode') and the four modes (price_compare, cheaper, dropship, supplier) with brief definitions. It implies when to use each mode but does not explicitly state when not to use this tool or list alternatives among siblings. Overall clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds return value details (brand count, ASIN count, buybox days) beyond annotations, giving useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no unnecessary words. Front-loaded with key action and output, then usage examples. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with no output schema, the description fully covers what the tool does, when to use it, and what it returns. No gaps given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and param description is already present. Description does not add significant new meaning beyond reinforcing the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb 'Check' and resource 'operator presence on Amazon US, Amazon UK, and/or Walmart'. It includes example user queries that distinguish from sibling tools like 'brand_xmarket'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage examples and query patterns, but does not mention when not to use or list alternative tools. Clear context for positive usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by specifying the data source (Serper) and the return fields. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. It front-loads the action and return details, then adds context without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter search tool, the description is complete. It lists the return fields and clarifies the data source, which is sufficient given the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the query parameter. The tool description does not add additional meaning for the parameter beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches Google Shopping via Serper and returns retail listings with specific fields (title, price, image, rating, source). It distinguishes itself from siblings like alibaba_supplier_search (B2B), search_products (Amazon), and web_search (general web).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it is for retail price/margin reference, providing clear context for when to use. It does not explicitly state when not to use or list alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds context about the min_sellers floor behavior and that results show 'proven multi-seller demand'. However, it does not disclose output format, pagination, or rate limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured, front-loading the key function. Every sentence serves a purpose: definition, usage, exclusions. No unnecessary words. Efficient for its information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (17 params, no output schema), the description covers core concept and usage boundaries well. Lacks output description and default behavior, but the annotations and sibling context compensate. Could be more complete but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 53%. Description adds meaning for the 'min_sellers' parameter by explaining its role in filtering out single-seller listings. Other parameters are not elaborated, but the overall purpose is clear. Baseline for moderate coverage is around 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'find', resource 'BRANDS', and scope 'within a category that have proven multi-seller demand but are still under-competed'. It explicitly distinguishes from sibling tool 'find_underserved_niches' by stating what it returns and what not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage examples ('undercompeted brands in <category>') and contraindications ('Do NOT use for under-served niches...') with a direct sibling reference. Tells agent exactly when and when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description explains that this is an 'observation signal, NOT confirmed market entry' and warns that 'sparse sampling can surface a long-present seller the first time we see them', which adds crucial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a usage note, front-loaded with the core concept and differentiation, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description excels at explaining the tool's purpose and usage, it does not address the 18 parameters or output format. Given the complexity (many parameters, no output schema), the description could be more complete for an AI agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 28% (5 of 18 parameters have descriptions), and the tool description itself provides no additional parameter explanations. Many parameters remain undocumented, leaving the agent with insufficient semantic understanding to set them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb+resource ('Find operators we FIRST OBSERVED selling recently') and clearly distinguishes from the sibling tool top_expanding_operators by stating it's for newly-observed sellers, not existing operators adding brands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides example queries ('new sellers this month', 'who just started selling', 'newly seen operators') and explains the key difference from top_expanding_operators, giving clear guidance on when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds behavioral context beyond annotations by explaining that returned metrics like est_units_30d and est_revenue_30d are weighted by buybox share, and buybox share is normalized. This adds value without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured, starting with main functionality, then defining metrics, then usage examples. It could be slightly more concise, but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (33 parameters, no output schema), the description thoroughly explains the tool's purpose, returned metrics, sorting, and typical use cases. It provides a complete picture for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 30%, but the description adds meaning for key parameters: it explains the meaning of est_units_30d, est_revenue_30d, and buybox share. It also clarifies sort options. While many filtering parameters remain minimally described, the description compensates for the low coverage with essential context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows ASINs an operator wins the buybox on most often, ranked by estimated 30-day sales. It provides specific example queries for user intent. This distinguishes it from sibling tools that focus on other aspects like brand analysis or category metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit example phrases like 'what ASINs does this seller win on' and 'top ASINs for operator X'. However, it does not specify when not to use this tool or suggest alternative tools for different contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations set readOnlyHint=false, consistent with the mutation implied by 'Run'. The description discloses that the tool returns a digest and saves it to the in-app inbox. No contradictions, but could elaborate on potential side effects or execution time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by usage examples, with no wasted words. Information is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema, the description covers the core functionality: run a saved playbook and get a digest. It assumes the playbook exists but does not address error handling or prerequisites. Adequately complete for a simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. The description uses '<name>' in examples, clarifying that the parameter expects the playbook's name. This adds meaningful context beyond the bare schema, though it could specify naming conventions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run a saved playbook'), the resource ('saved playbook'), and the output ('return its digest'). It distinguishes from sibling tools like playbook_create, playbook_list, and playbook_schedule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit example phrases ('run my <name> playbook', 'check my brand watch now', 'run that workflow') indicating when to use. However, it lacks explicit exclusions or mention of alternatives for other actions like creating or scheduling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint annotation, stating it is a discovery tool. It adds important behavioral context such as being the flagship tool, detailing the default seller window, seed_brand constraint, and include_catchall filter, which goes beyond the annotation's scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a single paragraph that front-loads the core purpose, then provides example queries and seed_brand usage. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 18 parameters and no output schema, the description covers the main use case and seed_brand but does not describe the return format or results. It omits guidance on many parameters, which may leave the agent uncertain about the output. Slightly incomplete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema descriptions for parameters like min_sellers and max_sellers are already detailed and provide semantic meaning. The tool description adds value by explaining the purpose and context, though it does not elaborate on most parameters individually. With 56% schema coverage, the description supplements rather than repeats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds brands with low seller competition but real sales presence, and is identified as the flagship sourcing discovery tool. It distinguishes from siblings by providing specific user query examples and positioning as the primary sourcing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to use the tool with example queries and gives guidance on using seed_brand. It does not explicitly state when not to use or mention alternatives, but the provided examples sufficiently guide appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds rich behavioral details: output structure with fields like situation, suggested_action, totals, pagination note, and sorting options. It does not contradict annotations, though it could mention authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise despite its length. It is front-loaded with the core purpose, then details output, usage examples, and sorting/filtering without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and no nested objects, the description thoroughly covers all aspects: required parameters, optional filters, output fields, and sort options. It leaves no ambiguity for an agent to understand input and expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds contextual meaning beyond schemas, e.g., explaining max_buybox_share_pct's default as 'not dominating' and how situation_in is a comma-separated list. This enhances usability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds ASINs where a specific seller is losing the buy-box, ranked by revenue at risk. It includes specific verbs ('find', 'returns') and distinguishes from siblings like 'asin_buybox_history' by focusing on a single operator's losses with actionable suggestions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit example queries ('where is seller X losing the buy-box', etc.), giving clear guidance on when to use the tool. However, it does not explicitly state when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=true. Description adds that it's a 'sourcing feed' with ranking by score and sales, de-duped against tracked ASINs, and includes output fields. No destructive actions mentioned, consistent with annotations. Adds useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: starts with purpose, then usage, output details, market scope, and filters. Each sentence adds value. Could be slightly shorter, but front-loaded and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 21 parameters, no output schema, and many siblings, the description covers what the tool returns and how to filter. It lacks mention of pagination or default limit, but overall provides sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33%, but description groups and explains all filter categories (sourcing score, sales, price, fulfillment, etc.). It clarifies the meaning of 'resold_by_contains' and the shared product/fulfillment block, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds other ASINs that operators on a given ASIN/seller resell, ranked by sourcing fit. It uses specific verbs ('find', 'surfaces') and distinguishes from siblings like operator_top_asins by focusing on 'what else does this seller carry'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists three use cases: 'what else does this seller carry', 'find more like this from the same operators', 'arbitrage leads from this ASIN's sellers'. Also mentions de-duping, giving clear context for when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the tool writes data (consistent with readOnlyHint=false) and describes the return behavior (confirmation echoes product details). It also clarifies the effect of setting cost to 0.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently conveys purpose, usage examples, and constraints. Slightly more structure (e.g., separate sentences for behavior) could improve clarity, but it's concise and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, when to use, behavior, and return details. Although there is no output schema, the description mentions what the confirmation echoes, making it fairly complete for a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions. The description adds context: 'landed unit cost', 'marketplace currency', and ties parameters to the use case. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records the user's cost basis for an ASIN for later use in flagging buy box drops and computing net spread. It uses specific verbs and resource, and is distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit natural-language triggers ('my cost on B0... is $12') and constraints ('one ASIN per call', 'pass cost 0 to clear'). It lacks explicit when-not-to-use or alternatives but is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that capturing a baseline is part of the behavior, adding context beyond the annotation's readOnlyHint=false. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action. It is informative without being verbose, though the first sentence is moderately long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and minimal annotations, the description adequately covers purpose, parameter context, and usage. Missing return value details, but overall complete enough for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema covers all parameters, the description adds meaning by explaining list_type values (asin, brand, seller, niche) and what items represent (ASINs, brand names, etc.), which is not in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or adds to a saved tracking list, with specific verb (create/add) and resource (watchlist). It distinguishes from sibling tools like watchlist_list (listing) and watchlist_remove (removing) by focusing on the add action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use when the user says 'track these ASINs', 'add Nike to my brand watchlist', 'start monitoring ...''. This tells the agent exactly when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description confirms it reads already-collected results and does not run a live scan. It also explains behavior for unscanned ASINs (show 0 sources/never-scanned). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with core functionality and is comprehensive, though slightly long. Every sentence adds value, but could be more concise. Still, it avoids fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 16 parameters and no output schema, the description explains return fields in detail and covers key behaviors. It is complete for the tool's complexity, though parameter details rely on schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 56%, so many parameters already have descriptions. The description mentions filter concepts like violations_only and sort options but does not add significant meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: bulk web-wide price and MAP findings across a watchlist, reading already-collected results, not a live scan. It lists specific outputs (source count, cheapest price, violations, etc.) and distinguishes from sibling tools like find_product_across_web.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use cases are given: 'where is my whole watchlist cheaper off Amazon', 'web-wide MAP across everything I track', 'which tracked products are undercut on the open web'. It also states when not to use: for a live single-product check, use find_product_across_web instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and description consistently details all return fields, including coverage flags and explanation of null demand, adding value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, listing outputs then usage guidance. It is somewhat lengthy but every sentence adds value; could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (no output schema), the description thoroughly explains all return values including edge cases like data_coverage flag. Context including sibling tools is comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The tool description does not add significant extra meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Evaluate a single ASIN for FBA sourcing' and lists specific outputs, distinguishing it from sibling tools like find_sourcing_opportunities or asin_profit_calc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when the user asks 'should I buy this?', 'how fast does this sell?', or shares an ASIN and wants a sourcing recommendation.' This provides clear context for when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reveals that this is a write operation (remove/delete), consistent with readOnlyHint=false. It adds behavioral context about the two deletion modes and required parameters, though it could mention what happens if the list does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the main purpose. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers both operational modes and provides usage examples. It is complete for a simple remove tool with two clear use cases, though it could optionally mention error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite low schema coverage (33%), the description adds meaning by explaining how list_type + name identify the list and how items determines whether specific items are removed or the whole list is deleted. This compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes items from a tracking list or deletes the entire list, using specific verbs and resource. It distinguishes between two modes (remove items vs delete list) and implicitly differentiates from sibling tools like watchlist_add and watchlist_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use guidance with example user phrases ('stop tracking...', 'remove from my watchlist', 'delete my list'). Clearly explains parameter usage: provide items to drop specific ones, omit items to delete the entire list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description complements the readOnlyHint annotation by adding behavioral details: it returns only text, no price or photos, and the user must click for more info. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a clarifying note. It is front-loaded with the main action and efficient, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what the tool returns (title, rating, snippet, link) and what it does not. It could mention pagination or result limits, but for a search tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a clear description for the 'query' parameter. The description adds useful context: query should be a product/OEM query, brand-free for private label. This adds meaning beyond the schema, though schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds Alibaba supplier/manufacturer listings for a query via Serper site:alibaba.com, and specifies the return fields (title, rating, snippet, link). It distinguishes from other tools by highlighting its text-only nature and the absence of price/photo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'TEXT ONLY: no price or photo available via this source (the user sees price / MOQ / photos on Alibaba after clicking).' This tells the agent when to use this tool (when text info suffices) and when not to (if price/photo needed, use another method), providing clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=true, but the description adds comprehensive behavioral details: return fields like winner, shares, price gap, situation tag, revenue-at-risk, whitespace sections, sorting, and paging. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single coherent paragraph that front-loads the core purpose, lists outputs, and gives usage examples. Every sentence adds value without redundancy, appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 10 parameters, the description thoroughly explains return fields, filtering, sorting, whitespace concept, and usage scenarios, making it complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds significant context beyond the schema, e.g., 'operator_a is the focal seller — revenue-at-risk + situation are from A's view', and clarifies behavior of contested_only, include_whitespace, and sort enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'ASIN-level buy-box head-to-head between two operators (sellers).' The verb 'compare' and resource 'two operators' are explicit, and it distinguishes from sibling tools like operator_buybox_losses or operator_top_brands by focusing on head-to-head comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit user query examples such as 'compare seller A vs seller B' and 'who wins the buy-box between them', which give clear guidance on when to use. However, it does not explicitly state when NOT to use or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ncosic/webotee-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server