agentcentral
Server Quality Checklist
Latest release: v1.0.3
- Disambiguation4/5
Most tools are clearly distinguished by prefixes like sp, sb, sd for ad types and by the entity name. However, the sheer number of similar get_performance tools and get_sponsored_ads_entities_live vs get_sp_entities_live could cause occasional confusion.
Naming Consistency5/5All tools follow a consistent verb_noun pattern using snake_case, with clear hierarchical prefixes for ad types. For example, create_sb_campaigns, update_sd_target_state, get_inventory_health. No mixing of conventions.
Tool Count1/5With 149 tools, this is far beyond the typical scope for an MCP server (3-15 tools is ideal). Such a large surface will overwhelm agents, making selection and prioritization difficult. Even for a broad Amazon MCP, this is excessive.
Completeness4/5The tool set covers a wide range of Amazon advertising, catalog, inventory, fulfillment, finance, and utility operations with create, read, update, and archive capabilities. Minor gaps (e.g., lacking delete operations) exist but are not severe.
Average 3.4/5 across 127 of 149 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 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 passing
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.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
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?
With no annotations, the description bears full responsibility for behavioral disclosure. It labels the operation as a 'guarded write' but does not explain what that entails (e.g., permissions, reversibility, rate limits) or what 'archive' actually does to the ads.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes an irrelevant server note that adds no value for an agent. The first sentence is concise, but the second sentence should be omitted or moved elsewhere.
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?
For a guarded write tool with preview and archive modes, the description lacks essential context: prerequisites, effects of archiving, how preview differs from execution, and how parameters interact. The agent cannot fully understand the tool's 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 100%, so the baseline is 3. However, the description adds no additional meaning to parameters like 'changes' (vaguely defined as high-level desired changes with additionalProperties:true) or 'preview' vs 'dry_run'. The agent gets no guidance on how to construct valid input.
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 identifies the tool as previewing or archiving Sponsored Display product ads, distinguishing it from sibling tools that target campaigns or ad groups. However, the note about the server being an introspection stub is tangential and could confuse purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like archive_sd_ad_groups or create_sd_product_ads. The description does not clarify the difference between preview and archive actions, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It claims 'Live' discovery but also states it is an 'introspection stub' locally, creating confusion about actual behavior. It does not disclose whether data is real or mocked, nor any authentication 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose. However, the second sentence about 'introspection stub' is ambiguous and could be more clearly worded. Overall, it is concise but sacrifices clarity.
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 no output schema and a complex input (7 parameters including nested object), the description is too brief. It fails to explain return values, pagination, or the practical effect of the 'introspection stub' label. The tool likely requires more context for effective use.
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 all 7 parameters having descriptions. The tool description adds no additional meaning or context to parameters; it merely states the tool exists. Baseline of 3 is appropriate as the description does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is for 'Live Amazon Ads audience segment discovery' and indicates it is a read operation via '[Ads / direct API read]'. However, it does not differentiate itself from other get_* tools like 'get_dsp_advertisers_live' or 'get_sponsored_ads_entities_live', and the mention of 'introspection stub' may confuse the agent about its actual functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It mentions 'Hosted endpoint only' and 'local stdio server is an introspection stub', which hints at limitations but does not offer clear usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It indicates a read operation but offers no details on side effects, idempotency, auth requirements, or rate limits. The 'introspection stub' remark may confuse whether the tool is functional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but the structure is fragmented: starting with a bracket-enclosed tag, then a phrase, then environment notes. It is concise but not well-organized.
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 7 optional parameters, no required ones, and no output schema, the description lacks information about return format, pagination, filtering behavior, or use cases. It is insufficient for a tool of this 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?
All 7 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description does not add additional meaning or context beyond 'Daily final/priced revenue and estimates'.
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 includes a tag '[Inventory / read]' and states 'Daily final/priced revenue and estimates', which provides a clear verb (get) and resource (revenue and estimates). However, it does not distinguish this tool from similar siblings like get_sales_and_traffic or get_todays_sales.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The mention of 'Hosted endpoint only; this local stdio server is an introspection stub' is about environment, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It notes the tool is a 'stub' and 'hosted endpoint only,' but does not explain what happens when called (e.g., error or mock response), nor any auth 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences). The first sentence is clear; the second is potentially confusing and adds little value. It is concise but not optimally structured.
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?
No output schema exists, so the description should explain what data is returned. It does not. The domain term 'settlement economics' is not elaborated, and the stub nature is inadequately explained.
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 7 parameters, so the description does not need to add parameter details. Baseline score of 3 is appropriate since the schema does the heavy lifting.
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 this tool reads 'Settlement-finalized financial data' and labels it as a read operation. However, the mention of 'introspection stub' may confuse an agent about whether the tool is functional, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context of use, or exclusions. No comparison to sibling tools like get_financial_events or get_payment_transactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals it is a 'guarded write' and a local introspection stub, but fails to disclose side effects, required permissions, or behavior of preview vs archive. The stub note adds some transparency but is insufficient.
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—two short sentences covering purpose and a key caveat. It is front-loaded with the type indicator in brackets. However, the dual action (preview/archive) could be structured more 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?
The tool has 5 optional parameters, no output schema, and no annotations. The description does not explain how parameters like preview, dry_run, and changes interact, nor does it specify the target ad platform. The stub note warns of non-functionality but doesn't help an agent 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 coverage is 100%, so the description does not need to explain parameters. It adds no extra meaning beyond 'preview or archive,' which indirectly relates to preview/dry_run parameters, but this is not explicit. Baseline score of 3 is appropriate.
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 states it is for 'Preview or archive keywords,' which is a specific verb-resource combination. It differentiates from sibling archive tools targeting other entities (e.g., campaigns, ad groups) but lacks specification of keyword type, causing minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like archive_sp_negative_keywords or create_keywords. It does not explain the condition for preview vs archive or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. The description labels it as a 'guarded write' and mentions preview vs. create, but lacks details on side effects, authentication, rate limits, or what 'guarded' implies. Critical for a write operation.
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 at two sentences, front-loaded with the purpose. Every word serves a function; no unnecessary fluff.
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 5 optional parameters and no output schema, the description omits crucial context: how preview and dry_run relate, the format of 'changes,' and expected responses. The introspection stub note is helpful but insufficient for an agent to use the tool effectively.
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 parameter descriptions. The description adds minimal value beyond the schema, such as grouping 'preview' and 'dry_run' as similar but not clarifying their relationship. Baseline score due to high 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 previews or creates Sponsored Products targeting clauses, distinguishing it from sibling tools like create_sp_negative_targets. However, it could be more specific about what 'targeting clauses' are.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other create_ tools. It mentions it's a 'hosted endpoint only' and an 'introspection stub,' but that is a technical constraint, not usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description needed to disclose behavioral traits. It indicates read-only and stub nature but omits details on data refresh, pagination, rate limits, or that it supports time-range filtering (implied by parameters but not stated). This is insufficient for an agent to anticipate tool behavior.
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, using a single sentence plus bracketed tags. It front-loads the purpose and stub note. However, the structure is slightly choppy with three separate segments; a more integrated sentence would improve flow.
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 tool has 7 optional parameters, no output schema, and many siblings, the description is too minimal. It doesn't explain the return value, how filtering works, or how it differs from related tools. This lack of completeness hinders the agent's ability 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 100%, so baseline is 3. The description adds no additional meaning beyond the schema. Parameters like start_date and end_date are explained in the schema, but the description doesn't enhance understanding of their usage in the tool's context.
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 states 'AWD shipment tracking' with a '[read]' tag, clearly indicating it's a read operation for AWD shipments. However, it doesn't specify what specific tracking details are included, which could be more precise to differentiate from get_awd_inventory or get_awd_shipment_items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions it's a hosted endpoint and a stub for local use. It provides no guidance on when to use this tool over alternatives like get_awd_inventory or get_awd_shipment_items, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it is a read operation and a stub locally, but no annotations exist. It fails to disclose any behavioral traits such as rate limits, required permissions, or side effects. The read nature is implicit from the name.
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-loading the category and verb. It is concise with no wasted words, but the brevity sacrifices completeness.
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 complexity (7 optional parameters, nested objects, no output schema), the description is too minimal. It does not explain what 'days of stock remaining' means or how to interpret results, leaving significant gaps for an agent.
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 parameters are documented in the schema. The description adds no extra meaning beyond what the schema provides, achieving the baseline of 3.
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 identifies the tool as an inventory read for 'Days of stock remaining' and prefixes it with '[Inventory / read]', which specifies the category and verb. This distinguishes it from many sibling tools that deal with performance, orders, or campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_fba_inventory or get_inventory_health. It does mention 'Hosted endpoint only; this local stdio server is an introspection stub,' which warns about local functionality but does not help with tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral burden. It indicates the tool is a stub in local environments, but fails to disclose authorization needs, rate limits, or side effects, leaving significant gaps.
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 very short (two sentences) and front-loads purpose. While concise, it sacrifices necessary detail, but the structure is efficient.
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?
The tool has 7 parameters, no output schema, and no annotations. The description is too sparse, offering only an environment note and a basic purpose, lacking details on output, filtering logic, and constraints.
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 baseline is 3. The description adds no extra meaning beyond what the schema provides for parameters, and does not explain relationships or usage patterns.
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 explicitly states the tool reads FBA stock levels and quantities, using the verb 'read' and specifying the resource. However, it adds confusion by saying it's a stub on the local server, which may mislead agents about actual functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the tool is for hosted endpoints only and is a stub locally, providing some environmental context. But it offers no guidance on when to use this tool versus siblings like get_inventory_by_fulfillment_center or get_inventory_health, missing explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It states the tool is read-only and is a stub, but fails to describe what 'tracking' entails (e.g., fields returned, pagination, side effects). Critical behavioral details are omitted.
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, avoiding unnecessary detail. The purpose and stub nature are front-loaded, though the brevity slightly sacrifices completeness for efficiency.
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 rich schema and absence of an output schema, the description should clarify return values and integration with other tools. It provides minimal context about how this tool fits into inbound shipment workflows, leaving gaps in 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?
The input schema has 100% coverage with clear descriptions for all 7 parameters, so the description does not need to add parameter details. The baseline is 3; no extra meaning is added beyond the schema.
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 identifies the tool as handling FBA inbound shipment tracking under the Inventory/read category. It specifies the resource ('FBA inbound shipments') and the operation type. However, it does not differentiate from sibling tools like get_awd_shipments or get_shipment_receiving_status, which reduces clarity for an AI agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The note about being an introspection stub hints at technical limitations but does not offer practical usage context, leaving the agent to infer appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the tool is a 'local stdio server' stub and 'Hosted endpoint only', indicating it may not return real data. However, it does not describe read-only behavior, pagination, or other behavioral traits. With no annotations, the description carries full burden but fails to provide sufficient transparency beyond the stub nature.
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 sentence, very concise and front-loaded with the purpose. It efficiently conveys the tool's core function and stub status. However, it could be slightly more structured by separating the stub notice, but overall it is appropriately sized for the information provided.
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 tool has 7 optional parameters, a nested 'filters' object, and no output schema, the description lacks completeness. It does not explain what 'inventory movements' entail, how parameters interact, or what the response contains. Agents are left with minimal context to form correct requests.
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 all parameters have basic descriptions. The tool description adds no extra meaning beyond the schema, such as parameter interactions or typical usage patterns. Thus, it meets the baseline but does not enhance understanding.
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 'Inventory change history' with a verb+resource structure, indicating it reads inventory movement data. The prefix '[Inventory / read]' reinforces the domain and action. However, it does not differentiate from other inventory read tools like get_inventory_health or get_fba_inventory, which reduces clarity among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool over alternatives, nor does it mention any prerequisites or limitations beyond being a stub. Agents lack context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it is a read operation, which is good, but notes it is an 'introspection stub', implying it may not perform the actual hosted endpoint call. This is a key behavioral trait that is disclosed, but it lacks other behavioral details (e.g., no side effects, but no output description).
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 very concise with two sentences. The first sentence defines the purpose, the second provides an important caveat about the stub nature. No wasted words, though the second sentence could be clearer.
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 having 7 parameters and no output schema, the description does not explain return values, behavior of filters, or how to use the tool effectively. The stub caveat adds uncertainty. More context is needed 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?
Input schema has 100% coverage with clear descriptions for all 7 parameters. The tool description adds no further meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
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 performs 'keyword bid and targeting analysis', which is a specific read operation. It distinguishes itself from sibling tools that are write-oriented (e.g., create_keywords, archive_keywords). However, the note about being a stub may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or when to avoid this tool. The description does not mention alternatives or context for choosing this over other read tools (e.g., get_campaign_performance).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description indicates it is a read operation and a hosted endpoint stub, but does not disclose any other behavioral traits such as required permissions, rate limits, or data scope. With no annotations, the description carries the full burden and falls short.
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 that front-load the purpose. Every sentence earns its place, though more detail could be added without sacrificing conciseness.
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 7 parameters, no output schema, and no behavioral details, the description leaves significant gaps. It does not explain how to interpret the results or what the nested filters imply. The stub note also reduces completeness for actual usage.
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 all 7 parameters described in the schema. The description does not add new meaning beyond the schema, so baseline 3 is appropriate. It provides context that the tool is for 'performance by ad placement' but no parameter-specific insights.
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 it retrieves performance by ad placement, with an explicit read hint. It distinguishes from sibling performance tools by specifying 'by ad placement'. However, the note about being an introspection stub may cause confusion about its actual functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like get_campaign_performance or get_adgroup_performance. It only mentions it's a hosted endpoint and a stub, but does not provide any context for choosing this tool over similar ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It indicates read-only nature but lacks details on mutation safety, authorization needs, or parameter interaction effects. The 'introspection stub' note is a behavior but not explanatory.
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 very short (two sentences), efficient. The '[Inventory / read]' prefix provides quick categorization. The second sentence adds important but context-specific info. Could be more 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?
Given 7 parameters and no output schema or annotations, the description is too sparse. It doesn't explain the output format, pagination, or what happens when parameters are omitted. Leaves significant gaps for an agent.
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 all 7 parameters with descriptions (100% coverage), so baseline is 3. The description adds no additional semantics or context beyond the schema, such as how filters combine or defaults.
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 provides daily sales and traffic time series and identifies it as an Inventory read tool. However, the mention that it's an introspection stub may confuse an agent about actual functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like get_sales_and_traffic or get_sales_summary. The description only notes it's hosted-only, which is insufficient for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions the tool is read-only and a stub, but it does not disclose other behavioral aspects like pagination, rate limits, authentication requirements, or the impact of parameters. Important details are missing.
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, consisting of two short sentences. It front-loads the purpose and includes a critical caveat about the tool's availability, making every word count.
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 complexity (7 parameters, all optional, no output schema) and the large sibling list, the description is insufficient. It lacks explanation of the output format, how parameters like filters are used, and how this tool differs from other search-term tools.
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 schema already documents parameters. The description adds no additional semantic meaning beyond what is in the schema, such as the meaning of filters or the acceptable range for limit.
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 that the tool retrieves customer search terms that triggered ads, specifying it as a read operation. However, it does not explicitly differentiate it from sibling tools like get_search_query_performance or get_search_query_ad_coverage, which could be confused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns that the tool is only available as a hosted endpoint and that the local server is a stub, but it does not provide guidance on when to use this tool versus alternatives, such as other search-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes it is a read operation and a stub locally, but lacks disclosure of side effects, auth requirements, or behavioral details (e.g., rate limits, data freshness). With no annotations, the description carries full burden but is insufficient.
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?
Two concise sentences: first defines purpose, second clarifies hosting limitation. Information is front-loaded and no unnecessary text. Could be slightly improved with clearer structure.
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?
No output schema exists, yet description does not explain return values or format. With 7 optional parameters and no usage examples, it leaves the agent guessing about typical invocation. Incomplete for a complex 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%, so baseline is 3. The description does not add any parameter-specific meaning beyond the schema's own descriptions, which are already clear for each parameter.
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 retrieves 'Brand Metrics visibility and engagement signals' for ads, and the name 'get_share_of_voice' reinforces this. It distinguishes itself from siblings by specifying 'Ads / read'. However, it could be more specific about what signals are included.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_brand_health or other get_* tools. The mention of 'hosted endpoint only' and 'introspection stub' gives context but does not help with selection.
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 no annotations, the description carries the full burden. It labels the operation as a read ('[Inventory / read]') and notes the data is 'estimated'. The warning that this is an introspection stub is useful, but it lacks information on rate limits, authentication, or data freshness.
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 short sentences that convey purpose and a caveat. No unnecessary words. Could be slightly improved by placing the stub warning after the purpose, but it is already clear.
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 7 parameters (including a vague 'filters' object) and no output schema, the description is insufficient. It does not explain return format, how 'estimated' revenue is derived, or how optional filters work. The name-date range mismatch further reduces 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?
Although schema coverage is 100%, the description contradicts the name and schema: it says 'Today's' but the schema allows arbitrary date ranges via start_date and end_date. The description adds no additional meaning to the parameters, and the 'filters' object with additionalProperties is left unexplained.
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 returns 'Today's priced/estimated revenue by ASIN', indicating a read operation for inventory revenue. The verb is implied by the tool name, and the resource is specific. However, it does not explicitly differentiate from sibling tools like get_sales_summary or get_sales_and_traffic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only notes that the tool is a hosted endpoint and the local server is a stub, which implies it should not be used locally. No guidance on when to use this tool vs. other sales tools, or what conditions to consider.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it is a read operation but also a stub, implying it may not execute on local stdio. It does not disclose any additional behaviors or side effects.
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 sentence that is front-loaded with the purpose. It is concise, though the stub information could be better integrated.
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 7 input parameters and no output schema, the description is extremely brief. It does not explain return values, usage patterns, or how parameters relate to the tool's function, leaving significant 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 100%, so all parameters are already documented in the schema. The description adds no additional meaning or context for the parameters beyond what the schema provides.
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 reads 'parent/child variation relationships', which is a specific verb and resource. However, the note about being an introspection stub for local stdio may confuse the agent about actual functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Hosted endpoint only', providing a constraint but no guidance on when to use this tool versus sibling tools like get_product_details or get_listing_quality. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose all behavioral traits. It labels the tool as a 'guarded write' but fails to elaborate on what guards exist, what side effects occur, or what the hosted endpoint's behavior entails. The stub nature is transparent, but the actual hosted behavior remains opaque.
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 extremely concise (two sentences) and front-loaded with the tool's type and purpose. Every word carries meaning, and there is no redundancy. However, it could be slightly more structured with explicit sections, but given the brevity, it remains efficient.
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 complexity (guarded write with 5 params, no output schema) and the fact that it's an introspection stub, the description fails to provide sufficient context about the actual hosted tool's behavior, such as what the response looks like or how to chain it with other tools. The local stub purpose is clear, but completeness for real-world usage is lacking.
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?
All 5 parameters are described in the input schema (100% coverage), so the schema does the heavy lifting. The tool description adds no further meaning beyond reiterating 'guarded write' context. The baseline score of 3 is appropriate as the description neither adds nor subtracts value beyond the schema.
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 identifies the tool as related to MCF return authorization ('[Fulfillment / guarded write] MCF return authorization'), distinguishing it from sibling tools like 'get_returns' (read-only) and 'create_mcf_order' (order creation). However, it does not explicitly contrast with these siblings, and the mention of 'introspection stub' adds context but slightly dilutes the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is 'Hosted endpoint only; this local stdio server is an introspection stub,' which tells the agent not to expect functional behavior locally. However, it provides no guidance on when to use this tool versus alternatives (e.g., when to authorize a return vs. look up returns), nor any prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions 'guarded write' and 'preview or set', implying potential mutation, but does not detail consequences, permissions, or what setting state entails. The stub note is useful but insufficient for a write operation.
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 very concise, using a single line with brackets to convey essential context. No extraneous text, but could expand slightly on return values or state specifics without losing conciseness.
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 covers the tool's purpose and stub context, but lacks detail on return values (no output schema) and the specific campaign type it targets. Given the complexity of 5 optional parameters and a write operation, it is somewhat under-specified.
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?
Parameter schema coverage is 100%, so baseline is 3. The description adds the preview/set context that ties to the 'preview' and 'dry_run' parameters, but does not provide additional meaning beyond the 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 'Preview or set campaign state', specifying the verb and resource. The '[Ads / guarded write]' label adds context. However, it does not differentiate which campaign type (e.g., Sponsored Products) it applies to, especially given sibling tools like update_sb_campaign_state and update_sd_campaign_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides limited guidance, only noting that it's a 'hosted endpoint only' and that the local server is a stub. It does not specify when to use this tool over alternatives, prerequisites, or conditions for preview vs. set operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so description must convey behavior. 'Guarded write' and 'preview or set' hint at mutation with safety, but no details on side effects, permissions, or idempotency. Stub note explains local behavior but not actual runtime effects.
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 redundancy. Critical info front-loaded. Each sentence serves a distinct purpose: tool function and deployment context.
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?
Missing output schema and no annotations, so description must compensate. It does not explain return values, failure modes, or how 'changes' parameter works. Stub note is helpful but insufficient for full understanding of a mutation 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%, so baseline is 3. Description adds no new param-specific info beyond schema explanations. It does not elaborate on the 'changes' array structure or preview/dry_run semantics.
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 can preview or set Sponsored Brands negative target state, with a specific verb and resource. It distinguishes from siblings by mentioning 'negative target' but could be more explicit about contrast with update_sb_target_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like update_sb_target_state. The 'guarded write' hint is present but not expanded. Lacks context of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It mentions 'guarded write' and 'preview', but does not explain the guard's requirements, whether changes are reversible, or what happens during preview. The introspection stub note is a limitation, not a behavioral disclosure.
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 very concise, fitting in one sentence with a prefix. However, the prefix '[Ads / guarded write]' is slightly cryptic, and the structure could be clearer by separating the behavior from the limitation.
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 lack of output schema and the tool's role (updating state), the description omits return value information, error scenarios, and permission requirements. It is incomplete for a tool with 5 parameters and no annotations.
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 schema already describes parameters. The description's 'Preview or set' relates to the preview/dry_run parameters but adds no further semantics. Baseline score of 3 is appropriate.
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 previews or sets the Sponsored Display target state. The '[Ads / guarded write]' prefix and 'Hosted endpoint only' add context, distinguishing it from other tools. However, 'target state' could be more explicitly defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance on when to use this tool vs. alternatives like archive_sd_targets or update_sd_target_bids. It mentions it's an introspection stub, but does not specify prerequisites, conditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, making description the sole source. It mentions 'guarded write' and 'preview', but does not explain guarded write behavior, side effects, or permissions needed. The 'introspection stub' note is a limitation, not behavioral insight.
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. Every word adds value; no redundancy. Highly efficient for the intended message.
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 5 parameters and no output schema, description is minimal. Lacks return value explanation, error handling, or success criteria. The 'introspection stub' context partially excuses incompleteness, but leaves gaps for an AI agent.
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 has 100% description coverage, so baseline is 3. Description adds no significant meaning beyond schema; 'preview or update/archive' paraphrases boolean parameters but doesn't clarify their interplay or defaults.
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 previews or updates/archives Sponsored Products ad groups and product ads. It provides a specific verb and resource, but doesn't strongly differentiate from sibling tools like 'archive_sp_ad_groups' or 'update_sp_ad_group_state'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The mention of 'introspection stub' is a technical limitation, not a usage guideline. Lacks context for selection among sibling update/archive tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It labels the tool as a 'guarded write', indicating destructive potential, but does not specify required permissions, side effects (e.g., what happens to bids), or whether the stub actually processes requests or returns an error. The 'introspection stub' clarification is useful but insufficient for a write operation.
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. The first sentence clearly states purpose, and the second provides necessary context about the endpoint being a local stub. No extraneous words, though the first sentence could be slightly more specific about the action (e.g., 'modify' instead of 'adjust').
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 5 parameters, no output schema, and no annotations, the description covers the basic purpose and the stub nature. However, it lacks details on expected output, error handling, and specifics about the 'changes' parameter structure. The agent may not understand how to construct a valid request or interpret the response.
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 adds some context beyond the schema, such as explaining 'preview' as an alternative to applying writes and 'dry_run' as an alias. However, the 'changes' parameter remains vague ('high-level desired changes'), and no example or format is provided.
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 previews or adjusts Sponsored Products target bids, using verbs 'preview' and 'adjust' with a specific resource. It mentions 'guarded write' and 'hosted endpoint', differentiating it from read tools, but does not explicitly distinguish it from other update bid tools like update_keyword_bids or update_sd_target_bids.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., update_keyword_bids, update_sp_target_state). It mentions it's a 'hosted endpoint only' and a local 'introspection stub', implying it may not be functional locally, but does not clarify how the agent should behave or when to choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. 'Guarded write' is mentioned but undefined; no information on authentication, side effects, or what 'preview' entails. The local stub status is noted, but behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and context. However, it is too concise, omitting important detail like parameter relationships. Adequate but not optimal.
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?
For a tool with 5 parameters and no output schema, the description is insufficient. It lacks explanation of return values, the 'changes' array structure, and why two preview-related booleans exist. Does not fully equip an agent.
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 parameter descriptions, so the description adds minimal extra meaning. It paraphrases 'preview' and 'dry_run' but doesn't clarify their interaction or the structure of 'changes'. 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 explicitly states 'Preview or create Sponsored Products negative ASIN/brand targets.', specifying the resource and action. The prefix '[Ads / guarded write]' adds context, and the mention of a hosted endpoint distinguishes it from sibling tools dealing with other ad types or operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No direct guidance on when to use this tool vs alternatives like create_sp_targets or archive_sp_negative_targets. The statement 'Hosted endpoint only; this local stdio server is an introspection stub' hints at usage restrictions but doesn't provide clear usage criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It only labels it as 'read' and reveals it's a stub. No info on required permissions, data freshness, rate limits, or side effects. Minimal disclosure for a complex tool with 7 parameters.
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?
Very concise at two sentences. Front-loaded with purpose and scope. However, it omits important details that could be added without bloating (e.g., output format). Still, no fluff earns a high conciseness score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 optional parameters including a nested object, no output schema, and no behavioral cues, the description is woefully incomplete. Agent cannot understand return format, filter behavior, or how parameters interact. Needs substantial expansion for a tool of this 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 covers 100% of parameters with descriptions, so baseline is 3. The description adds no extra meaning beyond the schema; agent must rely solely on parameter descriptions. No examples or clarifications.
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 retrieves products purchased from ad clicks, with a prefix indicating it's a read operation. The name is self-explanatory and distinguishes from sibling tools like get_orders or get_product_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Only a note that it's hosted endpoint only, which is a deployment constraint, not usage context. Could benefit from mentioning it's for ad-attributed purchases, contrasting with other product/order tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions 'guarded write' and preview/archive but does not elaborate on what archiving entails (e.g., deactivation, irreversibility) or side effects. The 'introspection stub' note indicates limited functionality, but key behavioral traits are missing.
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 short (two sentences) and front-loaded with the key action. It is concise without unnecessary detail, though it could be better structured with separate sections for purpose and limitations.
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 tool is a write operation with 5 parameters and no required ones, the description lacks details on return values (no output schema), the difference between preview and archive, and prerequisites. The complexity is moderate but the description is too minimal to fully inform an AI agent.
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 any parameter-specific context beyond what is in the schema. The 'changes' parameter remains vague ('High-level desired changes') without further clarification.
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 action ('Preview or archive') and resource ('Sponsored Brands ad groups'). It is specific and distinguishes from sibling tools like archive_sb_ads (ads vs ad groups) and archive_sb_campaigns, though not explicitly.
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 notes that the tool is for hosted endpoints only and that this local server is an introspection stub, providing deployment context. However, no guidance is given on when to use this tool vs alternatives like update_sb_ad_group_state for state changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must compensate but only labels the tool as a 'guarded write' and mentions preview/archive. It fails to disclose side effects (e.g., whether archive deactivates or deletes), required permissions, or rate limits. The behavioral traits are minimally disclosed.
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 sentence plus a contextual note, which is concise and front-loaded with the core purpose. However, the note about the introspection stub is somewhat meta and could be restructured for clarity.
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?
The tool has 5 optional parameters, no output schema, and no annotations. The description lacks details about the expected behavior of 'preview' vs 'archive', the structure of 'changes', or any post-archive state. This leaves significant gaps for an agent to correctly 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%, so baseline is 3. The description adds no additional meaning to the parameters beyond what the schema already provides, such as clarifying the relationship between 'preview' and 'dry_run' or the format of the 'changes' array.
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 previews or archives Sponsored Display negative targets, specifying both the resource ('negative targets') and actions ('preview or archive'). This distinguishes it from sibling tools like 'archive_sd_targets' which target non-negative targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'update_sd_negative_target_state' or 'create_sd_negative_targets'. It only mentions it's an introspection stub, which does not help the agent decide between similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully convey behavioral traits. It labels the tool as a 'guarded write', indicating mutation, but does not disclose details such as required permissions, potential side effects, rate limits, or what happens on submission vs preview. The stub note is about deployment, not behavior.
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 purpose and context (guarded write, hosted endpoint restriction). Every word is purposeful with no redundancy. It is appropriately sized for the tool's complexity.
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 no output schema and no annotations, the description covers the basic write/validation purpose and deployment context. However, it lacks details on return values, error handling, and full behavioral coverage. Schema covers parameters well, but overall completeness is moderate.
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 100% schema coverage, the baseline is 3. The description adds no parameter-specific information beyond what the schema provides. It does not clarify how preview and dry_run interact or the structure of changes objects.
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 is for listing creation, with validation/submission options. It identifies it as a 'guarded write' and mentions hosted endpoint context. However, it does not explicitly differentiate from sibling update_listing, which would benefit from a clearer contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the hosted endpoint restriction and local stub, giving deployment context but no guidance on when to use this tool over alternatives like update_listing or other creation tools. No when-to-use or when-not-to-use criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. Only labels as 'guarded write' and notes it's a stub locally, but lacks details on success/error behavior, required permissions, rate limits, or side effects beyond writing.
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 that front-load the key action and important caveat about the local server being a stub. No unnecessary words, 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?
Missing critical context: no output schema, no explanation of return values, no required fields despite schema having no required parameters. The 'guarded write' concept is mentioned but not explained, and the stub aspect is noted but doesn't inform actual behavior.
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 100% with generic descriptions, but the tool description itself adds no information about parameters. Does not explain how parameters like 'preview', 'dry_run', or 'changes' map to the MCF order creation process.
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 submits an MCF order request from FBA inventory, using specific verb 'Submit' and resource 'MCF order request'. Differentiates from sibling 'get_mcf_orders' and other create tools by noting 'guarded write' and 'hosted endpoint only'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool over alternatives. Mentions it's a 'guarded write' but doesn't elaborate on prerequisites, when not to use, or how it differs from other create tools like 'create_listing' or 'create_keywords'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'guarded write' and 'introspection stub'. It does not explain behavioral traits like side effects (actual creation vs. preview), required permissions, rate limits, or error handling. The agent lacks critical context for safe invocation.
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?
Two sentences, no wasted words. However, the second sentence about the server being an 'introspection stub' is meta and may distract from the tool's purpose. Still, overall concise and 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?
Given the complexity (5 parameters, no output schema, many siblings), the description is severely lacking. It does not explain return values, how to use the 'changes' parameter, or the difference between preview and create. The agent cannot reliably use this tool based solely on the description.
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 baseline is 3. The description does not add any parameter-specific guidance beyond what the schema provides. For instance, it does not clarify the relationship between 'preview' and 'dry_run' or the expected format of 'changes'.
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 can 'Preview or create Sponsored Display product ads', specifying the resource (SD product ads) and the actions. It also labels the tool as 'Ads / guarded write', distinguishing it from sibling tools like archive or update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings (e.g., create_sd_ad_groups, create_sd_campaigns). The description mentions 'Hosted endpoint only' and 'introspection stub', but does not guide the agent on selecting this tool for actual creation vs. preview, or when to use it over archive/update 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?
Discloses guarded write and stub nature, but does not detail the exact behavior when invoked (e.g., error message or simulated response). No annotations to compare against.
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?
Single sentence with brackets, no fluff. However, the stub information could be separated for clarity.
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?
Lacks details on expected output, error behavior, and how guarded write works. No output schema. The stub nature severely limits 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 covers all 5 parameters with descriptions, so baseline is 3. The description adds no additional semantics beyond the schema.
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?
Clearly states it previews or creates Sponsored Products product ads, with a specific verb and resource. The mention of 'hosted endpoint only; this local stdio server is an introspection stub' slightly detracts from clarity by introducing stub behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as create_sd_product_ads for Sponsored Display. Does not explain when to preview vs create.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It states it returns quantities but does not mention read-only nature, prerequisites, rate limits, or side effects. The stub note is transparent but insufficient for the real endpoint.
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 very concise (two sentences plus a tag) with no redundant words. However, the use of brackets for categorization is slightly informal. Still, 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?
With 7 parameters, no output schema, and a nested object, the description is too minimal. It does not explain what 'Per-SKU AWD shipment quantities' means in practice, what the output format is, or how to use filters. The stub note helps locally but not for real usage.
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 clear parameter descriptions. The tool description adds no additional meaning beyond the schema, especially for the ambiguous 'filters' parameter. 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 explicitly states 'Per-SKU AWD shipment quantities' and tags it as '[Inventory / read]', clearly identifying the tool's function. It distinguishes from siblings like get_awd_inventory and get_awd_shipments by specifying 'shipment items' per SKU.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The note about being an introspection stub is about environment, not selection context. Missing exclusions or comparisons to related 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?
In the absence of annotations, the description reveals that the local server is an 'introspection stub' and not the actual hosted endpoint, which is a key behavioral trait. However, it does not disclose other aspects like authentication requirements, rate limits, or the structure of the response.
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 remarkably short, consisting of a single sentence that front-loads the core purpose. It avoids unnecessary verbosity, though the term 'introspection stub' may be jargon that could confuse some 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 no output schema and 7 optional parameters, the description is too sparse. It fails to explain the return format or fields of budget suggestions, and does not provide enough context for an agent to effectively use or select this tool among many siblings.
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 already documents all 7 parameters with descriptions, achieving 100% coverage. The tool description adds no additional meaning to the parameters, so it meets the baseline for high 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 'Live Amazon budget suggestion fields' and identifies it as a direct API read operation. It distinguishes from siblings like get_bid_recommendations by specifying 'budget' rather than 'bid', though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. The note about being an 'introspection stub' hints at limited local functionality but doesn't help an agent decide whether to choose this tool over similar read tools like get_bid_recommendations or get_budget_pacing.
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?
No annotations are provided, so the description must cover behavioral traits. It correctly notes that this is an introspection stub and not a live endpoint, which is critical for an agent. However, it omits other behaviors like auth requirements, rate limits, or error handling, making this a partial disclosure.
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 composed of two clear, front-loaded sentences. The first sentence groups the inventory health data, and the second explains the stub nature. There is no wasted text, but the structure is simple and not innovative.
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 that there are 7 parameters and no output schema or annotations, the description is too brief. It does not explain how to use the parameters effectively, what the tool returns, or how it differs from other inventory tools. The stub disclaimer is helpful but does not compensate for the lack of completeness for a real-world use case.
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%, meaning all 7 parameters are described in the input schema. The description adds no further context about parameters, so the information is sufficient but not enriched beyond the schema. Baseline score of 3 is appropriate.
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 action (read) and resource (inventory health) and lists specific data elements (age buckets, weeks of cover, storage fees). However, it does not explicitly differentiate this tool from sibling tools like get_fba_inventory or get_inventory_risk_triage, which could reduce clarity for an AI agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that the local stdio server is an introspection stub and the hosted endpoint is the real tool, but it provides no guidance on when to use this tool versus alternatives among siblings. There is no discussion of prerequisites or context for using inventory health metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but discloses only the read nature and hosting constraint. No details on pagination, authentication, rate limits, or response structure are provided.
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 one clear sentence and a technical note. It is front-loaded with purpose, but the 'introspection stub' phrase adds noise.
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?
For a tool with 7 parameters, nested objects, and no output schema, the description is insufficient. It lacks information about return values, pagination behavior, and how the 'filters' parameter works, leaving significant 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 coverage is 100%, so the schema already describes all 7 parameters adequately. The description adds no additional semantic value beyond the schema.
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 as retrieving a list of Multi-Channel Fulfillment orders, with a domain prefix '[Fulfillment / read]'. However, the note about being an 'introspection stub' introduces ambiguity about actual functionality.
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?
Implies that the tool is only available on a hosted endpoint, not locally, but provides no explicit guidance on when to use this tool versus other order-related tools (e.g., get_orders) or what alternatives exist.
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 no annotations, the description carries full burden. It correctly identifies the tool as read-only via '[Inventory / read]' and discloses that it is an introspection stub, which is important behavioral context. However, it omits details like pagination, rate limits, or error behavior.
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 only two sentences with no redundant information. It front-loads the core purpose and then adds deployment context, though the second sentence could be seen as meta-information rather than functional guidance.
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 complexity (7 parameters, no output schema), the description is incomplete. It does not explain the return format, pagination behavior, or the structure of the 'filters' object. The stub note excuses some gaps but leaves the agent underinformed.
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 baseline is 3. The description does not add additional meaning beyond what the schema already provides for each parameter, such as filters, dates, or limits.
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 states 'Order list with filters,' which combined with the name clearly indicates a read operation for retrieving orders. It distinguishes from siblings like get_order_details by implying a list vs. single order, 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_order_details. It only notes that it is a hosted endpoint and a local stub, which is not usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose any behavioral traits such as authentication requirements, rate limits, or what 'introspection stub' implies for the response. The only hint is that it is a stub locally, but this is ambiguous and insufficient 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 consists of two concise sentences. The first sentence states the purpose clearly. The second sentence adds essential context about the endpoint's limited availability. Every word earns its place, 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 7 parameters, a nested 'filters' object, no output schema, and no annotations. The description is short and does not mention what the tool returns (e.g., fields, pagination), how to interpret the 'stub' behavior, or any limitations. While the schema covers parameters well, the description lacks completeness for a complex read 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?
The input schema covers all 7 parameters with individual descriptions (100% coverage). The description itself adds no additional meaning beyond what the schema already provides. According to the rubric, with high schema coverage, the baseline is 3, and the description does not elevate it further.
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 retrieves 'Live Amazon Payments transaction rows and summaries' and labels it as '[Finance / read]'. It identifies the specific resource (Amazon Payments transactions) and the action (read). However, among many get_* siblings (e.g., get_financial_events), it doesn't explicitly differentiate itself, so a 4 is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_financial_events. It mentions the tool is a 'hosted endpoint' and a 'local introspection stub', but does not explain in which context each mode applies or what prerequisites exist. The agent receives no contextual direction.
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?
No annotations provided, so description must disclose behavioral traits. It notes the tool is a read operation ('[Ads / read]') and that it's a stub not functional locally, which is important. However, it omits details on data scope, pagination, or error handling.
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?
Extremely concise with one functional sentence and one note. While the note is necessary, the structure is front-loaded and efficient.
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 7 parameters and no output schema, the description is insufficient. It fails to explain what 'sales and traffic' entails, how filters work, or what to expect from the stub. The stub disclosure is critical but incomplete for effective use.
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 adds no parameter-level context beyond what the schema already provides via its 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?
Description clearly states it provides 'Sales and traffic by ASIN', using a specific verb (get implied) and resource. However, the addition 'Hosted endpoint only; this local stdio server is an introspection stub' may confuse an agent into thinking the tool is non-functional locally, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_sales_summary or get_tacos. The description does not indicate context, prerequisites, or exclusions.
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 no annotations, the description carries the burden. It discloses that the tool is a stub and hosted endpoint only, which is a key behavioral trait. However, it does not mention permissions, side effects, or data availability.
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?
Two sentences, no fluff. The first sentence states purpose, the second warns about stub. Could improve by front-loading key words like 'get receiving status' but overall efficient.
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 7 optional parameters and no output schema, the description provides almost no context about the tool's usage, filtering, or return format. The stub warning helps but does not compensate for missing 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 100%, so the schema already documents all 7 parameters. The description adds no additional meaning or usage context beyond what the schema provides, meeting the baseline expectation.
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 states the tool retrieves per-SKU receiving progress, which is a specific resource. It adds a label '[Inventory / read]' to indicate domain and action. However, it lacks explanation of what 'receiving progress' entails, and the stub note may confuse about actual functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_inbound_shipments or get_fba_inventory. The only note is that it's a stub, which indicates it may not be the primary tool for the task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description labels it as a read operation but does not disclose rate limits, authentication needs, or potential side effects. Lacks behavioral depth beyond basic safety profile.
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 brief and front-loaded with purpose. However, it lacks structure (e.g., no sections) but is efficient for a read tool.
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 7 parameters, no output schema, and nested objects, the description is minimal. Does not explain output format or behavior when parameters are omitted. Agent may need additional 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 coverage is 100%, meeting baseline. Description does not add meaning beyond schema; parameters are adequately described in schema itself.
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 retrieves targeting candidates, categories, and negative brands. It specifies this is a direct API read and notes it's a stub, distinguishing 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_sponsored_ads_targeting_options'. Does not mention prerequisites or contexts where this tool is appropriate.
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 no annotations provided, the description carries full burden for behavioral disclosure. It correctly indicates a read operation and notes that the local server is a stub (hosted endpoint only), which is important safety context. However, it omits details like authentication requirements, rate limits, or potential side effects, leaving gaps.
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 very concise at two sentences, front-loading the core purpose and adding a critical note about the stub environment. It avoids waste, though it could be slightly more informative 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 lack of output schema, the description fails to explain return format (e.g., aggregated number vs table, data structure). With 7 optional parameters and nested objects in schema, a more complete description is needed to guide correct invocation. The omission of output details and parameter combinations leaves significant 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 100%, so the baseline is 3. The description adds minimal value beyond the schema, only reinforcing 'per ASIN' which matches the asin parameter. No additional details are provided on how start_date, end_date, or other parameters filter or affect results.
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 specifies the tool retrieves 'Total ad cost of sales per ASIN' and labels it as a read operation, providing a specific verb and resource. However, it does not differentiate from similar sibling tools like get_campaign_performance, and the mention of 'introspection stub' may confuse an agent about actual functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as when to filter by ASIN vs SKU, or when to use other financial metric tools. The description lacks explicit usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states 'guarded write' and 'preview', but does not clarify the side effects of a write, required permissions, or what happens in preview mode. The note about being a stub is transparent about local functionality but insufficient for the actual hosted endpoint.
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 sentence plus a brief note, all essential information. It front-loads the action and category, with no redundancy. It could include a tiny bit more usage context, but overall it's efficient.
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 tool has 5 parameters and no output schema or annotations, the description lacks details on return values, error behavior, or the effect of different parameter combinations. It does not leverage sibling tool context to guide selection.
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 baseline is 3. The description adds minimal context ('Preview or set') that aligns with the 'preview' and 'changes' parameters, but does not elaborate on parameter relationships or constraints beyond what the schema already 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 action ('Preview or set keyword state') and the resource ('keyword state'), and the prefix '[Ads / guarded write]' immediately classifies it. It distinguishes from siblings like 'update_campaign_state' or 'archive_keywords' by specifying the resource is keyword state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'create_keywords' or 'update_campaign_state'). It mentions it's a stub for local use, but does not indicate when preview vs. set should be chosen or any 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?
The description labels it as a 'guarded write' and mentions 'Preview or set', hinting at behavioral safeguards. It also transparently states it's a stub. However, it does not disclose what state transitions occur (e.g., active/paused) or any side effects beyond being a stub.
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 brief, two sentences, and front-loaded with key information. However, the brackets and phrasing could be streamlined for clarity.
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?
Without an output schema, the description should explain what the tool returns or what 'state' changes mean. It only mentions preview/set and stub nature, leaving important context about effects and responses missing.
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 5 parameters. The description adds no additional parameter meaning beyond what the schema provides, so it meets the baseline for high 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 indicates the tool is for updating Sponsored Products negative keyword state, and it distinguishes itself from sibling tools like 'archive_sp_negative_keywords' by focusing on state changes. However, mentioning 'Preview or set' creates slight ambiguity about whether it previews or actually updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance. The description notes it is a stub for introspection, implying it should not be used for actual writes in this local server, but no alternatives or context are provided.
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 no annotations provided, the description must carry the full burden. It discloses that the tool supports preview and set operations, and that it is a 'guarded write'. It also clarifies that this local server is an introspection stub, which is important behavioral context. However, it does not describe any side effects, return values, or error conditions.
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 sentence that efficiently conveys key information: purpose, guarded nature, and the fact that it's a stub. No redundant phrases.
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 tool has 5 parameters, no required fields, no output schema, and many sibling tools, the description is incomplete. It does not explain the expected format of the 'changes' parameter, how preview differs from set, or what the return value looks like. More detail is needed for an agent to use it effectively.
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?
All 5 parameters have descriptions in the input schema (100% coverage), so the baseline is 3. The description does not add significant meaning beyond the schema, except for implying the 'preview' and 'dry_run' are aliases for preview behavior, but this is already implied by their names.
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 specifies the verb ('Preview or set') and resource ('Sponsored Products target state'), clearly indicating the tool's function. The intro 'Ads / guarded write' adds context, and the name itself differentiates from sibling tools like 'update_sp_negative_target_state' or 'update_target_bids'. However, explicit differentiation from closely related siblings is not provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it specify prerequisites or exclusions. The note about being a 'local stdio server' introspection stub implies it is not functional for actual writes, but this is more about tool availability than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions 'Preview or archive' but then states it is an 'introspection stub', creating ambiguity about actual behavior when run locally. No annotations are provided, so the description carries the full burden, which it fails to meet by not disclosing side effects, permissions, or the guarded write 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?
Two sentences, no wasted words. The first sentence states the action, the second adds critical context. Information is front-loaded and efficiently structured.
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 having 5 parameters and no output schema, the description leaves significant gaps: the meaning of 'guarded write', the distinction between preview and dry_run, and the practical implications of the stub. An agent would not have enough context to use this tool correctly without additional information.
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 new information about parameters beyond what the schema already 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?
Description clearly states 'Preview or archive Sponsored Products negative keywords', distinguishing it from sibling archive tools like archive_keywords or archive_sp_negative_targets. The specific verb+resource combination leaves no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., create_negative_keywords, update_sp_negative_keyword_state). The note about 'hosted endpoint only; this local stdio server is an introspection stub' hints at technical limitations but does not help an agent decide when to invoke.
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 reveals it's an introspection stub and emphasizes 'guarded write', hinting at safety measures. However, it lacks details on side effects, required permissions, or what happens during preview vs. actual creation. Without annotations, the description partially compensates but is insufficient.
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 impactful sentences: first clearly states purpose; second adds essential context about hosted endpoint and stub nature. No redundancy or filler.
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 no output schema, no annotations, and 5 parameters, the description is too brief. It fails to explain return values, error handling, or the structure of 'changes'. The tool's complexity demands more guidance.
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?
All 5 parameters are described in the schema (100% coverage), so baseline is 3. The description adds no additional meaning beyond what the schema provides, such as clarifying the 'changes' array structure or 'reason' usage.
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 previews or creates Sponsored Brands campaigns, with a mention of 'guarded write' and 'introspection stub', distinguishing it from sibling tools like archive or update. However, it could be more explicit about what 'preview' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like create_sb_ad_groups or other create tools. It does not specify prerequisites, context, or when not to use. The mention of 'hosted endpoint only' hints at a limitation but not when to choose this over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It labels the tool as a 'guarded write' and notes it is a 'stub', but does not explain what guarded write entails, what happens on execution (e.g., whether it actually creates or just returns a preview), or any side effects. The behavioral traits are insufficiently disclosed.
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 very concise, consisting of only two sentences. It is front-loaded with the core purpose ('Preview or create Sponsored Display campaigns') followed by a necessary context note about being a stub. Every word serves a purpose with no redundancy.
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 tool has 5 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the output format, error conditions, or how to interpret the results (e.g., what 'preview' returns vs. what 'create' returns). As a creation tool, more detail is needed 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?
The input schema has 100% coverage with descriptions for all 5 parameters. The description does not add any additional meaning or context to the parameters beyond what is already in the schema, so it meets the baseline of 3 but does not exceed it.
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: 'Preview or create Sponsored Display campaigns.' It uses specific verbs ('preview', 'create') and a specific resource ('Sponsored Display campaigns'), which distinguishes it from sibling tools like archive_sd_campaigns or create_sd_ad_groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance on when to use this tool. It mentions it is a 'hosted endpoint only' and a 'local stdio server is an introspection stub,' which implies limited functionality, but does not explicitly state when to use it vs. alternatives like create_sd_ad_groups or when to preview vs. create. No 'when not to use' or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It states the tool is a utility and revokes a link, but does not explain side effects (e.g., whether the revoke is irreversible), required permissions, or error conditions. The mention of 'hosted endpoint' and 'introspection stub' adds confusion rather than clarity.
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 action. However, the last sentence about 'introspection stub' is unnecessary for an agent invoking the tool and could be removed to improve focus.
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?
The tool has 2 optional parameters, no output schema, and allows nested objects. The description omits return value details, error handling, and prerequisite conditions. For a deletion action, critical context like 'is this reversible?' or 'what confirms success?' is 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 coverage is 100% with descriptions, but the descriptions are vague ('Optional high-level request', 'Optional lightweight context'). They add no meaningful guidance beyond stating optionality. No examples or constraints are provided, leaving the agent uncertain about what values to supply.
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 action ('Revoke an existing public snapshot report link') and the resource ('shareable report'). It distinguishes from siblings like create_shareable_report and update_shareable_report by the verb 'delete' and the specific mention of revocation.
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 includes a usage condition ('after the user explicitly asks to take it down'), which implies when to use. However, it lacks explicit guidance on when not to use or mention of alternatives like create_shareable_report vs delete.
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?
No annotations provided, so the description must carry the transparency burden. It discloses the read nature and that it's an introspection stub, which is useful. However, it fails to mention any behavioral aspects like data freshness, permissions, or error behavior.
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, front-loaded with the core purpose, and an important clarification about the stub. No wasted words.
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 having 7 parameters and no output schema, the description does not explain the return format, the nature of 'daily win-rate history,' or any constraints. The stub note reduces expectations, but completeness is lacking for an agent to fully understand invocation results.
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 baseline is 3. The description adds context that the tool returns both current status and historical win-rate, but does not explain how parameters like date range or filters affect the query beyond what the schema already says.
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 retrieves live Buy Box status and daily win-rate history, and the prefix '[Inventory / direct API read]' indicates it's a read operation. However, it does not distinguish it from many other get_* tools in the sibling list that may also return status data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool over alternatives. It only notes that it is a hosted endpoint and a local stub, which is more about deployment than 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?
No annotations are provided, so the description must bear the full burden. It clarifies the read nature and that the local version is a stub, which is critical. But it omits details like rate limits, authentication, or responses from the hosted endpoint.
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-loading the core purpose and a critical usage constraint (hosted only). No superfluous words.
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?
The tool has 7 optional parameters, nested objects, and no output schema. The description offers minimal context on return values, filtering, or how to use the parameters effectively. Given the complexity, it falls short.
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?
All 7 parameters have descriptions in the schema, achieving 100% coverage. The description adds no extra meaning beyond what the schema provides, so it meets the baseline for high 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 states the tool is for reading campaign setting history and change detection, which clearly identifies its purpose. However, it could be more precise about what 'snapshots' entail, and it doesn't prominently separate it from other read tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that the tool is for hosted endpoints only and the local server is a stub. This hints at usage context but does not compare to alternative tools or specify scenarios where this tool is preferred over others.
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?
With no annotations, the description carries full burden. It notes this is a 'hosted endpoint only' and an 'introspection stub', indicating it is not the actual live API call. This is a key behavioral disclosure. However, it omits details about authentication, rate limits, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and front-loads purpose. While concise, it may be too minimal, lacking structure or additional context that would justify a higher score. Every word is relevant, but the description could be more informative 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 tool has 7 optional parameters, no output schema, and no annotations, the description is insufficient. It does not explain what DSP advertisers are, how filtering works, what the returned data looks like, or how it differs from other DSP tools. The stub note is important but incomplete.
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 baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions. No interaction between parameters is mentioned.
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 retrieves 'Live Amazon DSP advertiser records' and identifies it as a read operation. The verb and resource are specific. However, it does not explicitly differentiate from similar siblings like get_dsp_entities_live, though the name provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only mentions it is a hosted endpoint and an introspection stub, but does not explain scenarios or prerequisites for 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?
No annotations are provided, but the description adds the context '[Ads / direct API read]' and states 'Hosted endpoint only; this local stdio server is an introspection stub,' disclosing its stub nature. However, it does not disclose behavior such as data freshness, pagination, or error handling, which would be expected for a read operation.
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 very concise: two sentences that front-load the purpose and include a necessary caveat about the stub. No redundant or vague wording; 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?
Given the absence of an output schema, the description should explain what the tool returns. It only says it reads 'campaigns, ad groups, and targets' but omits return format, fields, pagination, or any details about the filters parameter. This leaves significant gaps for an AI agent to invoke 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?
The input schema covers all 7 parameters with descriptions (100% coverage). The tool description does not add any parameter-specific meaning beyond what is already in the schema, so it provides no extra value for parameter semantics. Baseline 3 applies because the schema is self-sufficient.
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 reads 'Live Amazon DSP campaigns, ad groups, and targets,' specifying the verb and resource. It distinguishes from similar tools like get_dsp_advertisers_live by focusing on entity types, though it doesn't explicitly differentiate from get_dsp_performance or other DSP tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no explicit guidance on when to use this tool versus other get_* tools like get_dsp_advertisers_live or get_sp_entities_live. It lacks when-not-to-use or alternative tool references, leaving the agent to infer usage from the name and partial description.
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 discloses that the tool is a read operation (implying no destructive side effects) and importantly notes that it is an introspection stub, meaning the local stdio server does not host the actual endpoint. However, it does not explain what the stub returns, permissions required, or any rate limits. Given no annotations, the description partially carries the burden but lacks depth.
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, using two sentences: one for purpose and one for the stub note. It is front-loaded and devoid of fluff.
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?
The tool has no output schema, and the description does not describe the return format or content. Additionally, while it notes the stub nature, it doesn't clarify what happens when called locally (e.g., returns empty array or error). For a tool with 7 optional parameters and no required ones, more context about what data to expect is needed.
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 provides full descriptions for all 7 parameters (100% coverage). The description adds no additional semantics beyond the schema, so it provides no extra value. Baseline at 3 is appropriate.
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 identifies the tool as a read operation for listing restrictions and approvals, using the prefix "[Inventory / direct API read]". This distinguishes it from many sibling tools that are archive/create/update operations. However, the mention of "introspection stub" slightly muddles the purpose of the local instance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only states the tool's purpose and that it's a stub; it provides no guidance on when to use this tool versus other similar "get_" tools like get_listing_quality or get_listing_registry. There are no exclusions or contextual cues for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover all behavioral traits. It only implies read-only behavior via the 'read' tag and notes it's a stub locally, but does not disclose side effects, idempotency, data freshness, pagination, or rate limits, leaving significant gaps.
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 very short, using two sentences to convey the purpose and a critical hosting constraint. It wastes no words, but could be slightly more informative without becoming verbose. Nonetheless, it is well-structured and front-loaded.
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 7 optional parameters and no output schema, the description should explain the return format or provide examples, but it does not. It adequately defines the resource and hosting context, but leaves the agent guessing about what data the tool returns, which is a notable gap.
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 input schema already documents all 7 parameters. The description adds no parameter-specific details beyond what is in the schema, making it neither helpful nor harmful for parameter understanding.
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 identifies the tool as a read operation for customer review topics and snippets, and distinguishes it from other tools by specifying it's from the Catalog domain. However, it does not explicitly differentiate it from similar tools like get_review_trends, leaving some ambiguity.
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 states it is a 'Hosted endpoint only' and that the local server is an 'introspection stub', which gives a clear constraint on when it works. However, it offers no guidance on when to use this tool vs alternatives or any prerequisites, limiting its utility for tool selection.
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 discloses that it is a read operation and importantly notes that this is a local introspection stub, which is critical behavioral context. However, it does not explain any side effects, rate limits, or what happens on failure, and annotations are absent.
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 focused sentences. The first sentence states the purpose, the second adds the crucial stub limitation. No wasted words.
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 having 7 optional parameters and no output schema, the description does not explain the return value, supported categories, or how parameters like filters work. The tool is left under-specified for an agent to use effectively.
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 adds no additional meaning beyond the schema; it does not explain parameter interactions or usage patterns.
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 that the tool retrieves 'best seller rank by category' and identifies it as a read operation in the catalog domain. This is specific enough to distinguish from many sibling tools, though it does not elaborate on the exact format or scope of the rank data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool compared to alternatives like get_sales_and_traffic or get_sales_summary. The description lacks any context for tool selection.
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?
No annotations are provided, so the description must convey behavioral traits. It notes 'Hosted endpoint only; this local stdio server is an introspection stub', which clarifies that the actual functionality is remote and this is a stub. However, it lacks details on authentication, rate limits, or the nature of the metrics returned.
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, very concise and front-loaded. The first sentence directly states the purpose, and the second provides critical behavioral context about the stub nature. 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good schema coverage, the description lacks explanation of output format, metric types, or any limitations beyond the stub note. For a tool with 7 parameters and no output schema, more context is needed for complete understanding. The stub clarification is helpful but insufficient.
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 for all 7 parameters, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions, which are adequate but not enhanced.
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 states 'Sponsored Brands campaign metrics', clearly indicating it retrieves metrics for Sponsored Brands campaigns. The '[Ads / read]' prefix clarifies it's a read operation. However, it does not explicitly differentiate from sibling tools like get_campaign_performance or get_sd_campaign_performance, leaving room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Given the large number of sibling get_* tools, this omission makes it harder for an agent to select the correct tool without additional context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates a read operation and that it's a stub, but lacks details on rate limits, authentication, or what happens if invoked locally. The behavioral implications of 'introspection stub' are not explained.
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, front-loaded with category and function. Every word adds value, no redundancy.
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 7 parameters and no output schema, the description is incomplete. It does not explain return format, filter usage, or what events are. The stub nature might limit completeness, but for agent decision-making, more context is needed.
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 all parameters have descriptions. The description adds context about the 52-week demand curve but does not enhance parameter understanding beyond the schema. 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 it is a read tool for inventory, providing a 52-week demand curve with events. It distinguishes itself as a hosted endpoint and notes this server is an introspection stub, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention conditions, prerequisites, or exclusions, leaving the agent without decision-making support.
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 notes it's a read operation ('[Ads / read]') and warns that it's an introspection stub on local stdio. However, without annotations, it should disclose more about data recency, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that cover purpose and a critical limitation. No wasted words, though the second sentence could be phrased more clearly.
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 provides enough context for a basic understanding but lacks details on output format or what 'retained report views' entails. Given the complexity (7 parameters, 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-documented. The description adds no additional semantics beyond the schema fields.
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's for reading consolidated SP/SB/SD sponsored ads reports. It distinguishes from sibling tools by specifying 'Consolidated' and 'retained report views', though it could be more explicit about the exact data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like get_sponsored_ads_entities_live or get_campaign_performance. The note about 'hosted endpoint only' is important but does not provide comparative usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. It indicates a read operation and that the endpoint is a stub, but lacks details on behavioral aspects such as authentication, rate limits, or what the stub returns (e.g., mock data or error). This is insufficient for safe agent usage.
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 with no redundant information. Every part serves a purpose: stating the tool's function and clarifying it is a stub.
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 having 7 optional parameters and no output schema, the description does not explain the return format or how parameters like 'filters' influence results. It is incomplete for an agent to fully understand the tool's behavior and output.
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 input schema already documents each parameter. The description adds no additional meaning beyond the schema, meeting the baseline of 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?
The description clearly states the tool retrieves live SP/SB/SD targeting options and bid fields, distinguishing it from siblings like 'get_sp_targeting_options' which may cover only SP. The mention of 'hosted endpoint only' further clarifies its nature as a stub.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description notes it is a local stub for the hosted endpoint, but does not explain under what circumstances an agent should invoke this tool rather than other related tools like 'get_bid_recommendations' or 'get_sp_targeting_options'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions 'guarded write' and 'preview' but does not disclose mutational behavior, required permissions, reversibility, or output. The description is insufficient for an agent to understand the tool's side effects.
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 concise at one sentence, front-loading the core action. The extra context about hosted endpoint is marginally useful but does not waste space.
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 no output schema and sparse annotations, the description outlines the tool's purpose but lacks details on return values, error handling, or precise behavior. It is minimally complete for a straightforward 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 all parameters described adequately. The description adds no parameter-specific information beyond what's in the schema, so baseline score of 3 applies.
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 previews or adjusts placement bid modifiers, with specific verb+resource. It distinguishes from sibling tools like update_adgroup_bid and update_campaign_budget by focusing on placement bid modifiers, not other bid aspects or campaign budget.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like update_target_bids or update_adgroup_bid. The description only includes meta information about hosted endpoint and introspection stub, which does not help in selecting the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description discloses that it is a preview/update tool and that it is a stub, but lacks information on mutation effects, error handling, or authorization requirements. With no annotations, the description carries the full burden and is insufficient.
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 two sentences, concise and front-loaded with key purpose and limitation. No unnecessary words.
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 no annotations, no output schema, and 5 optional parameters, the description is incomplete. It does not explain return behavior, the structure of 'changes', or how preview differs from update, which are critical for an AI agent 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 the schema fully documents parameters. The description adds no extra meaning beyond the schema, which is acceptable given the high 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?
Description clearly states it can preview or update Sponsored Brands campaign budgets, specifying 'Ads' category and 'guarded write'. It distinguishes from sibling tools like update_campaign_budget by naming 'Sponsored Brands'. However, the term 'preview' could be more explicit.
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?
Description mentions 'Hosted endpoint only; this local stdio server is an introspection stub', indicating the tool is not functional locally. It does not provide explicit guidance on when to use vs. not use or alternatives 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?
No annotations are provided, so the description carries the burden. It reveals 'guarded write' (indicating safety mechanisms) and the ability to preview or set state. The 'introspection stub' note clarifies that the tool is non-functional locally, adding behavioral context beyond the name.
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 no wasted words. It front-loads the category and action, 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?
Despite 5 parameters, the description lacks details on return values, the structure of 'changes', or how preview differs from set. The 'introspection stub' note partially excuses incompleteness, but the AI agent lacks guidance for actual use.
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 does not need to elaborate on parameters. It adds no additional meaning beyond what the schema already provides.
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 action ('Preview or set') and the resource ('Sponsored Brands campaign state'). The '[Ads / guarded write]' prefix provides context, but it does not explicitly differentiate from the sibling tool 'update_campaign_state' which likely targets other campaign types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Hosted endpoint only; this local stdio server is an introspection stub' which is a constraint but not proactive usage guidance. It does not state when to use this tool versus alternatives like 'update_sb_campaign_budget' or 'update_campaign_state'.
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 no annotations, the description carries the burden. It reveals guarded write behavior via '[Ads / guarded write]' and the stub nature locally. However, it does not disclose side effects (e.g., what archiving does to targets), permissions needed, or whether operations are reversible.
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 substantive sentences, each adding unique value: purpose and environment. 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?
Given the lack of output schema and annotations, the description adequately identifies the tool as a stub with guarded write capability. However, it does not explain return values, error states, or when to use preview vs. archive, leaving gaps for an agent to interpret.
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 parameters are already described. The description adds context connecting 'preview' and 'dry_run' to the overall behavior, but does not provide additional meaning beyond the 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 can preview or archive Sponsored Display targets, with a verb and specific resource. It also distinguishes itself from sibling archive tools by specifying the resource type. However, it doesn't explicitly define what 'archive' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that the tool is a local introspection stub and hosted endpoint only, which sets expectations. But it provides no guidance on when to use this tool vs. sibling archive tools (e.g., archive_sd_ad_groups) or when to prefer preview over archive.
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?
No annotations provided, so description bears full burden. It discloses the tool is a guarded write and hosted endpoint, and notably states it is an introspection stub on a local server. However, no details on side effects, permissions, or response behavior beyond the stub 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?
Two sentences, no redundancy. Front-loaded with purpose, followed by critical context about being a stub. 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 no output schema and the stub nature, the description covers the tool's essential behavior. However, it omits what the stub returns or how to interpret responses, which would be helpful for an agent.
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%, providing full param descriptions. The description adds no extra meaning beyond the schema; it briefly mentions 'preview or archive' which maps to the preview parameter. Baseline 3 is appropriate.
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 previews or archives Sponsored Products negative targets, specifying both the resource and action. It distinguishes from siblings like 'archive_sp_negative_keywords' by naming 'negative targets', but could be more explicit about differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. alternatives like 'archive_sp_negative_keywords' or 'archive_sp_targets'. The note about being an introspection stub is useful but does not cover usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It labels the tool as a 'guarded write' and a stub, but lacks details on auth requirements, rate limits, or consequences of actual writes. The behavioral disclosure is 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 concise sentences: the first states purpose with context, the second clarifies this is a stub. No redundant information. Perfectly 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?
Given the tool has 5 parameters, no output schema, and is a guarded write, the description is too sparse. It fails to explain preview vs add logic, expected changes format, or any return behavior. For a stub, it's adequate but for actual use it's incomplete.
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 value by clarifying that 'preview' and 'dry_run' are aliases and that 'changes' are high-level. This enhances understanding beyond the schema alone.
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 can preview or add keywords, and the bracketed '[Ads / guarded write]' provides context. The name aligns with the action, and it's distinguishable from sibling tools like create_negative_keywords. However, it doesn't explicitly contrast with all similar tools.
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 mentions 'Preview or add keywords' and notes this is a stub, implying limited usage. It does not explicitly state when to use preview vs add, nor provide alternatives or exclusions, leaving some ambiguity for 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 no annotations, the description carries full burden. It discloses that the tool is a 'guarded write' and that it can preview or create, and notes it is a stub (local introspection). However, it lacks details on side effects, auth specifics, rate limits, or failure modes, which are important for a write 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 two sentences, concise and front-loaded with the category and action. However, the second sentence about the stub nature could be more integrated or clearer about its implication.
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 no output schema and no annotations, the description should cover return behavior, required permissions beyond 'guarded write', and the expected structure of the 'changes' parameter (array of objects). It fails to do so, leaving significant gaps for an agent 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 coverage is 100%, so the schema already describes all parameters. The description adds no additional meaning beyond what is in the parameter descriptions, meeting the baseline expectation.
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 resource ('Sponsored Display negative targets') and the actions ('Preview or create'), clearly distinguishing it from sibling tools like archive_sd_negative_targets and update_sd_negative_target_state. The category '[Ads / guarded write]' further contextualizes the tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives (e.g., when to use preview vs. create, or when to use this tool vs. archive_sd_negative_targets). The stub note is meta-context, not usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions it is a read tool (implied by '[Ads / read]') and a stub locally, but fails to detail rate limits, authentication requirements, or what happens upon invocation (e.g., returns mock 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 sentence that efficiently conveys purpose, scope, and deployment limitation. While brief, it contains essential information without redundancy.
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 tool has 7 parameters, no output schema, and no annotations, the description is insufficient. It does not explain the return format, pagination behavior, error handling, or the nature of 'lightweight filters', leaving the agent with significant gaps for correct usage.
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 baseline is 3. The description adds no further meaning to the parameters beyond what the schema already provides, such as format or constraints.
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 read tool for 'Off-Amazon Amazon Attribution performance', distinguishing it from other performance tools like get_campaign_performance. The '[Ads / read]' prefix and specific naming make the purpose unambiguous.
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 notes it is 'hosted endpoint only' and a 'local stdio server is an introspection stub', implying it should not be used locally. However, it does not provide explicit guidance on when to use this tool over other performance tools, nor does it list alternatives.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool is a read operation and a stub, but does not elaborate on other behavioral traits such as rate limits, authentication requirements, or what happens when called locally. Adequate but 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?
The description is two sentences with no wasted words. It efficiently conveys the tool's purpose and an important caveat (stub status).
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 7 optional parameters and no output schema. The description covers the return metrics broadly but omits details on output structure or pagination. Given it is a stub, completeness is acceptable but could be improved.
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 each parameter has a description in the schema. The tool description adds no additional meaning beyond the schema, such as highlighting required or commonly used parameters. Baseline of 3 is appropriate given high 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 it reads campaign health, spend, and ACOS metrics, and categorizes it as [Ads / read]. However, it does not differentiate from sibling tools like get_sb_campaign_performance or get_sd_campaign_performance, which could confuse an AI agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is a stub and hosted endpoint only, but provides no guidance on when to use this tool versus alternatives (e.g., more specific campaign tools). No exclusions or prerequisites are stated, limiting the agent's ability to decide correctly.
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 no annotations provided, the description does convey that it's a read operation (no destructive hint) and that it's a stub for introspection. It adds context about the data scope (live + historical). However, it does not disclose rate limits, authentication, or pagination behavior, which would be expected for a read 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 sentences, each serving a distinct purpose: stating the function and clarifying the hosting limitation. No unnecessary words or 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?
The tool has 7 parameters (all optional) and no output schema. The description only mentions live and historical pricing, which is adequate but does not specify the return format, data structure, or typical use cases. Given the complexity of pricing data and the number of parameters, the description could provide more context to help the agent decide when to invoke this 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 description coverage is 100%, so the schema already documents each parameter. The description adds no extra meaning beyond what is in the schema (e.g., no hints on which parameters are commonly used together or how they affect the output). Baseline 3 is appropriate as the description does not degrade parameter understanding.
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 reads 'Live price points plus historical pricing snapshots', indicating a specific verb and resource. However, it does not differentiate from sibling tools like get_offer_listings or get_buybox_status that also involve pricing, so it's not perfectly distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it's a 'Hosted endpoint only; this local stdio server is an introspection stub', which implies it's not functional locally. However, it provides no explicit guidance on when to use this tool versus alternatives (e.g., when historical pricing is needed vs. live prices).
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 discloses it is a stub and thus non-functional locally, but lacks details on side effects, permissions, or return behavior, especially with no annotations provided.
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, front-loaded sentences with no extraneous information; the second sentence adds important context about the stub nature.
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 no output schema and no annotations, the description adequately states the stub nature but lacks details on return format, when to use, and behavioral specifics, leaving 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?
All parameters are described in the schema (100% coverage), so the description adds no additional semantic value beyond what the schema already provides.
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 performs a live keyword rank check via catalog search, but does not differentiate from the sibling tool get_keyword_ranks, leading to potential confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_keyword_ranks, and the note about being an introspection stub may mislead about actual usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It mentions 'read' but does not disclose what the tool returns, side effects, permissions, or any restrictions beyond the environment limitation.
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 very concise, with one sentence plus a note. It front-loads the purpose and environment limitation, but it could be slightly more informative without losing conciseness.
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 no output schema and moderate complexity (7 parameters, nested objects), the description is incomplete. It fails to explain what the hosted endpoint returns, how line items are structured, or how parameters like filters work.
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 any extra meaning to the parameters beyond what is already in 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 it is for 'Per-order line items' under 'Inventory / read', specifying a verb and resource. It distinguishes from siblings like get_orders (orders) and get_product_details (products).
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 indicates it is a 'Hosted endpoint only' and that the local stdio server is an 'introspection stub', implying it should not be used locally. However, it does not explicitly state when to use it or provide alternatives.
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 declares it a read operation ('[Ads / read]') and states it is a stub in this environment, aligning with typical read-only behavior. However, with no annotations provided, the description fails to disclose other behavioral traits such as authentication requirements, rate limits, or whether it supports pagination. It is minimally transparent but not comprehensive.
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 extremely concise, consisting of one sentence that is front-loaded with the purpose. It uses keywords like '[Ads / read]' for quick scanning. However, the phrasing 'introspection stub' may be unclear to some users, and the brevity sacrifices some explanatory depth, warranting a score slightly below perfect.
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 tool has seven parameters, no output schema, and no annotations, the description is insufficiently complete. It does not explain the return value structure, pagination behavior, or provide any usage examples. An agent would lack critical context to invoke the tool correctly and interpret results.
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% parameter descriptions, so the schema itself adequately documents all seven optional parameters. The description adds no additional semantic information about the parameters, resulting in no extra value beyond the schema. Baseline 3 is appropriate.
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 retrieves 'Sponsored Products advertised-ASIN performance' with a read hint, distinguishing it from sibling tools like get_adgroup_performance or get_campaign_performance. However, it lacks explicit sibling differentiation and could be more precise about what performance metrics are included.
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 for reading ad performance data but provides no guidance on when to use this tool versus alternatives like get_keyword_performance. It notes the tool is a hosted endpoint and a local stub, which is helpful for understanding its availability, but doesn't offer explicit when-to-use or when-not-to-use advice.
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?
Despite no annotations, the description discloses that the tool is a stub and only works as a hosted endpoint, which is critical behavioral information. However, it does not mention output format, pagination, or typical read behavior.
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 short and to the point, but the second sentence could be more concise or integrated. It clearly front-loads the core purpose.
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 tool has 7 parameters, nested objects, and no output schema, the description is too minimal. It lacks information about return data structure, pagination, and relationships with sibling tools like 'manage_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 description coverage is 100%, so all parameters are already documented. The description adds no additional semantic value beyond the schema, resulting in a baseline score of 3.
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?
Purpose is stated as '[Inventory / read] FBA return records' which clearly indicates it retrieves FBA return records. However, the second sentence about it being an 'introspection stub' may confuse the agent about whether the tool is functional.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not mention when to use this tool versus alternatives like 'get_fba_inventory' or 'manage_returns', nor does it specify any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states the tool is a read operation and a stub, but omits details like return format, pagination, error handling, or auth requirements, leaving significant gaps.
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 extremely concise at one sentence, front-loading the purpose with no wasted words. However, it may be too brief given the tool's complexity.
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 7 optional parameters, no output schema, and many similar sibling tools, the description lacks crucial context about what entities are returned, how to filter effectively, pagination, and data fields. It is incomplete for effective usage.
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 adds minimal extra meaning, only noting that 'filters' are 'Optional lightweight filters supported by the hosted tool,' which echoes 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 this is a read operation for live Sponsored Products entity state from Amazon, using 'Ads / direct API read' and 'Live' to distinguish it from sibling tools that handle archives, creations, updates, or performance metrics.
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 mentions it is a 'Hosted endpoint only; this local stdio server is an introspection stub,' implying it is meant for hosted use, but it does not specify when to use this tool versus alternatives like other get_* tools or provide exclusions.
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 no annotations, the description carries the burden. It reveals the tool is a guarded write and is an introspection stub locally, but does not explain what 'guarded write' implies for permissions or side effects.
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 core functionality, and includes essential information without waste.
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 no output schema and no annotations, the description covers core purpose and the local stub limitation. However, it omits details about error conditions, prerequisites, and the nature of 'guarded write'.
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 each parameter is already explained in the schema. The description adds no further parameter details, which is acceptable but not improving.
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 states the tool is for previewing or updating ad group default bids, which is clear and specific. However, it does not explicitly differentiate from sibling tools like update_sd_ad_group_bid, which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions that the tool is a local stub for introspection, providing a technical limitation. There is no guidance on when to use this tool versus alternatives such as update_keyword_bids or update_target_bids.
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?
No annotations are provided. The description hints at guarded write and preview/validate behavior through the 'preview' and 'dry_run' parameters, and mentions audit logging with 'reason'. However, it lacks details on permissions, reversibility, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences), efficient, and front-loaded with the action. However, the brackets notation ('[Ads / guarded write]') is somewhat cryptic. Overall, it is concise but could be more informative.
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 5 parameters and no output schema, the description fails to explain key aspects: what the 'changes' array should contain, the difference between preview and dry_run, or which campaign type this tool applies to. The tool's complexity (flexible schema with additionalProperties) demands more explanation.
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 adds little beyond parameter names; it does not explain the 'changes' array structure or differentiate 'preview' from 'dry_run'. The description's mention of preview/change aligns with the parameters but adds minimal value.
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 action ('Preview or change daily campaign budget') and resource ('daily campaign budget'). It also identifies as an ads tool via '[Ads / guarded write]'. However, it does not distinguish between campaign types (SP, SB, SD), especially given sibling tools like update_sb_campaign_budget and update_sd_campaign_budget.
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 mentions that this is a 'Hosted endpoint only; this local stdio server is an introspection stub', implying it's used via a hosted API. It does not provide guidance on when not to use it or alternatives, such as the more specific sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions 'guarded write' and 'preview or set', which suggest preview and apply behavior, but does not explain what 'guarded' means, what the side effects are, or any failure conditions. The 'introspection stub' note indicates it may not perform real operations, but this is vague.
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, consisting of two short sentences. It front-loads the key action and resource in brackets and then adds necessary context. Every word is informative with 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?
Given the tool's moderate complexity (5 optional parameters, no required fields, no output schema), the description covers the high-level purpose but lacks details on expected behavior, return values, or prerequisites. The 'introspection stub' note is helpful context, but overall completeness is average. It does not explain how to use the 'changes' array or the effect of setting state.
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 default baseline is 3. The description adds some context with 'Preview or set', which aligns with the 'preview' and 'dry_run' parameters, but does not elaborate on other parameters like 'changes', 'reason', or 'marketplace_id'. The schema descriptions already cover their meanings, so the description provides no additional insight beyond that.
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 ('Preview or set') and the resource ('Sponsored Brands ad group state'). It distinguishes it from sibling tools like 'update_sd_ad_group_state' by specifying 'Sponsored Brands'. The verb-resource combination is 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance on when to use this tool. It mentions 'Hosted endpoint only' and 'introspection stub', hinting at testing scenarios, but does not explicitly state when to use it versus other tools like 'archive_sb_ad_groups' or 'update_sb_ad_state'. No alternatives or exclusions are 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 discloses that it is a 'guarded write' and an 'introspection stub', indicating limited functionality. However, it does not explain what happens on invocation (e.g., no actual updates) or detail the preview behavior.
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 short and front-loaded with the core purpose, but the structure could be improved by separating the stub note.
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?
For a tool with 5 parameters and no output schema, the description lacks completeness. It does not explain what 'preview' means, the structure of 'changes', or the stub's implications for 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?
All parameters have descriptions in the schema (100% coverage). The description adds no extra meaning beyond the schema, maintaining the baseline score.
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 action ('Preview or update') and resource ('Sponsored Brands target bids'), distinguishing it from sibling tools like update_target_bids or update_sd_target_bids by specifying the ad type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as other bid update tools for different ad types. The note about being a stub is not usage 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?
With no annotations, description carries full burden. It discloses the tool is a stub ('local stdio server is an introspection stub') and mentions 'guarded write'. However, it does not explain what guarded write entails or behavioral details like whether preview is non-destructive.
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?
Two sentences plus prefix, efficient and minimal. Every part adds context, though 'introspection stub' might be jargon.
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?
Lacks explanation of guarded write, expected response (no output schema), or specific state values. For a tool with 5 optional params, more detail on usage flow is needed.
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%, baseline is 3. Description adds value by linking 'preview' and 'dry_run' boolean to the preview behavior, but does not clarify the 'changes' array structure or required fields for state transitions.
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 operates on Sponsored Display ad groups with actions 'Preview or set' state. The prefix '[Ads / guarded write]' and explicit resource differentiation from siblings like update_sb_ad_group_state provide strong purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use preview vs set, or when to choose this tool over alternatives. The mention of 'Hosted endpoint only' hints at limitations but does not provide explicit usage context or exclusions.
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 no annotations, the description carries the burden. It mentions 'guarded write' and preview capability, but doesn't disclose side effects, permissions, or destructiveness. The 'introspection stub' note adds implementation context but not 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, efficient and front-loaded. The second sentence about 'introspection stub' is less relevant for tool usage but not overly distracting.
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 no output schema and 5 optional parameters, the description lacks details on return values, effects of the 'changes' field, and how to differentiate preview from archive actions. It misses essential usage 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 coverage is 100%, so baseline 3. The description adds minimal meaning beyond schema: 'Preview or archive' loosely maps to preview/dry_run, but doesn't explain the relationship or how 'changes' drives archiving.
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 'Preview or archive Sponsored Brands ads', specifying the action and resource. It distinguishes from sibling tools like 'archive_sb_ad_groups' by focusing on ads, though it doesn't explicitly name alternatives.
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 for ads vs. ad groups or campaigns, but provides no explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool is a '[Ads / guarded write]' and that this is a 'local stdio server [introspection stub]' – indicating it cannot actually perform the action. However, it does not explain consequences of archiving, authorization needs, or what 'guarded' means.
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 efficient sentence, front-loading key information ('Ads / guarded write', 'preview or archive', 'introspection stub'). Every part earns its place, though it could be structured slightly more explicitly.
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 5 parameters (0 required) and no output schema, the description covers basic purpose and the stub nature, but lacks depth on parameter use, common scenarios, or error handling. It is adequate but not comprehensive for the tool's 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%, so baseline is 3. The description does not add meaning beyond the schema; it merely repeats 'preview' without elaborating on parameter usage or relationships. No added value for parameter understanding.
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 can 'Preview or archive Sponsored Brands negative targets,' which matches the tool name. It distinguishes from siblings like 'archive_sb_targets' by specifying negative targets, but does not explicitly differentiate from other archive tools for different ad types.
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 for Sponsored Brands negative targets via the tool name and context, but offers no explicit guidance on when to use this tool vs alternatives, or when not to use it. No exclusion criteria or alternatives are mentioned.
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 no annotations, the description must disclose behavior. It states the tool can 'preview' or 'create', and labels it as 'guarded write', implying safeguards. However, it does not explain what 'guarded write' entails, what happens to existing data, or what the response looks like. The behavioral details are present but insufficiently detailed.
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 long, front-loads the purpose, and contains no redundant information. Every phrase serves a purpose: indicating the tool's action, scope, and limitations. Highly efficient.
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?
The tool has 5 parameters and no output schema, yet the description does not mention what the tool returns (e.g., the created ad group ID or preview results). It lacks context on error handling, idempotency, or the effect of setting both preview and dry_run. The description is too sparse given the tool's complexity and missing 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 description coverage is 100%, so the baseline is 3. The description adds little beyond what the schema already provides: 'Preview or create' aligns with the 'preview' and 'dry_run' parameters, and 'changes' is described as 'high-level desired changes'. No additional 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 explicitly states 'create Sponsored Brands ad groups', which is a specific verb+resource combination. It also mentions 'Preview or create', clarifying the dual capabilities. The tool is clearly distinguished from siblings like 'create_sp_ad_groups' by specifying 'Sponsored Brands'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention when-not-to-use, prerequisites, or comparisons with sibling tools like 'create_sp_ad_groups' or 'archive_sb_ad_groups'. The note about 'Hosted endpoint only' is informative but not a usage guideline.
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?
Without annotations, the description discloses that it is an '[Ads / guarded write]' and a 'local stdio server is an introspection stub', which are key behavioral traits. It does not detail the consequences of invoking the stub or the exact behavior of 'guarded write', but the disclosure is substantial.
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, efficient sentence that front-loads the core purpose and includes essential context about the stub nature. No wasted words.
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?
For a tool with 5 optional parameters, no required ones, and no output schema, the description is insufficient. It does not explain what the stub returns, what format the 'changes' parameter expects, or how the preview vs create logic works. Additional context is needed for effective use.
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 baseline is 3. The description adds no significant meaning beyond the schema descriptions for parameters like preview, dry_run, changes, etc. It does not clarify interactions between 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 the tool's purpose: 'Preview or create Sponsored Brands targets.' It also notes it is a stub, which differentiates from functional tools. However, it does not explicitly distinguish from sibling create tools like create_sb_negative_targets or create_sb_ad_groups, though the resource 'targets' is reasonably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use preview vs create, nor when to prefer this tool over alternatives (e.g., create_sb_targets vs create_sb_negative_targets). The stub nature is noted, but usage context is missing.
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 implies a read operation via the '[read]' tag and the nature of 'views,' but with no annotations provided, it lacks explicit disclosure of safety (e.g., no mutation conveyed). It also does not mention prerequisites, rate limits, or data sensitivity.
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 only two sentences, front-loaded with the purpose and key deployment detail, with no wasted words. It is appropriately concise for the tool's complexity.
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 tool has 7 parameters, no output schema, and no annotations, the description omits important context such as the structure of the fee breakdown, pagination behavior, or any error conditions. The brief purpose alone is insufficient for a full 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?
All 7 parameters are fully described in the input schema with clear descriptions, so the tool description adds no extra value beyond the schema. The baseline score applies because schema coverage is 100%.
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 retrieves financial event fee breakdown and profitability views, with a '[Finance / read]' tag indicating purpose. However, it does not explicitly differentiate from similar sibling tools like get_settlement_economics or get_profitability_review, leaving some ambiguity.
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 notes the tool is 'Hosted endpoint only; this local stdio server is an introspection stub,' which tells the agent it won't work locally but gives no guidance on when to prefer this tool over 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?
No annotations provided, so description carries full burden. It warns that this server is an introspection stub and the actual endpoint is hosted, which is useful. However, it does not explain what 'review topic trends' means or any aggregation behavior.
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-load purpose and scope, then clarify stub vs hosted. No wasted words.
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 100% schema coverage, the description lacks explanation of output format, meaning of 'review topic trends', and why an agent would choose this. The stub notice is helpful but incomplete for a tool with 7 parameters and no 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 detailed descriptions for all 7 parameters. The description adds minimal extra value beyond 'six-month review topic trends' which implies a time range, but parameters already allow custom dates.
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 starts with '[Catalog / read]' and 'Six-month review topic trends,' clearly indicating a read operation for review trends over a six-month period. It distinguishes from sibling tools like get_product_reviews or get_sales_and_traffic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description only notes it's a hosted endpoint stub, but does not explain use cases or when to choose it over other review-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only indicates a read operation via the '[Inventory / read]' tag and notes the tool is a hosted endpoint stub. Missing details like authentication, pagination, or return 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?
Two sentences, no fluff. Purpose is front-loaded in brackets. Efficiently communicates core function and environmental limitation.
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 7 parameters and no output schema, the description is minimal. It doesn't explain what suppressed/stranded listings entail, what data is returned, or how filtering behaves. Agents would lack sufficient context for effective use.
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 meaning beyond the schema; it merely restates the tool's purpose. No additional insight on parameters like 'filters' is provided.
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 retrieves suppressed and stranded listings under the Inventory/read category. This verb-resource combination is specific and distinguishes it from sibling tools like get_fba_inventory or get_inventory_health.
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 for suppressed and stranded listings but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives or exclusions, leaving the agent to infer context from the name alone.
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 discloses it is a 'guarded write' and an 'introspection stub,' indicating it does not execute real operations. However, it lacks details on side effects, required permissions, or what 'guarded' entails. Without annotations, the description carries the burden and is adequate but not rich.
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 and efficiently conveys purpose and key context. It is front-loaded with the action. A minor improvement could integrate the stub note more seamlessly, but overall it is concise and clear.
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 5 parameters, no output schema, and no annotations, the description covers the purpose and behavioral note but omits return format, error handling, or guard details. For a stub tool, it is adequate but incomplete for a production 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 coverage is 100% with all parameters described. The tool description adds minimal extra meaning beyond the schema, such as the 'changes' parameter described as 'high-level desired changes.' No additional constraints or usage tips are provided, so baseline 3.
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 previews or sets Sponsored Brands target state, with 'Ads / guarded write' providing context. It distinguishes from sibling tools like update_sb_target_bids by focusing on state rather than bids, but could be more explicit about the exact action (e.g., enabling/disabling).
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 mentions 'guarded write' and 'stub' providing some usage context, but does not explicitly state when to use this tool versus other update_* tools like update_sb_ad_group_state. No alternatives or exclusions are mentioned.
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?
With no annotations, the description carries full burden. It discloses the tool is a 'guarded write' with preview capability and crucially states it's a local stub that only works as a hosted endpoint. This prevents misuse but omits details like required permissions or post-write effects.
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 exceptionally concise, covering key points in a single sentence with a parenthetical qualifier. It front-loads the category '[Ads / guarded write]' for quick scanning, though it lacks structured formatting like bullet points.
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?
The tool has no output schema, requiring the description to explain return values, which it does not. It also fails to clarify the relationship between preview and dry_run parameters or how changes should be structured. The stub note is helpful but insufficient for full usability.
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 baseline is 3. The description adds no additional meaning to parameters beyond what the schema already provides. The parameter names and descriptions are self-explanatory, and the tool name gives domain 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 identifies the tool as handling negative keywords with verbs 'preview' and 'add'. It distinguishes itself from sibling tools by specifying the resource type (negative keywords vs negative targets) and notes it's an introspection stub, which sets clear expectations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like archive_sp_negative_keywords or create_sp_negative_targets. It lacks when-not-to-use directives and does not reference sibling tools for comparison.
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?
No annotations are provided, so the description must carry full weight. It mentions 'guarded write' and that the local stdio server is an 'introspection stub,' which is transparent about limited functionality. However, it does not detail side effects, permissions, or error behaviors for a full write operation.
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 brief (two sentences), front-loaded with the core action, and avoids extraneous details. The bracket prefix '[Ads / guarded write]' is slightly cryptic but not overly harmful; overall, each sentence earns its place.
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?
Without an output schema or annotations, the description should explain what the tool returns or effects. It only says 'preview or create' but gives no indication of output format, success indicators, or post-creation state. For a mutable tool, this is insufficient.
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 schema already documents all five parameters. The tool description adds no further semantic value beyond restating the purpose; 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 explicitly states 'Preview or create Sponsored Display ad groups,' providing a clear verb and resource. It distinguishes from sibling tools like archive_sd_ad_groups by mentioning both preview and creation, and notes its hosted endpoint nature, avoiding ambiguity.
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 this tool is for previewing or creating ad groups, but does not explicitly state when to use it vs alternatives like create_sd_campaigns or archive operations. No 'when-not' or alternative tool names are provided, leaving usage context somewhat implicit.
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 discloses it is a read-only operation and importantly flags that it is a hosted endpoint only, and the local server is an introspection stub. This is critical behavioral information.
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?
Very concise, front-loads important context in brackets, and every word is necessary. 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?
For a tool labeled as a stub, the description covers the basics. However, it lacks details on return format (no output schema) and does not explain the meaning of 'bid recommendations' in context. Given the stub nature, it is minimally acceptable.
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?
All 7 parameters have schema descriptions (100% coverage), so the baseline is 3. The tool description adds no additional insight into parameter usage beyond the schema.
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 explicitly states it provides 'live suggested bids' and labels it as an Ads/direct API read, clearly indicating its purpose. However, it does not differentiate from sibling tools like get_budget_recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description does not mention any prerequisites or limitations beyond being a stub.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It labels the tool as a 'guarded write' implying destructive action but does not explain what happens on success/failure, rate limits, authentication requirements, or any side effects. This is insufficient for a write operation with zero annotation support.
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?
Two sentences, front-loaded with '[Catalog / guarded write]' for quick classification. Efficient but could include brief behavioral notes 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?
No output schema is present, yet the description does not explain return values or error handling for a write tool. Critical details like response format or confirmation of price update are missing, making it incomplete for agent use.
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 good parameter descriptions. However, the tool description adds no additional meaning beyond the schema—e.g., what format the 'changes' array should have or how 'preview' vs 'dry_run' interact. Baseline 3 is appropriate as the schema does the heavy lifting.
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 submits listing price updates via the Listings Items API, specifically a guarded write for catalog operations. It distinguishes itself from sibling update tools like update_listing by focusing solely on price updates.
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 mentions it is a hosted endpoint only and that this local server is an introspection stub, providing context that it may not be functional locally. However, it does not explicitly state when to use this tool versus alternatives like update_listing or other update 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?
With no annotations, the description carries the full burden. It discloses the guarded write nature and that the tool is a stub, adding transparency. However, it does not explain the side effects of archiving (e.g., campaign state changes) or what 'guarded write' entails beyond preview support.
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—a single sentence with a brief tag and one note. It is front-loaded with the core purpose and avoids extraneous information. Every word earns its place.
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 lack of output schema and five parameters, the description is insufficient. It does not explain expected return values, the difference between preview and archive outcomes, or the implications of 'guarded write.' The stub note partially excuses functional details, but for an agent to invoke it correctly, more context is needed.
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 already provides detailed descriptions for all five parameters (100% coverage). The tool description adds the '[Ads / guarded write]' tag but does not enhance parameter understanding beyond the schema. Thus, the description offers minimal added value for 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 the tool previews or archives Sponsored Brands campaigns, distinguishing it from sibling tools targeting different ad types (SD, SP). The mention of 'hosted endpoint only; this local stdio server is an introspection stub' clarifies the tool's limited functionality, which slightly reduces clarity.
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 does not explicitly guide when to use preview vs archive or when to prefer this tool over alternatives like archive_sd_campaigns. The sibling list is extensive, and the description offers no differentiation criteria, leaving the agent to infer usage from the resource name alone.
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 no annotations, description carries full burden. Discloses it is a guarded write and a stub, but does not explain what 'archive' does (e.g., deactivate), side effects, or response behavior.
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 concise (one sentence plus note) and front-loads key info. Could be slightly more structured by separating purpose from behavior.
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 5 parameters, no output schema, and no annotations, description covers the stub nature but lacks detail on preview vs archive behavior, parameter interactions, and return value.
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. Description adds no additional meaning to parameters beyond what schema already 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?
Description clearly states verb 'Preview or archive' and resource 'Sponsored Display ad groups', distinguishing it from sibling tools like archive_sd_campaigns and archive_sd_targets. Also includes label '[Ads / guarded write]' for context.
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?
Provides important usage context by noting 'Hosted endpoint only; this local stdio server is an introspection stub', implying the tool is not functional locally. However, it lacks explicit guidance on when to choose this tool over siblings or when to use preview vs archive.
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?
With no annotations, the description provides key behavioral traits: 'guarded write' indicates safety mechanisms, and the note that this local server is an introspection stub for a hosted endpoint explains that it's not fully functional locally. This adds useful context beyond the basic function.
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, concise and front-loaded with the main purpose. However, the second sentence is somewhat cryptic and could be clearer about the stub nature.
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 5 parameters and no output schema, the description adequately states the purpose and guard mechanism but lacks details on expected output or how to distinguish preview versus create behavior. The sibling context is provided but not leveraged in the description.
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 adds no parameter-specific details beyond what the schema provides; it only mentions 'caller-supplied creative' and 'preview or create' at a high level.
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 is for previewing or creating Sponsored Brands ads with caller-supplied creative. It differentiates from siblings by mentioning 'guarded write' and that it's a hosted endpoint stub, though it doesn't explicitly contrast with other create tools like create_sb_ad_groups.
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 for previewing or creating SB ads but does not explicitly state when to use this tool versus alternatives (e.g., when to preview vs create, or vs archive tools). No exclusions or prerequisites are 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?
No annotations are provided, so the description must carry the behavioral disclosure. It labels the tool as a 'guarded write' (indicating potential authorization requirements) and explicitly states that the local server is an 'introspection stub' for a hosted endpoint. However, it does not detail what happens on invocation (e.g., error or description of the real call), rate limits, or state changes beyond creation.
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: a single sentence plus a clarifying suffix. It uses a bracketed tag for immediate context, then explains the stub nature. Every word serves a purpose, with no redundancy or filler.
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 having 5 parameters with 100% schema coverage, the description fails to provide crucial context for the open-ended 'changes' parameter (array of objects with additionalProperties). It does not specify expected input patterns, validation rules, or return values. The tool is a stub, but the description does not clarify what the agent should expect as a response, leaving gaps for effective use.
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%, with all parameters documented in the schema. The description adds no extra meaning beyond the schema; it only reiterates the 'preview or create' behavior, which relates to the 'preview' and 'dry_run' parameters. The schema handles the parameter explanations, so the description does not significantly enhance 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 verb-resource pair: 'Preview or create Sponsored Products ad groups'. It also includes the distinction 'Sponsored Products', differentiating it from sibling tools for SB and SD ad groups. The mention of 'hosted endpoint' provides additional context.
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 two modes (preview or create) but does not explicitly state when to use this tool over siblings like archive_sp_ad_groups or create_sb_ad_groups. There is no guidance on prerequisites or alternatives. The 'guarded write' tag hints at a write operation, but usage context is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions it's an introspection stub and hosted endpoint only, hinting at no side effects, but does not disclose rate limits, data sensitivity, or any other behavioral traits beyond that.
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: the first clearly states the purpose, the second clarifies constraints. It is concise, front-loaded, and includes no redundant information.
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 lists the outputs (marketplace scope, connection status, tool availability, next-step guidance). This is adequate for a low-complexity utility tool, though it does not explain how to use the 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 coverage is 100%, and the description does not add extra meaning beyond the schema. The parameters are optional and described generically in the schema; the description offers no additional context for their use.
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 returns marketplace scope, connection status, tool availability, and next-step guidance for the active API key. It also distinguishes itself as an introspection stub and hosted endpoint only, contrasting with sibling tools that perform specific actions like create, update, or get performance.
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 frames this as a utility for API key introspection, implying it should be used to understand available tools and scope. However, it does not explicitly state when to use it versus alternatives or provide exclusions, leaving some ambiguity.
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?
No annotations are provided, so the description must disclose behavior. It states it is a 'direct API read' (implying no side effects) and an 'introspection stub' (implying it may not be fully functional). However, it does not detail what happens when called (e.g., error or mock response).
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, front-loading the purpose. It is efficient but slightly terse; the technical note about introspection stub could be rephrased for clarity. Still, no waste.
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 (7 parameters, no output schema), the description is minimal. It explains the core function but does not elaborate on what 'eligibility for ad types' means, what ad types exist, or the output format. Adequate for a stub but incomplete for a fully functional 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?
All 7 parameters have descriptions in the input schema (100% coverage), so the baseline is 3. The description does not add additional semantics beyond the schema; it mentions ASIN but the schema already describes it.
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', the resource 'ASIN eligibility', and the domain 'ad types'. It also distinguishes itself by noting that it is a hosted endpoint (direct API read) and an introspection stub, setting it apart from sibling tools like get_fba_eligibility.
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 context that the tool is a stub and not the actual hosted endpoint, implying limited functionality but does not explicitly state when to use it or suggest alternatives. Some guidance is implied but not fully developed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states that the tool is a 'read' operation and a 'stub', but does not disclose data freshness, permissions, rate limits, or whether the tool returns live or historical data. This is insufficient for an agent to anticipate tool behavior.
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. Each sentence adds distinct value: the first states the purpose, the second provides a critical caveat about availability. No unnecessary words or repetition.
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 complexity of the tool (7 optional parameters, no output schema), the description is somewhat sparse. It does not explain what metrics are included in the performance breakdown or how to interpret results. However, the schema fully documents parameters, and the stub nature is clearly stated, providing situational 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%, so the input schema already describes all parameters. The description adds no additional meaning or context about the parameters beyond what is in the schema, earning a baseline score of 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 it provides an 'ad group level performance breakdown', which is a specific verb+resource combination. This distinguishes it from sibling tools like get_campaign_performance or get_keyword_performance by specifying the level of aggregation.
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 notes that it is a 'hosted endpoint only; this local stdio server is an introspection stub', which informs the agent that the tool is not functional locally. However, it does not provide explicit guidance on when to use this tool versus other performance tools, nor does it mention prerequisites or alternatives.
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 no annotations, the description partially covers behavior: it states it's a read operation and a stub. However, it does not detail other traits like authentication, rate limits, or what constitutes quality issues, leaving gaps.
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 that front-load the purpose and environmental context. No fluff or redundant information.
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 no output schema, the description lacks detail on return format and what quality issues entail. It is a stub, but as a standalone definition it leaves the agent without enough context to fully understand behavior.
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 basic descriptions. The tool description does not add extra meaning beyond the schema, so it meets the baseline but does not compensate for missing detail.
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 reads catalog listings with quality issues, using a specific verb and resource. It distinguishes itself by noting it's a hosted endpoint stub, which separates it from other get_ tools.
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 explains when to use (to list listings with quality issues) but does not provide guidance on when not to use or compare to alternatives. The note about the stub indicates limited functionality but lacks explicit usage context.
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?
With no annotations provided, the description carries full behavioral burden. It labels the tool as a 'direct API read' (read-only) and warns that the local server is a 'stub,' indicating limited functionality. This adds valuable context beyond the input schema.
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: the first clearly states purpose, the second provides hosting context. 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 7 optional parameters and no output schema, the description does not explain return values, behavior with multiple parameters, or pagination. The stub warning partially compensates, but completeness is low.
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?
Input schema coverage is 100% with descriptions for all 7 parameters. The description does not add any additional meaning or highlight critical parameters, so baseline 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 action ('Check'), resource ('FBA eligibility'), and scope ('per ASIN'), distinguishing it from sibling tools like get_ad_eligibility. The prefix '[Inventory / direct API read]' further clarifies it's a read-only inventory operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Hosted endpoint only; this local stdio server is an introspection stub,' which warns about limited local functionality but does not provide explicit guidance on when to use this tool versus alternatives, such as get_inventory_by_fulfillment_center, 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly states this is a read operation and explicitly declares that the local server is an introspection stub, not the actual hosted endpoint. This prevents misuse by agents expecting real data. However, it does not describe any potential side effects or output behavior.
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 with no superfluous words. It uses a clear bracket notation for domain/type and immediately states the 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the schema covering parameters, the description is incomplete. It does not describe the return format, pagination, or what the stub actually returns. With no output schema, the agent needs to know what data to expect, but the description only vaguely mentions 'completeness scores and issues'. Given the tool's complexity (7 parameters, nested objects), this is insufficient.
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 for all 7 parameters, so the schema itself provides full meaning. The description adds no parameter-specific information beyond what is already in the schema, so it doesn't elevate beyond the baseline of 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?
The description clearly identifies the tool as a read operation for listing completeness scores and issues, using specific verb 'get' and resource 'listing quality'. The bracket notation '[Catalog / read]' reinforces the domain and action. It distinguishes from sibling tools by focusing on listing quality rather than performance or inventory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus siblings or alternatives. It mentions it's an introspection stub for a hosted endpoint, which informs that the local server is not functional, but does not provide context on what scenarios call for listing quality data or how it differs from other get tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. While it notes the tool is a 'read' and a 'stub', it lacks details on data freshness, pagination, rate limits, or what metrics are returned, leaving the agent underinformed.
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: first states the core operation, second clarifies the stub nature. No unnecessary text or repetition.
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 7 optional parameters and no output schema, the description is too vague, providing no information about return values, metric types, or how filters affect results. This leaves a significant gap 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 100%, with each parameter having a basic description. The tool description adds no additional context beyond 'Sponsored Display campaign metrics' and does not clarify parameter relationships or usage patterns.
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 reads Sponsored Display campaign metrics, and the '[Ads / read]' prefix plus the tool name distinguish it from siblings like get_sb_campaign_performance or get_campaign_performance.
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 this is a hosted endpoint stub for introspection, implying it is not for actual campaign metric retrieval locally. It distinguishes itself by specifying 'Sponsored Display', but does not explicitly contrast with other performance 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?
Although no annotations are provided, the description explicitly states that the tool is a 'hosted endpoint only' and an 'introspection stub', indicating it is not fully functional in the local environment. This critical behavioral trait is disclosed, though other aspects like permissions or rate limits are not mentioned.
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 at two sentences, with no wasted words. The first sentence defines the function and the second reveals the stub limitation, making key information easily accessible.
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 lack of output schema and annotations, the description should compensate with details on return values and parameter effects. It does not explain the output format or how parameters like filters or date ranges influence results, leaving significant gaps for the agent.
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 for all 7 parameters, so the schema already documents parameter semantics. The description adds no extra meaning beyond the schema, resulting in a baseline score of 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?
The description clearly states the tool's purpose: 'MCF shipping options and cost estimates' and specifies it is a read operation. This distinguishes it from sibling tools like 'create_mcf_order' or 'get_mcf_orders' by focusing on previewing options rather than creating or retrieving orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other tools, such as 'get_mcf_orders' for actual orders or other fulfillment tools. It also does not mention any prerequisites or exclusions, leaving the agent to infer usage context from the name and 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?
The description labels the tool as '[Ads / guarded write],' indicating it requires certain permissions and may have safeguards. It mentions 'Preview or set' behavior, with preview and dry_run parameters enabling validation. However, it does not disclose the exact effects of setting the state (e.g., immediate vs. queued, reversible vs. irreversible) or detail any destructive implications. The note about being a stub is helpful but incomplete.
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 short sentences that cover purpose and a critical behavioral note (the stub nature). Every word is necessary, and the structure is front-loaded with the core action and context.
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 complexity of the input (an array of objects with additionalProperties: true) and no output schema, the description is insufficient. It does not explain how to structure the 'changes' array, what valid state values are, or the implications of setting vs. previewing. The note about being a stub is valuable but does not compensate for the lack of guidance on making effective use of 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%, so the baseline is 3. The description elaborates on the preview/dry_run parameters as aliases for validation behavior. It describes the 'changes' parameter as 'High-level desired changes for the hosted guarded write tool,' which adds some context but remains vague. No additional meaning is added for the reason or marketplace_id parameters, which are self-explanatory.
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: 'Preview or set Sponsored Products negative target state.' It identifies the specific ad type (Sponsored Products) and resource (negative target state), and distinguishes from siblings like update_sb_negative_target_state (for Sponsored Brands) and update_sd_negative_target_state (for Sponsored Display).
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 mentions this is a 'Hosted endpoint only' and an 'introspection stub,' which provides context that it is not a live tool in this environment. However, it does not provide explicit guidance on when to use this tool versus alternatives like create_sp_negative_targets or archive_sp_negative_targets. The usage is implied by the tool's name and type but lacks direct comparison.
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 discloses that the tool is a 'guarded write' allowing preview before archiving, and clarifies it is an introspection stub. This adds behavioral context beyond the absent annotations, though it omits details like reversibility or side effects.
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-loading the category and core action. It is concise and avoids redundancy, though the stub clarification could be more prominently placed.
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?
No output schema exists, and the description provides no information about return values, error handling, or the expected structure of 'changes'. For a tool with 5 parameters, this is insufficient 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%, so baseline is 3. The description's mention of 'preview or archive' loosely aligns with the 'preview' and 'dry_run' parameters but does not explain other parameters like 'changes' or 'reason' in detail.
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 explicitly states 'Preview or archive Sponsored Display campaigns', providing a specific verb and resource. It distinguishes from sibling tools by focusing on SD campaigns and including a preview capability.
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 notes 'Hosted endpoint only; this local stdio server is an introspection stub', cautioning that the tool is non-functional on this server. However, it does not explicitly guide when to use this tool versus alternatives like 'archive_campaigns' or other archive 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?
The description tags the tool as '[Ads / guarded write]', indicating authorization requirements, and states it is a stub. However, without annotations, it fails to detail behaviors such as how preview differs from archiving, reversibility, or side effects.
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 that efficiently conveys the purpose and context, with no extraneous 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 schema covers parameters and the description notes this is a stub, it lacks information about the output or return values. For an introspection stub, this may be acceptable, but it could be improved by clarifying what preview/archive results look like.
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?
All 5 parameters have schema descriptions (100% coverage), so the schema already defines their meanings. The tool description adds no additional context about 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's action ('preview or archive') and the resource ('Sponsored Products targets'). It distinguishes itself from sibling tools like 'archive_sp_negative_targets' by specifying 'Sponsored Products' targets.
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 notes that this is a 'hosted endpoint only' and an 'introspection stub', implying it's not functional in this environment, but it does not provide explicit guidance on when to use this tool versus alternatives like archive_sp_negative_targets.
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 notes 'Preview or create' and 'guarded write', implying two behaviors and safety measures, but does not detail what happens on create or how preview differs. Annotations are absent, so the description carries the burden but fails to fully disclose behavior.
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 that efficiently convey purpose and modality. No redundant or extraneous content.
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 5 parameters and no output schema, the description should offer more guidance on when to use preview vs create and the expected format of 'changes'. As a stub, it partially fulfills but leaves gaps for an agent.
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 parameter descriptions exist. However, the description adds meaning for 'dry_run' as an alias and 'changes' as 'high-level desired changes', which provides context 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 'Preview or create Sponsored Brands negative targets,' giving a specific verb and resource. It distinguishes from siblings like 'archive_sb_negative_targets' and 'create_sb_targets' by focusing on negative targets and includes context of 'hosted endpoint' and 'introspection stub'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description mentions it is a 'hosted endpoint only' stub but does not compare to sibling tools like 'create_sb_targets' or 'archive_sb_negative_targets'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only mentions it's a utility and a stub, but does not describe side effects, permissions, return values, or whether the action is reversible. For a create tool, this is insufficient.
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 with no wasted words. It front-loads the purpose and includes essential context about the stub server.
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 stub nature, the description is adequate but lacks details about the created report's properties, lifespan, and how the secret link works. The absence of an output schema is not compensated for by the description.
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 both parameters. The description adds usage context but no new meaning to the parameters beyond what the schema provides, satisfying the baseline.
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 a secret-link public snapshot report after explicit user request to publish/share. It distinguishes from sibling tools like delete_shareable_report and update_shareable_report, and identifies itself as a utility stub.
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?
It specifies the tool should be used only after the user explicitly asks to publish or share, and notes that this local server is an introspection stub. However, it does not explicitly state when not to use it or provide 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?
No annotations are provided, so the description carries the full burden. It discloses the tool is read-only and notes the local server is an introspection stub, which sets expectations. However, it does not mention authentication requirements, rate limits, or whether outputs are real-time or cached, leaving gaps 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?
Two concise sentences with clear front-loading of purpose. Every sentence adds value: the first defines the tool, the second clarifies its environment. No wasted text.
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 7 parameters (all optional), no output schema, and no annotations. The description covers the purpose and stub nature but does not explain what the output looks like, how filtering works, or whether pagination is supported. A more complete description would outline return structure or example usage.
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 baseline is 3. The description does not add additional meaning beyond the schema descriptions; it only restates the tool's purpose. No parameter relationships or examples are provided.
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 provides per-ASIN profitability across fees, returns, and ad spend, using a specific verb ('get') and resource ('profitability review'). It distinguishes itself from sibling tools like get_financial_events or get_settlement_economics by focusing on aggregated profitability metrics.
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 notes the tool is a read operation and local stub, implying limited functionality, but does not explicitly state when to use this tool versus alternatives such as get_settlement_economics or get_financial_events. Usage context is implied but not contrasted with 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?
Discloses that the tool is a read-only operation ('Live and historical status') and clarifies it is an 'introspection stub' calling a hosted endpoint. This provides useful behavioral context beyond the missing 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 efficient sentences: first defines the tool's purpose and scope, second clarifies its stub nature. No redundant 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?
For a read tool with no output schema, the description lacks details on the return format or content of offer status. While sufficient for basic selection, further context would be helpful.
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?
All 7 parameters have schema descriptions (100% coverage), so the description adds no additional meaning. The baseline of 3 applies as the schema already documents 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 is for reading 'Live and historical Subscribe and Save replenishment offer status', specifying a verb (get), resource (replenishment offers), and context (Subscribe and Save). It distinguishes from sibling tools by targeting a specific inventory domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_inventory_health or get_fba_inventory. The description only states it's a hosted endpoint stub, which is behavioral, not usage advice.
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 no annotations provided, the description carries the transparency burden. It discloses that the local instance is a stub, which is critical behavior. However, it omits details about authentication, rate limits, error behavior, or the fact that it is a read-only operation (though implied by '[read]').
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 only two sentences, front-loaded with the core purpose and critical caveat. Every word 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?
For a tool with 7 parameters and no output schema, the description covers purpose and a key behavioral constraint (stub). However, it lacks description of return values, error handling, or guidance on common use cases, leaving some 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 100%; all 7 parameters have adequate descriptions. The description adds no extra meaning beyond 'market share and conversion data', so it meets the baseline for high coverage without adding value.
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 'Market share and conversion data' for search queries, using a verb-resource structure ('read'). It distinguishes from sibling 'get_' tools by specifying the data type, and the prefix '[Ads / read]' clarifies domain and action.
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 notes the tool is 'Hosted endpoint only; this local stdio server is an introspection stub', implying it should only be used via the hosted endpoint. However, it does not explicitly guide when to use this tool over siblings like get_campaign_performance or get_keyword_performance.
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 no annotations, the description carries the full burden. It discloses the guarded write nature and stub status, but does not explain what 'guarded' entails (e.g., auth requirements, rate limits) or preview behavior.
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 with no wasteful words: first states purpose, second provides critical context about the stub nature. Very concise and front-loaded.
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 adequately explains this is a stub, but without an output schema, it does not describe return values or behavior of preview vs. set, leaving gaps for an agent fully utilizing 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 description coverage is 100%, so baseline is 3. The tool description adds no extra context beyond the schema; the parameters are well-described in the schema itself.
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 'Preview or set' and the resource 'audience bid adjustments', which is specific and distinguishes it from siblings like update_campaign_bidding or update_target_bids.
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 notes this is a stub for a hosted guarded write, implying it is not fully functional locally and should be used via the hosted endpoint for real operations, but does not provide explicit when-to-use or alternatives 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?
With no annotations, the description carries full burden. It discloses 'guarded write' and 'preview' behavior, and notes the tool is an introspection stub (not fully functional). This adds important context beyond the schema, though more details on side effects or authorization would improve it.
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?
Two sentences, each serving a purpose: first defines core action, second adds technical context. No filler, but the second sentence is somewhat jargon-heavy ('introspection stub') which may hinder clarity for some 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?
Given no output schema and moderate complexity (preview vs. apply, guarded write), the description omits expected responses, failure modes, permission requirements, and lifecycle details. The agent would struggle to use this tool effectively without external knowledge.
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 baseline is 3. The description adds minimal extra meaning beyond parameter descriptions (e.g., 'high-level desired changes' is vague). It does not significantly enhance understanding of parameter usage or constraints.
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 explicitly states 'Preview or update Sponsored Display campaign budgets', clearly identifying the action and resource. The '[Ads / guarded write]' prefix and 'Hosted endpoint only' distinguish it from sibling tools that may operate on other ad types or endpoints.
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 mentions preview vs. update and notes it's a stub, providing some context. However, it fails to explicitly state when to use this tool over siblings like update_campaign_budget or update_sb_campaign_budget, nor does it specify exclusions 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?
No annotations are provided, so description carries full burden. Discloses guarded write and preview capability, but does not detail side effects, required permissions, rate limits, or consequences. The term 'guarded write' adds some safety context but insufficient for full 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?
Very concise: two sentences covering purpose and environment. Front-loaded with category and action. Efficient but could include slightly more detail on usage 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 no output schema and 5 parameters, the description is too minimal. It does not explain return values (e.g., preview results or success confirmation), error conditions, or prerequisites for the write operation. The stub note helps but leaves significant gaps for a tool that mutates state.
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 adequate parameter descriptions. The tool description adds no additional parameter context, so baseline score applies.
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 ('Preview or set') and resource ('Sponsored Display campaign state'). Differentiates from sibling tools targeting budget, ad groups, or other ad types (SB, SP) and from state updates on other entities.
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?
Mentions use cases: preview and set. Indicates it's a guarded write for Ads, and that it's a hosted endpoint (not a local stub). However, lacks explicit when-not-to-use or direct comparison to alternatives like other state-update 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?
Discloses key behavioral traits: 'guarded write' implies a cautious mutation, and 'introspection stub' clarifies it is non-functional locally, which is critical for an agent. No annotations exist, so description carries full burden.
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 brief but informative, front-loading purpose and guard. Could be slightly more structured but remains 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?
Adequate for an introspection stub, but lacks details on return values or side effects for the actual hosted tool. No output schema exists to compensate.
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 has 100% description coverage for all 5 parameters, so description adds no extra meaning beyond what is already in 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?
Description explicitly states the tool's action ('Preview or archive') and target resource ('Sponsored Brands targets'). Differentiates from sibling tools like 'archive_sb_negative_targets' by specifying positive targets.
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?
Indicates it is a hosted endpoint and an introspection stub locally, implying when to use (for hosted SB targets) but does not explicitly state 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?
No annotations provided, so description carries the burden. Clearly states it's a read operation via '[Inventory / read]' and discloses it is a hosted endpoint only and an introspection stub. This is a key behavioral trait, but lacks details on authentication 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?
Two sentences, no fluff. The first states purpose, the second provides critical context about hosting and stub nature. Every word 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?
Given 7 parameters, no required fields, nested objects, and no output schema, the description gives a good high-level view including the hosted/stub limitation. It could mention what the response typically contains, but is largely sufficient.
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 description adds no extra parameter information beyond what is in the schema, so baseline 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?
Description starts with '[Inventory / read]' specifying domain and operation, and names the resource as 'Active listing registry, search, and brand ASIN views.' This clearly distinguishes it from sibling tools like get_listing_quality or get_listing_restrictions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. Mentions it's a hosted endpoint only and a local stub, implying limited functionality, but does not state when to prefer this over other read 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?
No annotations exist, but the description discloses the tool is a read operation and explicitly states it's an introspection stub not functional locally. This provides important behavioral context beyond basic purpose.
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 with no wasted words. First sentence covers purpose, second provides critical context about hosting. Highly concise.
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 7 parameters and no output schema, the description lacks information on output format, pagination, filter usage, or what data is returned. This leaves the agent with significant uncertainty.
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 no additional meaning beyond what the schema provides. 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 identifies the tool as reading live seller offers for an ASIN, specifying it's a read operation and a hosted endpoint stub. This distinguishes it from sibling mutating tools.
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 is only for hosted environment due to stub nature, but lacks explicit when-to-use or alternatives among siblings. No guidance on when to use this tool versus similar read 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?
Without annotations, the description carries the full burden. It discloses that the tool is read-only via the 'read' tag and warns that this local server is an introspection stub for a hosted endpoint, making the behavioral limitation clear. It does not detail auth or rate limits, but for a stub, the transparency 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 extremely concise: two sentences (plus a tag) with no filler. It front-loads the read tag and key items, and every word serves a purpose.
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 7 optional parameters and no output schema, the description is too sparse. It does not explain how to use parameters like filters or limit, nor does it describe the return format. The stub warning is useful but leaves gaps for a production 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 coverage is 100% with all parameters described, so baseline is 3. The description adds no extra meaning beyond the schema, such as how to use start_date or end_date together, so no improvement over baseline.
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 explicitly states it reads product info, images, dimensions and is tagged as '[Catalog / read]'. It clearly differentiates from sibling tools like get_order_details or get_inventory_health, which cover different domains.
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 the tool is for product details but does not explicitly state when to use it over other get_ tools or when not to use it. The note about being a stub provides some context, but lacks direct comparison to alternatives.
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?
No annotations are provided, so the description carries the burden. It implies a read operation (non-destructive) but does not disclose other behaviors like authentication needs, rate limits, or data format. The stub limitation is noted, but more detail would improve 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 two sentences with no redundant information. It efficiently conveys the purpose and a key limitation, making it concise and well-structured.
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 the schema covering parameters, the description lacks information on return values, pagination, or any behavior beyond being a stub. With no output schema and no annotations, more context is needed for full usability.
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 parameters, so the description adds little beyond that. It does not provide additional meaning beyond what the schema already offers, resulting in a baseline score.
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 specifies the tool reads FBA reimbursement records under the Inventory category. The verb 'read' and resource 'reimbursements' are explicit, distinguishing it from sibling tools that handle other 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?
The description states it's a hosted endpoint only and the local server is an introspection stub, which guides the agent to not rely on local execution. However, it lacks direct comparison to alternative tools for reimbursements.
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?
With no annotations, the description carries full burden. It discloses the tool as a 'guarded write' that can preview updates, and reveals it is a stub on the local server. This adds valuable context about safety and availability, though it does not detail authentication needs 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 two concise sentences, each adding unique value: the first states purpose, the second provides critical deployment context. No unnecessary words or redundancy.
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 having no output schema and 5 parameters, the description does not clarify what preview returns, which parameters are required for update vs preview, or the tool's full behavior. The stub status is noted, but essential operational details are missing, leaving the agent underinformed.
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 parameters are already well-documented. The description adds no additional meaning beyond the schema; it only reiterates the tool's purpose. Baseline 3 is appropriate as the description does not compensate for any existing gaps.
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 explicitly states 'Preview or update Sponsored Display ad group default bids,' clearly identifying the verb (preview/update) and resource (SD ad group default bids). It distinguishes from siblings like 'update_adgroup_bid' (likely for SP) and 'update_sd_target_bids' (for targets).
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 notes 'Hosted endpoint only; this local stdio server is an introspection stub,' advising that the tool is not fully functional locally. However, it does not provide guidance on when to use this tool versus alternatives like 'update_adgroup_bid' or 'update_sd_ad_group_state,' limiting its helpfulness for tool selection.
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 no annotations, the description carries full burden. It discloses the tool is a 'guarded write' and a local 'introspection stub', which is important behavioral context. However, it does not explain how the stub behaves (e.g., mock responses), what guardrails exist, or any side effects beyond being a stub.
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 that front-loads the key action ('Preview or set...') and includes important context (guarded write, hosted endpoint, stub). No unnecessary words or repetition.
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 the tool being a complex 'introspection stub', the description lacks details on how the stub works (e.g., whether it returns static data or errors) and what the 'guarded write' implies. No output schema exists, so more behavioral context is needed for a write 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 100%, so baseline is 3. The description adds value by clarifying that 'preview' and 'dry_run' are aliases for validation/preview mode, and 'changes' represents 'high-level desired changes'. This enhances meaning beyond the schema's generic 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 identifies the tool as previewing or setting Sponsored Display negative target state, with a specific verb and resource. It distinguishes itself from sibling tools like update_sd_target_state (targets vs negative targets) and update_sb/sp_negative_target_state (different ad types).
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 for Sponsored Display negative targets and mentions 'Hosted endpoint only' and 'introspection stub', but provides no explicit guidance on when to use this tool over similar tools (e.g., update_sd_target_state or update_sb_negative_target_state). No alternatives or exclusions are stated.
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 'guarded write' and 'preview' capabilities and notes it is an 'introspection stub,' which provides behavioral context beyond the no-annotation baseline. However, it does not disclose permissions, side effects, or rate limits. For a creation tool, more detail on what actions are guarded and what happens on write would improve 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 two sentences long, front-loading the core purpose in the first sentence and adding essential context in the second. No redundant words. The use of brackets and slashes is compact but clear.
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 (5 optional params, no output schema, no annotations), the description could offer more details on the 'changes' parameter structure and return values. It adequately explains the stub nature and preview capability, but lacks complete guidance on what the tool returns or how to structure changes.
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 100% schema coverage, each parameter already has a clear description. The tool description does not add new meaning to individual parameters beyond the schema. It provides overall context (preview vs. create, hosted stub) but that is separate from 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 is for 'Preview or create Sponsored Products campaigns,' specifying the verb (preview/create) and resource (Sponsored Products campaigns). This distinguishes it from sibling tools for other ad types (e.g., create_sb_campaigns) and from other operations like archive or get.
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 implies when to use it (for Sponsored Products campaigns) through the resource name and context, but it does not explicitly exclude alternatives or provide when-not-to-use guidance. An explicit mention of 'use this for SP, not SB or SD' would elevate it to 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 declares read-only behavior via the '[Ads / read]' prefix and explains that it is a local stub for introspection, not a full implementation. This adds important behavioral context beyond the name. However, without annotations, it could further clarify that no destructive actions are taken, but the read nature is clear.
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, highly concise, and front-loads the core purpose. Every word earns its place: '[Ads / read]' for type, 'SP/SB/SD root cause analysis' for domain, 'between date ranges' for scope, and the stub disclaimer for context.
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 7 optional parameters, no output schema, and no annotations. The description explains the tool's purpose and local limitation but does not describe what the output contains (e.g., what root cause analysis results look like). Since the agent cannot infer return structure, the description falls short of full 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?
The input schema has 100% parameter description coverage, with clear descriptions for each field (e.g., start_date, end_date, asin, sku). The tool description adds no additional meaning beyond the schema, such as how parameters influence root cause analysis output. Baseline 3 is appropriate given high 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 it's a read tool for ads root cause analysis (SP/SB/SD) by date range. The verb 'diagnose' is implicit in the name but reinforced by the phrase 'root cause analysis'. It distinguishes from sibling tools like get_campaign_performance by focusing on diagnosis rather than raw metrics.
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 notes the tool is only functional on a hosted endpoint and is a stub locally, which is useful guidance. However, it does not explicitly state when to prefer this tool over other performance analysis tools (e.g., get_campaign_performance, get_keyword_performance), leaving ambiguity for the agent.
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?
With no annotations provided, the description bears full responsibility for disclosing behavior. It explicitly states the tool is an introspection stub and hosted-endpoint-only, signaling limited local functionality. It does not, however, detail other behaviors like pagination, rate limits, or authentication.
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 convey purpose and deployment context. No redundant or filler content; every word 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?
Despite good schema coverage, the description lacks details on return values (no output schema) and does not explain how the stub behaves locally (e.g., mock data vs. errors). It provides enough context for basic understanding but leaves gaps for practical use.
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 having a description in the input schema. The tool description adds no extra meaning beyond what the schema already provides, meeting the baseline for high 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 reads A+ Content status and associated ASINs, with a '[Catalog / read]' prefix that distinguishes it as a read operation in the Catalog domain. It also clarifies that it's a local stub, not the hosted endpoint, which adds precision.
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 via 'Hosted endpoint only; this local stdio server is an introspection stub,' but does not explicitly state when to use this tool versus alternatives among the many sibling tools. No exclusion criteria or alternative recommendations are given.
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?
With no annotations provided, the description carries the full burden. It clearly discloses that the tool is a stub, which is a critical behavioral trait. It does not mention side effects or rate limits, but the stub disclosure is sufficient given the 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 very concise: two sentences front-load the purpose and the stub nature. Every word contributes value without 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 the tool's stub nature, the description is adequate for an introspection scenario. However, for a real tool, it would be incomplete as it does not describe return values or the meaning of the funnel/benchmarks. The nested filters object and 7 parameters are not elaborated beyond the 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 description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for the 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 states 'Brand Metrics funnel and peer benchmarks' and labels it as an Ads/read tool, which clearly indicates the tool's purpose. The name and description together distinguish it from sibling tools like get_campaign_performance. However, it could be more explicit about the exact data returned.
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 notes that this is a 'Hosted endpoint only; this local stdio server is an introspection stub,' which clearly tells the agent that the tool cannot be invoked locally and is only for introspection. This provides clear context for when not to use it, but lacks explicit guidance on when to use 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?
With no annotations, the description clearly states it is a read-only operation ('read') and explicitly warns it is a stub for introspection only, which sets expectations accurately. However, it does not detail rate limits, authentication, or the behavior of the hosted endpoint.
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?
Extremely concise: two sentences covering purpose and deployment context with no filler. Every word 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 the complexity (7 parameters, nested filters, no output schema), the description is adequate for a stub but lacks details on output format, pagination, or error handling. The explicit stub warning partially compensates.
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 the schema. It provides high-level context (e.g., 'order, line item, and creative metrics') but does not explain parameter nesting or special filter behavior, earning the baseline score.
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 it retrieves Amazon DSP metrics for orders, line items, and creatives. The prefix '[Ads / read]' specifies it's a read operation, and it distinguishes from sibling tools like get_dsp_advertisers_live or get_campaign_performance by focusing on DSP performance data.
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?
Provides an important usage constraint by noting the tool is a hosted endpoint and this local server is an introspection stub, preventing misuse. However, it does not mention when to use this tool versus alternatives like get_campaign_performance or give criteria for exclusion.
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?
With no annotations, the description bears full transparency burden. It discloses the read nature, the risk categories, and the stub status. This is sufficient for an agent to understand the tool's behavior and limitations, though it could mention that no data is returned locally.
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: the first states purpose and scope, the second notes hosting constraint. No unnecessary words, well-structured and front-loaded.
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 7 optional parameters and no output schema, the description could elaborate on what 'at risk' entails or how filters interact. The stub note reduces expectations but still leaves gaps about expected 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 coverage is 100% with each parameter having a description. The tool description adds no additional meaning beyond what the schema already provides (e.g., 'Optional start date for time-range reads'). 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 starts with a clear tag '[Inventory / read]' and specifies 'SKUs at risk: low stock, overstock, aged, or stranded'. This clearly identifies the tool as a read operation for risky inventory, distinguishing it from sibling tools that handle archives, creates, updates, etc.
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 notes 'Hosted endpoint only; this local stdio server is an introspection stub', informing the agent that this tool is not functional locally. However, it does not provide explicit guidance on when to use this tool versus other inventory-related get_* tools (e.g., get_fba_inventory, get_inventory_health) or specify prerequisites.
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?
With no annotations, the description must disclose behavior. It clearly states '[Ads / read]' (read-only) and 'Hosted endpoint only; this local stdio server is an introspection stub,' which is a critical behavioral trait. It does not detail pagination or authentication, but the stub nature is adequately communicated.
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 that front-load the purpose and then clarify the hosting context. Every sentence adds value without 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 the tool has 7 optional parameters and no output schema, the description provides high-level purpose and stub status but omits expected return structure. For an agent to fully understand invocation, more detail on output format would be beneficial, but the description is adequate for an introspection stub.
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 adds no further meaning to parameters beyond what the schema already provides. It does not elaborate on how parameters like 'filters' or 'limit' affect results.
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's a read operation for Sponsored Products portfolio-level performance rollups, distinguishing it from other performance tools (e.g., get_campaign_performance, get_adgroup_performance). The '[Ads / read]' tag and mention of 'Sponsored Products' provide specific verb-resource-scope clarity.
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 for portfolio-level Sponsored Products performance but does not explicitly state when to use this tool versus alternatives. It mentions 'Hosted endpoint only' which hints at environment restrictions but lacks direct guidance on tool selection among many sibling performance 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?
No annotations are provided, so the description carries the burden. It indicates the read nature and the local stub limitation, but lacks details on authentication, rate limits, or specific behavioral traits beyond that.
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, then critical constraint. Every word earns its place with no redundancy or 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?
Given the tool has no output schema and 7 optional params, the description is minimal. It does not explain what the output represents or how to interpret results, leaving gaps for an agent.
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 parameters are already well-documented in the schema. The description adds no extra meaning to the 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 it reads search queries with ad coverage, and the '[Ads / read]' prefix clarifies the domain and operation. It distinguishes from siblings by focusing on ad coverage rather than performance or specific campaign entities.
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 'Hosted endpoint only; this local stdio server is an introspection stub,' informing users that the tool is not fully functional locally. However, it does not compare to similar search tools like get_search_query_performance or provide explicit when-to-use 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?
With no annotations provided, the description carries the full burden. It discloses that the tool performs a read operation ('direct API read') and that locally it is an 'introspection stub', meaning it will not actually fetch data. This transparently sets expectations about behavior, though it omits details on rate limits or authentication.
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, consisting of two sentences that front-load the core purpose and key limitation. Every word is necessary, with no fluff or repetition. It efficiently communicates the essential 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 has 7 optional parameters, a rich set of sibling tools, and no output schema, the description is minimal. It covers the purpose and stub limitation but lacks details on the output structure, the differences between SP/SB/SD entities, or how to effectively use the parameters. It is adequate but not 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?
The input schema has 100% description coverage, with each parameter including a short description. The tool description adds no further parameter-level details beyond what the schema provides, so it meets the baseline without adding extra value.
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 'direct API read' for 'Live SP/SB/SD entity state from Amazon', specifying the verb (read), resource (entity state), and scope (SP/SB/SD). This distinguishes it from the sibling tool get_sp_entities_live, which likely covers only SP, by explicitly including SB and SD.
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 notes that the tool is a 'Hosted endpoint only; this local stdio server is an introspection stub', providing context that it works only on the hosted endpoint and is non-functional on local. However, it does not explicitly state when to use this tool over alternatives like get_sp_entities_live or other read tools, nor provide exclusions or prerequisites.
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?
Despite no annotations, the description discloses two key behaviors: it is a read-only operation ('read') and that it is merely a stub locally. This goes beyond what annotations would provide, though it does not detail response characteristics.
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 efficiently convey purpose, read status, and the critical stub limitation. No redundant or extraneous 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?
The description covers the essential purpose and the important stub disclosure. However, with no output schema, it fails to describe what the returned insights contain, leaving the agent to infer response structure. For a simple read tool this is adequate but not thorough.
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?
All 7 parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds high-level context (e.g., 'traffic, page, source, tag, and sales insights') that hints at parameter relevance but does not elaborate individually.
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 reads 'Brand Store traffic, page, source, tag, and sales insights' and labels it as a read tool. This specificity, combined with the sibling list dominated by creation/update/archive tools, ensures strong differentiation.
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 includes a critical usage warning: 'Hosted endpoint only; this local stdio server is an introspection stub.' This tells agents the tool is non-functional locally. However, it does not provide explicit when-not-to-use scenarios or alternatives, leaving some ambiguity.
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?
No annotations are provided, so the description carries the full burden. It discloses the tool is a stub locally and a hosted utility, implying no side effects locally. It mentions 'redacted' for privacy, but lacks details on success/failure behavior, authorization, or rate limits. Adequate but not comprehensive.
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, efficient sentence with no unnecessary words. It packs purpose, usage condition, and environment constraint into minimal text. Every part earns its place, making it very concise.
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 simplicity and lack of output schema, the description covers the essential purpose and usage condition. However, it does not specify what happens when called locally (likely error) or describe return values/error states. Adequate for a stub tool but not fully 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 both parameters described briefly. The description does not add extra meaning beyond the schema; 'request' and 'context' remain generic. Baseline 3 is appropriate as schema does the work, but description adds no value.
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 submits a redacted structured product-quality report, specifically after the user explicitly asks for feedback. The verb 'submit' and resource 'conversation_feedback' are precise, and the utility tag distinguishes it from the many action-oriented 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 explicitly states when to use: when the user asks agentcentral for feedback. It also notes that the tool is only functional on a hosted endpoint, not on the local stdio server, providing clear environmental context. However, it does not explicitly list alternatives or exclusions beyond the local restriction.
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?
With no annotations, the description carries the full burden. It discloses that the tool is a 'guarded write' with preview/audit trail, and explicitly states it is a local introspection stub, not the actual hosted endpoint. This prevents the agent from expecting real mutation locally. However, it lacks details on authentication requirements 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?
Two concise sentences that front-load the core purpose and add essential context about the stub nature. Every sentence adds value without 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?
For a write tool with 5 parameters and no output schema, the description explains the purpose and stub limitation but does not detail the structure of 'changes', the difference between preview and dry_run, or expected results. It is adequate but leaves gaps for the agent.
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 baseline is 3. The description adds minimal semantic value beyond the schema: it mentions 'preview and audit trail' explaining the reason parameter, and 'high-level desired changes' for the changes parameter, which is still vague. The meaning of 'dry_run' is covered by schema as an alias for preview.
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 'update' and resource 'listing attributes', with distinguishing features 'preview and audit trail'. The sibling tools include many update_* tools, and this one uniquely mentions preview/audit trail and explicitly states it is a stub for introspection, making its purpose unambiguous.
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 for updating listing attributes with preview/audit trail and mentions it is a hosted endpoint only, but does not explicitly state when to use this tool versus other update tools (e.g., update_price) or when not to use it. There is no guidance on prerequisites or 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?
Without annotations, the description carries burden. It states 'guarded write' and stub nature, but does not detail error behavior, idempotency, or other traits beyond being a stub.
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 front-loaded with purpose and limitations, 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?
Given the 5-parameter schema and no output schema, the description covers purpose and stub nature but lacks details on return values and distinction between preview and set.
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?
All 5 parameters have descriptions in the schema (100% coverage), so the description adds no extra semantic value, meeting the baseline of 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?
The description clearly states the tool previews or sets Sponsored Brands ad state, distinguishing it from sibling tools like archive or create ads. It also notes the local server is a stub.
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 the tool is a stub for introspection, implying it should not be used for actual operations locally. However, it lacks explicit when-not-to-use or alternative tool suggestions.
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?
No annotations provided, so description carries full burden. Discloses it is a guarded write and a local introspection stub, which is key behavior. Could mention preview vs update semantics more, but 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?
Two sentences with no fluff. Front-loaded purpose and stub clarification. 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 stub nature but lacks details on parameter usage, return values, or guarded write implications. Adequate for a stub but gaps remain for full agent 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 description coverage is 100%, so baseline 3. Description adds no additional context for parameters like preview, dry_run, or changes beyond schema definitions.
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 previews or updates Sponsored Display target bids, with specific verb+resource. Distinguishes from sibling tools like update_sd_ad_group_bid or update_sb_target_bids. Also adds stub context.
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?
States general use case but does not provide guidance on when to use this versus alternatives like update_sd_ad_group_bid or update_sd_target_state. No explicit when-not or alternative naming.
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?
No annotations are provided, so the description carries the full burden. It states the tool returns a complex data structure but does not disclose behavioral traits such as idempotency, latency, or side effects. The term 'Return' implies read-only, which is adequate but not explicit.
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 no filler. Every word adds value, efficiently communicating purpose, content, and deployment constraint.
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 enumerates key components of the returned tour (trust preflight, business pulse, etc.), providing sufficient context for an agent to understand the tool's output. The note about being a stub adds deployment context, though further structural details could be beneficial.
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 both parameters have descriptions. The description does not add extra meaning beyond the schema, meeting the baseline for high 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 uses a specific verb 'Return' and clearly identifies the resource as a 'first-run account data tour' with concrete components (trust preflight, business pulse, etc.). It distinguishes from sibling tools which are standard CRUD operations, making its unique composite purpose evident.
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 notes 'Hosted endpoint only; this local stdio server is an introspection stub,' providing a clear when-not (local use). While it doesn't name alternatives, the context implies this tool is for a specialized composite data view, not for standard data retrieval.
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?
With no annotations, the description carries full burden. It discloses important behavioral traits: requires specific permission, only functional on hosted endpoint, and local server is a stub. This goes beyond typical parameter descriptions.
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 with a useful '[utility]' prefix, no wasted words, and critical constraints included upfront.
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 covers purpose, permission, and hosting constraint, but omits details like pagination, output format, or how to specify date ranges. Given no output schema and generic params, more context would help.
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 100% but parameter descriptions are vague ('Optional high-level request'). The tool description does not clarify how to use them for filtering or querying audit history, adding little 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 explicitly states the tool returns 'tenant-wide write audit history', which is a specific verb-resource combination. It also distinguishes from sibling tools by noting it's a utility tool, unlike the many campaign/keyword 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 context on when to use (need audit history) and a prerequisite (API key permission), but no explicit exclusions or alternatives. Since no sibling tool serves the same purpose, this is acceptable.
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?
With no annotations, the description carries full burden. It clearly notes the tool is a stub locally and is a read operation. This honesty about its limited functionality is valuable, though it could elaborate on what happens when called.
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: first presents purpose, second notes the limitation. Every word contributes, 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with no output schema, the description covers the resource and its limitation. It lacks details on return format or pagination, but given the stub context, it is reasonably 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?
The input schema has 100% parameter coverage with descriptions. The tool description adds no extra meaning beyond 'AWD inbound and on-hand stock', so it meets the baseline without further value.
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 'AWD inbound and on-hand stock', specifying the exact resource this tool accesses. The category '[Inventory / read]' further clarifies verb and domain, distinguishing it from sibling tools like get_fba_inventory or get_inventory_health.
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 mentions 'Hosted endpoint only; this local stdio server is an introspection stub', implying it is not functional locally. However, it does not explicitly state when to use this tool versus alternatives or provide any scenario 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?
No annotations are provided, so the description carries full burden. It clearly states the tool is a read operation and explicitly declares it is a stub for introspection only. This is a critical behavioral trait that prevents misuse.
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 words. First sentence packs the purpose, second sentence provides essential context about the stub nature. Highly 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?
With full schema coverage and no output schema, the description provides enough context for a stub tool: it indicates what data is conceptually returned and that it's not operational. Lacks output format details, but acceptable for an introspection stub.
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%, and the description adds no additional meaning to the parameters beyond what is already in the schema. 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 identifies the tool as a read/ranking endpoint for keyword rank positions, changes, and SQP volume views. It uses specific verbs and resource names, and the sibling tools list shows many get_* tools, making this unique and distinguishable.
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 states that this is a hosted endpoint and a local stdio stub, implying it should not be used for actual data retrieval. However, it does not provide explicit guidelines on when to use this tool versus alternatives like get_keyword_performance or get_current_rank.
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 no annotations, the description carries full burden. It reveals the tool is a utility that replaces a report and is non-functional locally. However, it lacks details on side effects, permissions, or what happens to the old report.
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 with no wasted words. The first sentence states the core action and condition, the second clarifies scope. Effectively 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?
Given no annotations, no output schema, and simple optional parameters, the description covers the essential purpose and usage constraints. It could mention return behavior but is 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 coverage is 100%, so the baseline is 3. The description does not add any additional meaning beyond what is in the input schema for the two optional 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 replaces an existing public snapshot report at the same URL, with a specific condition. It also distinguishes itself from sibling tools like create_shareable_report and delete_shareable_report.
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 guidance on when to use ('after the user explicitly asks for an update') and notes this is a hosted-endpoint only stub, implying it won't execute locally. However, it does not explicitly name 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?
With no annotations provided, the description carries the full burden. It correctly labels the tool as 'guarded write' and discloses that this local server is an introspection stub, meaning writes are not performed locally. This is a key behavioral trait. However, it does not elaborate on guard details or return behavior.
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 long, front-loading the purpose and key behavioral notes. No extraneous content.
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 absence of an output schema and annotations, the description should provide more context about the guarded write flow, especially how preview differs from actual creation. The 'changes' parameter is vaguely described as 'High-level desired changes' without examples or constraints. Adequate but with 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 coverage is 100%, with each parameter having a description in the schema. The tool description adds no further details beyond what the schema already provides for parameters like 'preview', 'dry_run', 'changes', etc. The baseline for high coverage is 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?
The description clearly states the verb actions ('Preview or create') and the specific resource ('Sponsored Display targets'). It distinguishes from sibling tools like create_sd_campaigns by targeting a different entity. The addition of '[Ads / guarded write]' and the stub clarification further refine the purpose.
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 when to use the tool (for preview or creation of SD targets) and notes that it's a local stub for a hosted endpoint. However, it does not explicitly state when not to use it or compare it with alternatives such as update_sd_target_state or archive_sd_targets.
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?
Despite no annotations, the description reveals it is a read operation (via '[Ads / read]') and crucially states that the local version is a stub, meaning it won't return live data without the hosted endpoint. This is valuable behavioral context beyond a simple 'get'.
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. The first sentence identifies purpose and category; the second clarifies the operational context. Every word 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?
The description is adequate for a read-only tool with good parameter coverage, but lacks any information about return format or data structure. Given no output schema, some additional context on what 'snapshots' contain would improve 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?
All 7 parameters have descriptions in the schema (100% coverage), so the description adds no extra meaning. Baseline 3 is appropriate as the schema does the heavy lifting.
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 an ads read tool for 'Daily campaign budget usage and pacing snapshots', with a specific verb and resource. It distinguishes itself from siblings by specifying the hosted endpoint vs local stub nature.
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 notes that it is a hosted endpoint only and the local server is an introspection stub, guiding when to expect real data. However, it does not explicitly compare with alternative get_* tools for similar ad data.
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?
No annotations are provided, so the description carries full burden. It discloses the tool is a 'guarded write' and that it is a stub, preventing the agent from attempting destructive actions locally. This is transparent about behavioral limitations.
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 brief and front-loads the key purpose and constraint. It uses minimal verbiage to convey essential information, though it could be slightly more explicit about preview vs. adjustment behavior.
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 is a stub, the description provides sufficient context that it will not perform real writes. Without an output schema, it does not explain return values, but as a stub, this is acceptable. It is complete enough for an agent to avoid misuse.
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 schema already documents all parameters adequately. The description adds no additional meaning beyond the purpose, so it meets the baseline but does not enhance understanding.
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 ('Preview or adjust'), the resource ('keyword bids'), and the context ('guarded write'). It also distinguishes itself from sibling tools by specifying it's for keyword bid adjustments, which is unique among the update_* 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 mentions the tool is only available as a hosted endpoint and that this local instance is an introspection stub, guiding the agent not to expect real functionality. However, it does not explicitly state when to use this tool versus alternatives like update_target_bids.
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?
Without annotations, the description reveals 'guarded write' behavior and preview capability but omits details on side effects, permissions, or error handling. The stub context reduces expectations, but an agent needs more operational 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?
Two concise sentences that efficiently convey purpose, modality (preview/set), hosting context, and stub nature. 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?
For a mutation tool with 5 optional parameters and no output schema, the description lacks detail on expected return values, outcome of a write, or exact structure of 'changes'. It is adequate for a stub but incomplete for production use.
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%, but the description adds value by clarifying 'dry_run' as an alias for preview and describing 'changes' as high-level desired changes. This goes beyond the schema's basic 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 specifies 'Sponsored Display product ad state' with verb 'Preview or set', distinguishing it from sibling tools like update_sd_ad_state. It identifies as a 'guarded write' and notes it's a hosted endpoint stub.
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?
It indicates two usage modes (preview/set) and states it's a stub for introspection, implying limited functionality. However, it does not explicitly contrast with related siblings or provide criteria for when to use preview vs set.
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?
With no annotations, the description provides behavioral context: it is a guarded write, can preview or archive, and notes that preview/dry_run are supported conditionally. The mention of 'hosted endpoint only' clarifies it is a stub, adding transparency beyond the schema.
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 core action and product scope, followed by necessary stub context. Every word 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?
Given the tool has 5 optional parameters and no output schema, the description provides sufficient context: the guarded write nature, preview/archive duality, and stub environment. It could elaborate on the archive behavior, but the context is adequate for an introspection stub.
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 tool description aligns with the schema's parameter descriptions (e.g., preview and dry_run as aliases) but does not add new meaning beyond what the schema already 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 previews or archives Sponsored Products campaigns, specifying the verb and resource. It distinguishes itself from sibling archive tools by explicitly targeting Sponsored Products, unlike archive_sb_campaigns or archive_sd_campaigns.
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 mentions it is a guarded write and that the local server is an introspection stub, indicating it is not the actual execution endpoint. However, it does not explicitly state when to use this versus other archive tools beyond the product type differentiation.
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?
With no annotations, the description carries the full burden. It labels the tool as a 'guarded write', implying cautions, and clarifies it is a stub, so calls will not actually modify data. This adds valuable behavioral context beyond a simple 'update' description.
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 with no unnecessary words. The first sentence front-loads the core purpose and safety class. The second sentence concisely conveys a critical behavioral constraint and context.
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 does not explain the return value, the expected structure of the 'changes' parameter, or any prerequisites for the guarded write. Given 5 parameters and no output schema, the description leaves gaps that the agent must infer.
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%, but the descriptions in the schema are generic (e.g., 'High-level desired changes'). The tool description adds no additional parameter meaning or formatting guidance, so it stays at the baseline of 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?
The description clearly states 'Update seller-fulfilled listing quantities', which is a specific verb-resource pair. The prefix '[Catalog / guarded write]' adds domain and safety context. This distinguishes it from other update tools (e.g., update_price, update_listing) and other inventory tools.
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 states 'Hosted endpoint only; this local stdio server is an introspection stub.' This tells the agent not to use it on this server. Additionally, 'seller-fulfilled listing quantities' implies it is for MFN, not FBA, guiding the choice among 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?
The description discloses that the tool is a stub and implies a read-only operation, which aids transparency. Without annotations, it carries the full burden, and it could further detail the expected behavior (e.g., returns empty or mock data), but it is sufficient.
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-loading the purpose and critical stub note. 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?
For a stub tool, the description sufficiently conveys purpose and limitations. However, it lacks details on return format or error handling, which would be needed for a production tool. Given the stub context, it is 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?
The input schema has 100% description coverage, so the description adds no new parameter meaning beyond the schema. According to guidelines, 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 (read) and resource (inventory stock levels per fulfillment center), making it distinct from sibling tools like get_fba_inventory or get_inventory_health. It is specific and actionable.
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 notes that the tool is a hosted endpoint and that this server is only an introspection stub, guiding the agent not to rely on it for real data. This provides clear context for 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It states the tool returns data (connection details, setup links), implying read-only, non-destructive behavior. Could mention authentication needs or response format, but for a simple info tool 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?
Single sentence, front-loaded, no superfluous words. Every word is informative and necessary.
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 zero parameters and no output schema, the description fully explains what the tool does. No additional information is needed for correct invocation, especially considering the tool's simple nature.
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?
Tool has zero parameters, so baseline is 4. Description does not need to explain parameters; it correctly omits param 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?
Description clearly states verb 'returns' and resource 'connection details and setup links for the hosted agentcentral Amazon MCP server', distinguishing it from all sibling tools which are about managing Amazon Ads entities.
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?
Implied usage: when you need connection details or links to set up the MCP server. No sibling tool provides setup info, so alternatives are clear. Lacks explicit when-not-to-use or prerequisites, but context is sufficient.
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/agentcentral-to/agent-central-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server