Market Brew

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

Annotations already declare read-only, non-destructive, idempotent, and non-open-world behavior, so the safety profile is covered. The description adds a useful data-visibility constraint ('only data visible to the linked Market Brew account'), but it does not describe the return format or what 'availability' means operationally.

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

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

The description is two short sentences with no filler, and it front-loads the usage condition before the data-visibility note. The first sentence is somewhat boilerplate and repeats the title, but the overall structure is efficient.

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

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

For a tool with no output schema and an undocumented required parameter, the description should explain what the availability check returns and how askWidgetId is used. Instead it gives only a usage trigger and an account-visibility note, leaving the agent without enough context to interpret results or supply the ID confidently.

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

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

The single required parameter askWidgetId has 0% schema description coverage, and the description never mentions it or explains its format or source. The schema provides only type information (string or number), leaving the parameter's meaning entirely undocumented.

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

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

The description restates the title (check Ask Widget availability) rather than explaining what the health check actually evaluates or returns. It does not distinguish the tool from siblings like get_ask_widget or list_ask_widgets, so an agent gets no concrete sense of the operation beyond the name.

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

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

It gives a clear trigger: 'Use this when the user asks to check Ask Widget availability.' That is explicit context for invocation, though it provides no exclusions or guidance on when to prefer a sibling tool such as get_ask_widget.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds a genuinely useful scope note ("Returns only data visible to the linked Market Brew account"), but says nothing about the return shape or the effective filter defaults.

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

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

Two short sentences with the trigger front-loaded first and the scope caveat second; every clause carries information and nothing is padded.

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

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

For a simple single-optional-param count tool with no output schema, the description covers trigger and visibility scope adequately; the return value (a count) is self-evident from the name. Minor gap is the absence of any alternative-tool routing.

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

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

Schema description coverage is 100% and the query filter (startDate/endDate ISO-8601) is documented in the schema itself. The description adds no additional parameter meaning, so the baseline of 3 applies.

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

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

The description names a specific verb+resource (count Ask Widget conversations), which is distinct from the other count_* siblings and from list_ask_conversations. It is clear what the tool does, though it does not explicitly note that it returns an aggregate rather than records.

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

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

"Use this when the user asks to count..." gives trigger-based guidance, which is useful. However, it does not contrast with the obvious alternative (list_ask_conversations) or state when a count is preferable to listing, leaving the routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds a useful scope note ('only data visible to the linked Market Brew account'), but says nothing about what the count represents or how pagination filters affect it.

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

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

Two short sentences, front-loaded with the trigger and followed by the scope caveat. Slightly redundant since it restates the tool name, but otherwise no waste.

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

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

For a simple read-only count tool with full schema coverage and no output schema, the description is nearly sufficient. The absence of any hint about the return value is minor given the schema carries the parameter detail.

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

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

Schema description coverage is 100% with the query object documenting all filter fields, so baseline 3 applies. The description adds no parameter 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.

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

States a specific verb (count) and resource (Content Boosters), distinguishing this from listing/getting siblings by name. However, it never explicitly contrasts with list_content_boosters, so the agent must infer the difference from the name alone.

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

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

Provides a trigger condition ('when the user asks to count Content Boosters') but no alternatives or exclusions. It does not tell the agent to prefer this over list_content_boosters for a pure count, leaving usage only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds one useful behavioral fact — results are scoped to the linked Market Brew account's visibility — but says nothing about return shape or aggregation semantics.

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

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

Two short sentences with the usage trigger front-loaded and no filler. The first sentence is close to a restatement of the title, which keeps it just under full marks.

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

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

For a simple no-required-param counting tool with full annotation coverage and a fully documented schema, the description covers purpose and the account-visibility constraint. There is no output schema, but the aggregate nature of a count makes return details largely self-evident.

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

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

Schema description coverage is 100%, and the single nested 'query' object already enumerates all supported filters (customerId, crewIds, websiteId, serverHost, startDate, endDate). The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

States a specific verb (count) and resource (visible Crew accounts), which cleanly separates it from get_crew, get_current_crew, and list_crew_websites by implying an aggregate rather than a single record or list. It does not explicitly name those siblings, 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.

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

"Use this when the user asks to count visible Crew accounts" is a usage trigger, but it essentially restates the purpose rather than contrasting with alternatives. No when-not conditions or sibling routing are given, so the guidance is implied at best.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a real behavioral constraint beyond the annotations: results are scoped to 'only data visible to the linked Market Brew account'.

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

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

Two short sentences, front-loaded with the trigger condition and followed by the scoping caveat. Every sentence earns its place with no redundancy.

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

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

For a zero-parameter, read-only count tool with no output schema, the description covers the essential trigger and the account-scoping behavior. It could state what is returned (a numeric total), but that is a minor gap given the simplicity.

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

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

The tool takes zero parameters, so there is no parameter semantics to document; baseline 4 applies. Nothing in the schema requires compensating description text.

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

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

States a specific verb+resource (count Knowledge Bases), which cleanly separates it from the sibling list_knowledge_bases and get_knowledge_base. It doesn't explicitly name that sibling, but the operation is unambiguous from the name and description.

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

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

Provides an explicit trigger phrase ('Use this when the user asks to count Knowledge Bases'), which is adequate usage guidance. However, it offers no exclusions or routing to alternatives such as list_knowledge_bases when the user wants the actual items rather than a total.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds a genuine scope constraint — results are limited to what the linked Market Brew account can see — but says nothing about counting semantics (approximate vs exact) or whether filters affect the total.

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

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

Two short sentences with the trigger condition front-loaded and no filler. The first sentence largely restates the tool name/title, which costs it the top score, but nothing is bloated.

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

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

For a single-optional-parameter count tool with no output schema, the description covers the trigger and the visibility scope, and the return value (a count) is self-evident. Nothing essential is missing, though noting that the count reflects only accessible records with filters applied would make it airtight.

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

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

Schema description coverage is 100%: the query object already documents websiteId/serverHost filters. The description adds no filter syntax or semantics beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (count) and resource (Listen keyword monitors), which is enough for an agent to distinguish it from list_listen_monitors and get_listen_monitor on the action axis. However, it never explicitly names those siblings or contrasts counting with listing, so differentiation is inferred rather than stated.

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

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

"Use this when the user asks to count Listen keyword monitors" gives a trigger condition, but offers no when-not guidance and does not point to list_listen_monitors for retrieving the actual records. Usage is implied rather than fully framed.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful context beyond the annotations: 'This makes one billable DataForSEO request,' a cost/latency signal an agent can factor into invocation decisions.

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

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

Two sentences, both front-loaded and functional: the first states the use case and scope, the second discloses the billing cost. No filler or redundancy.

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

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

For a simple one-param read tool with no output schema, the description covers what data it returns (backlink and referring-domain totals) and the cost. The only missing piece is any pagination, limit, or return-shape note, which is minor here.

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

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

Schema coverage is 100% for the single `target` parameter, and the schema already documents that it's a domain/subdomain without URL scheme or path. The description adds no format or syntax detail beyond that, so the baseline 3 applies.

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

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

States a specific resource (backlink and referring-domain totals) for a domain, which is enough to distinguish it from the sibling dataforseo_google_serp and dataforseo_ranked_keywords tools, which cover different DataForSEO resources. It doesn't explicitly name those siblings, but the resource is clear.

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

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

