GoodBarber

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

The description only states 'create article' and adds no side-effect details beyond the annotations. The annotations already cover read-only, idempotency, and destructiveness, but the description does not mention default status, return value, or publication 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?

The description is short and mostly concise, but the 'Guidance: ... | context: title, categories' fragment is awkward and slightly redundant, reducing clarity without adding meaningful structure.

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 covers all parameters and notes category discovery via cms_list_cms_sections, but the description is minimal and does not mention the created article output or basic workflow expectations. It is adequate but not complete for a 15-parameter 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?

The input schema already describes every parameter with 100% coverage, so the description does not need to repeat them. It adds little semantic value beyond the schema's own detailed field 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 clearly identifies the action as creating one CMS article, which distinguishes it from sibling tools like cms_create_article_paragraph and the other content-type create tools. The phrase 'from article category ids' reinforces the intended input.

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 this is the tool for creating a new article versus updating or creating paragraphs, but it does not explicitly call out alternatives such as cms_update_article or cms_create_article_paragraph. Sibling names allow inference, but there is no direct usage 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 indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the creation behavior is clear. The description adds little beyond the fact that it creates a paragraph; it does not mention potential side effects, required parent article existence, 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?

The description is extremely concise, consisting of two short sentences with no redundant phrasing. It avoids fluff and gets directly to the point.

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 plus the fully covered parameter schema is sufficient to understand the core operation and required inputs. It does not describe the return value, but with no output schema and a straightforward create action, this is not a significant 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% with each parameter having a meaningful description, so the baseline is 3. The tool description adds no extra semantic context beyond what the parameter descriptions already provide.

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 tool creates one paragraph under a CMS article, specifying the verb and resource. It distinguishes this tool from sibling paragraph-creation tools for events, maps, sounds, and videos by naming the article context.

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 does not provide explicit guidance on when to choose this tool over the many sibling create_*_paragraph tools. It merely restates the action without mentioning alternatives or conditions such as 'use for article body blocks only'.

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 description adds no behavioral details beyond the annotations. It does not mention side effects (beyond creation), idempotency, error behavior, or what happens on success. The annotations already indicate non-read-only and non-destructive, but the description contributes nothing about the tool's actual 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?

The description is very short and to the point, which is concise. However, the structure is awkward: it includes a 'Guidance' portion that rephrases the purpose and lists parameters, adding redundancy without new information. The main purpose is front-loaded, but the extra text is not fully earned.

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 has 21 parameters, multiple enums, and a nested object, the description is highly incomplete. It does not explain the event model, relationship to categories, expected configuration, or any workflow context. No output schema is present, and the description gives no hint of the return value or side effects, leaving the tool largely unexplained beyond its name.

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 additional parameter semantics beyond repeating a few parameter names (title, categories, sortDate) without elaboration. It neither clarifies nor contradicts the schema, so it remains 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 clearly states the verb ('Create') and resource ('event'), and specifies it creates a CMS agenda event from category ids. However, it does not distinguish this from other create tools (e.g., cms_create_article) or mention alternatives, so purpose is functional but not fully precise.

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 usage guidance is provided. The description does not state when to use this tool versus alternative creation tools, nor does it give any scenario-based instructions. The 'Guidance' phrase merely rephrases the purpose and lists some parameters, not actual usage direction.

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 indicate the tool is not read-only, not destructive, and not idempotent, which aligns with the 'create paragraph' description. The description does not add behavioral detail beyond this, such as whether the created paragraph is returned, what happens on validation failure, or how automatic positioning works when position is omitted.

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 very short and mostly direct. The first sentence 'Create paragraph' is somewhat redundant with the title, but the second sentence adds the key context about creating under a CMS agenda event. Overall it is concise and easy to parse.

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 too sparse for the complexity of the operation. It does not mention output or return value, error behavior, conditional requirements across block types, or relationship to thumbnail selection. Given eight parameters and conditional dependencies, the description alone leaves important operational context unstated.

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 provides 100% coverage with detailed descriptions for all eight parameters, including conditional fields like content for text/quote blocks, embedUrl for embed blocks, and originalThumbnail for photo blocks. The tool description itself adds little beyond the schema, so it meets the baseline for high schema coverage.

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

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

The title and description clearly state the action: create a paragraph under a CMS agenda event. This distinguishes it from sibling tools that create paragraphs under articles, maps, sounds, videos, or shop products. The description is slightly minimal but 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 guidance says to create one paragraph under a CMS agenda event, which signals the primary use case. It does not explicitly contrast with other cms_create_*_paragraph tools or state when not to use it, leaving some inference to the agent based on 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 communicate readOnly=false, idempotent=false, openWorld=true, and destructive=false. The description only adds that it creates an item and does not describe side effects, errors, or return behavior, but core safety properties are covered by 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?

The description is short and free of irrelevant detail, but it slightly repeats the same idea: 'Create map item' followed by 'Create one CMS map item.' The pipe-separated context fragment is also minimally redundant, though not harmful.

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 17 parameters and no output schema, the description does not state what the create call returns (e.g., created item ID) or outline follow-up actions. Required inputs are fully specified in the schema, making the description adequate but not fully complete for a complex create 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 description coverage is 100%, and the parameter descriptions are detailed (e.g., categories discovery, useThumbAsPinIcon sequencing, status/publishedDate rules). The tool description itself adds no parameter-level meaning, so it stays at the baseline for high schema 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 states 'Create one CMS map (point of interest) item from map category ids', giving a concrete action and object type. It distinguishes the top-level map creation from sibling paragraph tools, though it repeats 'map item' and relies on the tool name for full clarity.

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?

There is no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives such as cms_create_map_paragraph, cms_update_map, or cms_get_map, leaving the agent to infer the appropriate selection from the title and schema.

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 description does not disclose side effects, output, or any behavioral details beyond the basic create action. The annotations (readOnlyHint=false, destructiveHint=false) provide some context, but the description itself adds little beyond purpose. No contradiction with 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?

The description is concise, with only two short sentences. The first sentence 'Create paragraph.' is redundant with the tool name, but the second sentence adds key context. Overall, it is efficient and free of unnecessary detail.

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 provides enough context to understand what the tool does, but it lacks information about return values or any post-condition of the creation. Since there is no output schema, the agent might need additional details about what to expect after calling the tool. This is a minor 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%, so all 8 parameters have descriptions in the schema. The description text itself does not add extra semantic meaning beyond the schema. According to the rubric, with high schema coverage the baseline score is 3, and no additional value is provided.

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 tool's purpose: 'Create one paragraph under a CMS map item.' It specifies the resource type (map item) and the action (create paragraph), which distinguishes it from sibling tools that create paragraphs for other CMS entities (e.g., cms_create_article_paragraph).

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 usage context by stating the paragraph is created 'under a CMS map item,' which is sufficient for an agent to know when to choose this tool over similar paragraph-creation tools. It does not explicitly mention alternatives or exclusions, but the target is 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?

The annotations already declare non-read-only, non-destructive, and non-idempotent behavior. The description adds context about batch creation and default publication status, but does not disclose potential side effects like partial failures or response format, so it goes slightly beyond annotations but not fully.

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 extremely concise—two sentences—and directly conveys the essential purpose and batch behavior without redundant wording or unnecessary details.

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 references a prerequisite (section id from cms_list_cms_sections) but does not mention what the tool returns after successful creation, any error conditions, or the 10-item limit. Given the absence of an output schema, this leaves some ambiguity 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?

