Server Quality Checklist

Tool Scores

• create_update_product_set_for_campaignC
  2.7/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It adds some behavioral context (each product becomes an individual product ad, supports AUTO/MANUAL modes), but it fails to disclose critical behavior such as whether updates replace or merge, required permissions/headers, error states, or reversibility. The description is too shallow for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The first two sentences are essentially identical ('Create or update the product set for a campaign'), making the description redundant. While the remaining sentences are informative, the duplication is wasteful and violates the principle that every sentence should earn its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a create/update tool with 5 parameters and no output schema or annotations. The description does not explain return values, error behavior, or how to construct the request body. Given the complexity and many sibling tools, the description is notably incomplete and does not adequately position the tool within the broader API context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3 even without additional parameter details. The description mentions AUTO/MANUAL modes, which hint at body content but do not explain the structure of the 'body' parameter, which is left to 'see get_endpoint_definition'. This does not add much beyond the schema, so a 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Create or update' and the resource 'product set for a campaign', which is specific. It also mentions AUTO and MANUAL modes, adding specificity. However, it does not explicitly differentiate from sibling tools like get_product_set_for_campaign, so it falls short of a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does 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. It does not mention prerequisites, exclusions, or scenarios where another tool (e.g., get_product_set_for_campaign) would be preferred. The only implied usage is for creating or updating product sets, but no explicit context or decision criteria is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_update_positive_keyword_settings_for_campaignB
  3.1/5.0
  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 important behavioral rules: each entry is either a create (no id) or update (id required; keyword and match_type forbidden). This adds value beyond the schema, but the description is truncated and does not mention outcomes, errors, or other 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.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description repeats the same idea in consecutive sentences ('Create or update... Creates or updates...') and ends abruptly mid-sentence. This is not concise or well-structured; it wastes words and fails to complete a critical instruction.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no annotations and no output schema, so the description must be self-sufficient. It is not: the update workflow is truncated, return values are not described, and error handling is absent. For a create/update operation with conditional rules, this level of detail is insufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does 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 little parameter-specific meaning; it only vaguely refers to 'body' as 'JSON request body matching the endpoint schema' and describes the create/update distinction, which is more about workflow than parameter semantics. No compensation is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Create or update positive keyword settings for a campaign,' which is a specific verb+resource combination and clearly distinguishes from negative keyword settings via the name and content. However, the first two sentences are redundant and the truncation obscures the full scope, preventing a perfect score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a partial usage hint: 'To update a keyword, first fetch keywords via GET to obtain the keyword ...' implying that updates require an existing id. However, it does not explicitly contrast with alternatives like get_positive_keyword_settings_for_campaign or create_update_negative_keyword_settings_for_campaign, and the instruction is cut off mid-sentence.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_update_category_bids_for_campaignB
  3.2/5.0
  Behavior3/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 reveals validation behavior based on mode (required/forbidden category_bids), which is useful. But it does not disclose whether updates are partial or overwrite existing bids, nor any error or 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short but contains redundancy: 'Create or update category bids for a campaign' is immediately restated as 'Creates or updates the category bid settings for a campaign.' The mode-specific guidance is useful but could be integrated more tightly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a create/update mutation tool with no annotations and no output schema. The description omits critical context such as the full body structure (deferred to get_endpoint_definition), upsert behavior, response format, and error conditions. It is not self-contained enough for an agent to invoke correctly without external lookups.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% description coverage at a basic level, but the body parameter is only described as 'matching the endpoint schema.' The description adds valuable meaning by explaining the mode/category_bids relationship, but it does not define what category_bids contains or how mode is specified.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Create or update') and resource ('category bids for a campaign'). It is specific enough to distinguish from the getter sibling (get_category_bids_for_campaign), though it does not explicitly name alternatives. The redundant second sentence adds no new purpose information.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit conditional usage for mode=MANUAL vs mode=AUTO, explaining when category_bids is required or forbidden. However, it does not state when to prefer this tool over alternatives or any prerequisites beyond the schema's required fields.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_spa_campaignB
  3.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  There are no annotations, so the description carries the full burden of behavioral disclosure. It states that the tool creates a campaign and supports two budget types, but it does not explain that this is a mutating operation requiring authentication (x_token, x_retailer_id), how the body is used, or what the return value is. Important behavioral traits like prerequisites and side effects 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded, but the first two sentences are redundant ('Create a new...' and 'Creates a new...' say the same thing). The content could be condensed into two sentences without losing meaning. The third sentence adds valuable detail, but the redundancy prevents a higher score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create tool with no annotations and no output schema, the description is incomplete. It does not explain how to construct the body (instead referencing get_endpoint_definition), does not mention that x_token and x_retailer_id are required for the call despite the schema, and gives no indication of the expected response. While it covers budget types, several critical contextual aspects are missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are already documented. The description adds meaningful context beyond the schema by mentioning budget settings, bidding strategy, and campaign type, and specifically identifying AVERAGE_DAILY_BUDGET and LIFETIME_BUDGET as supported types. This enriches understanding of the opaque 'body' parameter, though it does not map every parameter explicitly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb and resource: 'Create a new Sponsored Products Advertising (SPA) campaign.' It distinguishes from sibling tools like update_spa_campaign and list_spa_campaigns by explicitly indicating a create operation. It also adds details about budget settings and campaign type, making the purpose clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for creating new SPA campaigns, but it does not explicitly state when to use this versus alternatives like update_spa_campaign. It mentions supported budget types, but no exclusions or alternative guidance is provided, leaving the usage context implicit rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_campaign_network_settingsB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden. It adds value by defining 'network' and documenting that a campaign with no saved settings returns an empty array. But it doesn't cover error behavior, authorization needs, or other 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.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The first two sentences are essentially identical ('Get the networks... Returns the networks...'), wasting words. A single sentence would have sufficed, making this less concise than it should be.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description explains the network concept and the empty-array case, which is useful given no output schema. However, it doesn't describe the structure of the networks array or any edge cases, leaving some gaps for a tool with five parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are already described. The description adds no parameter-level details beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets the networks a Sponsored Products campaign targets, with a specific verb and resource. This distinguishes it from sibling tools like save_campaign_network_settings and other getters.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: it's the read operation for campaign network settings. However, no explicit guidance is given about when to use this versus alternatives, and no exclusions or prerequisites are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_update_negative_keyword_settings_for_campaignA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden of behavioral disclosure. It adds useful constraints: each keyword entry is either a create (no id) or update (id and status required; keyword, match_type, and bid_value forbidden), and BROAD match type is not allowed. However, it omits auth requirements, side effects, idempotency, and is truncated mid-sentence, leaving behavior incomplete.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description repeats the exact same sentence twice ('Create or update negative keyword settings for a campaign.'), wasting a sentence. It also ends abruptly with 'negative keyw', indicating truncation. This is not a well-structured or concise description.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  As a mutation tool with no output schema and no annotations, the description needs to explain return values, prerequisites, error conditions, and side effects. It only covers partial body-schema rules and stops mid-word. The description is insufficient for the tool's complexity and lacks completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description enriches the vaguely described 'body' parameter ('JSON request body matching the endpoint schema') by explaining the structure of keyword entries and the match type restriction, which is not evident from the parameter schema alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Create or update negative keyword settings for a campaign' with a specific verb and resource. It differentiates from sibling tools like get_negative_keyword_settings_for_campaign and create_update_positive_keyword_settings_for_campaign by explicitly naming negative keyword settings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the tool name and the phrase 'for a campaign', but there is no explicit guidance on when to use this tool versus alternatives (e.g., get_negative_keyword_settings_for_campaign or create_update_positive_keyword_settings_for_campaign). The create/update entry rules are internal to the request body, not usage selection criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_product_set_for_campaignA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description adds useful behavioral information by noting the two response types (MANUAL vs AUTO product set). It omits details on error handling, auth requirements (beyond schema descriptions), or side effects, but for a read operation the disclosed response variety is meaningful.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief, but there is slight redundancy: 'Retrieve the product set for a campaign' and 'Returns the product set configured for a campaign' convey the same idea. Still, it is front-loaded and avoids waste overall.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description partially compensates by explaining response types, but it does not describe the product set structure, potential error cases, or authentication expectations beyond the schema. For a simple getter, this is adequate but incomplete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema's property descriptions already cover all five parameters with clear meanings, achieving 100% coverage. The tool description adds no extra parameter context, so the baseline of 3 applies; schema does the work.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb and resource: 'Retrieve the product set for a campaign.' It also distinguishes from sibling tools by focusing on retrieval, contrasting with create_update_product_set_for_campaign and others. The second sentence reinforces 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 Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied: this tool is for retrieving a product set, while siblings like create_update_product_set_for_campaign handle creation/update. However, the description does not explicitly mention when not to use it or point to alternatives, leaving guidance to inference.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_endpointsA
  3.6/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  There are no annotations provided, so the description must carry the burden. It describes the output (methods and paths) but does not disclose any behavioral traits such as read-only nature, 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, one sentence, front-loaded with the action 'List', and contains no extraneous words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with no parameters and no output schema, the description covers the essential function. However, it could be slightly richer about the response format or scope, but overall it is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema is empty, so the baseline is 4. The description adds no parameter information, but none is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: listing all API endpoints with their methods and paths. It distinguishes from siblings like get_endpoint_definition (which fetches a single endpoint) by emphasizing 'all'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does 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 get_endpoint_definition. It only implies usage through the verb 'List', with no mention of exclusions or alternative tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_category_bids_for_campaignA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the burden. It discloses the return fields (spend, revenue, ROI, current bid, ranges) and implies read-only via 'Retrieve'. However, it does not mention authentication requirements (though schema has x_token), rate limits, or error behavior. It's not misleading 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the main action. The first sentence 'Retrieve the category bids for a campaign' is somewhat redundant with the tool name, but the second sentence adds valuable return-field detail. Overall efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema exists, so the description compensates by listing the return content (spend, revenue, ROI, current bid, allowed/recommended ranges). It does not mention pitfalls like empty results or required headers, but for a straightforward retrieval it's adequately complete. Slightly more context on authentication would improve it, but schema covers that.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description doesn't add parameter-specific details beyond saying 'for a campaign', which is already in 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/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves category bids for a campaign, using the specific verb 'Retrieve' and the resource 'category bids for a campaign'. It distinguishes from the sibling 'create_update_category_bids_for_campaign' by implying a read-only operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides strong context that this is for retrieving category bids, but does not explicitly state when to use it over alternatives like create_update_category_bids_for_campaign. No explicit exclusions or alternative tool references are given, so it's clear but not fully guiding.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_service_detailsA
  3.7/5.0
  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 of disclosing behavior. It does not explicitly state that this is a read-only operation with no side effects, nor does it mention any authentication requirements for invoking the tool itself or potential errors. It only lists the content 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that conveys the purpose and key details in a compact manner, with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the zero-parameter scope and absence of an output schema, the description adequately covers what the tool returns (base URL, auth requirements, campaign hierarchy). It is sufficient for an agent to understand the tool's functionality and invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema is already complete. The description adds no parameter-specific information, but the baseline for zero-parameter tools is 4, as there is no semantic gap to fill.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly specifies the verb 'Get' and the resource 'OSMOS Marketing API service definition' with details (base URL, authentication, campaign hierarchy). It distinguishes from sibling tools like get_endpoint_definition by focusing on the overall service rather than a specific endpoint.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not specify when to use this tool versus alternatives such as get_endpoint_definition or list_endpoints. It provides no exclusions or context about choosing this over the other service metadata tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• save_campaign_network_settingsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden and does disclose the overwrite behavior and a specific error condition (404 with RESOURCE_NOT_FOUND). It does not mention auth or response details, but it covers the most important side-effect.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The first sentence is repeated verbatim ('Save the networks... Saves the networks...'), which is redundant and unprofessional. The error code is also truncated, adding noise without clarity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the key replace behavior and one error case, but with no output schema and no annotations it omits return values, accepted network values, and authentication prerequisites. 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/5

  Does 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 the 'include every network' instruction, but parameter meanings are mostly delegated to the schema; body semantics are deferred to get_endpoint_definition.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Save the networks a Sponsored Products campaign targets.' It also adds the critical replace-all behavior, clearly distinguishing this from a partial update or from the sibling 'get_campaign_network_settings' tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives actionable usage guidance: 'Each call replaces the previously saved set; include every network the campaign should target.' It does not explicitly name alternatives or exclusions, but the context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_negative_keyword_settings_for_campaignA
  4/5.0
  Behavior3/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 states the return value (list of negative keywords) and that it provides ids, but it does not explicitly confirm the operation is non-destructive or describe any authentication requirements beyond what the schema already shows.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences with no fluff. The first sentence states the main purpose, the second describes the return value, and the third gives a usage tip. All sentences earn their place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple retrieval tool with 5 schema-documented parameters and no output schema, the description adequately explains the return value (list of negative keywords) and purpose. It lacks nothing critical, though it could mention the read-only nature explicitly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all parameters with descriptions, so baseline is 3. The description adds no parameter-specific details beyond mentioning 'negative keyword ids' in the context of the response, not the request parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves negative keyword settings for a campaign, using a specific verb ('Retrieve') and resource ('negative keyword settings'). It also notes it returns the list of negative keywords, and the 'negative' qualifier distinguishes it from the positive keyword settings sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a concrete usage scenario: 'Use this endpoint to fetch negative keyword ids before updating their status.' This gives clear context for when to use the tool, though it doesn't explicitly mention 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.

