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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the operation is a bulk add, but does not mention whether prompts are appended or replace existing ones, whether duplicates are allowed, whether the operation is idempotent, or what the return/response looks like. This is a significant gap for a mutating tool.

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?

A single, front-loaded sentence with no filler. Every word earns its place: 'Bulk-add' communicates the operation, 'prompts' the resource, 'topic' the grouping, and 'industry index' the scope.

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 annotations and no output schema, the description leaves out critical operational context: whether the target index/topic must pre-exist, how duplicate prompts are handled, what a successful call returns, and how this tool relates to list_prompts or run_index_prompts. For a mutation tool with three required parameters, this is insufficient.

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%, so the baseline is 3. The description adds no parameter-level information beyond the schema: 'topic' and 'prompts' map directly to the fields, but the schema already describes each parameter, including the index UUID source. No new semantic detail is offered.

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 uses a specific verb ('Bulk-add'), names the resource ('prompts'), and specifies the target scope ('topic in an industry index'), making it immediately clear what the tool does. The 'industry index' qualifier helps differentiate it from the generic sibling add_prompts, though it does not explicitly name 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?

No guidance is provided on when to use this tool versus alternatives such as add_prompts, add_index_topic, or run_index_prompts. The description does not state prerequisites (e.g., whether the index and topic must already exist) or conditions that would make this tool preferred.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It primarily restates the mutation ('Add...') and offers a domain explanation, but it does not mention duplicate-name handling, whether the index must already exist, confirmation behavior, or return value. This leaves meaningful gaps for an agent deciding whether this operation is safe and how to interpret success.

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 concise sentences with no fluff. The primary action is front-loaded, and the clarifying example earns its place by disambiguating what a 'topic cluster' means.

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 create operation, the description plus full schema coverage is reasonably usable, but the absence of annotations and output schema leaves some context unaddressed. There is no guidance on when to prefer this over related tools or what side effects to expect, so completeness is adequate but not strong.

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%, so the schema already documents all three parameters. The description adds example topic names and explains the concept of a topic cluster, but it does not add parameter-level details beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific action and resource: 'Add a topic cluster to an industry index.' It also clarifies the concept with examples ('Pricing Questions', 'Best-of Comparisons'), making the tool's purpose clear. It does not explicitly contrast with siblings like create_topic, but the object is still 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?

The intended use is implied by the description: use when you need to add a topic cluster to an existing industry index. However, it provides no explicit when-to-use versus alternatives, no exclusions, and no guidance about prerequisites such as the index already existing.

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?

With no annotations provided, the description carries the full behavioral burden, and it delivers a meaningful disclosure: the operation is subject to a monthly prompt limit and will return an error when exhausted. This is exactly the kind of rate-limit context the rubric credits. It stops short of revealing partial-failure or deduplication semantics for the bulk write, but the disclosed error condition is substantive.

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 with zero waste. The verb and resource are front-loaded in the first sentence, and the second sentence adds a single high-value constraint. 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?

For a low-complexity bulk-add tool with three fully documented parameters, the description covers purpose, scope, and the primary failure condition. No output schema exists, so the return value is never described, and partial-failure behavior is unaddressed — but the open questions are minor given how simple the call is.

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% — all three parameters (brandId, topicId, prompts) are already documented with source hints ('from list_brands', 'from list_topics') and types. The description's 'under a specific topic' phrase merely restates the schema's topicId semantics rather than adding new parameter meaning, 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 ('Bulk-add'), resource ('prompts'), and scope ('to a brand under a specific topic'), which clearly distinguishes this from index-scoped siblings like add_index_prompts. However, it doesn't explicitly name alternatives, so differentiation is implied 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?