Schema descriptions cover 100% of parameters with detailed semantics (e.g., order alignment, source formats, defaults). The tool description itself adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Upload'), the resource ('CMS photo gallery section'), and the batch nature, making it unambiguous. It is distinct from sibling tools that create other content types (e.g., articles, events).

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

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

The description explicitly indicates batch upload and provides a default for publication status, giving practical usage direction. It does not explicitly contrast with alternatives, but the tool name and content type make the appropriate scenario 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?

The description indicates a creation operation, consistent with the readOnlyHint=false annotation. It does not add behavioral details beyond the basic 'create' action, such as side effects, error handling, or idempotency implications, though the annotations cover the read/write and destructive hints.

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 very brief and focused: 'Create paragraph. Guidance: Create one paragraph under a CMS sound item.' It avoids unnecessary words and is easy to parse, though the formatting with '| context: id, type' is slightly odd but not confusing.

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 straightforward creation operation and well-detailed schema, the description is sufficient. It does not mention return values (no output schema exists), and the absence of nested objects simplifies context. However, it could slightly benefit from a note on which parameters are required versus optional, but the schema already handles that.

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 provides 100% coverage with descriptions for all parameters. The tool description itself adds no additional semantic meaning beyond what is already in the schema, so it does not improve upon 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 clearly states the action ('Create') and the resource ('paragraph under a CMS sound item'). It distinguishes this tool from similar paragraph-creation tools for other content types (articles, events, maps, videos) by specifying 'sound item'.

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 usage when a paragraph needs to be created for a sound item, but it does not explicitly contrast with sibling tools like cms_create_article_paragraph or cms_create_video_paragraph. The resource type is clear, but no direct alternative 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?

The description aligns with the annotations by indicating a non-read-only, non-destructive create operation. It does not add extra behavioral context such as side effects, defaults, permissions, or error behavior, but it also does not contradict 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?

The description is short but redundant: 'Create video item' and 'Create one CMS video item' repeat the same idea. The '| context:' segment is awkwardly formatted and 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?

The schema provides rich parameter context, but the tool description does not mention return values, output shape, or failure modes. With no output schema present, some additional context about what the create operation returns would improve completeness.

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 covers all 13 parameters with descriptions, including enums and the nested meta object. The description adds little beyond naming required fields like title, categories, and embedUrl, so it provides no significant additional 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?

The description clearly states the tool creates a CMS video item, using a specific verb and resource. This distinguishes it from sibling tools like cms_create_video_paragraph, cms_update_video, and cms_list_videos.

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 use for creating a new video item, but it does not explicitly compare against alternatives such as updating an existing video or adding a video paragraph. The 'Guidance' sentence mostly restates required inputs rather than providing when-to-use direction.

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 provide readOnlyHint false and destructiveHint false; the description aligns with create semantics and does not claim any side-effects beyond creating a paragraph. No additional behavioral details are needed.

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, front-loaded with the purpose and contains no redundant or filler 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 straightforward create operation with rich parameter descriptions and no output schema, the description provides sufficient context. It does not mention return values, but none are defined.

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 descriptions cover all parameters with meaningful details (e.g., id as video item id, type enum). The tool description adds no additional parameter context 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?

Description clearly states 'Create one paragraph under a CMS video item', specifying the verb and resource, and distinguishing it from sibling tools that target other content types (articles, events, maps, sounds).

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 the use case (adding a paragraph to a CMS video item) but does not explicitly name alternative tools or conditions for when to use them, such as comparing with cms_create_article_paragraph.

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 indicate destructive behavior (destructiveHint: true), and the description's 'Delete' matches that. No additional behavioral details such as cascade effects, irreversibility, or confirmation requirements are provided, but there is no contradiction.

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 extremely concise, consisting of only a verb and resource, with no redundant or tangential content. It is well-structured and immediately comprehensible.

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 delete operation, the description and schema cover the essential information an agent needs: what to delete and how to specify it. No output schema is required, and the context is sufficient to act without further clarification.

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 fully describes the single 'id' parameter with type, minimum value, and a clear explanation that it is the article ID from cms_list_articles. The description adds no extra semantic information 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 clearly states the action 'Delete' and the resource 'article', making the tool's purpose unambiguous. It is easily distinguished from sibling tools like cms_delete_article_paragraph, which target a different resource.

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 specifies that the tool deletes one article by its ID, which is sufficient for typical usage. It does not explicitly state when to prefer this tool over alternatives, but the resource name and parameter description disambiguate from paragraph-level delete 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 destructiveHint=true and readOnlyHint=false, so the description does not need to repeat that this is a destructive write. The description adds the specific resource (article paragraph) and the operation, but it discloses no additional behavioral details such as irreversibility, cascading effects, or required permissions. With annotations covering the safety profile, 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 description is redundant: 'Delete paragraph.' repeats the tool name, and the 'Guidance' line restates the purpose and then lists parameters already explained in the schema. The 'context' field is clutter. A single clear sentence would suffice. This is not concise; it wastes words.

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 delete operation with only two required parameters and a destructive annotation, the description is minimally adequate. It tells the agent exactly what is deleted (one article paragraph) and the schema provides parameter provenance. It does not mention any side effects or prerequisites, but given the tool's simplicity and annotation coverage, this is acceptable.

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 describes both parameters (id and paragraph_id) with their origins and types, achieving 100% coverage. The description merely repeats the parameter names in the 'context' line without adding any new meaning or constraints. Since the schema does the heavy lifting, a baseline 3 is correct.

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: 'Delete one article paragraph by paragraph id.' It distinguishes the tool from whole-article deletion (cms_delete_article) and other paragraph types by specifying 'article paragraph'. While it does not explicitly name sibling tools, the scope is unambiguous and self-contained.

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 no guidance on when to use this tool versus alternatives. It does not mention that this is for deleting a single paragraph from an article, nor does it exclude cases like deleting an entire article or paragraphs from other content types. The agent is left to infer usage from the name and context.

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 destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds that it deletes a single event, which clarifies the target, but does not disclose any cascading effects, permission requirements, or irreversibility beyond what the annotation implies. Minimal added value over 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?

The description is short but contains redundancy: 'Delete event.' duplicates the title, and the trailing '| context: id' is cryptic and unexplained. The useful part is the second sentence, but the first sentence and the suffix do not earn their place, making the structure imperfect.

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 delete tool, the description covers the core action and target. However, it does not mention return behavior, error cases (e.g., non-existent id), or any cascading effects. Given the low complexity, it is adequate but leaves some operational details 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%: the 'id' parameter already has a description ('Event id returned by cms_list_events'). The tool description merely repeats 'by event id' without adding new semantics like format, constraints, or relationships. No extra meaning beyond 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 specific verb (delete) and resource (CMS agenda event) with a clear scope (by event id). It distinguishes from sibling tools like cms_delete_event_paragraph by naming 'event' rather than a paragraph, making the target 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 description implies usage when you want to delete an event by its id, but it does not explicitly state when to use this tool versus alternatives like cms_delete_event_paragraph or other delete tools. No exclusions or alternate routing is given; usage is inferred from the resource type rather than 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?