Provides a usage trigger ('when a team member asks for a domain's backlink and referring-domain totals') but names no alternatives or when-not conditions. The trigger implies when to use it, but routing vs the other DataForSEO tools is left to inference.

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

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

Annotations already cover safety (readOnly, non-destructive, openWorld), so the description's added value is the cost/latency profile: 'one billable DataForSEO request with a depth of 10.' That is genuinely useful context beyond the structured fields. It omits rate limits or failure behavior, and idempotentHint=false is not explained (repeat calls are re-billed).

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

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

Two short sentences, zero filler, with the usage trigger front-loaded before the cost note. Every clause earns its place.

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

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

No output schema exists, so the description need not detail return values, and the depth-of-10 note implicitly signals ~10 organic results. Annotations carry the safety profile. The only gap is that language/location selection (important for SERP correctness) is left entirely to the schema.

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

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

Schema coverage is 67%: languageCode and locationCode are documented in the schema, but the required 'keyword' param carries only length constraints. The description adds 'for a keyword' but no format or syntax guidance, and its mention of 'depth of 10' refers to a setting that is not even a parameter, which could confuse an agent looking for a depth input. Baseline 3 is appropriate since the schema does most of the work.

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

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

The description names a specific verb (get) and resource (live Google SERP) for a given keyword, matching the title and distinguishing it from sibling DataForSEO tools like dataforseo_backlink_summary and dataforseo_ranked_keywords. It is clear what the tool returns, though it does not explicitly contrast itself with the other SERP/search siblings.

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

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

It gives an explicit trigger: 'Use this when a team member asks for current Google search results for a keyword.' That is clear contextual guidance. It stops short of naming alternatives or exclusions (e.g., when to prefer a cached/history SERP tool instead), so it is not a full 5.

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

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

Annotations already declare readOnly, openWorld, and non-destructive, so safety is covered. The description adds real value beyond them by disclosing that the call is billable and capped at 20 returned keywords, which is cost/scope context an agent needs before invoking.

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

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

Two tight sentences with zero waste; the usage trigger is front-loaded and the cost/result caveat follows immediately.

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

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

For a read-only, billable API call with no output schema, the description covers when to use it, cost, and result ceiling. It stops short of describing the shape of returned keyword data or routing to sibling tools, but nothing critical for a correct invocation is missing.

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

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

Schema coverage is 75%, with target, languageCode, and locationCode all documented in the schema itself. The description adds no parameter-level detail (no mention of language/location or the limit parameter), so the baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description names a specific verb+resource: returns Google keywords a domain ranks for. An agent can distinguish it from dataforseo_google_serp and dataforseo_backlink_summary by the 'ranked keywords' framing, though it never names those siblings explicitly.

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

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

It gives a clear when-to-use trigger ('when a team member asks which Google keywords a domain ranks for'), which is better than nothing. However, it offers no when-not-to-use guidance and does not point to the obvious alternative (dataforseo_google_serp) for SERP-level queries.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description usefully adds the account-scoping constraint ('only data visible to the linked Market Brew account'), but says nothing about the paged/character-offset nature of the export implied by offset and maxChars.

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

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

Two short sentences, front-loaded with the trigger condition and no wasted prose. It is efficient, though the account-visibility sentence is somewhat tangential to invocation.

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

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

For an export tool with pagination parameters and no output schema, the description should clarify return format and how offset/maxChars chunk the export; it does not. The account-visibility note is a partial substitute for return-value guidance.

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

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

Schema coverage is 50%: offset and maxChars have descriptions, while the two required parameters (website, seedId) have none. The description adds no parameter meaning at all, so it fails to compensate for the undocumented required inputs.

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

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

States a specific verb-plus-resource ('export crawl seed attempt history'), so an agent knows what the tool does. It does not distinguish itself from close siblings such as list_deep_crawl_seed_attempts, export_deep_crawl_seeds, or export_deep_crawl_seed_errors, leaving the agent to infer the boundary.

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

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

'Use this when the user asks to export crawl seed attempt history' is an explicit trigger, but it is circular with the tool name and adds no decision criteria. No alternatives or when-not conditions are given, and the sibling list contains several near-identical export/list tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, so an agent knows this is a safe, idempotent, read-only operation. The description adds that only data visible to the linked Market Brew account is returned, which is useful scope information. However, it doesn't explain what the export contains (format, error structure) or pagination.

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

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

Two short sentences, no wasted words. The first sentence repeats the tool purpose, and the second adds the account-scope caveat. Efficient, though the first sentence adds little beyond the title.

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

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

For a read-only export tool with annotations covering safety, the description gives the essential account-scope constraint. But it doesn't address what 'website' means (ID vs URL), export format, or pagination behavior. The lack of output schema means the agent doesn't know the return structure, and the description doesn't fill that gap.

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

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

Schema coverage is 67%: 'offset' and 'maxChars' are documented in the schema, and 'website' is required but has no schema description. The description adds no information about parameters. With moderate schema coverage and no compensating parameter info, baseline is 3.

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

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

The description states the purpose ('export crawl seed error history') and the resource (crawl seed error history). However, it largely restates the title and name rather than adding specifics. It doesn't distinguish itself from siblings like export_deep_crawl_seeds or export_deep_crawl_seed_attempts beyond the word 'error'.

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

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

The description says 'Use this when the user asks to export crawl seed error history,' which is essentially a restatement of the purpose rather than an actual usage condition. No alternatives or exclusions are mentioned, and there's no guidance on when to use this versus summarize_deep_crawl_seed_errors or other export tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds the account-scoping constraint ("only data visible to the linked Market Brew account"), which is genuinely useful context, but says nothing about the char-based paging/truncation this export implies.

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

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

Two short, front-loaded sentences with no filler; the scoping caveat is placed immediately after the trigger. It is efficient, though the first sentence spends words restating the name.

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

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

For an export tool with offset/maxChars paging and no output schema, the description should convey that output is a character-limited text chunk and how to continue past maxChars. It omits this and never clarifies its relationship to list_deep_crawl_seeds, leaving an agent under-informed.

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

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

Two of three params (offset, maxChars) are documented in the schema, but the required 'website' parameter has no schema description and the description does not compensate or explain its accepted formats (string or number). The description adds no parameter meaning at all beyond what the schema already says.

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

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

The verb+resource (export crawl seed inventory) are present, but the first sentence largely restates the tool name and title rather than adding specificity. It does not distinguish this export from the sibling list_deep_crawl_seeds or export_deep_crawl_seed_attempts/errors, so an agent can't tell them apart from the description alone.

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

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

"Use this when the user asks to export crawl seed inventory" is a trigger that merely echoes the name, offering no real when-to-use guidance. There is no mention of alternatives (list_deep_crawl_seeds, get_deep_crawl_seed) or conditions that select export over a list.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds one non-obvious access constraint: results are scoped to the linked Market Brew account. That is genuinely useful context beyond the annotations, but return shape, potential size and pagination remain unstated.

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

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

Two short sentences with no padding, which is a point for conciseness. However, the first sentence is essentially a restatement of the tool name ('Use this when the user asks to get...'), so its structural real estate is not earning its place.

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

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

For a sibling set this dense with account-scoped getters and no output schema, the definition should describe what the snapshot contains or how it differs from preview_account_management_command and the usage/metric getters. It does neither, leaving an agent unable to decide when this tool is the right choice.

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

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

The tool takes zero parameters and the description does not invent any, so the no-params baseline of 4 applies. There is no parameter content for the description to add or omit.

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

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

The description restates the tool name and title almost verbatim: 'get the internal account-management snapshot.' It identifies no specific resource, no dimensions of the snapshot, and does nothing to distinguish it from the many sibling get_* tools (e.g., get_usage_metrics, get_launchpad_stats) that also return account-level data.

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

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

The only guidance is a near-exact echo of the user phrasing ('when the user asks to get the internal account-management snapshot'), which is circular and offers no when-to-use vs. when-not-to-use logic. No alternatives are named despite dozens of overlapping get_* siblings, not least preview_account_management_command and get_customer_license.

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

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

Goes beyond annotations by disclosing data provenance (DataForSEO estimates) and explicitly warning what the numbers are NOT (citation counts, referrals, causation proof). Annotations cover read-only/idempotent safety, which the description doesn't need to repeat.

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

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

Four tightly-written sentences, front-loaded with the trigger condition, followed by workflow, scope caveat, and definitional caveat. No filler.

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

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

Complete enough for a read-only reporting tool: usage trigger, workflow, scope caveat, and data-provenance warning are all present. No output schema exists, but the description clarifies the return semantics (US/English monthly counts and estimated search volume) sufficiently.

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

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

Schema coverage is only 33%, so the description must compensate. It explains platform scope (US/English), that each platform is requested separately, and what the query filter produces — adding meaning beyond the sparse schema. Still doesn't fully define the 'crew' parameter format or the query object's full key semantics.

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

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

Specific verb+resource: returns historical AI mention/AI search volume data for a licensed website, with explicit scope (monthly history). Distinguishes from siblings like get_usage_metric_history by naming the AI visibility domain and DataForSEO sourcing.

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

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

Clear trigger condition ('when the user asks for historical AI mentions or AI search volume'), plus a workflow hint ('Resolve the Crew and website first, then request each platform separately'). Doesn't name a sibling alternative to distinguish from, so not a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds a useful data-scoping note — returns only data visible to the linked Market Brew account — but does not describe auth requirements, rate limits, or return behavior 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.

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

The description is short, but the first sentence is tautological and earns little, while the second sentence adds real scoping value. It is structurally clean but not fully front-loaded with useful information.

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

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

With no output schema and a nested query object, the description should explain what session state is returned and how askWidgetId/query shape the result. Instead it only notes account-level data visibility, leaving key call semantics and return expectations unaddressed.

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

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

Schema description coverage is only 50%: the nested query object documents websiteHost and conversationId, but askWidgetId has no schema description. The tool description mentions no parameters at all, so it fails to compensate for the undocumented required parameter or clarify accepted ID formats.

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

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

The description restates the tool name and title: 'Use this when the user asks to get Ask chat session state.' It does not clarify what 'session state' contains or how this differs from siblings like get_ask_conversation, list_ask_conversations, or get_ask_widget.

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

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

The only usage guidance is circular: 'Use this when the user asks to get Ask chat session state.' It gives no when-not conditions and never names an alternative such as get_ask_conversation or list_ask_conversations.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true), so the bar is lower. The description adds a meaningful behavioral fact: 'Returns only data visible to the linked Market Brew account,' which discloses a scoping/authorization constraint not captured in annotations. However, it doesn't describe error behavior when the conversation isn't found or what the response contains.

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

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

Two short sentences, front-loaded with the use case. No unnecessary detail or repetition. Efficient, though the first sentence is effectively tautological.

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

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

For a tool with two undocumented required parameters, no output schema, and no explanation of return values, this description is far from complete. The scoping note is helpful but doesn't compensate for the missing parameter semantics and lack of output format guidance.

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

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

Schema description coverage is 0% and the description mentions no parameters at all. With two required parameters (askWidgetId, conversationId) that are completely undocumented in both the schema and the description, the agent has no guidance on what these IDs are or how to obtain them. This is a critical gap.

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

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

States a clear verb ('get') and resource ('Ask conversation'), which tells an agent the basic purpose. However, it doesn't distinguish this from siblings like get_ask_chat_session or list_ask_conversations beyond the name, and the phrase 'Use this when the user asks to get an Ask conversation' is essentially a restatement of the tool name rather than an explanation of what data it retrieves.

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

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

The description offers no guidance on when to use this tool versus alternatives. There's no mention of when to prefer list_ask_conversations, get_ask_chat_session, or get_ask_widget. The only condition given ('when the user asks to get an Ask conversation') is tautological and doesn't help routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds one piece of genuine context that annotations cannot express: results are scoped to the linked Market Brew account. No pagination, rate-limit, or error behavior is disclosed, so it only adds modest value over the annotations.

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

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