Usage context is implied by the action itself — adding prompts to a brand under a topic — and the plan-limit warning functions as a constraint on when to call it. But there is no explicit guidance about when to prefer this over update_prompts, add_index_prompts, or run_brand_prompts.

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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It does disclose one meaningful behavior: the API enforces a plan-based brand limit and returns an error when reached, which is valuable context. But it omits the success response shape, idempotency, and whether duplicate names are rejected, leaving the mutation's full behavior only partially specified.

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 with zero filler: the purpose is front-loaded first, followed by the operative constraint that would otherwise surface as a confusing runtime error. Every sentence earns its place, and the description avoids tautological restatement of 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?

The schema fully documents all five parameters and no output schema exists, so return-value explanation isn't required. However, with no annotations, the description is the only source of behavioral context, and it doesn't cover the success response, name uniqueness, or any hidden side effects — adequate for a simple create operation, but with 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% — every parameter (name, website, industry, products, competitors) already has a description in the input schema, so the baseline is 3. The description adds no additional parameter-level meaning beyond the plan-limit caveat, so it neither helps nor hurts.

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 ('Create'), resource ('brand'), and scope ('on your AEO Copilot account'), making the operation unambiguous. It naturally distinguishes from siblings like list_brands, scan_brand, create_topic, and create_index based on verb+resource, though it doesn't name any alternative 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?

The description implies when to use the tool — when the user needs to create a brand — and adds one operational constraint: the plan's brand limit will trigger an API error. However, it offers no explicit when-not-to-use guidance, no mention of alternatives, and no prerequisites, so the agent must infer selection context from the name and purpose.

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?

No annotations are provided, so the description must carry the behavioral transparency burden. It describes the conceptual purpose but does not disclose side effects, such as whether creating the index triggers prompt scanning, whether it is idempotent, what permissions are required, or what the response looks like.

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 a single sentence with the key verb and resource front-loaded. The parenthetical 'no single brand is the focus' is slightly redundant with 'brand-agnostic' but reinforces the distinction without adding much length.

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 creation tool with fully documented parameters, the description is mostly adequate: an agent knows what to create and what the index represents. However, with no output schema and no annotations, the expected response, error conditions, and follow-up steps such as adding topics or prompts are left unspecified.

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 baseline is 3. The description adds context about what an industry index is, but it does not extend the meaning of the individual parameters beyond their schema descriptions.

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 and resource ('Create an industry index') and clearly defines its unique role as a 'brand-agnostic view of an industry that tracks every entity cited across prompts.' This distinguishes it from brand-focused siblings like create_brand and from topic-related 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?

The description conveys when to use this tool: when the goal is an industry-wide, brand-agnostic tracking view rather than a single-brand focus. It does not explicitly name alternatives or state hard when-not-to-use conditions, so it falls just short of full 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?

No annotations are provided, so the description carries all behavioral responsibility. It discloses only that it creates a topic cluster, but not what happens on duplicate creation, whether existing brands are required, or what the response contains. A mutation tool with no annotations should give more operational detail.

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 are front-loaded with the action and resource, and the second sentence earns its place by clarifying the topic concept with concrete examples. 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?

For a straightforward create operation with fully documented parameters, the description is adequate, but it omits usage guidance and expected result behavior. Since there is no output schema and no annotations, more operational context would make it complete.

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%, so the schema already documents all parameters. The description adds the domain concept of topics grouping related prompts, which is helpful but does not add meaning to individual parameters.

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

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

States a clear verb+resource: create a topic cluster for a brand, and adds the concept that topics group related prompts with examples. It does not explicitly distinguish from siblings like create_index or add_index_topic, but the resource and use case are evident.

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?

No guidance on when to use this tool versus the many sibling tools (e.g. create_index, add_prompts, add_index_topic). No prerequisites or exclusions are mentioned; only the definition 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?

No annotations are provided, so the description carries the full burden of disclosing behavior. It clearly states that deletes are soft, prompts stop collecting data immediately, stay restorable for 48 hours, are then permanently removed along with their results, and non-owned prompts are skipped and reported rather than causing failure. This is thorough and non-misleading.

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 concise, well-ordered sentences: the first gives the core action and scope, the second explains the lifecycle, the third clarifies edge behavior. Every sentence adds distinct information with no redundancy or 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?