The destructiveHint annotation is consistent with the 'delete' action; no contradiction. The description does not elaborate on side effects, but annotations already convey the destructive nature.

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 text is brief, but there is slight redundancy between 'Delete paragraph.' and 'Delete one agenda event paragraph...' which could be streamlined without losing clarity.

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?

Together with the schema and annotations, the description provides enough context for an agent to call this tool correctly. No output schema is needed for a delete 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?

The schema descriptions are detailed (event ID and paragraph ID with source references), so the added description contributes little beyond restating the paragraph ID usage. Baseline 3 applies given high schema 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 clearly states the action (delete) and the resource (agenda event paragraph), distinguishing it from other paragraph deletion tools via the type specification.

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 identifies the target by paragraph ID and mentions the event context, but does not explicitly contrast with sibling delete tools. However, the event qualifier makes the appropriate usage 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?

The description matches the annotations: it is explicitly destructive and not read-only. It does not disclose side effects beyond deletion, but the annotations already convey the destructive nature.

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, direct, and free of unnecessary content. It conveys the purpose and required parameter efficiently.

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 delete operation, the description and schema provide sufficient context. It does not describe return values or error cases, but the absence of an output schema and the straightforward destructive action make this acceptable.

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 only parameter, id, is documented in the schema as an integer returned by cms_list_maps. The description repeats this context without adding significant new information, so it meets the baseline but does not exceed it.

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?

Description clearly states the specific action of deleting a CMS map item and distinguishes it from related tools like cms_delete_map_paragraph.

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 explains the operation but does not explicitly state when to choose this tool over alternatives such as cms_update_map or cms_get_map. However, the delete intent is unambiguous.

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 destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds no extra behavioral context such as permanence, side effects, or permissions, and merely restates the action. It does not contradict 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?

The description is very short and front-loads the action, but the 'Guidance:' and 'context:' fragments are somewhat awkward and partly redundant. It is concise but could be more neatly structured.

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 two-parameter delete operation with strong schema descriptions and annotations covering destructiveness, the description is nearly sufficient. It does not explicitly state consequences, but these are covered by annotations and the simple scope.

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%, with both parameters described (returned by other tools). The description only lists the parameter names and adds no new meaning 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 clearly states the verb 'delete' and the resource 'map item paragraph', distinguishing it from other delete_*_paragraph tools by specifying 'map item'. It is specific and unambiguous.

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

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

The description implies usage for map paragraphs but does not explicitly state when to use this tool versus alternatives like cms_delete_article_paragraph. It lacks exclusions or comparative guidance, leaving the agent to infer from the name and context.

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 description openly states the destructive nature by saying 'Delete,' and the annotations confirm destructiveHint: true. It does not add details about side effects or permanence, but given the annotation coverage, the bar is met without contradiction.

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 guidance portion is redundant, repeating 'Delete one CMS photo gallery item by photo id.' The cryptic 'context: id' suffix adds clutter without clear value. It could be more streamlined.

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 delete operation, the description provides enough context: what it deletes (photo gallery item) and how to specify it (by photo id). It does not mention error conditions or prerequisites, but these are not essential for a straightforward delete tool, especially with the sibling list disambiguating scope.

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 describes the 'id' parameter as 'Photo item id returned by cms_list_photos,' so schema coverage is 100%. The description does not add further meaning beyond that, aligning with the baseline for high schema 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 clearly states the action and target: 'Delete photo' and 'Delete one CMS photo gallery item by photo id.' It specifies the resource type (photo gallery item) and the scope (by photo id), distinguishing it from other delete tools in the sibling list.

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 explicit guidance on when to use this tool versus alternatives, such as other delete or update tools. It only restates the action, with no prerequisites or conditions for use.

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 description is consistent with annotations (destructiveHint=true) but adds no extra behavioral context beyond stating the delete operation. Since annotations already cover destructiveness, the description meets the baseline but does not go further.

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 brief and front-loaded, but contains slight redundancy between 'Delete sound item' and 'Delete one CMS sound item by sound id'. Still, it is well-structured and free of unnecessary 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 simple delete operation with one input and no output schema, the description is fully sufficient. No additional context about return values or complex behavior 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?

The input schema already provides a complete description for the 'id' parameter ('Sound item id returned by cms_list_sounds'). The tool description only repeats this information without adding new meaning, so baseline score of 3 applies given 100% schema 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 clearly states the tool's function: deleting a CMS sound item by ID. It uses a specific verb ('Delete') and resource ('sound item'), and is distinct from sibling tools that handle paragraphs or other content types.

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. It repeats the operation but does not mention boundary conditions (e.g., 'use this for sound items, not sound paragraphs') or recommend when deletion is appropriate.

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 destructiveHint annotation already indicates the action is destructive, and the description reinforces this with the word 'delete.' It does not describe irreversibility or cascading effects, but given the annotation covers the core destructive nature, the description is adequate.

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

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

The description is extremely concise, starting with the essential action and followed by a brief clarification. No unnecessary words or redundant information are 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?

The description and schema provide enough information to invoke the tool, but they do not clarify whether paragraph_id is globally unique or scoped to the sound item, nor do they mention potential effects on paragraph ordering. Given the sibling reorder tools exist, this missing context could be relevant.

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 have schema descriptions that reference the relevant list tools ('cms_list_sounds' and 'cms_list_sound_paragraphs'), providing helpful context. The description's 'context: id, paragraph_id' line adds minimal extra value, but the schema coverage is complete.

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 ('Delete one sound paragraph') and identifies the target resource. It is easily distinguishable from sibling paragraph-deletion tools by the 'sound' qualifier in both 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?

The description mentions 'by paragraph id' and lists the two parameters, but it does not explain when to use this tool versus deleting an entire sound item or deleting other paragraph types. The context line 'id, paragraph_id' hints at the parameters but adds little 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?

The destructive nature is already indicated by the destructiveHint annotation, and the description simply says 'Delete video item' without adding extra behavioral context such as irreversibility or cascading effects. It does not contradict 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?

The description is extremely concise and front-loaded. It immediately states the action and the key parameter, with no unnecessary elaboration 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 simple delete operation with one documented parameter and a destructive annotation, the description is largely complete. It does not explain return values or side effects, but these are not essential given the tool's simplicity and existing annotations.

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 provides full coverage for the single id parameter, including its type, minimum, and provenance. The description only repeats the parameter usage without adding meaningful semantic detail 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 clearly states the action: deleting a single CMS video item by its ID. The resource and verb are unambiguous, and it is distinct from sibling tools like cms_delete_video_paragraph.

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 usage when a video item needs to be deleted, but it does not explicitly compare with alternatives or state when not to use this tool. The intended context is mostly inferred from the title and resource type.

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 destructiveHint=true and idempotentHint=false, so the destructive nature is covered. The description adds no context about permanence, side effects, or prerequisites. It merely restates the action without enriching behavioral understanding.

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 terse, but the structure is awkward: 'Delete paragraph. Guidance: Delete one video paragraph by paragraph id. | context: id, paragraph_id' includes a redundant 'context' section that doesn't add value. It's concise but not well-organized.

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 destructive mutation with no output schema, the description is minimal. It doesn't mention what happens on failure, whether deletion is permanent, or any dependencies. Given the large sibling list, it also fails to differentiate when to use this tool over others, making it 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?