Two short sentences with no filler and the trigger front-loaded, which is good structure. However, the brevity comes from under-specification rather than efficiency, so it neither wastes words nor earns credit for substance.

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

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

For a simple single-parameter read tool whose annotations cover safety and with no output schema to explain, the description is minimally complete. It still omits the identifier's meaning and any hint of what the returned widget contains, which leaves real gaps for an agent.

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

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

There is one required parameter (id) with 0% schema description coverage, so the schema gives no meaning for it and the description must compensate. It never explains what the id refers to (widget id, account-scoped id, accepted string vs number), leaving the sole parameter semantically undocumented.

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

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

"Use this when the user asks to get an Ask Widget" essentially restates the tool name and title rather than describing what retrieval actually yields (which fields, what an 'Ask Widget' is). It offers no differentiation from the many sibling get_* and list_ask_widgets tools, so an agent must infer the resource from the name alone.

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

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

The opening clause is a bare trigger ('when the user asks to get an Ask Widget') with no when-not conditions and no pointer to alternatives such as list_ask_widgets for enumeration or check_ask_widget_health. An agent gets no help deciding among the sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds one genuine piece of context beyond that — the result is scoped to 'data visible to the linked Market Brew account' — but says nothing about what is returned or failure modes.

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

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

Two short sentences with no filler, and the usage condition is front-loaded. It is efficient, though the first sentence is redundant with the name/title rather than adding information.

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

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

With no output schema, the description should characterize the returned booster object, but it only states an access-scoping note. Combined with the undocumented 'id' parameter and no sibling differentiation in a crowded namespace of 60+ tools, the definition is too thin to call correctly with confidence.

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

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

There is a single required 'id' parameter with 0% schema description coverage and no enum. The description does not say what kind of identifier this is, where to obtain it, or whether it accepts a slug vs. numeric ID (the schema permits string or number), so the schema's ambiguity is left unmitigated.

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

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

The verb+resource ('get a Content Booster') is identifiable, but it is essentially a restatement of the tool name and title, offering no differentiation from close siblings like get_content_booster_asset, get_content_booster_metrics, or list_content_boosters. An agent cannot tell from the description which of these it should reach for.

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

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

'Use this when the user asks to get a Content Booster' is circular — it restates the purpose rather than giving real selection criteria. No alternative tool is named, and no condition distinguishing it from get_content_booster_metrics/asset or list_content_boosters is provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds a genuine data-scoping disclosure ("returns only data visible to the linked Market Brew account"), which is beyond the annotations, but says nothing about behavior when the asset is missing or inaccessible.

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

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

Two short sentences with no filler, and the trigger is front-loaded. Nothing is padded, though the brevity reflects under-specification rather than tight writing.

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

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

For a one-parameter tool with no output schema and 0% schema description coverage, the description should clarify what an asset is and what is returned. It leaves the return shape and parameter semantics entirely unexplained, relying only on annotations for the safety profile.

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

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

Schema description coverage is 0% for the single assetId parameter, and the description provides no meaning, format, or sourcing guidance for it. The name is self-suggestive, but the description does nothing to compensate for the undocumented parameter.

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

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

The description essentially restates the tool title ("get a Content Booster asset") without adding a distinguishing verb scope or resource detail. It does not differentiate from close siblings such as get_content_booster or list_content_booster_assets, so an agent cannot tell which to pick from the description alone.

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

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

"Use this when the user asks to get a Content Booster asset" is a circular trigger condition that gives no real when-to-use context. No alternatives are named (get_content_booster, list_content_booster_assets) and no prerequisites 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.

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety is covered. The description adds one genuinely useful behavioral fact beyond the annotations: 'Returns only data visible to the linked Market Brew account,' disclosing account-scoping/permission boundaries. It adds nothing about pagination, filter behavior, or metric shape.

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

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

Two short sentences, front-loaded with the usage trigger and followed by the scoping note. No filler or redundancy, though the content is thin rather than efficient-but-rich.

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

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

For a no-required-parameter read tool with no output schema, the description needn't explain return values, and annotations carry the safety profile. However, it never clarifies what 'metrics' this returns or how the query filters affect results, leaving the agent without context to invoke it meaningfully.

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

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

Schema description coverage is 100% and the single 'query' object is documented with its candidate filter keys (websiteId, serverHost, title, status, sortBy, etc.). The description adds no parameter meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description essentially restates the tool name and title ('get Content Booster metrics') without adding a distinguishing verb, scope, or resource detail. It does not distinguish this metrics endpoint from siblings like get_content_booster, get_flight_plan_metrics, or get_task_metrics. This is near-tautology.

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

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

The only guidance is 'Use this when the user asks to get Content Booster metrics,' which is a trivial restatement of the name rather than real routing advice. No alternatives (e.g., get_content_booster for entity details vs. this for metrics) 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.

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The one added fact is the account-scoping constraint ('only data visible to the linked Market Brew account'), which is genuinely useful authorization context but is the only new 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.

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

Two sentences, no padding, and the scoping caveat is stated up front after the trigger. It is appropriately sized, though the first sentence is pure restatement and carries no informational payload.

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

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

There is no output schema, so the description is the only place return semantics could be described, yet it says nothing about the shape or format of the metrics returned. Combined with zero sibling differentiation, the definition leaves the agent under-equipped to use this tool confidently.

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

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

Schema description coverage is 100% and the single 'query' object parameter already enumerates its filters (customerId, crewIds, websiteId, serverHost, startDate, endDate). The description contributes no parameter meaning at all, so the baseline 3 for full schema coverage applies.

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

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

The description is essentially a restatement of the title: 'get crawl activity metrics' adds nothing beyond the name/title pair. It never says what a crawl activity metric actually is, what dimensions it covers, or how it differs from the numerous sibling metrics tools (get_search_metrics, get_task_metrics, get_ranking_sensor_metrics, get_flight_plan_metrics).

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

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

'Use this when the user asks to get crawl activity metrics' is a circular trigger phrase, not routing guidance. It gives no when-not condition and never names an alternative among the metric-getting siblings, leaving the agent unable to disambiguate the crowded metrics family.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior. The description adds a real behavioral trait beyond those: results, notably website summaries, are visible only 'when the linked account is allowed to see it.' It does not cover failure behavior for unresolved references.

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

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

Two sentences, no waste, and the usage condition is front-loaded ahead of the return description. Every sentence earns its place.

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

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

For a single-parameter read tool with no output schema and full annotation coverage, the description supplies the trigger, the identifier forms, and a return summary. The shape of the returned details is only loosely characterized, but nothing critical for invoking it is missing.

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

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

With 0% schema description coverage, the schema alone only shows a string-or-number union. The description fully compensates by enumerating the accepted identifier forms (business name, email, numeric ID), which is exactly the meaning an agent needs to fill crewReference.

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

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

The description states a specific verb ('resolves') and resource ('Crew') and specifies the return ('its details, including website summaries'). It implicitly contrasts with the sibling get_current_crew by requiring an identified Crew, though it never names that alternative.

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

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

It gives a clear triggering condition: use when the user identifies a specific Crew by business name, email, or numeric ID. There are no explicit exclusions or named alternatives, so it falls short of the top tier.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds a meaningful scoping constraint — results are limited to data visible to the linked Market Brew account — which the annotations do not convey.

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

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

Two short sentences, zero filler, and the usage trigger is front-loaded before the return-scope caveat. Every sentence earns its place.

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

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

For a no-param, no-output-schema read tool, the description covers purpose, trigger, and result scope adequately. It could be slightly richer by hinting at what fields the returned crew record contains, but nothing essential is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the schema (empty object, 100% coverage) is fully sufficient. Baseline for a no-param tool applies.

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

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

States a specific verb (get/return) and resource (the currently linked Market Brew Crew) and frames it as a 'current/selected' lookup, which distinguishes it from the ID-based get_crew sibling. It does not explicitly name that sibling, 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.

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

Gives a clear trigger condition: 'use this when the user asks which Market Brew Crew is currently linked or selected.' It does not mention when not to use it or point to get_crew for ID-based lookups, so there is no explicit alternative routing.

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

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

Annotations already state readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds only 'Returns only data visible to the linked Market Brew account,' which is a minor scoping note. It does not disclose return format, pagination, or error behavior. Given annotations carry the load, this is barely adequate.

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

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

Two short sentences with no waste, but the first sentence is a tautology and the second is marginally useful. Front-loading is fine, but content is low-value.

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

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

With no output schema, 0% schema coverage, and two required parameters, the description should explain what the tool returns and what the parameters mean. It does neither, leaving the agent with insufficient guidance to invoke correctly beyond the obvious.

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

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

Schema description coverage is 0%, and the description mentions no parameters. Both 'crew' and 'licenseId' are required but undocumented in both schema and description. For a tool with 2 required parameters, this is a significant failure to compensate.

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

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

The description essentially restates the tool name ('get a customer license') without adding a specific verb+resource differentiation. The sibling 'list_customer_licenses' exists, but the description doesn't clarify how this differs from listing licenses. It's tautological.

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

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

The description says 'Use this when the user asks to get a customer license,' which is circular and provides no when-to-use vs. alternatives guidance. No mention of get_license_definition or list_customer_licenses as related tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety and idempotency profile is fully covered structurally. The description does add one genuinely useful behavioral fact - results are scoped to the linked Market Brew account's visibility - but says nothing about what "progress" states are returned, whether this is a polling operation, or how fresh the data is.

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

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