For a tool with one param, no annotations, and no output schema, the description covers the essential operational details: limits, deletion semantics, permanence, and non-owner handling. The only minor gap is that it doesn't specify the exact shape or content of the 'reported back' response, but this is not critical 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?

The schema already documents promptIds as an array of 1-50 UUIDs sourced from get_results. The description adds meaning by clarifying the operational effect on the parameter values (skipping non-owned prompts and reorting them back) and by reinforcing the 'by id' nature. Since schema coverage is 100%, this extra context pushes it above the baseline of 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 opens with 'Delete 1 to 50 prompts by id,' specifying the verb, resource, and cardinality. It further clarifies that this is a soft delete, which distinguishes it from a permanent deletion tool and from sibling tools like update_prompts or restore_prompts.

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 provides clear behavioral context for when to use the tool: it deletes prompts by id, is a soft delete, and handles non-owned prompts gracefully. It doesn't explicitly name alternatives or say 'use restore_prompts if you need to recover,' but the soft-delete and 48-hour restoration window effectively communicate the usage boundaries. The absence of explicit when-not-to-use guidance keeps it just short of 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It does convey that the operation is a read ('Get'), covers all 4 LLMs, and captures every cited entity, but it does not disclose details like pagination, exact return fields, error conditions, or any side effects. This is adequate but not rich.

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

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

The description is two dense sentences with no filler. The main purpose is front-loaded, and the comparison to get_results earns its place by clarifying the output shape.

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, the description gives enough context for correct invocation: it names the input source, describes the output scope, and references a sibling tool for shape comparison. It could be slightly stronger with explicit usage conditions or exact excluded fields, but it is otherwise complete.

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 indexId documented as 'The index UUID from list_indexes.' The tool description adds no parameter-specific 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?

The description uses a specific verb and resource: 'Get raw per-prompt results for an industry index across all 4 LLMs.' It also distinguishes itself from the sibling get_results by explicitly noting the difference ('minus the brand-mention fields'), so an agent can identify what this tool provides.

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 references get_results and explains the key difference, but does not explicitly state when to prefer this tool over get_results or any other sibling. The guidance is implied rather than direct, so an agent must infer the appropriate selection 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?

No annotations are provided, so the description must carry the behavioral transparency burden. It does disclose useful return concepts: ranked entities, citation frequency, top-1 share percentage, and an HHI-style concentration score. However, it doesn't clarify sorting direction, entity count limits, or whether this is strictly a read-only operation beyond the 'Get' verb.

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 a single well-structured sentence that front-loads the main purpose ('ranked entity list') and then adds the concentration details. Every clause contributes useful information with no unnecessary 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?

The tool has one required parameter documented in the schema, and this description adequately covers the key output concepts for a low-complexity tool. It is complete enough for an agent to select and invoke it, though it could be strengthened by mentioning the expected ordering or any limits on the ranked list.

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 only parameter, indexId, is already described as 'The index UUID from list_indexes'. The tool description adds no additional parameter-level meaning, so the baseline score 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 clearly specifies the verb 'Get' and the resource: a ranked entity list for an index by citation frequency, plus concentration metrics. It communicates the tool's unique output, but it doesn't explicitly distinguish it from sibling tools such as get_index_results or get_index_sources.

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 provides no guidance on when to use this tool versus alternatives like get_index_results, get_index_sources, or get_index_whitespace. It implies a share-of-voice use case, but it does not state conditions, prerequisites (such as first listing indexes), 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?