Schema descriptions fully cover both parameters (id and paragraph_id) with clear provenance (from cms_list_videos and cms_list_video_paragraphs). The description's 'context: id, paragraph_id' adds nothing beyond the schema, so baseline 3 for high schema 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 states 'Delete one video paragraph by paragraph id', which is a specific verb+resource. It distinguishes from sibling delete tools by explicitly naming 'video paragraph'. However, the first line 'Delete paragraph' is generic, though the guidance clarifies the exact target.

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 explicit guidance on when to use this tool versus the many sibling delete-paragraph tools (e.g., cms_delete_article_paragraph). The description only says it deletes a video paragraph, which is inferred from the name, but doesn't provide conditions 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 indicate that the operation is read-only, idempotent, and non-destructive, which lowers the burden on the description. However, the description does not mention what is returned, whether missing ids produce errors, or any other behavioral details, leaving some uncertainty.

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 repeats the same sentence twice and includes an odd 'Guidance:' and '| context: id' fragment. This redundancy and inconsistent formatting hurt clarity and make the description less concise than it should be.

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 getter, the description combined with annotations covers the core purpose and parameter. It does not describe the output shape or error behavior, but these are less critical given the simple nature of the tool and the high schema coverage.

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 'id' has 100% schema coverage and its description adds useful provenance by stating it is returned by cms_list_articles. This goes beyond the basic schema and clarifies where the 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?

The description clearly states that the tool retrieves one CMS article by article id, which is a specific verb and resource. It is distinguishable from sibling getters by the 'article' resource, though it does not explicitly contrast with getters for paragraphs or other CMS entities.

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 a usage hint ('after cms_list_articles discovery when needed'), but it does not clearly explain when not to use this tool or how it differs from related getters. The guidance is present but minimal and somewhat 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?

The description says 'Read' and 'Retrieve', which aligns with the readOnlyHint, idempotentHint, and non-destructive annotations. It adds a small amount of context about how the paragraph is identified (by paragraph id) but does not describe error behavior or side effects, which are already covered by 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?

The description is short but somewhat redundant: 'Read one paragraph' and 'Retrieve one paragraph by paragraph id' convey the same idea. The 'Guidance' and 'context' fragments add a slightly awkward structure, but the overall length is acceptable.

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 operation with fully described parameters and annotations covering safety, the description is adequate. It does not explicitly explain the relationship between the article id and paragraph id, but the parameter descriptions make this clear enough. No output schema exists, so no details are missing there.

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 provides full coverage of both parameters with clear descriptions ('Article id' and 'Paragraph id'). The tool description mentions 'by paragraph id' and references the context of id and paragraph_id, but adds little beyond what the schema already states. Since schema coverage is 100%, 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 states a specific verb ('Read') and resource ('one paragraph'), and the tool name clarifies the article context. It is distinguishable from sibling tools like cms_get_article or cms_get_event_paragraph because it explicitly targets a paragraph, though it does not explicitly say 'article paragraph' in the description itself.

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 does not provide any guidance on when to use this tool versus alternatives such as cms_list_article_paragraphs. There is no mention of conditions that would favor retrieval of a single paragraph over listing all paragraphs, leaving the agent to infer the appropriate use case.

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 read-only, idempotent, and non-destructive behavior. The description adds no extra behavioral detail such as error cases, return format, or side effects, so it provides only baseline transparency beyond 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?

The description is short but contains significant redundancy: 'Retrieve one CMS agenda event by event id after cms_list_events discovery when needed.' is repeated verbatim as 'Guidance:', followed by an unclear '| context: id' fragment. The repeated sentence 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 simple single-event retrieval tool, the description provides sufficient context: it identifies the resource, the required id, and the recommended discovery flow. It does not mention output shape or error behavior, but the absence of an output schema makes this acceptable for such a straightforward read 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?

The parameter schema is fully covered by the description in the schema itself, but the description adds helpful context by specifying that the id is returned by cms_list_events. This gives the agent a clear source for the parameter value.

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 (retrieve), the resource (one CMS agenda event), and the key identifier (event id). It is immediately obvious what the tool does.

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 practical guidance to use this tool after cms_list_events discovery and only when needed. It does not explicitly contrast with sibling tools like cms_get_event_paragraph, but the resource type is clear enough to avoid confusion.

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 description is consistent with the annotations (readOnlyHint, idempotentHint, destructiveHint) and does not contradict them. However, it adds no extra transparency beyond the annotations, such as potential side effects or error conditions.

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

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

The description is concise, using only two short sentences, and is well-structured with a separate 'Guidance' line. It is easy to read and does not contain fluff, though it could be slightly more informative without losing conciseness.

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

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

The description covers the basic purpose and parameters, but it does not mention any output format, prerequisites, or related list tools (e.g., cms_list_event_paragraphs). Given that there is no output schema, the description could still benefit from a note about what is returned or when to use this after listing paragraphs.

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 provides descriptions for both parameters ('Event id returned by cms_list_events' and 'Paragraph id returned by cms_list_event_paragraphs'), covering 100% of parameters. The tool description adds no additional semantic information beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'read' and identifies the resource as an 'event paragraph' with a specific identifier. It is distinct enough given the tool name includes 'event' and the description mentions 'agenda event paragraph.' However, it is terse and does not elaborate on what a paragraph 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 description provides a basic guidance line ('Retrieve one agenda event paragraph by paragraph id') but does not explicitly explain when to choose this over other paragraph getter tools (e.g., cms_get_article_paragraph). The distinction is implicit via the resource type, but no explicit selection criteria 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 readOnly, idempotent, and non-destructive behavior; the description only repeats retrieval semantics and adds no extra behavioral detail such as error or not-found 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?

The description contains an exact duplicate under 'Guidance:' and a stray '| context: id' suffix, which makes it redundant and noisy despite being short.

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 getter, the description provides enough purpose and usage context, but the redundancy and lack of return/error detail keep it from being fully polished.

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 only parameter is fully described in the schema as an ID returned by cms_list_maps, so the description adds little beyond reinforcing the source of the ID.

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?

Clearly states it retrieves a single CMS map item by ID, distinguishing it from listing maps and map paragraphs. The verb 'Retrieve' and resource 'CMS map item' are specific.

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?

Explicitly frames usage after cms_list_maps discovery, giving a clear when. It does not name alternative tools or state when not to use it, but the context is sufficient.

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 and idempotent hints, so the bar is lower. The description adds no further behavioral context—no mention of side effects, error cases, or data returned. It simply repeats the read intent without additional 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 extremely concise—two short sentences—with no redundant fluff. The 'Guidance' prefix is slightly odd but does not harm clarity. It is well-structured and to the point.

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 simplicity and lack of output schema, the description still omits essential context: it does not explain the relationship between the two ids (map item id and paragraph id) or clarify that both are required. It also lacks any situational context, making it incomplete for an agent deciding to use 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 coverage is 100% because both parameters have descriptions in the input schema. The tool description itself does not add any semantic detail beyond listing 'id, paragraph_id', so it neither enhances nor detracts from the parameter meaning. 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 clearly states the action ('Retrieve') and the resource ('one map paragraph'), which is specific enough to distinguish from other get_* tools. However, it only mentions 'paragraph id' without explicitly referencing the map id parameter, so it is not fully explicit about the required input combination.

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 cms_list_map_paragraphs or cms_get_map. The 'Guidance' section merely restates the purpose rather than offering selection criteria or exclusions, leaving the agent without direction on tool choice.

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, which cover the safe read behavior. The description's 'Retrieve' aligns with these annotations but adds no extra behavioral context such as error handling or response format, so the bar is partially met.

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 contains significant redundancy: the main sentence and the 'Guidance' sentence are nearly identical, and the trailing '| context: id' appears to be a template artifact. This bloats the text and distracts from the core message.

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 does not need to explain return values. The parameter is well-covered and annotations handle safety. However, the ambiguous 'when needed' and lack of context about when to prefer this over list_photos leaves some gaps, though it is adequate for a simple get 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?