Two short sentences with no filler, and the usage condition leads. Size is appropriate for a simple read tool, though the brevity comes partly from under-specification rather than discipline.

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

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

With no output schema, 0% parameter coverage, two required undocumented parameters, and a crowded deep-crawl namespace, the description leaves real gaps: what fields come back, what the two arguments mean, and how this differs from sibling retrieval tools. It is not wrong, simply insufficient for the complexity of the surrounding surface.

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

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

Both required parameters (website, importId) have 0% schema description coverage, and the description never explains what either one means, what format importId takes, or whether website accepts a domain name, URL, or numeric ID. The schema's anyOf string/number unions make the ambiguity worse; the description should have compensated and does not.

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

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

The sentence names a recognizable verb+resource (get crawl seed import progress), so the intent is inferable, but it is framed as a usage trigger that essentially restates the tool name and title. It makes no attempt to separate this from closely related siblings such as get_deep_crawl_seed, list_deep_crawl_seed_attempts, or get_deep_crawl_schedule, so an agent must open the schemas to tell them apart.

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

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

It gives a trigger ("when the user asks to get crawl seed import progress"), but that trigger is circular - it says to use the tool when someone asks for exactly what the tool is named after. No alternative tool, prerequisite, or when-not-to-use condition is mentioned, despite five other deep-crawl 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.

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds one useful behavioral note — output is scoped to the linked Market Brew account — but says nothing about the schedule's format or coverage.

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

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

Two short sentences, no filler, with the usage condition front-loaded. It is efficient, though the second sentence is the only substantive content.

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

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

For a single-parameter read tool, the description leaves both the purpose ('explicit' schedule vs. other crawl data) and the parameter semantics unresolved, and there is no output schema to compensate.

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

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

Schema description coverage is 0% and the single 'website' parameter accepts either a string or a number with no explanation. The description adds nothing about whether this is a domain, URL, or internal ID, leaving the parameter ambiguous.

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

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

The description essentially restates the title: 'Use this when the user asks to get explicit crawl schedule.' It names a resource (crawl schedule) but 'explicit' is undefined and it offers no differentiation from siblings like get_crawl_metrics, get_deep_crawl_seed, or list_deep_crawl_seeds.

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

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

The trigger condition is circular — 'use this when the user asks to get explicit crawl schedule' — which tells the agent nothing beyond the tool name. No alternatives, prerequisites, or when-not-to-use conditions are named.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description does add one useful piece of context beyond annotations - the account-scoped visibility ('only data visible to the linked Market Brew account') - but nothing about what a seed record contains or how the two identifiers relate.

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

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

Only two sentences, but the first is tautological filler that earns nothing; the second, with the account-visibility constraint, is the only substantive content. Reasonably sized but front-loaded with waste.

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

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

With no output schema and two undocumented params, the description leaves the agent unable to reason about inputs or results. Given a read tool whose safety profile is already in annotations, it should at minimum explain the identifiers or point to the listing sibling.

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

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

Both required parameters (website, seedId) have 0% schema description coverage and the description says nothing about either. It does not clarify what a 'seedId' is, whether 'website' is a domain or a numeric ID (the schema allows string or number for both), or how they pair.

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

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

The sentence 'Use this when the user asks to get a crawl seed' merely restates the tool name and title with no added specificity. There is no distinction drawn from siblings like list_deep_crawl_seeds or get_deep_crawl_import, so an agent cannot tell what 'a crawl seed' actually is.

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

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

The stated trigger ('when the user asks to get a crawl seed') is circular - it defines use by the request rather than by any condition the agent can evaluate. No alternatives (e.g., list_deep_crawl_seeds for enumerating vs. this tool for fetching one) are mentioned.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds one genuinely useful behavioral fact — that results are scoped to the linked Market Brew account — which is auth/permission context the annotations do not convey. It says nothing about latency, pagination, or metric granularity, so it stays at a modest 3.

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

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

Two short sentences with no padding, and the scoping caveat is placed second where it belongs. It is efficient, though the first sentence spends its words restating the name rather than earning them.

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

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

There is no output schema and no return-value information, so the description should explain what 'metrics' actually contains — dimensions, time series, aggregation level — and it does not. For a metrics endpoint sitting alongside a dozen other metrics endpoints, this leaves the agent unable to tell what it will receive or how it differs from siblings.

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

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

Schema description coverage is 100% and the single 'query' object already enumerates customerId, crewIds, websiteId, serverHost, startDate, and endDate. The description contributes no additional parameter meaning, so the baseline of 3 applies.

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

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

The description is a tautological restatement of the tool name: 'Use this when the user asks to get Flight Plan metrics' adds no verb, scope, or resource explanation beyond what 'get_flight_plan_metrics' already says. It never defines what a 'Flight Plan' is or what kind of metrics are returned, so an agent cannot distinguish it from siblings like get_crawl_metrics, get_search_metrics, get_ranking_sensor_metrics, or get_task_metrics.

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

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

The only guidance is a circular trigger ('when the user asks to get Flight Plan metrics'), which offers no when-not condition, prerequisite, or named alternative among the many sibling metrics tools. Usage is implied at best and gives the agent nothing to route on.

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

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

Annotations already disclose readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds one piece of behavioral context beyond that: results are limited to data visible to the linked Market Brew account. It says nothing about behavior on a missing/invalid id or about the shape 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.

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

Two short sentences with no filler; the usage trigger is front-loaded. It is efficient, though the first sentence spends words restating the tool name rather than adding information.

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

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

With no output schema, the description carries the burden of explaining what is returned, and it only gestures at account-scoped visibility without describing the payload or error cases. For a single-entity fetch with an undocumented id parameter, an agent lacks enough to call it confidently.

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

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

Schema description coverage is 0% and the single required 'id' parameter (string or number) is completely undocumented. The description does not state what the id refers to, where to obtain it, or how it relates to ids returned by list_knowledge_bases, so it fails to compensate for the schema gap.

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

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

The description names a clear verb and resource ('get a Knowledge Base'), but it largely restates the tool name and title rather than sharpening the purpose. It does not distinguish this single-record fetch from siblings like list_knowledge_bases or count_knowledge_bases. The scope note about Market Brew account visibility is the only genuinely informative clause.

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

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

'Use this when the user asks to get a Knowledge Base' is implied usage that simply echoes the name, giving no real selection criteria. There is no mention of when to prefer this over list_knowledge_bases or count_knowledge_bases, nor any prerequisite such as needing a valid id.

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

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so safety is covered. The description adds one genuine piece of context—results are scoped to the linked Market Brew account—which is real value. It stops there, saying nothing about what the statistics contain or how freshness/pagination works.

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

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

Two short sentences with no bloat, which is structurally clean. However the first sentence is pure filler and the substantive account-scoping constraint is buried in the second, so it is not front-loaded with useful information.

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

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

There is no output schema, so the description carries the burden of conveying what comes back—yet it never says what a 'content-gap statistic' includes. For a stats-retrieval tool with nested query objects and nearby gap-listing siblings, more orientation is needed.

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

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

Schema description coverage is 100% and the single optional 'query' filter is documented in the schema ('websiteId or serverHost'), so baseline 3 applies. The description adds nothing about filter semantics or defaults beyond what the schema already states.

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

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

The description essentially restates the title verbatim ('Use this when the user asks to get Launchpad content-gap statistics'). It names the resource but adds no distinguishing detail versus siblings like list_launchpad_keyword_gaps and list_launchpad_prompt_gaps. This is tautology rather than an independent statement of purpose.

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

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

The trigger is circular—'use this when the user asks to get Launchpad content-gap statistics' just echoes the tool's own name. No when-to-use vs. when-not, and no mention of the closely related launchpad gap-listing siblings that an agent would need to choose between.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds a small amount of useful context with 'Returns only data visible to the linked Market Brew account,' but says nothing about return format or the notion of a license definition. With annotations carrying the safety burden, a 3 is appropriate.

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

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

The definition is short and front-loaded, which is good, but the first sentence is pure filler that echoes the tool name. It is appropriately sized yet does not earn its place.

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

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

For a read-only tool whose annotations cover safety, the remaining gap is the fully undocumented required parameter and the undefined concept of a 'license definition.' Without an output schema, the description should explain more about what is returned and what identifier shape the parameter expects, and it does not.

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

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

Schema description coverage is 0%, so the single required parameter 'licenseDefinitionSummary' is documented nowhere. The description gives no meaning, format, or example for this parameter, leaving the agent to guess what value to supply.

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

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

The description restates the tool name almost verbatim ('Use this when the user asks to get a license definition'), which is a tautology rather than a specific statement of what the tool does. It does not distinguish this tool from close siblings such as list_license_definitions, get_license_definition_form_fields, or get_customer_license.

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

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

The only guidance is a circular 'when the user asks to get a license definition,' which provides no real disambiguation from the many other license-related siblings. There is no statement of when to prefer this over list_license_definitions or get_customer_license.

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

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

Annotations already declare readOnly, idempotent and non-destructive behavior, so the safety profile is covered. The description does add one genuinely useful piece of behavioral context: results are scoped to 'the linked Market Brew account,' which tells the agent about visibility/auth boundaries. Nothing else (paginations, shape of the field list) is disclosed, so this stays at a minimum-viable 3.

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

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

Two short sentences, front-loaded with the trigger and no filler. It is appropriately sized for its content, though the brevity reflects thin content rather than tight editing.

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

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

For a read tool with no output schema, no parameter documentation, and no annotations explaining return content, the description leaves the agent without enough to invoke it confidently. It never defines what 'form fields' are returned, how the identifier parameter is obtained, or how this differs from get_license_definition.

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

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