No annotations are present, so the description carries the behavioral disclosure burden. It does disclose key behavior: aggregation across every LLM response and ranking by citation frequency. However, it leaves out practical details such as whether the list is limited to top domains, pagination, or the exact shape of the response, which are relevant because there is no output schema.

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 one sentence with an em-dash clarification and contains no filler. The verb, resource, scope, and ranking criterion are front-loaded, so an agent can parse the purpose 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 single-parameter read-style tool, the description covers the main invocation need: what is returned (domains), the ordering (by citation frequency), and the scope (every LLM response in the index). With no output schema, it could have specified the result format more explicitly, but no critical selection or invocation cue 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 schema has 100% coverage for the single parameter: indexId is described as the index UUID from list_indexes. The description adds no new parameter detail, but the schema fully carries that responsibility, putting this at the baseline of 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 a specific verb and resource: it returns domains ranked by citation frequency across every LLM response in the index, and the trailing clause explains what that means in intent terms. It does not explicitly distinguish this from sibling tools like get_index_results or get_index_share_of_voice, 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 description implies a use case ('which sources the AI engines lean on most') and clarifies the scope (across every LLM response in the index), but it never states when to prefer this tool over the other index-related siblings or when not to use it. 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?

With no annotations, the description carries the burden of behavioral disclosure. It explains the selection threshold and the kind of data examined (prompts and topics), which is useful. However, it does not disclose output format, whether any aggregation or ordering is applied, or that this is purely a read operation beyond what the 'get_' prefix 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?

The description is two sentences with no filler. The first sentence front-loads the purpose and the operational threshold; the second adds practical value by framing the result as an authority-building opportunity. 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?

Given the tool's low complexity (one required parameter) and clear description of the selection criteria and output concept ('prompts and topics'), an agent has enough to invoke it correctly. It lacks explicit return-structure or pagination details, but the expected result type is reasonably inferable.

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 only parameter is indexId, already documented as 'The index UUID from list_indexes'. The description's phrase 'in an index' softly reinforces that the parameter identifies the index, but it adds no new semantic detail 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?

The description uses a specific verb-resource pairing ('Find whitespace opportunities in an index') and precisely defines the concept: prompts and topics where no entity is consistently cited, with a concrete threshold. This clearly differentiates the tool from siblings like get_insights or get_index_results by naming the distinctive output type and selection criteria.

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 provides clear context for when to use the tool: when identifying index-level gaps where a brand could establish authority. It does not explicitly name alternatives or exclusions, but the use case is stated directly rather than left only to inference, so it earns a 4 rather than a 3.

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?

No annotations are provided, so the description carries the full behavioral transparency burden. It clearly enumerates what kind of data is returned, which helps set expectations, but it does not disclose failure behavior, data freshness, required prerequisites, or any limitations. It is adequate but not richly transparent.

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?

A single, front-loaded sentence states the tool's purpose and then lists the concrete output components. There is no filler or repetition, and every clause contributes actionable 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 one-parameter read-style tool with no output schema, the description provides a solid list of return categories, which is enough for an agent to understand what it will receive. It could be more complete with notes on error cases or data scope, but the essentials are present.

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%, and the sole parameter brandId already has a descriptive schema comment ('The brand UUID from list_brands'). The description adds little beyond tying the tool to 'a brand', so the schema does the heavy lifting and a 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 uses a specific verb ('Get') and clearly identifies the resource ('analytics insights for a brand') while enumerating the exact components returned. This distinguishes it from sibling tools like get_results or get_index_share_of_voice, which focus on different resource types or scopes.

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 implies a use case—fetching brand-level analytics—but provides no explicit guidance on when to choose this tool over alternatives such as get_index_results, get_recommendations, or get_insights-related siblings. It lacks any when-not-to-use instructions or comparisons.

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?

With no annotations, the description must disclose behavioral eatures itself. It states that recommendations are 'prioritised, actionable' and derived from prompt results and an audit, but it does not clarify whether the operation is read-only, whet it triggers any computation or analysis, or what side effects or dependencies may apply.

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 a single, well-prefaced sentence that front-loads the action and outcome while adding the evidential basis. There is no redundancy or 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?