The sole parameter 'id' is described as 'Photo item id returned by cms_list_photos', which gives clear provenance and meaning. This adds value beyond the schema's type and requirement, though it could be more explicit about the id being the specific photo 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 clearly states the tool retrieves a single CMS photo gallery item by photo id, using the specific verb 'Retrieve' and identifying the resource. It also mentions discovery via cms_list_photos, which helps differentiate it from list and other get tools, though the wording is slightly indirect.

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 a hint to use this after cms_list_photos discovery, but the guidance is vague ('when needed') and does not explicitly contrast with alternatives like list_photos or other get_* tools. There is a redundant 'Guidance' statement that adds little.

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 read-only, open-world, idempotent, and non-destructive behavior. The description adds no contradictions and the note about 'discovery' provides a small amount of behavioral context. Since annotations carry the main safety info, the description meets the lowered bar.

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 extremely concise, with the core action in the first sentence and only one additional qualifying phrase. No filler or redundant 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 simple single-parameter getter with no output schema, the description sufficiently covers what it does and where the id comes from. It could mention the return shape, but given the tool's simplicity and the provided annotations, it is complete enough.

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 only parameter 'id' is described as 'Sound item id returned by cms_list_sounds', which adds a clear origin and validates the type and minimum. With full schema coverage, this extra context elevates it above 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 clearly states the action ('Retrieve') and the resource ('one CMS sound item'), distinguishing it from other getters for different content types. It also notes a typical usage flow via 'after cms_list_sounds discovery', which adds specificity.

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 provides guidance on when to use the tool ('after cms_list_sounds discovery when needed'), which implies a sequential context. It doesn't explicitly name alternatives like 'use cms_list_sounds for multiple items', but the mention of discovery is a useful pointer.

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, covering the behavioral profile. The description adds no further details about side effects or constraints, but it does not contradict the annotations either.

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 brief and to the point, but the 'Guidance' segment partially repeats the main sentence and the 'context' field is somewhat cryptic. Still, it remains compact without unnecessary fluff.

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 adequately covers the core retrieval action and parameter origins, but it omits any mention of output format, error behavior, or relationship to similar getter tools. Given the simplicity of a getter, this is acceptable but not fully 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?

The schema descriptions for both parameters are meaningful ('Sound item id returned by cms_list_sounds' and 'Paragraph id returned by cms_list_sound_paragraphs'), providing context that links to list operations. The main description itself adds no extra parameter detail, but the high schema coverage warrants a score above 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 clearly states 'Read one paragraph' and 'Retrieve one sound paragraph by paragraph id', which unambiguously identifies the action (retrieve) and the resource (a single sound paragraph).

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 sibling tools like cms_list_sound_paragraphs or cms_get_sound. The description only restates its function without clarifying conditions or 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?

The description accurately reflects a read-only, idempotent retrieval operation. Annotations already declare readOnlyHint and idempotentHint, and the description adds no contradictory or misleading behavioral claims.

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 concise and front-loads the core action. The repeated 'Guidance' sentence is slightly redundant, but it does not harm clarity.

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 provides enough context for a simple get-by-id operation and references the discovery tool. It does not specify the output shape, but that absence is acceptable for this tool type.

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 only parameter, id, is well explained: it is a video item id returned by cms_list_videos. This gives the agent clear guidance on how to obtain a valid value.

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 tool retrieves one CMS video item by video id, with a specific verb and resource. It also distinguishes this from listing operations by referencing cms_list_videos for discovery.

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 advises using cms_list_videos first for discovery, which provides useful sequencing guidance. It does not explicitly contrast with related get/paragraph tools, but the intent is clear enough.

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. The description's 'Read' and 'Retrieve' align with these hints but add no further behavioral detail such as error handling or return format, which is acceptable given 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?

The description is extremely concise, consisting of a single sentence plus a short guidance line. It contains no redundant information and is well-structured for quick parsing.

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 is a simple get operation, and the description sufficiently explains what it does and how to invoke it. The lack of an output schema is not a major gap, though specifying that it returns a paragraph object could have added slight completeness.

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% with both parameters described referencing their source lists (cms_list_videos and cms_list_video_paragraphs). The description's mention of 'paragraph id' and the context list reinforces but does not add 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 clearly states the tool's function: 'Retrieve one video paragraph by paragraph id.' It uses a specific verb ('retrieve') and resource ('video paragraph'), and distinguishes itself from sibling tools like cms_get_video and cms_list_video_paragraphs.

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 direct usage guidance: retrieve a single video paragraph given the paragraph id, with context on the required ids. It does not explicitly mention alternatives, but the specificity makes the appropriate use case 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?

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description needs no extra safety caveats. The description adds context that it lists body paragraphs for one article, but no additional side-effect info is needed given 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?

The description is extremely concise, using only two short phrases. Every word adds value, and the guidance is separated clearly with a pipe separator. No redundancy or fluff.

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?

Although there is no output schema, the description provides enough context for a simple read operation: it lists body paragraphs for a given article. The absence of output details is acceptable for a tool whose purpose is obvious from the name and parameter description, but a note on what each paragraph contains could slightly improve completeness.

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 only parameter 'id' has a schema description that fully explains its role: 'Article id returned by cms_list_articles.' Schema coverage is 100%, so the description does not need to add further detail. It correctly points to the source of the id.

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 ('List') and the resource ('paragraphs' for one CMS article), distinguishing it from other paragraph-listing tools like cms_list_event_paragraphs. The guidance reinforces the specific scope.

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 guidance explicitly says 'for one CMS article', making the intended use clear. While it doesn't name alternatives, the tool name and sibling context make the choice obvious. It could benefit from saying 'use this when you need paragraphs belonging to a specific article' but that is well 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?

The annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description does not add behavioral details beyond the annotations, but there is no contradiction.

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 brief and to the point, with no redundant information. It clearly lists the filter options without excessive detail.

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 sufficient for a read-only list operation. It does not specify output structure, but that is not required for a list tool without an output schema. The guidance sentence is somewhat redundant but not harmful.

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 descriptions cover all parameters. The tool description adds value by explaining that category ids come from cms_list_cms_sections, and clarifies the 'status' filter behavior. This goes 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 clearly states the tool lists CMS articles and mentions specific filters (category, status, title, pagination, ids, sorting). It is distinct from sibling list tools for other entity types.

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 indicates when to use this tool (listing articles) and references cms_list_cms_sections for category ids, providing context. It does not explicitly compare with alternatives but the entity-specific naming makes usage 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?