• get_positive_keyword_settings_for_campaignA
  4/5.0
  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 plainly states this is a retrieval operation ('Retrieve', 'Returns the list'), implying no side effects. It also discloses the focus on keyword ids. It doesn't cover auth or rate limits, but for a simple read operation 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is only three sentences but redundant: 'for a campaign' appears twice in the first two sentences. It could be condensed to two sentences without losing meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward read tool with clear sibling differentiation and explicit usage guidance, the description is mostly complete. No output schema exists, but the description notes it returns a list of positive keywords with ids, which suffices for this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does 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 mentions 'keyword ids' but adds no specific parameter-level meaning beyond what the schema already provides for campaign_id, advertiser_id, etc.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Retrieve the positive keyword settings for a campaign' with a specific verb and resource. It distinguishes from the sibling get_negative_keyword_settings_for_campaign by specifying 'positive', and mentions the use case of fetching keyword ids before 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage guidance: 'Use this endpoint to fetch keyword ids before updating keyword bids or status.' This clearly indicates when to use the tool, though it doesn't explicitly mention alternatives or exclusions beyond what sibling names imply.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_spa_campaign_by_idA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the burden. It adds some transparency by specifying the returned fields (budget settings, bidding strategy, dates, status), but it doesn't mention authentication headers (though those appear in the schema) or error behavior like not-found cases. The verb 'Retrieve' implies read-only, but that is not stated explicitly.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, concise sentence that front-loads the purpose and includes key return details. Every word earns its place, and there is no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple get-by-id tool, the description adequately covers purpose and return content. The schema documents required parameters and header fields. However, with no output schema or annotations, it could be slightly more complete by noting potential error cases or the optional body parameter's role, though these are minor gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already explained clearly (e.g., campaign_id, advertiser_id, x_token). The description adds no extra parameter semantics, which is acceptable given the schema-heavy lifting, but it doesn't go beyond the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the verb 'Retrieve' with a specific resource ('a specific SPA campaign by its ID'), which clearly distinguishes it from siblings like list_spa_campaigns (listing all) or create/update (mutating). The scope and action are unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies usage when a single campaign's details are needed by ID. It doesn't explicitly name alternatives or state when not to use it, but the sibling list_spa_campaigns naturally covers the batch case, and the context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• update_spa_campaignA
  4.1/5.0
  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 partial-update behavior and bidding strategy constraints, which is useful. However, it does not mention possible validation failures, response shape, or side effects, leaving some behavioral ambiguity typical of mutation tools.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences, front-loaded with the main purpose. Every sentence adds unique value: purpose, partial-update behavior, and bidding constraints. No filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a mutation with no output schema, and the description covers the core behavior and constraints. However, it does not describe the expected return value, error conditions, or prerequisites beyond the schema. It is adequate but has clear gaps for a full understanding.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does 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 valuable meaning beyond the schema by specifying that bidding_strategy.type accepts limited families (CPC/CPM), which is not evident from the schema (no enums). It also clarifies that only fields to change need be sent, enriching the body parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Update') and resource ('existing SPA campaign'), clearly distinguishing it from sibling tools like create_spa_campaign and get_spa_campaign_by_id. It also clarifies the partial-update nature, 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool (updating an existing campaign vs. creating) and provides specific guidance for changing bidding strategies, including allowed families (CPC vs CPM). It does not explicitly name alternatives or exclusions, but the context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_campaign_forecastA
  4.2/5.0
  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 meaningful behavioral traits beyond the schema: the forecast uses 'current or overridden budget' and explicitly calls out the LIFETIME_BUDGET limitation. While it doesn't discuss auth or side effects, 'get' implies a safe read operation, and the disclosed constraints add significant value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences with no redundant content. It front-loads the purpose and efficiently adds the budget basis and the key limitation, every sentence earning its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a get-forecast tool with no output schema, the description explains the return value ('Returns the forecast'), the basis (current or overridden budget), and a critical limitation (LIFETIME_BUDGET unsupported). It lacks explicit guidance on how to pass an overridden budget via the body parameter, but the body parameter description references get_endpoint_definition, partially filling that gap. Overall, it is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes all 5 parameters with 100% coverage, so the baseline is 3. The description adds budget-related context but does not map that to specific parameters (e.g., how to set an overridden budget in the body). The schema's descriptions of body and campaign_id already provide necessary parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb and resource: 'Get forecast for a campaign.' It distinguishes itself from sibling tools like get_spa_campaign_by_id by focusing on forecasting rather than campaign details, and the LIFETIME_BUDGET note further clarifies scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool (to obtain a forecast) and explicitly states a key exclusion: forecasting is not supported for LIFETIME_BUDGET campaigns. It does not name alternative tools, but no sibling tool offers forecasting, so the guidance is sufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_spa_campaignsA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of disclosure. It mentions pagination (offset/limit required), optional status filter with values ACTIVE/PAUSED, and that it returns a paginated list. However, it does not describe auth requirements (x_token, x_retailer_id) or any default/maximum page size behavior, which are partly in the schema but not in the 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences long, front-loaded with the primary purpose, and contains no fluff. Each sentence adds functional detail: pagination, status filter, and required parameters.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description mentions the return type (paginated list) but not its detailed structure. It covers the main functional aspects of pagination and filtering. However, it does not mention the authentication headers (x_token, x_retailer_id) which are essential for making the call, though they are described in the schema. Overall, it is reasonably complete for a list operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does 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 value by specifying the exact status filter values (ACTIVE, PAUSED), which the schema only describes generically. It also reinforces the role of offset and limit for pagination, though this is already somewhat inferable from the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists all SPA campaigns for an advertiser, with specific mention of pagination and optional status filtering. This distinguishes it from sibling tools like get_spa_campaign_by_id (single campaign) and create_spa_campaign (creation).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for listing all campaigns for an advertiser, which is distinct from fetching a single campaign or creating one. It does not explicitly discuss when not to use it, but the context is clear enough for an agent to select it appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_endpoint_definitionA
  4.3/5.0
  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 is a read operation ('Get') and specifies what is returned (request/response schemas, params, examples). This goes beyond the schema, which only describes the input parameter. It lacks details about error behavior, but for a simple getter 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that leads with the primary action ('Get the full OpenAPI-derived definition') followed by a concise parenthetical listing contents. Every word earns its place, with no redundant or filler information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with only one parameter and no output schema, the description adequately explains the return value (schemas, params, examples) and the scope (specific endpoint by id). There is no pagination or error complexity to disclose. The description stands alone as complete context for invoking the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the endpointId parameter already includes a descriptive example ('create-spa-campaign'). The description does not add additional meaning about the parameter beyond 'by id', which is already implied in the schema. Therefore, the description provides no extra semantic value for this parameter, so the 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/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets the full OpenAPI-derived definition for a specific endpoint by id, including request/response schemas, params, and examples. This specific verb+resource+scope distinguishes it from siblings like list_endpoints (which lists endpoints) and get_service_details (which gets service-level details).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes it clear that this tool requires a specific endpoint id and returns the definition for that single endpoint, implying it should be used when detailed schema information for one endpoint is needed. However, it does not explicitly mention alternatives or exclusions, such as using list_endpoints to discover ids first.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.