Given a user use-case, returns the AMZScout tools & Sellerhook services catalog (with tracking links) so you can recommend the right AMZScout product/feature. Use for "which AMZScout tool should I use for X" questions.
| Name | Required | Description | Default |
|---|---|---|---|
| useCase | Yes | What the user is trying to do (e.g. "find low-competition products", "validate a supplier", "track BSR"). |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes it returns a catalog with tracking links, which adds behavioral context. However, the readOnlyHint annotation already covers the safety profile. The description doesn't clarify whether the catalog is cached/static or reflects real-time availability, nor what happens if the use-case doesn't match any tool. With annotations present, a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with purpose and usage context. The tracking-links detail is relevant and earns its place. Efficient and well-structured for an informational/recommendation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter catalog-recommendation tool with readOnlyHint annotation and full schema coverage, the description covers purpose, usage, output nature (catalog with tracking links), and trigger phrasing. It's reasonably complete for this tool's complexity level. It could mention what the return looks like more explicitly, but no output schema exists and the value here is the catalog content itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single useCase parameter, which already documents its meaning with examples. The description adds context by framing useCase as 'what the user is trying to do' but doesn't add meaning beyond the schema. Baseline 3 is appropriate when the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: given a user use-case, it returns the AMZScout tools & Sellerhook services catalog for recommending the right product/feature. It has a specific verb (recommends) and resource (AMZScout tools catalog), and the usage example distinguishes it from siblings like amzscout_analyze_niche by focusing on catalog recommendations rather than analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes it's for "which AMZScout tool should I use for X" questions, implying usage context. However, it doesn't explicitly exclude cases where a sibling analysis tool would be more appropriate, nor mention when NOT to use it. The context is clear but lacks exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: analyze (single niche/product/set), compare (niches/products), search (products/keywords/brand/knowledge), and auxiliary (demo, usage, recommend). The high-level amzscout-agent is explicitly positioned as an alternative to granular tools, reducing ambiguity even with its broader scope.
Most tools follow a consistent amzscout_verb_noun pattern (e.g., amzscout_analyze_niche, amzscout_compare_products, amzscout_get_keywords). The only deviation is amzscout-agent, which uses a hyphen instead of an underscore, breaking the uniform naming style.
13 tools is well within the ideal 3-15 range and each earns its place by covering analysis, comparison, search, keywords, brand lookup, knowledge retrieval, usage, and a demo entry point. The count feels justified for the scope of an Amazon research assistant.
The tool surface covers the full lifecycle of Amazon research: single and multi-product analysis, niche analysis and comparison, keyword/SEO data, brand footprint, product search, knowledge grounding, token usage, and a recommendation helper. No obvious gaps for the domain, as even history-based trends are included via analysis tools.