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

Annotations declare readOnlyHint=false and destructiveHint=false, and the description adds crucial behavioral context: it mutates participant data, requires prior token acquisition, imposes single-entry limits, and mandates honest reporting of API results. The honesty rule ('report EXACTLY what the API returned') and the prohibition on real sweepstakes use go well beyond structured metadata. No contradictions.

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 well-organized with headings, but it suffers from duplication: the opening paragraph is nearly identical to the '## When to use' section. This redundancy inflates length without adding new information. Otherwise, each section is purposeful and front-loaded.

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

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

For a tool with 5 parameters, a nested object, and no output schema, the description is remarkably complete. It covers pre-call dependencies, validation rules, consent verification, field naming conventions, response handling (honest reporting), and edge cases like US phone formatting. No output schema is provided, but the honesty instruction tells the agent how to interpret and relay API responses.

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 covers 100% of parameters, but the description adds significant value: clarifies that field keys must use underscores, gives an example, warns about US phone digit stripping, and specifies which parameters are required and defaults. This transforms a bare schema into actionable guidance.

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

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

The description opens with 'Add a new participant to a sweepstakes' — a clear verb+resource statement. It distinguishes this from sibling tools like fetch_participants, count_participants, and delete_participant by focusing on the creation action. The testing-only scope and pre-call steps further clarify its unique role.

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 states when to use: after fetch_sweepstakes and get_entry_fields, with a numbered pre-call list. Provides exclusions: only one at a time, never bulk/loops, not for real production entries (use Entry Page or proper integration). Includes refusal guidance for mass-loading requests, making usage boundaries 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?

Discloses important behavioral traits beyond annotations: the operation is billable, there is a per-plan cap on total sweepstakes, and user confirmation is mandatory. It also describes the complete copy nature (entry pages, calendar events, etc.). These details add significant context that annotations (readOnly=false, openWorld=true) do not convey. 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 repetitive: the exact same 'When to use' content appears twice, both before and after the heading. It also includes lengthy ethical disclaimers and tool-chaining remarks that are not directly necessary for tool invocation. While front-loaded with key info, the redundancy and verbosity hurt 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?

Covers prerequisites, billing, limits, confirmation workflow, and copy scope comprehensively. However, with no output schema, it does not mention what the tool returns (e.g., the cloned sweepstakes object) or potential error conditions. For a mutation tool, this is a minor omission, but the description is otherwise thorough.

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 documents all 7 parameters with full descriptions and formats (100% coverage). The 'Parameters to validate' section repeats this information verbatim without adding new semantics or constraints. Therefore, it meets the baseline for high schema coverage but does not enhance parameter understanding further.

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 'Clone an existing sweepstakes with new parameters' and enumerates exactly what is copied (entry pages, calendar events, short links, groups, and all configurations). This specific verb+resource framing distinguishes it from siblings like create_sweepstakes and update_sweepstakes.

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

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

Provides explicit when-to-use guidance: call fetch_sweepstakes first to obtain the handler, check plan limits via get_plan, confirm with the user before each clone, and never batch without approval. This goes above and beyond typical usage instructions and clearly differentiates from alternative 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 convey read-only, idempotent, and non-destructive behavior. The description adds value by mentioning the pre-call context and filter semantics, but it does not disclose other behavioral details like response format, date range inclusivity, or potential edge cases.

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 well-organized with headings, bullet points, and sections (When to use, Pre-calls required, Parameters to validate), making it scannable. The opening sentence is concise, but the subsequent markdown section repeats some of the same content, introducing slight redundancy.

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

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

Since there is no output schema, the description should explain return values, but it does not. It also omits details such as pagination or whether counts are broken down by filter type. For a simple count tool, this may be acceptable, but there is still a notable 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%, so the baseline is 3. The description restates parameters and adds minor clarifications (e.g., 'all (default)' for filter_type, ISO 8601 examples for dates), but this adds marginal value beyond the schema descriptions.

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

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

The description clearly states 'Get participant counts for a sweepstakes', identifying the specific verb and resource. The name 'count_participants' and the description distinguish this from sibling tools like fetch_participants (which retrieves individual records) by emphasizing aggregate counts.

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 explicit pre-call guidance: 'Use fetch_sweepstakes first to get the sweepstakes_token.' It also explains filtering options and date range usage. However, it does not list alternative tools or when-not-to-use cases, so it falls short of a perfect score.

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 discloses critical behavioral details beyond annotations: the API server uses UTC, today's date may be rejected as past, the exact error message 'Cannot Create Events In The Past', and a directive to always use tomorrow or later. This is actionable and not present in 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 highly redundant—the same UTC date rule appears multiple times, and the parameter list duplicates the input schema almost verbatim. While organized under headings, the excessive repetition makes it bloated and harder 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 tool with 19 parameters and no output schema, the description thoroughly covers the purpose, all parameter details, the required fields, and the primary usage pitfall (UTC date validation). However, it omits any description of the return value or response format, which would help an agent confirm success.

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?

Although the input schema covers all 19 parameters (100% coverage), the description adds a crucial semantic constraint for start_date and end_date: they must be in the future due to the UTC rule. This goes beyond the schema's generic format 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 states 'Create a new calendar event' with a specific verb and resource, and lists key fields (title, dates, location, time, notifications). This distinguishes it from sibling tools like update_calendar_event, delete_calendar_event, and fetch_calendar_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 provides clear context for when to use the tool (creating new events) and explicitly warns against using today's date, advising to suggest tomorrow instead. However, it does not mention alternative tools or when to prefer update_calendar_event.

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 this is a write operation (readOnlyHint false) but not destructive. The description adds behavioral context by noting the group_name must be unique within the sweepstakes and that fetching the token first is required. It doesn't contradict annotations and provides extra value beyond the structured fields.

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 structured with clear sections, but it repeats the opening sentence in the 'When to use' section almost verbatim. The parameter validation section also duplicates the schema. While organized, it could be more concise without losing value.

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

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

For a simple create tool with two well-documented parameters and no output schema, the description covers required pre-calls and parameter validation. It provides enough context for an agent to invoke it correctly, though it doesn't mention returned values or error cases, which would be nice but not essential.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description repeats the parameter details without adding new semantic meaning. Baseline of 3 is appropriate since the schema handles the parameter explanations.

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 'Create a new group within a sweepstakes' with a specific verb and resource. It distinguishes from sibling tools like update_group and delete_group by focusing on creation. The additional context about organizing and segmenting participants further clarifies the tool's role.

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 states when to use the tool and requires a pre-call to fetch_sweepstakes if given a name instead of a token. It provides a clear 'When to use' section, but it doesn't explicitly mention when not to use it or name alternative tools, so it falls short of a 5.

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

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

The description adds substantial behavioral context beyond the annotations: AES-256-CBC encryption for content, explicit note that titles are not encrypted, a whitelist of allowed HTML tags, prohibition of scripts/iframes, and guidance against <br>&nbsp; for spacing. This enriches the agent's understanding of security and formatting constraints.

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 has clear structure with headings, but it suffers from redundancy: the opening paragraph is identical to the 'When to use' section, and the 'Notes' section repeats the same HTML and encryption details. This duplication makes it longer than necessary without adding new 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?

Despite lacking an output schema, the description thoroughly covers input requirements, security constraints, HTML whitelist, and formatting pitfalls. It does not describe the return value (e.g., created note ID), but for a create operation this is a minor gap given the depth of other contextual details.

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 comprehensive descriptions for all three parameters with 100% coverage. The description's parameter section largely mirrors the schema, adding no new semantic meaning beyond what is already structured. The encryption and HTML notes are tool-level, not parameter-specific, so the baseline of 3 is appropriate.

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

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