For a one-paramter tool with no output schema, the description explains the purose and the data it relies on, but not the return shape or any prerequisites beyond an implicit audit and prompt results. It is adequate but not fully self-sufficient for an agent deciding whether results are ready.

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 input schema already fully documents brandId as 'The brand UUID from list_brands', so schema description coverage is 100%. The description adds context around 'your brand' but no additional parameter semantics; baseline 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 names a specific resource ('recommendations') and a clear purpose: improving a brand's AI visibility. It also specifies the basis ('prompt results and a technical audit'), which differentiates it from sibling data-retrieval tools like get_insights and get_results, though it does not explicitly name an 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?

The description implies that prompt results and a website audit should already exist, but it does not explicitly state when to choose this tool over siblings, nor does it mention any required prior steps. No exclusions or alternatives are provided, leaving usage inferable but under-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?

With no annotations provided, the description carries the full burden. It discloses the response structure in detail (per-engine block, full answer text, brand mention, position, sentiment, sources, competitors) and explains the behavior of the engine parameter. Minor behavioral aspects like pagination or what happens with empty results are not mentioned, but the core behavior is well covered.

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 tightly written sentences. The core purpose is front-loaded, followed by the output fields and the engine filter behavior. There is no filler or repetition; every clause adds information an agent needs.

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?

Despite the absence of an output schema, the description gives sufficient detail about the return value (per-engine block with response and analysis fields). All six parameters are documented in the schema, and the description explains the default when engine is omitted. An agent can invoke the tool correctly with the information provided.

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 every parameter has a clear description. The tool description adds no new parameter-level meaning beyond giving 'claude' as a concrete example, which the schema already covers. Baseline 3 is appropriate because 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 opens with a specific verb and resource: 'Get prompt execution results for a brand across AI engines.' It goes on to enumerate exactly what each result contains (response text, brand mention, position, sentiment, sources, competitors), which clearly differentiates it from sibling tools like get_index_results by anchoring it to brand-level, not index-level, results.

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?

Usage context is implied by the phrase 'for a brand,' but the description never explicitly says when to choose this tool over alternatives such as get_index_results or get_insights. No when-not-to-use guidance or named sibling tools 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states it lists brands, but does not mention that it's a read-only operation (no annotation to indicate that), nor does it disclose the response format, pagination, or any side effects. For a tool with zero annotations, this is a significant gap in transparency.

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 a single, front-loaded sentence with zero filler. It immediately states the action and scope. Perfectly concise and well-structured for its purpose.

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 must explain what the tool returns. It only says 'list all brands' without specifying the return format (e.g., brand IDs, names, objects). Additionally, it doesn't clarify if 'access' implies authentication context or any prerequisites. For a tool with no annotations and no output schema, this is incomplete.

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 has zero parameters, and the schema is empty with 100% coverage (trivially). Per the rubric, 0 params earns a baseline of 4. The description adds no parameter-specific meaning, but that's not needed when there are no parameters to describe.

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 ('list') and resource ('brands') with an explicit scope ('you have access to'). It clearly distinguishes from sibling tools like list_indexes or list_topics by naming the exact entity. However, it doesn't explicitly differentiate from other brand-related tools (e.g., create_brand, scan_brand), so it's slightly below a 5 for not noting any 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?

The description gives clear context: it's for retrieving accessible brands. But there is no explicit guidance on when to use this tool versus alternatives, nor any mention of when not to use it. For a trivial list operation, the implied usage is obvious, but the lack of any exclusion or alternative reference keeps it at a 'clear context, no exclusions' level.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals meaningful behavior: the 48-hour grace window, grouping by delete batch, and included output fields (sample texts, expiry). It stops short of stating auth requirements or potential side effects, but 'list' clearly signals a read operation, making the gap minor.

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 with no filler. The first sentence front-loads the core purpose and key behavioral constraints; the second provides actionable cross-tool integration. 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?