Annotations already cover the key behavioral traits (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description does not contradict them—'List' is consistent with read-only semantics. The description adds minor context (app-scoped, by content type) but no significant behavioral disclosure beyond 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?

The description is compact and front-loaded with the primary purpose, but the second sentence largely repeats the first ('List CMS content sections... by CMS content type' vs. the enum in sentence one), with only 'for the current app' as genuinely new information. The trailing '| context: type' fragment is also awkwardly formatted.

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-parameter read-only list tool with no output schema, the description conveys the core operation, but it leaves ambiguity around what 'sections and categories' separately mean and does not clarify how this tool relates to the nearly identical sibling cms_list_sections. These gaps prevent a higher completeness score.

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 'type' parameter already described as 'CMS content type to discover' plus a full enum. The description reinforces the parameter role ('by CMS content type') but adds no new meaning, such as what each enum value returns or how the result differs by type, 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') and resource ('CMS content sections and categories'), and scopes it by content types (article, maps, video, photo, agenda, sound). This implicitly distinguishes it from the plain cms_list_sections sibling, though the distinction is not explicit and 'sections and categories' is slightly ambiguous.

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 guidance sentence ('List CMS content sections for the current app by CMS content type') provides clear context on when to use the tool: when you need sections filtered by a specific content type, scoped to the current app. However, it does not explicitly state when not to use it or name alternatives like cms_list_sections or the per-type cms_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 indicate read-only, idempotent, non-destructive behavior. The description adds no further behavioral details such as ordering, pagination, empty results, or errors.

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 and mostly to the point, though 'List paragraphs.' and 'Guidance: List body paragraphs...' are somewhat 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?

The description is sufficient to identify the operation and required id, but it lacks any indication of the output shape, ordering, or result details, especially given no output schema is 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?

The schema fully describes the only parameter (id) with a clear source ('returned by cms_list_events'), so baseline applies. The description contributes no additional 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?

The title and guidance clearly identify the action (list) and resource (body paragraphs for one CMS agenda event). However, the first sentence 'List paragraphs.' is vague on its own.

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 does not explain when to use this tool versus alternatives like cms_get_event_paragraph or other list paragraph tools, nor does it contrast with related event 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, and non-destructive behavior. The description adds detail about default behavior (listing non-deleted items) and filtering options, but does not mention error cases or response structure.

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 concise and to the point, covering the main functionality and filters without extraneous detail. The guidance duplicates the description but does not harm clarity.

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?

While the description does not specify the response format (no output schema is provided), it adequately describes the input parameters and the operation's purpose. The lack of response details is a minor gap given the absence of an output 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?

All 8 parameters have clear descriptions, including enum values and repetition behavior. The schema coverage is 100% and the descriptions add meaningful context beyond the basic type information.

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 tool's purpose: listing CMS agenda events, with optional filters. It is a specific verb-resource pair that distinguishes it from other list tools for different entity types.

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 usage for event listing but does not explicitly contrast with sibling list tools. The guidance repeats the description, providing no additional decision context, though the resource-specific naming makes the intended use 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?

The annotations already declare readOnly, idempotent, and non-destructive behavior, so the description does not need to restate safety. It adds the map-item scoping but no further behavioral details.

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 redundant: 'List paragraphs.' repeats the guidance that follows. The pipe-delimited 'context: id' fragment is also cryptic and adds clutter.

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 listing tool, the description adequately states what is returned. It does not mention output format or ordering, but these are not critical for this 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?

The sole parameter 'id' is already described in the schema as 'Map item id returned by cms_list_maps.' The description adds no additional parameter meaning beyond that.

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 specifies the action ('List') and the resource ('body paragraphs for one CMS map item'), which distinguishes it from sibling paragraph-listing tools for articles, events, sounds, and videos.

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 implies when to use it: when needing the body paragraphs of a specific map item. It does not explicitly mention alternatives or exclusions, but the context is 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?

Annotations already cover read-only, idempotent, non-destructive, and open-world behavior. The description adds little beyond restating filters; it does not describe default response behavior 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?

The main sentence is concise, but the appended 'Guidance:' sentence is redundant and truncated mid-phrase. This duplication and incompleteness prevent the description from being well-structured.

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 could benefit from a brief note about return shape or defaults. The schema and annotations fill many gaps, but the truncated guidance leaves the description feeling 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?

Schema descriptions cover 100% of parameters, so the baseline is 3. The description mostly restates filter names already present in the schema; only the reference to cms_list_cms_sections adds cross-tool context, but that is also in the category 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 explicitly states the action ('List'), the resource ('CMS map (point of interest) items'), and the optional filtering dimensions. It clearly distinguishes this from single-item retrieval and paragraph listing 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 explains when to use the tool by describing optional filters (category, status, search, pagination, ids, sorting) and points to cms_list_cms_sections for category ids. It does not explicitly contrast with alternatives like cms_get_map, but the list-vs-get distinction is strongly 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=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no behavioral details beyond listing the resource, such as rate limits, authorization requirements, or response format. It does not contradict annotations, but it also doesn't provide extra context, so 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 description contains two sentences, but the second sentence is a near-verbatim repetition of the first part: 'Guidance: List CMS photo gallery items, optionally filtered by one photo gallery section.' This redundancy wastes space and could confuse the agent. A concise single sentence would suffice.

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, the description covers the action and main filters but does not explain the structure of returned photo items or how filters combine (e.g., AND vs OR). However, given that the sibling cms_get_photo likely describes a single photo object, and the parameters are well-documented, it is reasonably complete, though not exhaustive.

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%, meaning every parameter has a description in the schema. The tool description lists the filter categories but adds no additional meaning beyond what the schema already provides. For instance, the schema already explains that 'section' is returned by cms_list_cms_sections. The description is redundant here, so a 3 is given.

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 verb 'List' and the resource 'CMS photo gallery items', and enumerates the available filters (section, status, search, pagination, id, sorting). It is unambiguous and distinguishes from sibling list tools for other content types (e.g., cms_list_articles, cms_list_events) by naming the specific resource.

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 that this tool lists photo gallery items, which is appropriate when a list of photos is needed. It does not explicitly mention alternatives like cms_get_photo for single photo retrieval, but the context is clear. There is no explicit guidance on when not to use it, so a 4 is 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?

The annotations already indicate readOnly, idempotent, and non-destructive behavior, and the description's 'list' wording matches this. It does not add much behavioral detail beyond the annotations, but there is no contradiction.

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 first sentence is concise, but the appended 'Guidance: ... | context: type' is redundant and awkwardly repeats the same information. This hurts the overall structure and focus.

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 listing tool with one parameter and no output schema, the description is mostly complete. It explains the scope, mentions content and non-content sections, and points to the more specific CMS section tool, giving enough context for an agent to select it.

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 parameter schema already covers the 'type' parameter thoroughly with common values and the distinction from cms_list_cms_sections. The description only adds 'by section type', so it contributes little beyond the existing schema 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 clearly states the tool lists the generic app section catalog by type, including content and non-content sections. It also distinguishes itself from cms_list_cms_sections by using the word 'generic' and referencing CMS-only alternatives.

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 and parameter guidance indicate when to use this tool versus cms_list_cms_sections, especially through the parameter description instructing to prefer cms_list_cms_sections for CMS-only sections. The main description could be more explicit but still gives useful direction.

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 (readOnlyHint=true, destructiveHint=false) already indicate a safe read operation. The description's 'List' is consistent with these annotations and adds no further behavioral information, but there is no contradiction.

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 extremely short and to the point, containing only the essential verb and resource. Every word serves a purpose, and the format is clean and easy to parse.

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 provided, the description does not explain return fields or pagination behavior. However, the purpose is clear enough for a simple list operation, and the sibling tools follow a similar pattern, so it is adequate but not complete.

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

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

The only parameter 'id' is fully described in the schema as 'Sound item id returned by cms_list_sounds.' The tool description adds no additional meaning beyond this, so it meets the baseline but does not exceed it.

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?

Description clearly states the action ('List') and the resource ('body paragraphs for one CMS sound item'), and the title/name disambiguates from sibling paragraph-listing tools by specifying 'sound'. It also notes the 'id' context from cms_list_sounds, making the scope 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?

No explicit guidance on when to use this tool versus alternatives (e.g., cms_get_sound_paragraph or cms_list_sounds). It implies the id must come from cms_list_sounds, but does not describe scenarios where this tool is preferred or not recommended.

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. The description adds transparency by clarifying default behavior (e.g., 'Omit to list every non-deleted item in scope' and 'Omit to list across all categories'), which goes beyond the annotations and helps set expectations.

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 concise, but it contains slight redundancy with the 'Guidance' line repeating the core filtering idea. It is still compact and front-loaded with the primary action, so minor redundancy does not detract much.

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 complexity of 8 optional parameters and no output schema, the description adequately covers all relevant aspects by naming each filter type and referencing the schema for details. It does not describe return format, but that is not required without an output schema, and the filter semantics are complete enough for an agent to invoke 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 descriptions cover 100% of parameters with clear explanations for each (e.g., 'Optional sound category ids returned by cms_list_cms_sections'). The tool description does not add significant meaning beyond summarizing these filters, so it meets the baseline but does not elevate it.

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 tool lists CMS sound items, which is specific and unambiguous. It distinguishes from sibling tools like cms_list_videos or cms_get_sound by naming the resource type, and the reference to cms_list_cms_sections for category ids further clarifies scope.

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

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

The description implies usage for listing sound items with optional filters, and the reference to category ids from cms_list_cms_sections provides a practical hint. However, it does not explicitly contrast with alternatives (e.g., when to use cms_get_sound vs. cms_list_sounds), though the context of sibling tools makes this largely inferable.

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, covering the safety profile. The description adds no additional behavioral context such as ordering, filtering, pagination, or what fields each paragraph contains. The 'context: id' note is unhelpful.

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 poorly structured with a redundant 'Guidance:' prefix and a cryptic '| context: id' suffix. The phrase 'List paragraphs' is vague and not front-loaded with the specific 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?

For a list tool with no output schema, the description fails to describe what a paragraph contains or the structure of the returned list. It also omits any details about ordering or pagination, leaving an agent without enough information to anticipate 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?

Schema coverage is 100% and the id parameter is well described as 'Video item id returned by cms_list_videos.' The description does not add any extra meaning 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 states 'List body paragraphs for one CMS video item,' which specifies the verb (list), the resource (body paragraphs), and the scope (one video item). This is clear and not a tautology, though it does not explicitly contrast with sibling list tools like cms_list_article_paragraphs.

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?

There is no guidance on when to use this tool versus alternatives such as cms_get_video_paragraph or other cms_list_*_paragraphs tools. The cryptic 'context: id' offers no practical usage direction.

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. The description adds a meaningful behavioral detail by noting that omitting the status filter lists 'every non-deleted item in scope', which clarifies the default behavior. No contradictions with 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?

The description consists of two sentences, but the second sentence (under 'Guidance:') repeats the first nearly verbatim, adding no new information. This redundancy makes it less concise than it could be, though it is still brief overall.

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 the description does not state what the response format will be (e.g., array of video items, pagination metadata). It implies a list but leaves the return shape unspecified, which is a notable gap given the absence of an output 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 description coverage is 100% — every parameter (id, page, sort, order, search, status, category, per_page) has a description. The tool description adds no new parameter information beyond what the schema already provides, 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 clearly states the verb 'List' and the resource 'CMS video items', and it enumerates optional filters (category, status, search, etc.) that distinguish this from other list tools. The name and title align perfectly, and the reference to cms_list_cms_sections for category IDs adds precision.

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 specifies when to use the tool: to list videos with optional filters, and it provides concrete guidance on the status filter ('Omit to list every non-deleted item in scope'). It does not explicitly contrast with cms_get_video or cms_list_video_paragraphs, but the resource and filters make the use case clear enough.

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 mark this as destructive and non-idempotent, and the description adds no additional context about side effects, such as overwriting the paragraph order or requiring all paragraph IDs to be supplied. The phrase 'Reorder all paragraphs' hints at the requirement but does not explain behavioral consequences beyond the name.

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

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

The description is very concise, with the core action front-loaded. The guidance section is somewhat redundant ('Reorder all paragraphs for one CMS article' repeats the purpose) but not harmful. It is efficient and easy to parse.

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 2-parameter tool with no output schema, the description is adequate. It conveys that all paragraphs must be reordered and that the id and paragraph_ids are the relevant context. However, it does not mention any return value, success indicators, or immediate effects, which could be helpful but is not strictly required given the low 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 both parameters are documented with useful descriptions (e.g., 'Full ordered list of paragraph ids'). The description only lists the parameter names ('context: id, paragraph_ids') without adding any extra meaning beyond the schema, so it meets 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 action ('Reorder paragraphs') and scopes it to 'one CMS article', which clearly distinguishes it from sibling reorder tools like cms_reorder_event_paragraphs. The verb and resource are explicit and 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 description clearly indicates the use case (reorder all paragraphs for one CMS article) and implicitly separates it from reordering other entity types. However, it does not explicitly name alternative tools or state when not to use it, so it lacks full guidance but is still 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?

Annotations already mark the tool as destructive (destructiveHint=true) and not read-only. The description adds that it reorders 'all paragraphs', implying a full replacement of ordering, but does not elaborate on side effects, validation, 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 very brief and to the point, containing only necessary information. The formatting is slightly awkward with the '| context: id, paragraph_ids' suffix, but it does not detract from clarity or economy of words.

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 is simple with only two parameters and no output schema. The description sufficiently covers the operation's purpose and parameter roles. While it omits details about errors or return values, such information is not typically required for a straightforward reordering 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?

Both parameters (id and paragraph_ids) are already described in the input schema with clear explanations (e.g., 'Event id returned by cms_list_events'). The description adds no additional semantic detail beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Reorder paragraphs') and the target resource (paragraphs for one CMS agenda event). It is unambiguous and easily distinguished from sibling reorder tools for other content types by name and scope.

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 'Guidance' line explicitly clarifies that the operation applies to 'all paragraphs for one CMS agenda event', providing clear usage intent. However, it does not explicitly contrast with sibling reorder tools (e.g., cms_reorder_article_paragraphs), though the tool name itself makes the distinction apparent.

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 flag the operation as destructive, non-read-only, and non-idempotent. The description further clarifies that the supplied paragraph_ids represent the full ordered list, reinforcing that the operation replaces the existing 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?

The description and guidance are extremely concise and directly actionable. There is no filler or redundant 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?

The tool is simple, has no output schema, and its input plus effect are fully described by the parameter schema and guidance. Missing details such as error behavior or return values are not necessary for this straightforward reorder 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?

Both parameters have meaningful schema descriptions: id is sourced from cms_list_maps and paragraph_ids is a full ordered list. This goes beyond mere names and gives enough context to construct a correct call.

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?

Clearly identifies the operation as reordering paragraphs and scopes it to a single CMS map item. The verb 'Reorder' plus the resource and map-item context is specific and distinguishes it from sibling reorder tools for articles, events, sounds, and videos.

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 guidance explicitly says to reorder all paragraphs for one CMS map item, making the primary usage context clear. It does not explicitly name alternatives, but the map-specific language and sibling tool names make the appropriate selection obvious.

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 destructiveHint=true and readOnlyHint=false, so the description adds no extra behavioral context beyond stating the action. It does not describe side effects, idempotency, or any additional caveats. The description relies entirely on annotations, offering no new transparency value.

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 very short and front-loaded with the main sentence, but the 'Guidance' line is somewhat cryptic and mixes guidance with a context listing. It is concise but could be clearer and more structured, e.g., separating usage guidance from parameter 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 destructive reorder operation with no output schema, the description covers the core action and the schema covers parameters. However, it lacks any usage context or preconditions, and the minimal text leaves some ambiguity about the exact ordering semantics (though the schema hints at it). Overall, it's barely adequate but missing any extra detail that would help an agent decide when to use it.

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 provides complete descriptions for both parameters (id and paragraph_ids) with 100% coverage, so the schema already explains their meaning and format. The description only repeats 'id, paragraph_ids' without adding any new semantic detail. 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 states a specific verb ('Reorder') and resource ('paragraphs'), and the guidance line clarifies it applies to one CMS sound item. However, it does not explicitly differentiate from sibling reorder tools (e.g., cms_reorder_article_paragraphs) except by the resource type, so it's clear but not fully distinguishing.

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. The description does not mention any conditions or exclusions, leaving the agent to infer from the tool name that it applies to sound items. There is no explicit 'use when' or 'not for' statement.

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 description says 'Reorder all paragraphs,' which implies a full replacement of ordering and aligns with the destructiveHint annotation. It does not add significant behavioral detail beyond the annotations, but there is no contradiction.

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 compact and directly to the point, with no unnecessary wording. The parameter descriptions are also concise and informative.

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 reorder operation with two well-described parameters and no output schema, the description is complete. It covers what the tool does, the target resource, and the expected parameter semantics.

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 are described with helpful context: id is identified as returned by cms_list_videos, and paragraph_ids is clarified as the full ordered list belonging to the video. This goes beyond the basic schema and aids correct usage.

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 tool name and description clearly state it reorders paragraphs for a CMS video item, distinguishing it from sibling reorder tools for articles, events, maps, and sounds. The resource (video paragraphs) and action (reorder all) are specific.

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 that this tool is for reordering all paragraphs of one CMS video item. It does not explicitly mention alternatives or exclusions, but the resource-specific wording makes the intended use unambiguous.

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 description adds no behavioral detail beyond what the annotations already convey (destructiveHint true, readOnlyHint false). It does not mention partial-update semantics or side effects; those are only implied by the schema descriptions, not the tool description itself.

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 extremely concise, consisting of two short lines. It front-loads the core purpose and does not waste words, though the 'Guidance' line is somewhat 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?

Given the high complexity (16 parameters, nested objects, enums), the description is very thin and lacks a high-level overview of what fields are updatable or that it supports partial updates. However, the schema provides thorough parameter explanations, so the description does not need to carry that burden entirely.

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% per the context signals, and the description text adds no parameter meaning beyond the schema. The baselines for high coverage apply, so a score of 3 is appropriate even without param info in the description.

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 identifies the tool's action ('Update article') and specifies the target resource ('one CMS article by article id'), giving a specific verb and resource. It does not explicitly differentiate from sibling update tools like cms_update_event, but the resource type 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?

The description provides no guidance on when to use this tool versus alternatives such as cms_create_article or other update tools. It lacks any contextual advice like 'use this for modifying an existing article' or a comparison to creation or deletion.

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 disclose that this is a destructive, idempotent, non-read-only operation (readOnlyHint: false, destructiveHint: true, idempotentHint: true). The description itself says 'Update', which aligns with these annotations, and there is no contradiction.

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 concise and front-loaded with the essential action ('Update paragraph'). The guidance clarifies the target and key identifiers. It is appropriately sized for a simple update operation, though it could include a bit more detail on updatable fields.

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 minimal and does not explain whether the update is partial or full, nor does it mention optional fields or any side effects beyond what annotations state. Given the tool's simplicity and the annotations, it is adequate but not fully comprehensive.

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 descriptions already cover all parameters (100% coverage). The description adds a minor contextual note ('context: id, paragraph_id') but largely relies on the schema, so no significant additional meaning is provided beyond 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 clearly states the verb 'Update' and the resource 'article paragraph', distinguishing it from sibling tools for other paragraph types (e.g., event, map). The guidance explicitly mentions 'by paragraph id', making the purpose unambiguous.

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

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

The description indicates the tool updates one article paragraph using paragraph id, which provides clear context for when to use it. It does not explicitly contrast against alternatives, but the resource-specific wording and required parameters make the 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?

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description merely says 'Update,' which is consistent but adds no additional behavioral context such as partial-update semantics, potential side effects, or permission requirements. It contributes nothing beyond 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?

The description is extremely short—two sentences—and gets to the point immediately. It is well-structured with a clear 'Guidance' label, but it is arguably too sparse for a 22-parameter tool. Still, it is efficient and avoids unnecessary words.

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 complexity (22 parameters, nested objects, no output schema), the description is insufficiently informative. It does not mention that all fields except id are optional or that omitted fields retain current values, nor does it explain the update semantics beyond the schema. An agent might struggle to understand the tool's capabilities without reading the entire 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 description coverage is 100%, so the baseline is 3. The description adds only 'by event id,' which the schema already documents ('Event id returned by cms_list_events'). It provides minimal extra value for the remaining 21 parameters.

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

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

The description states 'Update event' and 'Update one CMS agenda event by event id,' which clearly identifies the verb (update) and resource (CMS agenda event). It is specific enough to distinguish from article/map/video tools, though it does not explicitly contrast with cms_update_event_paragraph.

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 about when to use this tool versus alternatives like cms_update_event_paragraph or when not to use it. The only hint is 'by event id,' which is implicit. No exclusions or context 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 indicate readOnlyHint=false and destructiveHint=true, but the description itself adds no extra context about side effects or what might be overwritten. No contradiction exists, but transparency is not enhanced beyond 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?

The description is concise and front-loaded, but the first sentence 'Update paragraph.' is somewhat redundant with the following guidance. Overall, it is efficient and to the point.

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 minimal and does not mention optional parameters or expected outcomes. While sufficient given the schema and annotations, it lacks depth and context about when or how to use the tool effectively.

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 provides full descriptions for all parameters (100% coverage), and the description does not add additional semantic meaning beyond referencing id and paragraph_id. 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 clearly identifies the action as updating an event paragraph by paragraph id, and the title further specifies it. It is specific enough to convey the tool's purpose, though it could be more explicit about the event context.

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 use for event paragraphs but does not explicitly differentiate from sibling tools like cms_update_article_paragraph or cms_update_map_paragraph. Direct guidance on when to choose this tool over alternatives is missing.

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