The description begins with 'Create a new note,' using a specific verb and resource that clearly differentiates it from sibling tools like update_note, delete_note, and get_note. The purpose is unambiguous and precisely states the operation's 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?

A dedicated 'When to use' section explicitly states the tool's purpose, though it merely repeats the primary description. It does not explicitly mention when not to use it or point to alternatives, but the context of creating new notes is clear from the sibling list and the create verb.

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

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

The description goes beyond annotations by explaining the secondary rules behavior: if primary rules exist, the new rules will be secondary and not published on the Entry Page or short URL, and the user must be warned. This is critical behavioral context not visible from annotations alone. 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 structured with headings but contains significant redundancy. The same text about the secondary rules warning and fetch_sweepstakes appears multiple times (in the opening paragraph, in 'When to use', and in 'Pre-calls required'). This unnecessary repetition makes it less concise than it could 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?

The description covers the essential context: prerequisites, the warning about primary rules, parameter details, and alternatives. It does not mention the return value of the tool (no output schema exists), but for a create operation this is often inferable. Overall, it is sufficiently complete for an agent to use the tool correctly.

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

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

Schema coverage is 100% with descriptive parameter definitions, so the baseline is 3. The description adds little new meaning beyond the schema; it restates parameters and their formats. The context about fetching the sweepstakes_token is useful but does not deepen the parameter semantics itself.

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 a new official rules document for a sweepstakes.' It uses a specific verb and resource, and differentiates from sibling tools like create_rules_wizard and update_rule by noting when each is appropriate.

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

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

Provides explicit when-to-use guidance: 'Use this only when you have a fully prepared HTML document and the wizard does not apply' and 'Prefer create_rules_wizard for legal-grade Official Rules.' Also specifies required pre-calls (fetch_sweepstakes, fetch_rules) and the warning procedure, giving clear instructions on when to use and what to check first.

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 non-read-only, non-idempotent behavior, which the description complements rather than contradicts. It discloses critical behavioral traits: the wizard asks questions, generates all legal text server-side, marks rules as primary vs secondary, and includes specific caveats about Age Gate and GeoLocation. These details go far 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 well-structured with headings, but it duplicates the entire parameter list that already exists in the schema, making it overly long. The opening paragraph is also repeated verbatim under '# create_rules_wizard', wasting space. It is front-loaded but not concise.

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 (49 parameters, conditional logic, compliance checks) and no output schema, the description is remarkably complete. It covers pre-calls, parameter validation, post-creation verification, compliance warnings, and return value hints (is_primary). It leaves little ambiguity for an agent to proceed.

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?