For a one-parameter list tool with no output schema and no annotations, the description is remarkably complete. It covers the operation, the scope condition (deleted, restorable, 48h), the output grouping and included data, and the follow-up action (restore_prompts with batchId). An agent has enough context to invoke it correctly and interpret results.

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 parameter brandId is already documented as 'The brand UUID from list_brands'. The tool description adds context by indicating the brand scope, but it does not add new parameter-level semantics beyond what the schema already provides, 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 states a specific verb ('list'), resource ('recently deleted prompts for a brand'), and a clear distinguishing scope ('still restorable (48-hour grace window)'). It also mentions grouping by delete batch, which further differentiates it from sibling tools like list_prompts and delete_prompts.

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 clearly indicates when to use this tool: when listing restorable deleted prompts within the 48-hour grace window. It also names the downstream tool, restore_prompts, and ties it to the batchId, giving explicit guidance on how the output feeds into the undo flow.

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?

No annotations are provided, so the description carries the full burden. It correctly indicates a read-only listing behavior and that only accessible indexes are returned, but it does not add detail about output format, ordering, or absence of side effects beyond what the verb 'List' 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?

A single front-loaded sentence with no filler. Every word earns its place by specifying action, resource, scope, and context.

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 listing tool, the description covers the core invocation needs: it names what is listed and the access boundary. Since no output schema exists, a note about return format or downstream ID usage would improve completeness, but it is not critical for simply listing indexes.

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 are no parameter semantics to document. The baseline for no-parameter tools is 4, and the description appropriately focuses on the returned resource and scope.

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 exact verb ('List'), resource ('industry indexes'), scope ('you have access to'), and product context ('AEO Copilot'). This clearly distinguishes it from sibling tools like create_index and get_index_results.

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 makes the tool's purpose obvious: enumerate all indexes the user can access. It does not explicitly name alternatives or exclusion conditions, but sibling tools such as create_index and get_index_results make the read/list usage context clear.

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?

No annotations exist, so the description carries the full burden. It adds useful behavioral facts—never-run prompts are returned, and get_results cannot see them—and lists return fields. However, it does not explicitly state read-only behavior, pagination/limits, or whether deleted prompts are excluded, which is relevant given sibling list_deleted_prompts.

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 succinct sentences with no filler. The first sentence front-loads the tool's purpose and outputs, and the second gives targeted usage guidance. 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 list tool with two documented params and no output schema, the description covers the key return fields, brand scoping, and the non-obvious inclusion of never-run prompts. It is slightly incomplete about whether deleted prompts are included or excluded and about pagination, but these are minor for a basic 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?

Both parameters already have descriptions in the schema (brandId and optional topicId), so schema coverage is 100%. The description does not add meaningful additional parameter guidance beyond restating the brand scope and the purpose of discovering prompt ids.

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 precise verb and resource ('List all prompts for a brand') and enumerates the returned fields: ids, text, topic, target page, last run date, and paused state. It also distinguishes from get_results by noting never-run prompts are visible here but not there.

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 explicitly instructs when to use this tool: to discover prompt ids for update_prompt, update_prompts, and delete_prompts. It also contrasts with get_results for never-run prompts, giving the agent enough direction to pick the correct sibling without 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?

There are no annotations, so the description carries the transparency burden; it clearly indicates a read-only listing behavior ('List all topics') and notes that topics organize prompts. It does not discuss empty results or pagination, but for a simple read tool the core behavior is adequately disclosed.

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 sentences with the main operation front-loaded and examples to clarify what a topic is. There is no redundant or filler text.

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 read tool with fully described parameters, the description supplies enough context: what the tool returns, how topics relate to prompts, and the brand scope. No output schema is present, but the expected output is self-evident from 'List all topics'.

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% because brandId is already described as 'The brand UUID from list_brands'. The tool description restates the brand scope but does not add new parameter guidance 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 uses a specific verb ('List'), identifies the resource ('topics'), and scopes it to a brand. It also defines topics as groupings of related prompts, which separates this tool from sibling tools like list_prompts.

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 statement is clear that this tool is for retrieving all topics configured for a given brand, and the topic-grouping context implies 'use this when you need topic structure rather than raw prompts.' It does not explicitly name alternatives or when-not-to-use conditions, so it falls just short of 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?