Schema description coverage is 0% and the single parameter licenseDefinitionSummary (accepting a string or number) is left completely unexplained — the description does not say whether it is an ID, a name, or where to obtain it. Since coverage is low, the description was required to compensate and does not, so it falls below the baseline.

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

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

The description essentially restates the title: 'get license-definition form fields' is the tool name with spaces. It never explains what a form field is here, what the returned field set describes, or how it relates to the sibling get_license_definition / list_license_definitions, so an agent cannot distinguish its purpose from those siblings.

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

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

The only guidance is the circular trigger 'use this when the user asks to get license-definition form fields,' which provides no when-to-use condition beyond the name itself. No alternatives are named and no prerequisite (e.g., needing a license definition first) is stated, even though get_license_definition exists as an obvious sibling.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description does add one useful behavioral fact beyond the annotations: results are scoped to data visible to the linked Market Brew account, which is a visibility/permission constraint worth knowing. It does not describe return contents or error behavior for a missing id.

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

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

Two short sentences with no filler and the trigger placed first. The first sentence, however, duplicates the title rather than adding information, so it is efficient but slightly redundant.

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

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

For a simple read-only single-resource fetch with complete annotations and one obvious parameter, the description covers the essentials. It still omits what the monitor payload contains and how a missing/foreign id is handled, which would help an agent set expectations.

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

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

Schema description coverage is 0% and the single 'id' parameter (string or number, required) is not explained in the description at all. The semantics are self-evident from the name 'id' on a get-by-id tool, so this is acceptable but adds no meaning beyond the schema.

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

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

The description states a retrieve-by-identifier operation on a 'Listen keyword monitor', so the verb+resource pair is present, but the phrasing largely restates the tool title and does not explicitly contrast with the sibling list_listen_monitors. An agent can infer this returns a single monitor, but the differentiation is left implicit.

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

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