While schema coverage is 100%, the description adds essential contextual semantics: pre-fill sources (get_business/get_profile), conditional requirements (e.g., entry_period_items needed when entry_period_selector=2), and special rules (rules_language always 'en', AMOE URL is not entry page). This meaningfully extends 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 'Generate official sweepstakes rules via the 14-step wizard' — a specific verb and resource. It distinguishes itself from sibling tools like create_sweepstakes and create_rule by focusing on the wizard flow and providing a unique output link (https://swpp.me/r/[handler]).

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

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

Provides explicit pre-call steps (fetch_sweepstakes, get_business, get_profile, fetch_rules), when to warn about secondary rules, and when to ask questions. It mentions using update_rule for corrections after creation, but does not explicitly contrast with alternative tools like create_rule for direct rule creation, so it lacks full when-not-to-use 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 annotations only indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the description carries substantial disclosure weight. It explicitly states this is a billable operation that creates real production data, warns about plan caps, and mandates user confirmation. No contradiction with annotations exists.

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 well-structured with headings and front-loaded critical warnings, but it is overly long and redundant: the raw description block repeats nearly verbatim in the '# create_sweepstakes' section. Extraneous phrases like 'Use them internally for tool chaining but present only human-readable information' add noise without operational value.

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

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

Given 11 parameters, no output schema, and sparse annotations, this description is exceptionally complete. It covers preconditions, plan limits, date/time validation rules, handler constraints, type selection, post-creation steps, and ethical/confirmation guardrails. No critical operational context is missing.

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

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

The input schema already covers 100% of parameters, so baseline is 3. The description adds genuine extra value beyond the schema: generating the handler from the name, always setting create_in_calendar and sync_with_winners to true, and explaining the rare use of SMS/Social types. The duplication of schema text is the only downside.

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

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

The description opens with a specific verb+resource ('Create a new sweepstakes programmatically'), lists the required fields, and clearly distinguishes this tool from sibling mutation tools like clone, update, and delete by emphasizing the creation of a new entity. It also clarifies the default type and when other types are appropriate.

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 an explicit 'When to use' section, mandatory pre-calls (get_plan, fetch_sweepstakes, fetch_timezones), a hard confirmation requirement, a prohibition on batch creation without per-item approval, and specific cap-warning behavior. It clearly tells the agent what to check before invoking and when not to proceed.

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?

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses specific behaviors: ticket is assigned to all admins if assign_to is omitted, never fabricate admin credentials, HTML tag whitelist and security restrictions, and spacing conventions. This adds substantial operational context that annotations alone would not convey.

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

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

The description is well-structured with headings and bullet points, but it is verbose and repetitive. The opening paragraph duplicates the 'When to use' section, and formatting restrictions appear twice (in the intro and in Notes). While the organization aids scanning, redundant statements prevent a higher score.

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 create operation with 4 parameters and no output schema, the description covers all necessary context: required fields, optional assignment semantics, security constraints, and a clear directive on when to avoid using the tool. It is sufficiently complete for an agent to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra guidance for assign_to (do not guess, case-insensitive names, exact emails) and clarifes the allowed HTML in description. However, much of the 'Parameters to validate' section repeats schema descriptions, so the incremental value is solid but not exceptional.

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

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

The description opens with 'Create a new support ticket with title, description, and priority level' — a specific verb + resource + key parameters. This clearly distinguishes it from sibling create_* tools (create_note, create_todo, etc.) and states the primary action unambiguously.

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 explicit when-not-to-use guidance: 'Search fetch_documentation first; only open a ticket if docs do not solve the question.' It also details when the optional assign_to parameter should be used (only when user explicitly provides a name or email), and notes the prerequisite that only admin-level users can be assigned.

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 only indicate readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds valuable behavioral context: admin privileges required, non-admin users receive 403, and specific HTML formatting constraints for the description parameter. This goes beyond the annotations to clarify authorization and input validation.

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 highly repetitive, with admin-only and HTML constraints stated multiple times (intro, 'When to use' section, Notes). The opening paragraph mixes purpose with formatting/spacing rules before the parameter list. While it has headings, the redundancy inflates length without adding value.

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

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

The description covers the key operational context: admin-only access, 403 behavior, and HTML restrictions. However, it does not describe the return value or success response, which is notable given the absence of an output schema. It also repeats information, which detracts from completeness. Overall adequate but with gaps.

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

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

Schema description coverage is 100%, so baseline is 3. The description repeats parameter details in the 'Parameters to validate before calling' section but adds no new meaning beyond the schema. It does emphasize validation, but that is procedural guidance, not additional parameter semantics.

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

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

The description clearly states 'Create a new internal To-Do item' with a specific verb and resource. It distinguishes from sibling tools like update_todo, delete_todo, and fetch_todos. The 'internal' qualifier 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?

The description includes a '## When to use' heading but the content only repeats the purpose and admin-only constraint. It does not explicitly compare to alternatives like update_todo or delete_todo, nor does it state when not to use the tool. Usage is implied rather than explicitly guided.

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?

Beyond the destructiveHint annotation, the description adds that the action is irreversible, cannot be undone, and instructs the agent to explain what will be lost. This provides critical behavioral context for a destructive operation.

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 well-structured with clear 'When to use', 'Parameters', and 'Notes' sections. However, the first two sentences are duplicated verbatim in the 'When to use' section, adding minor redundancy.

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

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

For a one-parameter destructive tool with no output schema, the description thoroughly covers the action, prerequisite, irreversibility, and required user confirmation. Nothing essential is missing.

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

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

Schema already documents event_token fully (UUID format, required). The description adds valuable context by specifying how to obtain the token ('Use fetch_calendar_events first'), which is not in the schema. This justifies a score above the baseline 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 uses a specific verb ('delete') and resource ('calendar event'), clearly distinguishing it from sibling delete tools like delete_file or delete_todo. It also states the permanent nature, 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?

The description explicitly instructs to use fetch_calendar_events first to obtain the event_token, and includes a warning to always confirm with the user. However, it does not explicitly contrast with update_calendar_event or other alternatives, so it falls short of a 5.

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

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

The description goes beyond the annotations by specifying concrete effects: removal from S3 storage and the database, immediate quota freeing, and irreversibility. It also adds the safety requirement to confirm with the user. This provides valuable behavioral context beyond the destructiveHint annotation.

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 heavily repetitive: the opening paragraph is repeated verbatim in the 'When to use' section, and the notes section echoes the same content. While markdown headings provide structure, the redundancy makes it unnecessarily long. Every sentence does not earn its place; this could be condensed to two sentences.

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 tool with one parameter and no output schema, the description covers the key behavioral outcomes (deletion, storage removal, quota freeing) and provides a critical safety warning. It does not discuss error cases or return values, but given the tool's simplicity and the annotations covering destructive/idempotent hints, it is largely 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 already covers 100% of the single parameter with a clear description. The description's 'Parameters to validate' section simply repeats the schema text verbatim, adding no additional meaning. Baseline 3 is appropriate because the schema does the heavy lifting and the description adds no new insights.

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 'Permanently delete a file from the user's Drive' with a clear verb and resource. It also details the deletion from S3 storage and database, distinguishing it from other delete_* tools. The scope is unambiguous and matches the tool name.

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

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

The 'When to use' section restates the purpose rather than providing situational guidance or excluding alternatives. It does include a strong usage instruction ('ALWAYS ask for explicit user confirmation before calling'), but it does not mention when to use this vs. other file tools or when not to use it. Guidance is implied rather than explicit.

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

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

Discloses destructive and irreversible nature, expanding on the destructiveHint annotation. Adds specific constraints (primary groups, locked groups, groups with participants) and a confirmation requirement, going beyond annotation data. 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 verbose and redundant, repeating the same opening sentence in the 'When to use' section. While it uses clear section headings, the duplication adds unnecessary length.

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

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

Covers prerequisites, deletion constraints, and user confirmation etiquette. No output schema exists, but for a destructive tool the operational context provided is sufficient; could benefit from noting expected response type but is generally complete.

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

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

Schema already fully describes both parameters with UUID format. The description repeats this but adds valuable context on how to obtain the tokens via fetch_sweepstakes and fetch_groups, elevating practical understanding above schema alone.

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 'Permanently delete a group from a sweepstakes' with a specific verb and resource. Differentiates from sibling deletion tools like delete_sweepstakes and delete_participant by explicitly targeting groups.

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

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

Provides explicit 'When to use' section and required pre-calls (fetch_sweepstakes, fetch_groups). Includes warnings about groups that cannot be deleted and instructs to always confirm with the user, offering strong usage 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 and readOnlyHint=false, but the description adds critical warnings: 'cannot be undone', 'DESTRUCTIVE — IRREVERSIBLE', and instructs to explain what will be lost. This goes beyond the annotations and gives the agent actionable behavior for a destructive operation.

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 structured and front-loaded, but it has redundancy: the main description repeats in the 'When to use' section, and the parameter info duplicates the schema. The warning appears multiple times. While not excessively long, the repetition detracts from 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?

For a simple destructive tool with one parameter and no output schema, the description covers purpose, prerequisite, parameter validation, and safety warnings. It is complete and leaves no critical gaps for an agent to misuse the 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% with a clear description for note_token ('The note token to delete (UUID format)'). The description repeats this information in a 'Parameters to validate before calling' section but adds no new semantics beyond the schema. Baseline 3 is appropriate since the schema fully documents the 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 clearly states 'Permanently delete a note' with a specific verb and resource. It distinguishes from sibling tools like delete_todo or delete_calendar_event by naming 'note' explicitly. The prerequisite 'Use fetch_notes first to get the note_token' adds 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?

Explicitly instructs to call fetch_notes first to obtain the note_token, and warns to always confirm with the user before calling due to destructive nature. This provides clear workflow context and safety guidance, going beyond what the schema or annotations alone offer.

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 destructiveHint, but the description goes further by emphasizing irreversibility, requiring user confirmation, and explaining what will be lost. It also mentions using get_participant before deletion, which adds behavioral context 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 well-organized with sections, but the first sentence is repeated almost verbatim in the 'When to use' section, creating minor redundancy. Overall, it is succinct and front-loaded with the warning.

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 destructive tool with no output schema, the description provides all necessary context: pre-call requirements, parameter validation notes, and a clear warning about confirmation and irreversibility. It is complete for an agent to safely invoke.

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 descriptions in the input schema already cover both parameters. The description repeats the parameter details but adds no new semantics beyond what the schema provides, so it meets the baseline without further value.

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

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

The description explicitly states 'Permanently delete a participant from a sweepstakes', which is a specific verb+resource pair that clearly distinguishes this from sibling delete_* tools. It also warns that the action cannot be undone, adding 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?

Provides clear context with a 'When to use' section and lists a required pre-call (fetch_sweepstakes) for converting a sweepstakes name to a token. It also instructs to use get_participant first for verification, but does not explicitly contrast with alternative tools or mention when not to use it.

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

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

Annotations already flag destructiveHint, but the description adds crucial behavior: 'cannot be undone,' 'Always confirm with the user before calling,' and 'Explain what will be lost.' This enriches beyond structured metadata 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 content is structured with headings and useful warnings, but the initial paragraph is repeated verbatim in the 'When to use' section, adding redundancy. It is reasonably sized but not maximally concise.

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 covers prerequisites, validation, and irreversibility. It could mention what a successful response looks like, but that is minor 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?

Schema coverage is 100% and both parameters are described with UUID format in the schema. The description repeats this information rather than adding new semantic depth, 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 and resource: 'Permanently delete an official rules document from a sweepstakes.' This clearly distinguishes from sibling tools like create_rule, update_rule, and fetch_rules, and the warning about irreversibility adds important 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 provides clear when-to-use guidance and required pre-calls (fetch_rules, fetch_sweepstakes for name-based input). It does not explicitly mention alternatives like update_rule for edits, so it stops short of full when-not-to-use 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 description adds key behavioral context beyond annotations: the action is irreversible, only pending drawings are eligible, and it warns to confirm with the user before calling. This complements the destructiveHint annotation with specific consequences and guardrails.

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 organized with headers but repeats the same information: the opening paragraph duplicates the 'When to use' section, and the Notes section restates the destructive warning. It could be tightened without losing meaning.

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 delete tool with no output schema, the description covers prerequisites, status constraints, confirmation requirement, and irreversibility. It fully addresses the operational context an agent needs to safely invoke 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%, so baseline is 3. The description adds value by explaining that fetch_scheduled_drawings provides the schedule_token and fetch_sweepstakes resolves a sweepstakes name to a token, giving parameter provenance 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 opens with 'Delete a pending scheduled drawing', using a specific verb and resource. It clearly distinguishes this from sibling delete tools by specifying 'scheduled drawing' and the pending status requirement.

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

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

It explicitly instructs to call fetch_scheduled_drawings first to get the schedule_token, and notes fetch_sweepstakes as a pre-call if the user provides a sweepstakes name. It also states that only pending-status drawings can be deleted, giving clear when-to-use guidance.

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

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

Beyond the destructiveHint:true annotation, the description emphasizes irreversibility ('DESTRUCTIVE operation that cannot be undone'), lists what data is lost, and mandates explicit user confirmation. This provides critical behavioral context that annotations alone don't convey, and there is 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 structured with headings but is repetitive; the same critical warning appears in the main description, 'When to use,' and 'Notes' sections. While front-loaded and organized, the redundancy makes it longer than necessary, though each repeated warning reinforces safety.

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 tool with one parameter and no output schema, the description covers everything: purpose, pre-calls, parameter validation, safety constraints, and the exact data affected. It is fully self-contained and leaves no ambiguity about usage.

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

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

The schema already fully describes sweepstakes_token with 100% coverage. The description adds value by advising that fetch_sweepstakes should be used if the user provides a name instead of a token, explaining how to obtain the parameter value. This supplementary guidance 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 'Permanently delete a sweepstakes and all associated data including participants, statistics, and automations.' This specifies the verb (delete), resource (sweepstakes), and scope (associated data), clearly distinguishing it from sibling tools like pause_sweepstakes or update_sweepstakes.

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

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

Provides explicit guidance: use fetch_sweepstakes first to get the token, always confirm with user, never delete in batch/loops, and refuse bulk deletion. This clearly defines when to use the tool and the necessary pre-calls and constraints, exceeding simple 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 goes well beyond the destructiveHint annotation by stating the action is irreversible, requires user confirmation, and only affects open tickets. This is critical risk-related context that annotations alone do not convey.

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

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

The description is well-structured with headings, but it is redundant: the opening paragraph and the 'When to use' section are nearly identical. This duplication wastes space and deviates from concise writing.

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

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

For a single-parameter destructive tool with no output schema, the description fully covers the purpose, prerequisite, constraints, and required confirmation. Nothing critical is missing.

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

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

The schema already describes case_id as 'The case number of the ticket to delete', but the description adds that the ID should be obtained via fetch_open_tickets. This extra source guidance provides meaning beyond the schema's basic type 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 states the action (permanently delete), the resource (open support ticket), and the prerequisite for obtaining the case_id. It effectively distinguishes this from sibling tools like resolve_ticket or update_ticket by emphasizing irreversible deletion.

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

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

It explicitly instructs to call fetch_open_tickets first to get the case_id and notes that only open tickets can be deleted, providing clear when-to-use guidance. However, it does not directly name alternative actions (e.g., using resolve_ticket instead), so it's not a full 5.

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

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

The description adds substantial context beyond the annotations: it warns that the action cannot be undone, states that admin privileges are required, specifies the 403 error for non-admin users, and advises confirming with the user before calling. This goes well beyond the destructiveHint and provides actionable behavioral guidance.

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 front-loaded with the critical warning, but it becomes repetitive: the 'When to use' section repeats the exact same text as the opening sentence. The 'Notes' section adds a confirmation reminder, but the duplication makes it less concise than it could 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 one-parameter delete tool with good annotations, the description is mostly complete: it covers prerequisites (admin), consequences (irreversible), and user interaction (confirm before calling). It does not describe edge cases like what happens if the todo token doesn't exist, but that is not critical 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 input schema already describes the only parameter (todo_token) with the same UUID format detail, so schema coverage is 100%. The description repeats the parameter info without adding new meaning, earning the baseline score 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 uses a specific verb ('Permanently delete') and a clear resource ('To-Do item'), making the action unambiguous. It immediately distinguishes this from other delete tools like delete_calendar_event or delete_note by naming the exact 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 clearly states when to use the tool: to permanently delete a To-Do item. It adds important usage constraints—admin privileges required and non-admin users getting a 403. It does not explicitly mention alternatives (e.g., update_todo), but the context is clear that this is for irreversible 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 description adds critical behavioral context beyond annotations: 'CRITICAL: This is a production operation that selects real winners. ALWAYS confirm with the user before drawing.' It also discloses weighted random selection, the constraint on paused/archived sweepstakes, and follow-up actions. These details go well beyond the readOnlyHint and destructiveHint flags, and there is 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 overly long and redundant. The opening paragraph is almost verbatim repeated in the 'When to use' section. The 'Parameters to validate before calling' section largely duplicates schema descriptions. While section headers help structure, the duplication wastes space and could confuse the agent by presenting the same information twice.

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 pre-calls (fetch_sweepstakes, fetch_rules, count_participants), validation constraints, critical warnings, and post-drawing steps (fetch_winners, calendar event). However, it does not describe the return value or output format, which is notable since there is no output schema. Otherwise, it is highly complete for a complex mutation 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%, so the baseline is 3. The description repeats parameter validation details already present in the schema (e.g., 'must be >= 1', 'default: true'). It adds minor context like 'group token to draw from, or "allgroups"', but this is also in the schema. No significant added meaning beyond what the schema 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 tool's function: 'Draw winners from a sweepstakes immediately.' It uses a specific verb ('draw'), names the resource ('winners from a sweepstakes'), and distinguishes from siblings like schedule_drawing and fetch_winners by emphasizing immediate execution. The purpose is 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 provides explicit pre-call instructions ('Use fetch_sweepstakes first', 'Use fetch_groups'), a detailed 'Pre-calls required' section, and a clear exclusion: 'Cannot draw from paused or archived sweepstakes.' It also includes confirmation steps and warns against drawing without rules. This fully guides when and how to use the tool versus alternatives.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context about the result limit and the behavior when search 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 core description is concise, but the long-form repeats the same information with a heading and parameter section, introducing redundancy.

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

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

For a simple read-only lookup with one optional parameter, the description fully covers purpose, usage, behavior, and parameters. No output schema is needed for this straightforward 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%, so the schema already documents the search parameter. The description repeats the same meaning without adding new semantic details.

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 searches US telephone area codes by code number or state name. The verb 'Search' and specific resource distinguish it from sibling tools like fetch_zipcodes and fetch_states.

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

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

Provides clear context: omit search to get all area codes, and returns up to 10 results. It doesn't explicitly mention alternatives, but the resource scope is self-evident.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about data sources (billing transactions and data transfers) but does not disclose additional behavioral details like time range limitations or response format.

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

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

The description text is repeated verbatim under both '# fetch_billing_consumptions' and '## When to use' headings, creating redundancy without adding information. The core message is concise, but the repetitive structure fails to 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 zero-parameter read-only tool, the description adequately explains what it returns (monthly and yearly totals, aggregated from transactions/data transfers). The lack of an output schema and low complexity mean the description is sufficient for the tool's context.

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

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

The tool has 0 parameters, making the schema trivial. Baseline for 0 params is 4. The description has no need to explain parameter semantics, as there is nothing to document beyond the empty schema.

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

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

The description uses a specific verb ('Get') and resource ('monthly and yearly billing consumption totals') and clarifies it shows 'aggregated usage data from billing transactions and data transfers,' distinguishing it from transaction-level tools like fetch_billing_transactions.

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 a 'When to use' section, but its content merely restates the tool's purpose without providing explicit guidance on when to use this tool versus alternatives or when not to use it. The context implies use for aggregated totals, but no exclusions or sibling comparisons are given.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is known. The description adds the behavioral detail that results are sorted by creation date (newest first), which is helpful, but it does not mention pagination, rate limits, or any other operational caveats.

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: the 'When to use' section repeats the main description verbatim. This wastes space and structure could be improved by merging into a single concise statement.

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 tool with no parameters and rich annotations, the description is sufficient. It states what data is returned and the sort order. However, it could clarify the distinction from similar billing/wallet transaction tools and whether pagination is handled, but the lack of output schema means the description carries some burden.

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

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

The tool has no parameters, so the schema fully covers this aspect. The description does not need to explain parameters, and none are mentioned.

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 fetches billing transactions for the account, including invoices, amounts, and status. The verb 'Get' and resource 'billing transactions' are specific, but it does not compare with sibling tools like fetch_billing_consumptions or fetch_wallet_transactions, so it lacks differentiation.

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 includes a 'When to use' section but it restates the exact same sentence as the main description, providing no additional context or exclusions. No alternative tools are mentioned, nor are any scenarios where this tool should be avoided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds a scoping detail ('your account') and a behavioral note for the agent to present only human-readable information, going beyond what annotations provide. 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 text is short but needlessly repeats itself: the same two sentences appear in the description and again under the 'When to use' heading. The markdown header duplicates the tool name, so the structure is not as tight as it could 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 read-only tool with no parameters and no output schema, the description adequately explains what it does, what fields are returned, and how the results should be used. The annotation set is strong, and the invocation is trivially correct. No meaningful information is missing.

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

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

The schema has zero parameters, so there is nothing to document. Baseline for 0 params is 4, and the description appropriately does not waste space on parameter details.

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 it retrieves all calendar events for the account, specifying the resource and scope. It distinguishes from sibling tools like get_calendar_event by the 'all' qualifier, making its purpose unambiguous.

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

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

The 'When to use' heading implies the tool is for fetching all calendar events, but it simply restates the description without naming alternatives or exclusions. There is no explicit guidance on when to choose this over get_calendar_event or other event-related tools.

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

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

The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so safety is well covered. The description adds useful behavioral context: pagination at 20 per page, summary-only response, and filtering capabilities. This goes beyond the structural 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 first paragraph and the 'When to use' section are verbatim duplicates of the same sentence. The 'Parameters to validate' section also needlessly repeats schema content. The redundancy makes it 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 read-only list tool with no output schema, the description covers purpose, usage context, all parameters, and response shape (summary info, paginated). It is complete enough for an agent to invoke correctly, though it could be improved by describing the exact summary fields.

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 description's 'Parameters to validate' section merely repeats the schema definitions. The priority mapping (1=Low, 2=Medium, 3=High) and platform options are already in the schema, so the description adds no extra semantic 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 opens with a specific verb+resource+scope: 'Get closed/resolved support tickets with pagination (20 per page) and search.' It clearly distinguishes itself from siblings like get_ticket by stating it 'Returns summary info only — use get_ticket with the case number to get full ticket details.' This makes the tool's purpose unmistakable.

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

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

The 'When to use' section provides clear context: it's for closed/resolved tickets, with an explicit alternative ('use get_ticket with the case number to get full ticket details'). It doesn't explicitly mention fetch_open_tickets, but the sibling name makes it 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context: 'Returns up to 10 results with English/Spanish names' and 'Omit search to get all countries.' This goes beyond the annotations without contradicting them.

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: the opening paragraph is repeated verbatim under the 'When to use' heading, and the parameter section adds no new information. While the first sentence is clear, the duplication wastes space and could be condensed to a single concise version.

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 (one optional parameter, no output schema), the description covers the key aspects: search term types, return limit, language options, and the behavior when search is omitted. It is sufficiently complete 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 coverage is 100% and the description's parameter section merely restates the schema's description for 'search.' No additional meaning is provided 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 identifies the tool's function: 'Search countries by name, international dial code, or ISO abbreviation.' It specifies the resource (countries) and the types of search terms, distinguishing it from sibling tools like fetch_areacodes and fetch_states. The 'Returns up to 10 results' statement adds 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 'When to use' section provides clear context, explaining search by country name, dial code, or ISO abbreviation, and notes that omitting search returns all countries. It lacks explicit exclusions or alternatives to sibling tools, but the resource-specific language inherently guides selection.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by naming the prerequisite call and summarizing the returned data (bytes transferred, payment status, rates), going beyond what annotations provide.

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 well-structured with headings, but it contains redundant repetition: the first sentence is duplicated verbatim in the 'When to use' section. This wastes space, though the overall length is still short and the sectioning helps readability.

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 tool with rich annotations, the description is complete: it explains the purpose, prerequisite, and expected data content. It lacks explicit mention of return format or pagination, but the tool's simplicity and the provided details make it sufficiently 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 input schema fully describes the single required parameter (sweepstakes_token, UUID format) with 100% coverage. The description repeats the parameter's purpose and adds the prerequisite that the token should come from fetch_sweepstakes, but it does not meaningfully enrich the parameter semantics beyond the schema.

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

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

The description states a specific action ('Get data transfer records') and clearly identifies the resource ('sweepstakes') and the data included (bytes transferred, payment status, rates). This clearly distinguishes it from sibling tools like fetch_billing_transactions or fetch_wallet_transactions.

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 explains when to use the tool and includes a required pre-call instruction: 'Use fetch_sweepstakes first to get the sweepstakes_token.' It does not mention specific exclusions or alternatives, but the context is clear enough for an agent to select it appropriately.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so safety is covered. The description adds useful behavioral context by disclosing pagination limits (max 10 per page) and search by title/content, which goes beyond the structured info.

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 repetitive: the opening paragraph is duplicated in the 'When to use' section, and the parameter list mirrors the schema. This redundancy violates conciseness—content that should have been kept once is repeated, wasting space and reader attention.

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 fetch with safe annotations and complete schema, the description is adequate. It mentions pagination and search, but doesn't describe the structure of returned documents or error scenarios, which would be useful since 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?

Schema coverage is 100% with detailed descriptions for each parameter, so the schema already carries the meaning. The description duplicates these parameter explanations without adding new semantic detail, effectively providing no extra value 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 'Get help and support documentation articles' with a specific verb and resource. It also mentions pagination and search, which gives a precise scope. While it doesn't explicitly contrast with siblings, the resource (documentation) is distinct from other fetch_* tools.

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

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

There's a 'When to use' section but it merely restates the main description—'Get help and support documentation articles'—without providing exclusions, prerequisites, or alternatives. The usage is implied by the tool's purpose, but no explicit guidance for choosing this over other tools 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?

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral context about sorting (newest first), pagination, and the inclusion of storage usage and categories. This augments the safety profile provided by annotations without contradicting them.

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 opening sentence is concise and informative, but the 'When to use' section repeats the same information verbatim, and the parameter section duplicates schema content. This redundancy makes the description less efficient than it could be, though it remains short and readable.

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, read-only tool with no output schema, the description covers the essential context: what the tool does, sorting behavior, pagination, and result content. It could add more detail about error handling or response format, but overall it is adequate for the tool's 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 coverage is 100%, and both parameters (page, limit) already have clear descriptions with defaults and maximums in the schema. The description's 'Parameters to validate before calling' section simply repeats this information, adding negligible value 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 action: 'List all files in the user's Drive' with additional specifics about storage usage, categories, pagination, and sorting. This distinguishes it from sibling fetch_* tools, 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 'When to use' section provides clear context for when to invoke this tool (listing files in Drive). However, it does not explicitly mention exclusions or alternative tools for specific file operations, such as get_file_url or send_file, which would differentiate it further.

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, idempotentHint, and destructiveHint=false. The description adds context that groups are used for organizing/segmenting participants and that results should only be used internally, which is useful beyond annotations. However, it does not disclose return format or error handling, so the added value is moderate.

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 opening sentence is duplicated verbatim in the 'When to use' section, making the description repetitive. The markdown headings help organization, but redundancy reduces overall 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?

With no output schema, the description hints at returning group names and statuses but does not specify the exact response structure or pagination. For a simple one-parameter read tool, it gives enough context for basic use, but gaps remain about the full return payload.

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 description repeats the schema's parameter description verbatim ('The sweepstakes token (UUID format)'). No new meaning is added beyond what the input 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 states 'Get all groups from a sweepstakes' with a specific verb and resource. It clearly distinguishes from sibling tools like create_group or delete_group by focusing on retrieval of all groups.

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

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

It explicitly instructs to call fetch_sweepstakes first to obtain the sweepstakes_token, providing a clear precondition. It also advises using group data internally and presenting only human-readable information, which gives strong usage context. It does not explicitly mention when not to use it, but the pre-call requirement offers sufficient guidance.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior, but the description adds valuable behavioral context beyond annotations: notes are automatically decrypted, sorted in reverse chronological order, and the output is intended for internal use only, with only human-readable fields presented. This fully discloses the key behavioral traits of the tool.

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

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

The core content is only three sentences, but the same text is repeated verbatim under the '# fetch_notes' heading and the '## When to use' section, which is redundant. The 'When to use' heading implies new guidance but actually duplicates the description, adding unnecessary waste.

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

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

For a zero-parameter, low-complexity tool, the description is complete: it states the output scope (all notes for the account), the ordering (reverse chronological), automatic decryption, and how the results should be used. Rich annotations cover safety and idempotency, leaving no meaningful gaps.

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

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

The tool has zero parameters, and the input schema is fully covered (100%). The description adds no parameter details because none exist, so the baseline of 4 is appropriate; there is no semantic gap to fill.

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

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

The description uses the specific verb 'Get' with the resource 'all notes' and clarifies the account scope, which clearly distinguishes it from siblings like get_note (which likely fetches a single note). It also mentions unique behaviors such as automatic decryption and reverse chronological ordering, making the purpose unmistakable.

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

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

The description provides clear context: this fetches all notes for the account, and the results should be used internally for tool chaining, presenting only human-readable information. It does not explicitly mention alternatives like get_note for retrieving a single note or state when not to use this tool, but the 'all notes' wording implies the distinction from single-note retrieval.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds value by disclosing that the tool 'Returns summary info only' and supports pagination/filtering. This goes beyond the structured fields and helps set expectations about the response, though it doesn't cover potential rate limits or auth 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 first sentence is front-loaded and clear, but the description is bloated by duplication: the main block and the 'When to use' section are identical, and the parameter list repeats schema contents. While well-structured, not every sentence earns its place, making it less concise than it could 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?

The tool has no output schema, but the description explicitly addresses what is returned ('summary info only') and directs users to get_ticket for full details. All parameters, including defaults and filtering options, are covered. For a read-only list tool with rich annotations, the description is complete enough to guide correct use.

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 input schema already fully documents all four parameters. The description's 'Parameters to validate before calling' section simply repeats the schema descriptions verbatim, adding no new semantic information. 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 states it 'Get[s] open support tickets' with pagination and search, using a specific verb and resource. It distinguishes itself from sibling tools by saying 'Returns summary info only — use get_ticket with the case number to get full ticket details', and the word 'open' differentiates it from fetch_closed_tickets.

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

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

The description provides clear context for when to use this tool (for summary listing of open tickets) and explicitly points to get_ticket as an alternative for full details. However, it doesn't give an explicit 'when not to use' statement or mention fetch_closed_tickets, so it slightly misses the bar for a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds behavioral details: pagination size (20 per page), sorting by creation date (newest first), supported search and date filters, and an instruction to present only human-readable information. This adds value 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 main paragraph is nearly duplicated in the 'When to use' section, creating redundancy. It is structured with headers and front-loaded with the key summary, but the repetition makes it longer than necessary.

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 paginated list tool with no output schema, the description covers required pre-calls, parameter validation, sorting, search/filter options, and presentation rules. It does not detail the exact return field names, but it addresses the main contextual needs for correct invocation and chaining.

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

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

Schema description coverage is 100%, and the schema fully documents all six parameters including interdependencies (start_date requires end_date, etc.). The description repeats this information but does not add new meaning 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 opens with a specific verb+resource: 'Get a paginated list of participants from a sweepstakes (20 per page).' It clearly distinguishes from siblings by stating 'Use fetch_sweepstakes first to get the sweepstakes_token' and 'For full participant details, use get_participant with a specific email, phone, or token.'

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?

Explicit guidance is provided: pre-call requirement ('Use fetch_sweepstakes first'), alternatives ('For full participant details, use get_participant'), and a strong anti-hallucination directive ('NEVER fabricate or hallucinate participant data'). This tells the agent when and how to use the tool.

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 read-only/idempotent. Description adds that the response includes primary and secondary rules and that a token from fetch_sweepstakes is needed. 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 repeats the primary sentence in the 'When to use' section and several sections restate existing schema info. It could be tightened without losing meaning.

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 1-param read-only fetcher, the description covers purpose, prerequisite, and parameter origin. No output schema, but description states what rules are returned.

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?

Input schema has 100% coverage with the same UUID description. Description reinforces that the token comes from fetch_sweepstakes, adding origin context 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?

States specific verb 'Get all official rules for a sweepstakes including primary and secondary rules.' This clearly identifies the operation and resource, and differentiates from rule-creation/update/delete 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?

Includes an explicit 'When to use' section and a 'Pre-calls required' note directing to fetch_sweepstakes first when given a sweepstakes name instead of a token. Does not explicitly discuss alternative tools, 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 declare read-only and idempotent, so the description adds value by disclosing that results are returned regardless of status and sorted newest-first. It also clarifies intended usage (tool chaining, not direct presentation). 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 repeats the same sentences in the intro and the 'When to use' section, making it longer than necessary. However, the use of headings does provide some structure, and each section serves a purpose.

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

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

Given rich annotations, full schema coverage, and no output schema, the description adequately covers prerequisites, return behavior, and usage context. It doesn't explain edge cases or errors, but these are not critical for this read-only 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% with a description for sweepstakes_token. The description enhances this by explaining how to obtain the token (via fetch_sweepstakes), which adds practical meaning beyond the schema's basic UUID format note.

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 'Get all scheduled drawings for a sweepstakes' with a specific verb and resource. It distinguishes itself from siblings by focusing on 'scheduled drawings' and adds scope details (all statuses, sorted by creation date), making it 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?

Explicitly instructs to call fetch_sweepstakes first to obtain the token, and advises using the output internally while presenting only human-readable info. This provides clear when-to-use context, though it doesn't mention alternatives 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 state readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds value by specifying the exact return format (full names and two-letter abbreviations) and the scope of included territories, which is not present in 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 duplicated: the exact same text appears twice, once at the start and again under the '# fetch_states' and '## When to use' headings. This repetition is wasteful and does not earn its place; a single concise paragraph 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 simple, parameterless, read-only tool with no output schema, the description adequately covers the return values (full names and abbreviations) and the scope (US states, DC, PR, territories). It does not detail the exact JSON structure, but given the simplicity, this seems sufficient.

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

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

The schema has zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed. It correctly implies that no inputs are required.

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: 'Get all US states including DC, Puerto Rico, and US territories' and specifies the output format ('Returns full names and two-letter abbreviations'). This distinguishes it from sibling tools like fetch_countries and fetch_zipcodes.

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 includes a 'When to use' heading, but the content simply restates the purpose. It implies the appropriate context (when you need US state data) but does not explicitly mention alternatives or exclusions compared to sibling tools.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the tool is known to be safe. The description adds value by disclosing that the output contains tokens that should be used internally and that only human-readable information should be presented to users. This is behavioral context beyond the annotations, hence a 4.

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 with the core action. However, the text is duplicated verbatim (the same sentences appear twice), which introduces redundancy. While this is likely a format artifact, it slightly harms structural clarity. Otherwise, every sentence provides value.

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

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

For a no-parameter, read-only list tool, the description covers what it returns ('a list of all sweepstakes with their details') and how to process the results (tokens vs. human-readable). It doesn't specify the exact fields returned, but no output schema exists, and the complexity is low. The presentation guidance adds useful context 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?

The tool has 0 parameters, so the baseline is 4. The description correctly omits parameter details, and with 100% schema coverage (vacuously), there is nothing missing. No inconsistencies or gaps are present.

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 'Get all sweepstakes associated with your account' with a specific verb and resource, and scopes it to the user's account. This distinguishes it from other fetch_* sibling tools like fetch_participants or fetch_rules. The purpose is unambiguous and actionable.

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

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

The description implies when to use the tool: when you need all sweepstakes for the account. It also provides guidance on how to use the output ('Use tokens internally for tool chaining but present only human-readable information'). However, it doesn't explicitly mention alternatives or exclusions, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds a valuable behavioral nuance: the DEFAULT timezone fallback rule, which is not inferable from annotations. It does not repeat annotation info.

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 core action. It uses only a few sentences to convey purpose, usage, and a default fallback. No filler or redundancy (the repetition in the input is a formatting artifact; the actual description is tightly written).

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 zero parameters, rich annotations, and no output schema, the description provides complete context: it lists the kind of data returned (IANA identifiers, abbreviations, UTC offsets), specifies 'all available' (no filtering), and includes the default fallback value. This is sufficient for an agent to select and invoke the tool correctly.

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

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

The tool has zero parameters, and the schema coverage is 100% (by triviality). The description needs no parameter explanations. With 0 params, the baseline is 4, and the description does not attempt to add unnecessary parameter context.

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: 'Get all available timezones with IANA identifiers, abbreviations, and UTC offsets.' This is a specific verb+resource combination that distinguishes it from sibling reference tools like fetch_countries or fetch_states.

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 states when to use: 'Use this tool whenever a timezone needs to be determined for any operation.' It also provides a fallback rule (TimezoneId 7) when the correct timezone cannot be determined, giving clear contextual guidance.

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

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

Annotations already declare read-only, idempotent, and non-destructive hints. The description adds valuable behavioral context: admin privileges required, 403 for non-admins, and pagination defaults. 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 is well-structured with headings but is verbose and redundant, repeating the same main sentence twice and duplicating the schema's parameter descriptions. It would be more concise by keeping only the core sentence and admin warning.

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 reasonably covers purpose, admin restriction, pagination, and all parameter details. It doesn't describe the response format, but the tool's name and read-only behavior imply the return of todo items.

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 10 parameters are fully described in the input schema, and the description's parameter list largely duplicates that information without adding new semantic meaning. Since schema coverage is 100%, a baseline of 3 is appropriate.

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

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

The description clearly states the tool retrieves all To-Do items with pagination, search, and advanced filters. It specifies the resource and operation, distinguishing it from create/update/delete todo tools.

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

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

The description includes a 'When to use' section and clearly notes the ADMIN ONLY restriction, which is a key usage condition. It doesn't explicitly mention alternative tools or exclusions, but the purpose is unambiguous given the tool name and sibling 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds minor context by indicating account-level scoping and the types of transactions included, but it does not disclose other behavioral aspects such as pagination, rate limits, or whether 'all' means unbounded result sizes. With annotations present, the added value is marginal but not entirely absent.

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 repetitive: the same sentence appears twice, once in the opening and again under the '## When to use' heading. The markdown headings add no new information, and the repeated sentence wastes space. A single sentence would have been sufficient and more concise.

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 parameterless read-only tool, the description adequately states what the tool returns ('all wallet transactions') and its scope. There is no output schema, but the description does not need to explain return values in detail given the simplicity of the operation. The main gap is the lack of any distinction from the similarly named fetch_billing_transactions, but this is not required for completeness of the description itself.

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 has zero parameters, so there is no parametric explanation needed. The baseline for no parameters is 4, and the description appropriately adds no extraneous parameter-related 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 states a specific verb ('Get'), a resource ('wallet transactions'), and scope ('for your account'), while also enumerating content ('credits, debits, and payment details'). This clearly distinguishes it from sibling tools like fetch_billing_transactions.

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?

Although there is a '## When to use' heading, the text under it simply repeats the main description. There is no explicit guidance on when to choose this tool over alternatives, no exclusions, and no mention of scenarios where another tool (e.g., fetch_billing_transactions) would be more 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: winners are sorted by draw date (most recent first), supports search by email or phone, and advises using raw data internally while presenting only human-readable names, emails, and draw dates. This goes beyond the annotation 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 structured with sections (title, When to use, Pre-calls, Parameters) which aids navigation, but it unnecessarily repeats the opening paragraph verbatim in the 'When to use' section. This redundancy makes it longer than needed, though the front-loaded summary does provide immediate 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 tool has no output schema, so the description carries the burden of explaining return-related context. It adequately covers prerequisites (fetch_sweepstakes), pagination defaults, sorting behavior, search capability, and how to present results. Given the read-only nature and modest complexity, this is sufficiently complete, though it could mention error scenarios or rate limits.

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 includes a 'Parameters to validate before calling' section that mirrors the schema's parameter descriptions (e.g., sweepstakes_token UUID format, default values for page and items_per_page). It adds minimal new meaning beyond the schema, except framing these as validations to perform before calling, which is a minor semantic addition.

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 'Get winners from a sweepstakes with pagination', using a specific verb and resource. It further distinguishes itself from siblings like 'draw_winners' (which creates winners) and 'fetch_sweepstakes' (which retrieves sweepstakes) by focusing on retrieving existing winners. The mention of sorting by draw date adds scope 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?

The description explicitly instructs to 'Use fetch_sweepstakes first to get the sweepstakes_token' and includes a 'Pre-calls required' section detailing the prerequisite. It also gives guidance on handling results ('Use them internally for tool chaining but present only human-readable information'). While it doesn't explicitly mention when NOT to use it or alternatives, the context is clear and actionable.

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 establish read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral details: 'Returns up to 10 results' and 'case-insensitive' search, which are not present in the annotations. No contradictions detected.

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 front-loaded with the core purpose, but it redundantly repeats the same sentence under 'When to use' and the parameter details mirror the schema. This unnecessary duplication prevents a higher conciseness score.

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

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

For a single-parameter search tool with no output schema, the description provides essential context: result cap (10) and the nature of results (city and state details). While more detail on response fields would be helpful, the low complexity and strong annotations make this sufficiently 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 input schema already fully describes the 'search' parameter with identical wording. The description's parameter section adds nothing beyond the schema. Baseline 3 applies since schema coverage is 100%.

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: 'Search US zip codes by zip code, city, or state name.' It specifies the resource (US zip codes), the action (search), and the input modes, distinguishing it from sibling tools like fetch_states and fetch_areacodes.

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

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

The 'When to use' section reiterates the purpose but does not explicitly contrast with alternatives or mention exclusion conditions. Usage context is clear, but no specific guidance is given about when to prefer this tool over other fetch_* tools, making it implied rather than explicit.

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

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

Annotations already declare this as readOnly, openWorld, idempotent, and non-destructive, so the safety profile is covered. The description adds context about the returned data (company details, address, business settings) but does not disclose additional behavioral traits such as authentication requirements, potential errors, or any constraints beyond the scope of a zero-parameter read operation.

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

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

The description is short but redundant: the same two sentences appear both in the opening and under '## When to use'. This duplication does not add value and wastes space. A single concise expression would be more effective.

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 (zero parameters, read-only, rich annotations), the description provides a sufficient overview. It clearly names the primary outputs, which is adequate for an agent to understand what the tool does. However, the phrase 'business settings' is somewhat vague, and since there is no output schema, a more detailed enumeration of return fields 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 tool accepts no parameters, so the input schema is fully covered. According to the baseline for zero-parameter tools, this score is appropriate. The description mentions the output categories, which indirectly clarifies what the operation retrieves, but no parameter details are needed.

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

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

The description clearly states the tool's function: 'Get business information for a Sweeppea account' and specifies the output categories (company details, address, business settings). It uses a specific verb and resource, and it is distinguishable from sibling tools like get_profile or get_plan, as it targets business-level data.

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

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

Although the description includes a '## When to use' heading, the content is a verbatim repetition of the initial description and provides no practical guidance on when to choose this tool over alternatives. It does not mention exclusions, prerequisites, or alternative tools, leaving the reader without clear direction on usage 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 readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering safety profile. Description adds only the workflow hint to fetch tokens first; no details on return format or error cases.

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 core sentence is repeated three times across the description, headings, and 'When to use' section. Significant redundancy for a one-parameter tool; could be one sentence.

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?

Provides the essential usage and parameter validation, but omits return value details or error handling. Since there is no output schema, the description should cover this but does not.

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

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

Schema fully describes event_token (type, required, description). Description only repeats the same schema text, adding no additional semantic context.

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 calendar event by token. Distinguishes from fetch_calendar_events, which lists events, by explicitly stating 'a single' and the need for a token.

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 instructs to use fetch_calendar_events first to get event tokens, providing clear workflow context. Lacks explicit 'when not to use' but the prerequisite is helpful.

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, openWorldHint, idempotentHint, and destructiveHint false. The description adds meaningful context beyond annotations by revealing the return content ('Returns field names, types, and whether they are required') and the dependency on fetch_sweepstakes. 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 is well-structured with headers and sections, but the content is redundant: the first paragraph is nearly identical to the 'When to use' section. This duplication wastes space and slightly blurs the document. Still, it is not excessively verbose.

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

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

For a tool with one parameter and no output schema, the description is complete: it states what it returns, the required precondition, and the intended workflow position relative to other tools. No gaps linger.

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

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

Schema coverage is 100% for the single parameter, with the parameter description already stating 'The sweepstakes token (UUID format)'. The tool description's Parameters section repeats exactly this, adding no new semantic value. 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 states the tool's function: 'Get all form fields for a sweepstakes entry page.' It uses a specific verb+resource construction and explicitly distinguishes its role from related tools by noting it should be called before add_participant to discover required fields.

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

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

Usage guidance is explicit: 'Use fetch_sweepstakes first to get the sweepstakes_token' and 'Call this before add_participant to discover required fields.' It also provides a concrete pre-call condition: 'fetch_sweepstakes if the user gave you a sweepstakes name instead of a token.'

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. The description adds behavioral context by stating this is a read operation that returns all configuration and is a precursor to updates. No contradictions exist, and the description is consistent with 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 somewhat redundant: the initial paragraph and the 'When to use' section repeat the same information verbatim. The 'Parameters to validate' section unnecessarily restates the schema. While the structure with headings is clear, the duplication wastes space.

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

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

For a single-parameter read-only tool with no output schema, the description sufficiently covers return scope by enumerating the many configuration areas (display, colors, compliance, etc.), the required pre-call, and its role before updating. It lacks error handling details but is complete for its simplicity.

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

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

The schema already covers 100% of the single parameter with a clear description. The tool description adds value by explaining that the token comes from fetch_sweepstakes and is a required pre-call, enriching the parameter's origin and usage 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 purpose: 'Get entry page settings for a sweepstakes.' It lists the extensive set of configuration categories returned, distinguishing it from sibling tools like update_entry_settings (which modifies) and fetch_sweepstakes (which fetches sweepstakes data, not settings).

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 instructs to use fetch_sweepstakes first to obtain the sweepstakes_token and to use this tool before update_entry_settings to see current values. This provides clear when-to-use guidance and a required pre-call, fully addressing usage 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 goes beyond the annotations (readOnlyHint, idempotentHint) by disclosing that the URL is short-lived, presigned, embeds Content-Type and Content-Disposition headers, and that transfer occurs directly between client and S3, avoiding data transfer costs. This is valuable behavioral context not present in 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 padded with redundant sections: the opening definition is repeated verbatim under 'When to use', and the parameter details are duplicated from the schema. While structured, it is unnecessarily verbose and fails to keep each sentence purposeful.

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

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

For a read-only tool with no output schema, the description adequately covers purpose, parameters, behavior, and benefits. The absence of an explicit return-value description is acceptable since the URL is clearly implied. It loses one point for the redundant structure that does not add 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 provides 100% coverage with detailed descriptions for all three parameters. The description restates these parameters but adds no new information beyond what annotations/schema already supply. The baseline of 3 is appropriate; the schema does the heavy lifting.

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

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

The description uses a specific verb ('generate') and names the precise resource ('short-lived presigned S3 URL') and action ('download or preview a file'). It clearly distinguishes itself from sibling tools like send_file or upload_file by focusing on URL generation for preview/download.

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

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

The 'When to use' section restates the main purpose but does not to explicitly contrast this tool with alternatives like send_file or fetch_files. There is no 'when not to use' guidance, though the benefit of 'no data transfer cost' implies a context for choosing this over direct transfer.

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 establish readOnly, idempotent, and non-destructive behavior. The description adds a valuable behavioral detail: 'The note content is automatically decrypted in the response', which informs the agent about response content and data sensitivity. This goes 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 and front-loaded, but it repeats the exact same sentence in the opening paragraph and the 'When to use' section. This redundancy wastes space, preventing a higher score.

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 tool, the description covers purpose, prerequisite, and a key behavioral aspect (decryption). With no output schema, it could explain return structure, but the essential information is present and sufficient for correct invocation.

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

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

With 100% schema description coverage, the schema already fully documents the note_token parameter. The description repeats the same definition without adding new meaning, so it meets the baseline but does not enhance 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 explicitly states 'Fetch a single note by its token', using a specific verb and resource. It distinguishes from fetch_notes by instructing to use fetch_notes first to obtain the token, clearly positioning this as the single-note retrieval tool.

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

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

Provides clear context: 'Use fetch_notes first to get the note_token'. This gives a prerequisite and implies when to use this tool. However, it does not explicitly mention exclusions or alternative tools for different scenarios, stopping short of a 5.

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

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

Annotations already declare read-only and idempotent behavior, and the description adds a valuable anti-hallucination directive: 'NEVER fabricate, invent, or hallucinate participant data' and 'If no result is returned by the API, report exactly that.' It also clarifies that tokens are for internal chaining while only human-readable information should be presented, which goes beyond the annotation baseline.

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 bloated and repetitive. The opening paragraph is restated almost verbatim under '# get_participant' and '## When to use,' and the parameter validation section duplicates the input schema's descriptions. This redundancy wastes tokens and makes the description longer than necessary, though the headings do provide some organization.

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

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

Despite the repetition, the description covers key contextual needs: pre-calls, required search parameter, alternative tools, and behavior in no-result scenarios. The lack of an output schema is partially mitigated by the phrase 'Fetch full details' and the caution about not guessing names, emails, or counts, giving an agent enough context to use the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds the cross-parameter constraint 'At least one search parameter is required,' which is not captured by the schema's individual parameter descriptions. However, much of the parameter section simply repeats the schema text, so the added value is modest.

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

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

The description opens with 'Fetch full details of a single participant from a sweepstakes by token, email, or phone,' which clearly identifies the resource, action, and search modalities. It also explicitly differentiates from sibling tools by directing list operations to fetch_participants and prerequisite fetch_sweepstakes.

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

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

Provides explicit when-to-use context: requires the sweepstakes token, states 'At least one search parameter is required,' and names the exact alternative for listing participants ('For listing participants, use fetch_participants instead'). It also lists a pre-call requirement, giving an agent clear invocation sequencing.

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