With no annotations, the description carries the behavioral disclosure burden. It discloses that the operation is batch-scoped, that it reverses a delete_prompts call, and that it is only valid within 48 hours. It doesn't cover edge cases such as already-restored batches or failure/return behavior, but the core side effects are clear.

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: the first names the operation, the second provides the time constraint and ID source. Every clause is load-bearing; there is no filler or 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 single-parameter restore operation, the description supplies the action, the exact batchId source, and the availability window, which is enough for an agent to select and invoke it correctly. Return-shape and failure-mode details are not described, but the low complexity and complete schema keep this from being a serious 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 100% and the batchId description in the schema already states its origin ('from list_deleted_prompts or delete_prompts'). The tool description repeats this origin without adding new format, type, or validation nuance, so it stays at the baseline of 3.

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

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

The description opens with a specific verb ('restore') and a concrete resource ('a batch of recently deleted prompts'), and immediately anchors the operation to delete_prompts via 'undo a delete_prompts call'. This clearly differentiates it from the prompt-management siblings such as list_prompts, update_prompts, and delete_prompts.

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 explicitly states the governing condition ('48-hour grace window') and tells the agent exactly where to obtain the required batchId (list_deleted_prompts or delete_prompts response). It lacks an explicit exclusion for batches outside the window, but the grace-window condition makes the usage boundary clear.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the action ('run prompts') and return value ('count'), but omits significant traits: invoking multiple external LLMs implies cost, latency, and non-idempotency, and there is no warning about side effects on existing results or whether the operation is synchronous. For a side-effecting execution tool, this is a meaningful transparency gap.

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 sentences with no fluff. The core action and scope are front-loaded, followed by the optional filter and return value. 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?

The description is adequate for a tool with two well-documented parameters and no output schema, covering the operation and its return value. However, it lacks operational caveats such as prerequisites (enabled LLMs), expected duration, how results are stored, and whether the operation can be safely repeated. For an execution tool with no annotation safety net, this is a noticeable completeness 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 description coverage is 100%, and both parameters are already well-documented (brandId as the brand UUID from list_brands, topicId as an optional topic UUID). The description adds no new parameter-level meaning, so the baseline score 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 states a specific verb ('Run'), a specific resource ('all prompts for a brand'), and the full scope ('across every enabled LLM'). It also distinguishes this from index-level or scanning tools by naming the brand-level operation and the optional topic filter. The purpose is unmistakable.

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 clearly indicates the brand-level use case and the optional topic filter, but it does not explicitly exclude or compare to sibling tools like run_index_prompts or scan_brand. The usage context is clear, but the when-not-to-use guidance is left to the agent's 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?

No annotations are present, so the description must carry behavioral disclosure. It does disclose the core side effect: it runs prompts and stores full per-LLM results. However, it does not mention whether runs are idempotent, whether existing results are overwritten, how long or costly the operation may be, or what the caller receives back.

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 with no flf filler. The main action and scope are front-loaded, and the 'No brand filter' clarifier is efficient and purposeful.

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 one parameter and full schema coverage, the description is mostly adequate, but without an output schema or annotations it leaves important gaps for a side-effectful execution tool: it does not point to how results are retrieved afterward (e.g., get_index_results) or warn about long-running/cost implications.

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 schema already fully describes the single parameter indexId as 'The index UUID from list_indexes' (100% coverage). The description adds no parameter-specific meaning beyond that 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?

States a specific verb and resource: 'Run all prompts in an index'. It further differentiates by scope: 'across all 4 LLMs' and the explicit exclusions 'No brand filter — every entity mentioned is captured'. This clearly distinguishes it from siblings like run_brand_prompts.

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 gives implied usage context by saying there is no brand filter and that every entity is captured, which suggests this is the unfiltered, index-wide execution tool. However, it never explicitly names an alternative such as run_brand_prompts or states when this tool should not be used.

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?