'Use this when the user asks to get a Listen keyword monitor' provides a trigger condition, but it is circular (it repeats the tool's own purpose) and names no alternatives such as list_listen_monitors for enumeration. Usage is implied rather than specified.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds one genuinely new fact — that results are scoped to the linked Market Brew account — which is useful authorization context. Beyond that it says nothing about return shape, pagination, or metric definitions.

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

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

Two short sentences with no padding, but the first sentence is pure tautology and carries no information, so the brevity comes at the cost of substance rather than from efficient density.

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

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

With no output schema, the description should explain what the metrics actually are and what a caller receives, which it does not. Annotations cover safety and the schema covers the filter object, so the basics are present, but an agent cannot tell what data comes back or how it relates to the sibling metrics endpoints.

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

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

Schema description coverage is 100%, and the single 'query' object parameter already documents the supported filters (customerId, crewIds, websiteId, serverHost, startDate, endDate). The description adds no syntax, format, or defaulting information 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.

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

The description restates the tool name almost verbatim: 'Use this when the user asks to get Ranking Sensor metrics.' It gives no indication of what 'Ranking Sensor metrics' actually contain or how this differs from the many sibling metric tools (get_search_metrics, get_task_metrics, get_crawl_metrics). This is effectively a tautology.

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

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

The only guidance is a circular trigger condition that simply echoes the tool name. There is no statement of when to prefer this over sibling metrics tools, no prerequisites, and no exclusion criteria.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact: results are scoped to data visible to the linked Market Brew account, which is an authorization/visibility constraint not expressed in the annotations. It still omits any note on result volume, pagination, or metric granularity.

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

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

Two short sentences with no padding, and the account-scoping caveat is placed where it will be read. The first sentence is largely wasted words since it only echoes the tool name, but the total length is tight enough that nothing is bloated.

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

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

For a simple, read-only, zero-required-parameter tool with full schema coverage and annotations covering safety, the description is minimally sufficient. It does not say what metrics are returned or at what granularity, and there is no output schema to fill that gap, so an agent still lacks a clear picture of the result content.

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

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

There is a single optional 'query' parameter whose nested filter fields are fully documented in the schema (100% coverage, including customerId, crewIds, websiteId, serverHost, startDate, endDate). The description contributes nothing about filter semantics or date-range behavior, so the baseline 3 applies when the schema carries the full burden.

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

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

The description names a verb+resource (get Search API metrics), so the action is identifiable, but the phrasing is effectively a restatement of the tool name and title with no differentiation from siblings such as get_ranking_sensor_metrics, get_crawl_metrics, or get_task_metrics. An agent cannot tell from this text what makes 'Search API metrics' distinct from the other metric tools.

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

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

"Use this when the user asks to get Search API metrics" is a circular trigger that adds no routing information. No alternatives are named, no when-not-to-use condition is given, and nothing distinguishes it from the many other metrics retrieval 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.

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description does add one piece of real behavioral context — output is scoped to 'the linked Market Brew account' — which is useful access-scope information not present in the annotations. It stops there, saying nothing about what a 'detail' record contains or pagination/limits.

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

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

Two short sentences, front-loaded with the usage trigger and scoping caveat. There is no padding, though the first sentence is largely redundant with the tool name.

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

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

With no output schema and zero parameter documentation, the description should carry more burden for a 2-required-param lookup tool. It covers access scope but omits parameter meaning, the relationship to list_search_widget_history, and any indication of what the returned detail contains.

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

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

Schema description coverage is 0% for both required parameters (searchWidgetId, searchHistoryId), and the description supplies no meaning for either. An agent must guess the ID types, formats, and where they come from, so the description fails to compensate for the schema gap.

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

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

The description essentially restates the tool name: 'get Search Widget query history detail' for a tool named get_search_widget_history. It identifies the resource (a single search widget history entry) but does not distinguish it from the sibling list_search_widget_history, leaving the singular-vs-list distinction to be inferred from the name alone.

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

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

'Use this when the user asks to get Search Widget query history detail' is a circular trigger that adds no condition beyond the name. There is no mention of when to prefer this over list_search_widget_history or get_search_widget_session, and no prerequisites are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral detail beyond that: the result is scoped to data visible to the linked Market Brew account, which signals an authorization boundary. It does not describe return shape or the meaning of session state, so it stays at a modest 3.

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

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

Two short sentences, front-loaded with the usage trigger and followed by the scoping caveat. Nothing is padded, though the first sentence is wasted effort since it merely echoes the title.

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

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

There is no output schema, a nested object parameter, and an undocumented required ID, yet the description explains none of what a 'session state' payload contains or how searchWidgetId is obtained. For a tool with this much structural complexity, the description leaves significant gaps.

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

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

Schema description coverage is only 50%: the nested 'query' object is documented (websiteHost), but the required searchWidgetId has no description at all. The description adds no parameter meaning to compensate, leaving the required identifier's format and source unexplained. With low coverage the description should carry more of this burden and does not.

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

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

The description is essentially a restatement of the tool name and title: 'get Search Widget session state' tells the agent nothing beyond what the name already conveys. It does name a resource (session state), but there is no differentiation from siblings like get_search_widget_history or list_search_widget_history, which an agent would plausibly confuse with this tool.

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

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

'Use this when the user asks to get Search Widget session state' is circular guidance that restates the purpose rather than explaining when to select this tool over alternatives. No exclusions, no prerequisites, and no mention of the closely named history tools that an agent could pick instead.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact: results are scoped to data visible to the linked Market Brew account. It omits any error behavior for an unknown taskId or what the returned record contains.

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

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

Two short sentences, no filler, with the purpose front-loaded before the scoping note. Efficient, though the first sentence is partly redundant with the tool name and title.

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

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

For a simple single-parameter read tool with no output schema, the description is minimally adequate: safety is covered by annotations and account scoping is stated. The gaps are the undocumented taskId and the absence of any statement about what the tool returns or how it fails.

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

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

Schema description coverage is 0% and the single required parameter (taskId) is never mentioned in the description. The schema shows taskId accepts a string or number but gives no format hints; the description does nothing to compensate or explain where a valid task ID comes from.

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

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

States a specific verb ('get') and resource ('a Ranking Sensor task'), which distinguishes it from sibling metric/history tools like get_task_metrics and get_task_history. It does not, however, clarify how it differs from list_tasks or list_task_children, so sibling differentiation is only partial.

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

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

The only guidance is 'Use this when the user asks to get a Ranking Sensor task,' which simply restates the tool's purpose as a trigger phrase. There is no mention of when to prefer it over list_tasks/get_task_history, nor any prerequisite (e.g., needing a taskId obtained elsewhere).

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description does add a genuine access-scope disclosure ('Returns only data visible to the linked Market Brew account'), but says nothing about pagination defaults or result size despite the query supporting offset/pageSize.

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

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

Two short sentences with no filler, and the usage trigger is front-loaded. Efficient, though the second sentence is the only substantive content.

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

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

For a two-parameter tool with a nested filter object and no output schema, the description is minimally adequate. It establishes scope and access limits, but omits any hint about the filter object's role or the shape/size of returned history data.

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

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

Schema description coverage is only 50% and the description adds no parameter meaning at all. It never mentions that taskId is required or explains the filter object (websiteId, startDate, pageSize, etc.), leaving half the parameter surface undocumented.

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

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

The description essentially restates the tool title ('get one task's calculation history'), so it borders on tautology. It does scope the operation to a single task, which implicitly distinguishes it from the sibling list_task_history, but it never names that sibling or clarifies what 'calculation history' contains.

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

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

It gives a trigger condition ('when the user asks to get one task's calculation history'), which is implied usage rather than explicit guidance. No alternatives are named (e.g. list_task_history for multi-task views) and no when-not conditions are provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and a closed-world scope, so the safety profile is fully covered. The description adds one genuinely useful non-annotation fact: results are scoped to 'data visible to the linked Market Brew account,' which tells the agent about permission-based filtering. However it says nothing about what the metrics contain, granularity, or time semantics.

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

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

Two short sentences, no waste, and front-loaded. But the brevity comes at the cost of substance — the first sentence is pure restatement, so the sentence budget is spent on something the agent already knew from the name.

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

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

There is no output schema, so the description should describe what 'task workload metrics' returns (counts? per-crew breakdown? time series?), and it does not. For a metrics tool with many look-alike siblings and no output schema, this leaves the agent unable to predict the response or confidently choose this tool.

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

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

Schema description coverage is 100% and the single 'query' parameter's filters (customerId, crewIds, websiteId, serverHost, startDate, endDate) are fully documented in the schema. The description adds no parameter info, so the baseline 3 applies; nothing here compensates or detracts.

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

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

The description is essentially a restatement of the tool name and title: 'Use this when the user asks to get task workload metrics.' It does not specify what 'task workload metrics' actually contains or how it differs from close siblings like get_top_task_metrics, get_task_history, or get_flight_plan_metrics. No distinguishing verb or resource detail beyond the name.

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

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

The only guidance is a tautological trigger ('when the user asks to get task workload metrics'), which the agent could already infer from the name. There are several metric-related siblings (get_top_task_metrics, get_search_metrics, get_usage_metrics, get_crawl_metrics) and the description gives no criteria for choosing among them.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds one useful behavioral fact — results are scoped to the linked Market Brew account — but says nothing about aggregation, sort defaults, or pagination behavior of the metrics.

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

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

Two short sentences, front-loaded with the usage trigger, with no filler. The brevity is appropriate, though the first sentence is wasted on restating the name.

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

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

For a metrics tool sitting among close siblings (get_task_metrics, get_search_metrics, list_top_tasks) with no output schema, the description should distinguish scope and return shape. It leaves an agent unable to choose confidently between this and adjacent metrics tools.

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

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

Schema description coverage is 100% and the single nested 'query' object already enumerates the filter fields (websiteId, serverHost, taskTitle, sortBy, offset, pageSize). The description contributes nothing beyond that, so the baseline 3 applies.

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

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

"Use this when the user asks to get top-task metrics" essentially restates the tool name and title without adding a distinct verb+resource characterization. It never explains what a 'top task' is or how the metrics differ from get_task_metrics or list_top_tasks.

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

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

The 'when to use' clause is circular — the user asking for the thing the tool is named after is not guidance. No alternatives (get_task_metrics, list_top_tasks) or conditions are named.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful piece of context — the account-scoped visibility limit ('only data visible to the linked Market Brew account') — but says nothing about time-range limits, granularity, or result size.

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

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

Two short sentences with the visibility constraint front-loaded after a wasted opening clause. It is compact, but the first sentence carries no information beyond the tool name, so half the text does not earn its place.

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

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

No output schema exists, so the description is the only place return shape could be conveyed, and it says nothing about granularity, time bucketing, or response format. For a history-metrics tool with a free-form nested query object, this leaves meaningful gaps.

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

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

With a single parameter and 100% schema description coverage, the schema already documents crewIds, metricKeys, startDate, endDate, and scale. The description contributes nothing about the query object, so the baseline 3 applies.

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

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

The description essentially restates the tool name and title ('get usage metric history') without adding a distinguishing verb/resource combination. It never differentiates from close siblings like get_usage_metrics, get_usage_report, or get_usage_report_history, so an agent cannot tell which history-oriented tool to pick.

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

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

'Use this when the user asks to get usage metric history' is circular — it only says to use the tool when its own name is requested. No when-not conditions, no prerequisites, and no mention of the several near-duplicate usage siblings that would be the real alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds one genuine piece of non-obvious context: results are scoped to data visible to the linked Market Brew account. It says nothing about aggregation windows, pagination, or freshness, so it adds value but not richly.

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

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

Two short sentences, so raw length is fine, but the first sentence is pure restatement of the name and earns no place. Front-loading is acceptable; only the account-scoping clause carries information.

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

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

With no output schema, the description should at least hint at the shape or granularity of returned metrics, and it does not. The nested query object also goes unexplained in the description. For a metrics-aggregation tool surrounded by similar siblings, this leaves the agent under-informed.

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

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

There is a single optional 'query' parameter and the schema documents it at 100% coverage, including the full list of accepted filters (customerId, crewIds, websiteId, serverHost, startDate, endDate). The description contributes nothing beyond the schema, so the baseline 3 applies.

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

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

The description merely restates the tool name and title ('get aggregate system usage metrics') with no added specificity about what is aggregated or over what dimensions. It does not distinguish this tool from close siblings such as get_usage_report, get_usage_metric_history, or get_usage_report_history, which an agent would need to tell apart.

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

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

'Use this when the user asks to get aggregate system usage metrics' is a circular condition — it names no distinguishing user intent, no prerequisite, and no alternative tool. With several usage/report/metrics siblings present, the absence of any routing guidance leaves selection ambiguous.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a useful scoping fact — results are limited to the linked Market Brew account — which is genuine behavioral context. It does not disclose what a 'report definition' contains 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.

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

Two short sentences, front-loaded and free of filler. It is appropriately sized; the brevity is fine given the low complexity.

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

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

A read-only lookup with one required param and no output schema needs to at least identify the id's meaning and what a report definition is. The account-scoping note helps, but the id semantics gap and tautological purpose keep it at minimum viable.

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

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

There is a single required 'id' parameter with 0% schema description coverage, so the description must compensate. It says nothing about what the id refers to (definition id? report id?) or accepted format, leaving significant ambiguity.

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

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

The description restates the title almost verbatim ('get a usage report definition'), which is tautological rather than clarifying. It does not name the resource scope or distinguish it from siblings like get_usage_metrics, get_usage_metric_history, or list_usage_reports.

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

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

The phrase 'Use this when the user asks to get a usage report definition' is a tautology of the name and offers no real routing guidance. Notably, it fails to distinguish this from list_usage_reports or the usage metric siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured fields. The description adds one piece of genuinely new context — results are restricted to data visible to the linked Market Brew account. It says nothing about pagination, history depth, or ordering, so it clears the lowered bar but only barely.

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

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

Two short sentences with the trigger front-loaded and zero padding, which is structurally sound. However, the first sentence carries no information beyond the tool name, so it does not earn its place, and the total length is under-specified for a two-parameter tool with a nested object.

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

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

There is no output schema, so the description should help the agent anticipate the return shape, but it only says the data is account-scoped. Combined with an undocumented required 'id', an unenumerated nested query object, and heavy sibling ambiguity, the definition leaves an agent under-equipped to call this tool correctly.

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

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

Schema description coverage is 50%: the nested 'query' object is documented with its filter keys, but the required 'id' parameter has no description in either the schema or the description text. The description never explains that 'id' identifies the usage report whose history is being fetched, so it does not compensate for the coverage gap.

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

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

The description is essentially a restatement of the tool name: "Use this when the user asks to get usage report history." It does not state what a usage report history actually contains or how it differs from close siblings such as get_usage_report, get_usage_metric_history, get_usage_metrics, and list_usage_reports. The only substantive content is the account-visibility clause, which is scope rather than purpose.

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

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

The "use this when..." phrasing is circular — it triggers on the phrase "usage report history" rather than on a recognizable user intent or data condition. No exclusions or alternatives are named, even though the sibling list contains at least four other usage-related tools an agent must choose between. Effectively no routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive/closed-world behavior, so the safety profile is covered. The description adds a useful visibility constraint ('only data visible to the linked Market Brew account'), but says nothing about scoping to the required askWidgetId or about 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.

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

Two short sentences with no filler, and the usage trigger is front-loaded ahead of the account-visibility note. Efficient, even if under-specified.

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

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

There is no output schema, so the description should carry more of the return-shape burden; it only hints at visibility scope and never explains what a conversation listing contains. With a required widget id and a nested filter object, an agent is left with open questions.

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

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

Schema description coverage is only 50%: the 'query' filter object is documented in the schema, but the required askWidgetId is not described anywhere. The description contributes no parameter meaning at all, so it fails to compensate for the coverage gap.

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

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

The description states 'list Ask conversations,' which is a clear verb+resource but essentially restates the tool name and title. It offers no differentiation from close siblings such as count_ask_widget_conversations or get_ask_conversation, so an agent must infer the distinction.

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

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

'Use this when the user asks to list Ask conversations' gives an implied trigger condition, but there is no guidance on when to prefer this over the count_ or get_ siblings, and no stated prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the safety profile is covered. The description adds one useful piece of context — that results are scoped to the linked Market Brew account — but says nothing about pagination, ordering, or result volume.

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

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

Two short sentences, front-loaded with the usage trigger followed by the scoping note. No wasted text, though the first sentence is close to pure name restatement.

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

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

For a zero-parameter read-only list tool with full annotation coverage, this is adequate but thin: it never indicates what a returned widget looks like or whether the list is bounded, leaving the agent without expectations about the response.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies no filtering inputs are needed.

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

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

The description states a verb (list) and resource (Ask Widgets), so the basic action is clear. However, it largely restates the tool name/title and gives no differentiation from sibling list tools such as list_content_boosters or list_ask_conversations, nor does it define what an 'Ask Widget' is.

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

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

'Use this when the user asks to list Ask Widgets' is essentially a restatement of the tool name as a trigger phrase rather than genuine guidance. There is no mention of alternatives, prerequisites, or when not to use it (e.g., when a count or a single widget lookup is wanted).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds one genuinely useful behavioral fact — results are scoped to data visible to the linked Market Brew account — but says nothing about it being a scoped read against the required id or about result size/pagination.

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

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

Two short sentences, usage first and scoping second, with no padding. It is appropriately sized, though the second sentence would be more valuable if paired with the missing parameter explanation.

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

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

For a simple read-only list tool with no output schema and full annotation coverage, the description is nearly adequate — but the required id parameter is left completely undefined, which is a real gap for correct invocation.

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

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

Schema description coverage is 0% and the description never mentions the single required "id" parameter. An agent cannot tell from either source whether this id identifies the parent Content Booster, the account, or something else, which is the one piece of information this tool most needs.

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

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

The description conveys a list verb plus the resource (Content Booster assets), so the basic operation is identifiable. However, it largely restates the tool name and title, and it does nothing to distinguish this tool from closely related siblings such as list_content_boosters and get_content_booster_asset.

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

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

"Use this when the user asks to list Content Booster assets" is circular — the trigger condition is just the tool name restated, so no real when-to-use guidance is added. There is no mention of alternatives (e.g., list_content_boosters vs this one) 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.

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds one useful behavioral fact — results are scoped to the linked Market Brew account — but omits pagination behavior (offset/pageSize exist in the schema) and return shape. Adequate given annotations, with real gaps.

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

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

Two short sentences with the trigger condition front-loaded and zero filler. It is efficiently structured, though the brevity edges toward under-specification rather than optimal density.

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

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

With no output schema, the description should describe what a listing returns and how pagination works, but it does neither. Annotations and the 100%-covered schema carry the safety and parameter burden, leaving the description minimally sufficient for a list tool with a nested filter object.

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

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

Schema description coverage is 100% and the query object already enumerates websiteId, serverHost, title, status, sortBy, sortDir, offset, and pageSize. The description adds no syntax, defaults, or filter semantics beyond the schema, so baseline 3 applies.

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

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

The description states a clear verb and resource ("list Content Boosters"), but it largely restates the tool name and title rather than adding specificity. It does not distinguish this listing tool from near-siblings like get_content_booster, list_content_booster_assets, or count_content_boosters. The only added detail is the account-scoping note in the second sentence.

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

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

"Use this when the user asks to list Content Boosters" gives an implied trigger condition but no alternatives or exclusions. It never tells the agent when to prefer count_content_boosters, get_content_booster, or list_content_booster_assets instead. Guidance is minimal but present.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: results are scoped to data visible to the linked Market Brew account, which constrains expectations about completeness.

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

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

Three tightly written sentences, front-loading the usage trigger before the filtering mechanics and scope note. No filler, though the closing visibility sentence is somewhat close to restating the account scoping already implied by the title.

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

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

For a single-nested-object list tool with no output schema, the description covers when to use it, how to filter, and the visibility boundary. Only the shape/pagination of returned website records is left off, which is a minor gap for a list operation.

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

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

Schema coverage is 100%, so the query filter fields are already documented. The description goes beyond the schema by explaining the semantic format of crewIds ('comma-separated numeric Crew IDs') and how to obtain the value via get_crew, adding practical meaning to the single nested parameter.

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

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

States a specific verb and resource ('list current or licensed websites') and ties it to the account's visibility scope, which cleanly separates it from siblings like list_customer_licenses or get_crew. An agent can identify the tool's job from the first sentence alone.

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

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

Gives an explicit trigger ('when the user asks for current or licensed websites') and a concrete prerequisite route ('use get_crew first when the user supplies a business name or email'). It does not, however, contrast this tool against near neighbors such as list_customer_licenses, so the alternative coverage is partial.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds account-visibility scoping ('only data visible to the linked Market Brew account'), which is useful context, but says nothing about pagination, result limits, or return shape.

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

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

Two short sentences, front-loaded with the trigger condition followed by the visibility constraint. No filler.

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

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

Adequate for a simple list tool with annotations carrying the safety profile and no output schema. However, it leaves the sole required parameter entirely unexplained and gives no sense of result content or scoping by crew.

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

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

The single parameter 'crew' has 0% schema description coverage and an anyOf string/number type, yet the description never mentions it or explains what a crew identifier is or how to obtain it. The description fails to compensate for the documented schema gap.

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

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

States a clear verb+resource ('list customer licenses'), matching the title. It is distinguishable from get_customer_license (singular detail fetch) and list_license_definitions, though it does not explicitly name those siblings.

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

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

Provides a trigger condition ('when the user asks to list customer licenses') but no when-not guidance and no explicit alternatives such as get_customer_license for a single license. Usage is implied rather than fully scoped.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful piece of context beyond that – the account-scoping constraint ('only data visible to the linked Market Brew account') – but says nothing about pagination, ordering, or what a version represents.

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

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

Two short sentences, appropriately sized and front-loaded. The first sentence largely duplicates the title, which costs a little, but there is no padding or verbosity.

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

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

For a tool with a required, undocumented parameter and no output schema, the description does little more than name the operation. It never explains what a 'retained inventory version' is or how the website parameter shapes the result.

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

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

There is one parameter ('website') with 0% schema description coverage, and the description does not mention it at all, so nothing compensates for the gap. The anyOf string/number typing is left entirely unexplained.

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

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

The description restates the title almost verbatim ('list retained crawl inventory versions'), providing no verb+resource detail beyond what the name already conveys. It does not distinguish this tool from close siblings like list_deep_crawl_seeds or list_deep_crawl_seed_attempts.

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

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

It offers only a circular trigger ('use when the user asks to list retained crawl inventory versions') with no conditions, prerequisites, or named alternatives. An agent has no way to know why it would pick this over the many other list_deep_crawl_* tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and non-openWorld, so the safety profile is covered. The description adds one useful non-obvious fact, that results are scoped to the linked Market Brew account's visibility, but omits pagination behavior and result shape; with annotations doing the heavy lifting, a 3 is appropriate.

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

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

Two short sentences with no filler, and the visibility scoping caveat is stated plainly. It is well-sized, though the first sentence is largely redundant with the title, wasting part of the already-minimal budget.

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

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

For a tool with two required, undocumented parameters, a nested filter object, and no output schema, the description should at least explain what identifies a seed attempt and how results are returned or paged. It instead leaves the agent with only a circular trigger and one scoping sentence, so it is not complete enough to invoke confidently.

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

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

Schema coverage is only 33%: the 'query' param is described in-schema (offset/pageSize) but 'seedId' and 'website' are undocumented, and both are required. The description provides no clarification of these parameters or their accepted formats, so it fails to compensate for the low coverage.

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

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

The description names the resource ('crawl seed attempt history') and implies a list operation, but it is essentially a restatement of the title 'List crawl seed attempt history.' It offers no differentiation from close siblings such as export_deep_crawl_seed_attempts or list_deep_crawl_seeds, leaving the agent to infer scope from the name alone.

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

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

'Use this when the user asks to list crawl seed attempt history' is a circular trigger that restates the purpose rather than giving real conditions. It never mentions when to prefer this over export_deep_crawl_seed_attempts or summarize_deep_crawl_seed_errors, so no genuine routing guidance is provided.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds a useful scoping note that results are limited to data visible to the linked Market Brew account, but says nothing about return volume, pagination, or result shape.

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

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

Two short sentences, front-loaded with the trigger condition, no filler. The first sentence largely restates the title, which is the only minor waste.

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

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

For a read-only list tool with no output schema and a nested query object offering many filters, the description omits return format, pagination, and default sort behavior. It is adequate but leaves real gaps an agent would want filled.

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

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

Schema description coverage is only 50%: the required 'website' parameter has no description, and the description does not explain it or give format examples. The only documented param (query, with its filter list) is already fully described in the schema, so the description adds no parameter meaning.

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

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

States a clear verb (list) plus the specific resource (Full Site Intelligence crawl seeds), and the product name disambiguates it from generic 'seeds'. It does not, however, distinguish itself from close siblings like list_deep_crawl_seed_attempts or export_deep_crawl_seeds.

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

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

The opener 'Use this when the user asks to list...' gives implied usage context, but there is no guidance on when to prefer this over export_deep_crawl_seeds, list_deep_crawl_seed_attempts, or get_deep_crawl_seed.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds one useful behavioral fact — results are scoped to the linked Market Brew account — but says nothing about return shape or pagination defaults.

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

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

Two short sentences with the usage trigger front-loaded and no filler. It could be marginally tighter but every sentence carries information.

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

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

For a simple, optional-parameter list tool whose annotations cover safety and whose schema documents filtering, the description supplies the needed usage trigger and the account-scoping constraint. No output schema exists, but for a list endpoint the missing return detail is minor.

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

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

Schema description coverage is 100%; the single query parameter and its name/pageSize/offset filters are fully documented in the schema. The description adds no parameter meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb (list) and resource (Knowledge Bases), so the core action is unambiguous. It does not differentiate from close siblings like count_knowledge_bases or get_knowledge_base, which would require the agent to infer the distinction.

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

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

"Use this when the user asks to list Knowledge Bases" gives a clear trigger condition, which is more than most siblings offer. However, it names no alternatives or exclusions, so the agent must infer that count_knowledge_bases is for totals and get_knowledge_base for a single record.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description usefully adds the account-scoping constraint ('only data visible to the linked Market Brew account'), but says nothing about pagination, result size, or the filter behavior beyond what the schema states.

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

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

Two short sentences with no bloat, but the first sentence is pure tautology that repeats the tool name and carries no information, while the second carries the only real content. Front-loaded, but half the text does not earn its place.

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

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

For a single-optional-parameter read tool with full annotation coverage and no output schema, the definition is minimally adequate. However, it never clarifies the concept of a keyword gap or routes the agent away from the sibling prompt-gaps tool, leaving the main selection ambiguity unresolved.

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

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

Schema description coverage is 100%, and the schema itself enumerates the filter keys (websiteId, serverHost, keyword, source, maxSimilarity, sortBy, sortDir, offset, pageSize). The description adds no parameter semantics of its own, so the baseline 3 for a fully documented schema is appropriate.

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

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

The description names a specific verb (list) and resource (Launchpad keyword gaps), but the first sentence is essentially a restatement of the tool name and title. It never explains what a 'keyword gap' is or how this differs from the sibling list_launchpad_prompt_gaps, so an agent has no basis for distinguishing the two.

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

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

'Use this when the user asks to list Launchpad keyword gaps' merely mirrors the name rather than giving real triggering conditions. No alternatives, exclusions, or prerequisites are mentioned, and the closely related list_launchpad_prompt_gaps is not referenced.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description does add one useful behavioral fact beyond the annotations: results are scoped to the linked Market Brew account. That is real added context, but nothing is said about pagination, result shape, or volume.

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

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

Two short sentences with no filler, and the trigger condition is front-loaded. It is efficient, though the brevity comes at the cost of substance rather than because everything needed is already present.

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

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

There is no output schema, so the description carries the burden of explaining what is returned; it only notes account scoping, not the shape or fields of the gap records. Given the nested query object and the presence of a closely related sibling, the definition is minimally viable but leaves clear gaps.

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

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

Schema description coverage is 100%, and the single nested 'query' object is documented in the schema with its filter fields (websiteId, serverHost, prompt, source, maxSimilarity, sortBy, sortDir, offset, pageSize). The description adds no parameter meaning at all, so the baseline of 3 applies.

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

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

The sentence restates the tool name almost verbatim ('Use this when the user asks to list Launchpad prompt gaps') without explaining what a prompt gap actually is. It also fails to distinguish this tool from the sibling list_launchpad_keyword_gaps, so an agent cannot tell them apart from the description alone.

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

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

The only guidance is 'use when the user asks to list Launchpad prompt gaps,' which is a restatement of the name rather than a usage condition. No alternatives, exclusions, or prerequisites are mentioned, even though a near-identical sibling (list_launchpad_keyword_gaps) exists and needs disambiguation.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral fact — results are scoped to the linked Market Brew account — but says nothing about pagination, result ordering, or volume limits.

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

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

Two short sentences, front-loaded with the usage trigger and followed by the scoping constraint. There is no padding, though the first sentence largely repeats the tool name and earns little on its own.

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

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

For a zero-parameter read-only lister with no output schema, the description is adequate on invocation but omits any hint of what a license definition contains or how results are shaped. A brief note that a sibling tool retrieves a single definition would have closed the remaining gap.

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

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

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies; the description introduces no parameter-level confusion.

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

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

States a specific verb+resource ('list license definitions') and adds the scope caveat that results are limited to data visible to the linked Market Brew account. It does not explicitly distinguish itself from the sibling get_license_definition, so it stops 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.

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

The first sentence gives a trigger condition ('when the user asks to list license definitions'), but it is circular with the tool name and purpose rather than discriminating. No mention of the get_license_definition alternative for retrieving a single definition, and no when-not guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds a real scope constraint (only data visible to the linked Market Brew account), which is useful context, but says nothing about pagination, result caps, or ordering.

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

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

Two short sentences with no filler, and the usage condition is front-loaded before the scope note. Slightly terse given the nested query object, but every sentence earns its place.

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

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

For a simple read-only list tool with no output schema, the description covers purpose and data scope but omits output shape and pagination behavior. Adequate but not complete for an agent planning a listing call.

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

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

Only one optional parameter and schema description coverage is 100%, so the schema fully documents the query object and its websiteId/serverHost filters. The description adds no filter syntax or format detail, so baseline 3 applies.

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

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

States a specific verb (list) and resource (Listen keyword monitors), and the title reinforces it. It is distinguishable from get_listen_monitor and count_listen_monitors, though the description never names those siblings explicitly.

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

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

"Use this when the user asks to list Listen keyword monitors" gives a trigger condition but no alternatives or exclusions. An agent cannot tell from this alone when to prefer it over count_listen_monitors or get_listen_monitor; usage is only implied by the verb.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description does add one genuinely useful behavioral fact beyond the annotations — results are scoped to data visible to the linked Market Brew account — but says nothing about pagination, result volume, or what happens with an invalid/unauthorized runId.

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

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

Two short sentences with the trigger placed first and the scoping caveat second; nothing is padded. The first sentence is borderline boilerplate restating the title, which keeps it just short of a 5.

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

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

With no output schema, one undocumented parameter, and no annotation gaps to lean on, the description should explain at least the shape of the returned artifact list and how to obtain the runId. Instead it omits both, leaving the calling agent under-informed for a tool whose only input is undocumented.

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

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

Schema description coverage is 0% and the single parameter runId has no description at all in the schema (an anyOf of string/number with no meaning attached). The description never mentions runId, so an agent gets no hint about where to source it or that it should come from list_listen_runs — a clear miss for a 1-parameter tool.

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

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

The description states a specific verb+resource — listing artifacts extracted during a Listen run — and the runId plus 'Listen' framing distinguishes it from siblings like list_listen_runs and list_listen_monitors. However, it never defines what an 'artifact' actually is, so the resource remains semantically opaque.

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

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

'Use this when the user asks to list artifacts extracted during a Listen run' gives an implied trigger but is essentially a paraphrase of the title. There is no when-not guidance and no mention of the relevant alternatives (e.g. list_listen_runs to obtain the runId, list_listen_monitors for monitor-level data).

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safe-read profile is covered. The description adds a useful multi-tenant scoping constraint ('only data visible to the linked Market Brew account') but omits pagination and result-shape behavior.

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

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

Two short sentences with no filler, and the usage trigger is front-loaded ahead of the scoping note. Efficient, though minimal.

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

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

There is no output schema, so the description should shoulder more of the return-value burden. It covers visibility scoping but says nothing about what a 'run' contains, its ordering, or whether results are paginated, leaving gaps for a list tool.

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

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

Schema coverage is 0% and the single 'id' parameter is undocumented in the schema. The description only weakly implies that 'id' is the monitor identifier ('runs for a Listen keyword monitor') without stating it, so it fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('list runs for a Listen keyword monitor'), making the operation and scope clear. It does not explicitly differentiate itself from close siblings like get_listen_monitor or list_listen_run_artifacts, but the resource is unambiguous.

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

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

Gives a trigger condition ('when the user asks to list runs for a Listen keyword monitor') but names no alternatives, prerequisites, or when-not-to-use guidance. For a tool with three closely related siblings, the routing help is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that: results are scoped to data visible to the linked Market Brew account. It says nothing about result volume, pagination, or ordering.

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

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

Two short sentences, front-loaded with the usage trigger and then the access constraint. It is tight and free of filler, though the opening sentence is largely redundant with the title.

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

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

There is no output schema, so the description should convey what a history listing returns, but it only notes the account-visibility scope. Combined with the undocumented required searchWidgetId and no pagination/result-shape cues, an agent lacks enough to call and interpret this reliably.

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

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

Schema coverage is only 50%: 'query' is documented in the schema but the required 'searchWidgetId' has no description anywhere. The description adds no parameter meaning at all, so it fails to compensate for the undocumented required identifier.

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

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

The description states a verb (list) and resource (Search Widget query history) and adds a visibility scope, so the purpose is recoverable. However, the first sentence essentially restates the tool name as a trigger and does not distinguish this from the close sibling get_search_widget_history, leaving the list-vs-get boundary unclear.

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

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

Guidance is limited to 'use this when the user asks to list Search Widget query history', which is a restatement of the name rather than a real usage condition. No alternatives, prerequisites, or when-not-to-use cases are given, and the near-identical get_search_widget_history sibling is never contrasted.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description does add one genuinely useful behavioral fact not in the annotations: results are scoped to data visible to the linked Market Brew account. It says nothing about pagination despite query supporting offset/pageSize, so it stops short of rich behavioral context.

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

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

Two short sentences, no bloat, and the usage trigger is front-loaded. The only weakness is that the first sentence largely duplicates the title, so not every word earns its place.

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

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

There is no output schema, so the description needn't explain return values, and the visibility constraint is a helpful addition. However, for a tool with a nested query object supporting filters and pagination, it never explains the parent/child relationship versus list_tasks, nor how paging works. Just barely complete enough to call correctly.

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

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

Schema description coverage is only 50%; the required taskId parameter has no description in the schema and is never explained in the description either. The description adds zero parameter meaning — no mention of the parent task identifier, the query filter object, or pagination fields. With half the parameters undocumented and no compensating prose, this falls below the baseline.

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

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

The description says it lists child tasks, which matches the name and title, but it is close to a restatement rather than a distinct specification. It offers no differentiation from the many siblings that also list or fetch tasks (list_tasks, list_task_history, get_task), so an agent cannot tell from the text alone why it should pick this one. Purpose is implied but vague about scope (e.g., what counts as a 'child').

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

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

"Use this when the user asks to list child tasks" gives a trigger condition, but that trigger is essentially the tool's purpose restated. It never names an alternative (list_tasks, list_task_history, get_task) or states when-not to use it, leaving the routing decision to inference. Adequate as implied usage only.

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