With no annotations provided, the description carries the burden of documenting behavior, and it does contribute meaningful return-value context by describing the full scan result and its contents. It does not disclose whether the scan is synchronous, whether it has side effects like cached results, or whether it involves external website fetching, which leaves a moderate transparency gap.

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 a single, front-loaded sentence that states the action immediately, then adds return-value detail and concrete examples. There is no redundant wording or filler, and the dashboard reference earns its place by clarifying the shape of the result.

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 one well-described parameter and no output schema, the description gives enough context: the operation, the target, and the return contents. It stops short of documenting scan lifecycle, freshness, or error behavior, but those are minor gaps for such a simple single-parameter 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?

The schema already covers brandId with a clear description ('The brand UUID from list_brands'), so schema description coverage is 100%. The free-text description adds no additional parameter-level detail beyond associating the audit with the brand's website, making the baseline score of 3 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 clearly states the action ('Run a technical audit') and the target (the brand's website), and it names the output domain with concrete examples (schema markup, sitemap, llms.txt). It also distinguishes this tool from siblings like get_insights by scoping it to the 'technical scan view' rather than general insights.

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 implies when to use the tool — whenever the agent needs a technical scan of a brand's website — and reinforces this by pointing to the dashboard's technical scan view. However, it does not explicitly state when not to use it or name an alternative sibling for adjacent tasks, so the guidance is implied rather than explicit.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose a critical side-effect—editing the text preserves links to past results and only future runs use the new wording—but this largely mirrors the text parameter's schema description. It does not discuss the effects of topic or URL edits, success/error behavior, or any permissions required, leaving a clear gap.

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 with no filler: the first front-loads the operation and editable fields, and the second adds a high-value behavioral caveat about past results. Every word earns its place and the structure is easy to scan.

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?

All parameters are fully documented in the schema and the description conveys the core scope and most important side-effect. However, with no annotations and no output schema, the description does not mention return/success behavior or explicitly route to the bulk sibling update_prompts, which is a moderate gap for a mutation tool of this complexity.

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%, so all five parameters are already documented in the input schema. The description restates 'text, topic, or target page URL' but adds no new format, syntax, or interaction details beyond what the schema already provides, keeping the value at 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 uses a specific verb ('Edit') and names the exact resource ('a single prompt') along with the three editable attributes: text, topic, and target page URL. The word 'single' clearly distinguishes it from the plural sibling update_prompts without needing to inspect any schema.

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 'a single prompt' gives a clear context for when this tool applies—one targeted edit—and contrasts implicitly with the bulk sibling update_prompts. It does not explicitly name alternatives or list when-not-to-use conditions, but the singular scope provides a sufficient directional cue for an agent selecting between 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?

With no annotations, the description fully carries the behavioral disclosure burden. It discloses independent item processing, partial-success reporting, and the important side effect that editing text leaves past results linked while only future runs use the new wording.

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 sentences, with the key batch capability front-loaded and no filler. Every sentence contributes operational knowledge: capacity limit, field requirements, independence/failure reporting, and text-update side effects.

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 bulk mutation tool with no annotations and no output schema, the description supplies the critical operational details: batch limit, required id, independent processing, and failure reporting. There is no obvious missing information an agent needs to invoke it 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 coverage is 100%, so the schema already documents all four editable fields and their types/constraints. The description adds the batch-level context and retry guidance but does not materially deepen per-parameter meaning beyond what the schema provides, 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 opens with a specific verb and resource — 'Bulk-edit up to 50 prompts in one call' — and defines the exact operation scope. This clearly distinguishes it from the singular sibling update_prompt by emphasizing the batch nature.

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 intended context is clear: use this when you need to update multiple prompts (up to 50) in one call, and the failure-reporting note guides retry behavior. It does not explicitly name update_prompt as the single-update alternative or state when not to use this tool, so it stops short of a 5.

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