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

Annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) indicate a write operation. The description adds important behavioral details: testing-only purpose, field naming conventions, honesty clause about reporting API results, and parameter validation notes. 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 lengthy and contains repetitive sections (e.g., rules appear twice, once in prose and once in markdown headers). While front-loaded with key information, the duplication and verbosity reduce conciseness. A more streamlined version would improve structure.

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

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

Given the tool's complexity (5 parameters, nested object, no output schema), the description is thorough. It covers prerequisites, rules, parameter validation, error handling (honesty clause), and contextual guidance for testing vs. production. Everything needed for correct invocation is present.

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

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

Schema coverage is 100% with descriptions for all parameters. The description adds meaning beyond the schema by explaining usage (e.g., email as KeyEmail, phone as KeyPhoneNumber, field keys use underscores, bonus_entries default 0, sweepstakes_token UUID format). This adds moderate value.

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

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

The description clearly states 'Add a new participant to a sweepstakes,' specifying the verb (add), resource (participant), and context (sweepstakes). It distinguishes from sibling tools like fetch_participants, get_participant, and delete_participant by focusing on the creation action.

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 when-to-use guidance, including required pre-calls (fetch_sweepstakes, get_entry_fields) and rules (only one at a time, never bulk, testing purposes only). It also instructs on how to handle prohibited mass loading requests, and mentions alternatives like the official Entry Page.

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 billability, complete cloning behavior, strict limits (3 active, 10 total), and ethical constraints, adding significant context beyond annotations (which already indicate mutability and side effects).

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

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

Contains redundant sections (same text repeated under markdown heading), making it longer than necessary. While content is valuable, the duplication reduces 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 purpose, usage, parameters, preconditions, and limits well. However, it does not describe the return value or response structure, which would be helpful given no output schema.

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

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

Schema descriptions already cover all 7 parameters clearly. Description restates them but adds no new semantic information, only grouping, so baseline 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 'Clone an existing sweepstakes' and specifies what is copied (entry pages, calendar events, etc.), distinctly differentiating from create_sweepstakes and other 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?

Provides explicit preconditions (use fetch_sweepstakes first, check limits), warns about billability and need for user confirmation, and prohibits batching without approval.

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, covering safety and side effects. The description adds the pre-call requirement and filtering options, which are useful but not necessary for behavioral transparency. 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 well-structured with clear sections and front-loaded purpose. However, the main description is repeated (first line then the # section), 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?

The tool has no output schema, yet the description does not mention what the return value contains (e.g., a JSON object with counts). It covers inputs and pre-requisites adequately but misses the output 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?

Schema coverage is 100%, so the baseline is 3. The description repeats parameter info but adds validation guidance (e.g., UUID format, ISO 8601). It does not provide significant additional meaning beyond the schema.

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

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

The description clearly states 'Get participant counts for a sweepstakes' with a specific verb and resource. It distinguishes from sibling tools like fetch_participants (which returns individual participants) and other sweepstakes 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 explicitly advises to 'Use fetch_sweepstakes first to get the sweepstakes_token' and includes a 'Pre-calls required' section. It does not mention when not to use or alternatives, but the guidance 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 indicate non-read-only and non-destructive. The description adds valuable behavioral nuance about the date rule and UTC dependency. 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-structured with headings but contains redundancy (date rule repeated in two sections) and repeats schema parameter info verbatim, making 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?

Covers purpose, guidelines, and one behavioral nuance, but lacks explicit mention of return value or post-creation behavior. With no output schema, this omission leaves a gap.

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

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

Schema coverage is 100%, and the description merely repeats the schema's parameter descriptions without adding new semantic meaning. Baseline 3 applies.

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

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

The description clearly states the action (create) and resource (calendar event) with details on optional fields. It does not explicitly distinguish from sibling 'update_calendar_event', but the verb 'create' makes the purpose clear.

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

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

Provides explicit when-to-use context, including a critical date rule (avoid today due to UTC timezone) and a user-facing fallback suggestion. This is high-quality guidance beyond minimal expectations.

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-destructive, non-idempotent. Description adds that group names must be unique and groups organize participants, but does not mention side effects or auth requirements. Adequate but not exhaustive.

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?

Well-structured with clear sections (When to use, Pre-calls, Parameters). Slightly repetitive as the first sentence echoes the markdown heading, but overall efficient and easy to parse.

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

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

For a simple creation tool with 2 parameters and no output schema, the description covers the prerequisite call, parameter constraints, and purpose. No gaps remain.

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%, baseline 3. Description adds value by specifying that group_name must be unique within the sweepstakes and that sweepstakes_token is in UUID format, providing clarity 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?

Description clearly states 'Create a new group within a sweepstakes,' specifying the action (create), resource (group), and context (within sweepstakes). It distinguishes from sibling tools like fetch_groups, update_group, and delete_group.

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_sweepstakes first to obtain the sweepstakes_token, and includes a 'Pre-calls required' section. While it does not explicitly state when not to use, it provides clear context for correct usage.

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 a write operation, and description adds encryption details (AES-256-CBC) and HTML restrictions, which go beyond annotations. 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?

Structured with sections but repeats information (e.g., HTML tags listed twice). Could be more concise without 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?

Covers encryption, allowed HTML, limits, and uniqueness. No output schema provided, but description is detailed enough for a creation tool. Missing error handling info.

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 description adds 'must be unique' for title and default for pinned, but mostly repeats schema info. Baseline 3 due to high coverage.

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

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

The description clearly states 'Create a new note' and specifies constraints like encryption and allowed HTML, distinguishing it from siblings like delete_note or update_note.

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 'When to use' and notes about sensitive data in title, but does not explicitly mention when not to use or alternatives. Provides good 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?

Beyond annotations (which indicate mutation with side effects), the description details the implications of creating secondary rules, the need to warn users, and prerequisite calls. This adds significant behavioral context.

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

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

The description is well-structured with headings and front-loaded main purpose, but it repeats the same secondary rules warning twice, making it slightly redundant.

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

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

The description covers main function, usage conditions, pre-calls, and side effects, but lacks any mention of the return value or response format. Given no output schema, this is a 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 schema already describes parameters well. The description repeats some constraints (max lengths) already in the schema, adding minimal new semantic value beyond usage instructions.

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 official rules document for a sweepstakes' and distinguishes from sibling create_rules_wizard by noting when to use each. It provides specific verb and 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 explicitly states when to use this tool (when a fully prepared HTML document is available and the wizard does not apply) and gives pre-call requirements and a warning about secondary rules with user acknowledgment.

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 this is a mutable tool (readOnlyHint=false) and the description confirms by detailing the creation process. It discloses behavioral traits such as always setting rules_language='en', never composing rules language, age gate activation rules, and geolocation constraints. 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 lengthy but well-organized with clear headings (When to use, Pre-calls, Parameters, Notes). It front-loads the essential purpose and usage. While every sentence adds value, the length could be slightly reduced without losing critical context.

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

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

Given the tool's complexity (49 parameters, wizard process, compliance rules), the description is exceptionally complete. It covers pre-conditions, post-creation verification (fetch_rules), compliance warnings, and outcome handling (URL for primary rules). No output schema exists, but the description sufficiently explains what to do with the result.

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

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

Schema coverage is 100%, but the description adds significant value beyond the schema: it explains parameter dependencies (e.g., entry_period_items required when entry_period_selector=2), pre-fill sources (sponsor fields from get_business), and behavioral implications (age gate activation based on min_age). This greatly aids agent understanding.

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.' It uses a specific verb (generate) and resource (official sweepstakes rules) and differentiates from siblings like 'create_rule' by emphasizing the wizard process and extensive pre-call requirements.

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 steps (fetch_sweepstakes, get_business, fetch_rules), conditions for use (warn if primary rules exist), and alternative actions (use update_rule for corrections). It also instructs the agent on how to interact with the wizard (ask questions in order, only ask for missing data).

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

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

Discloses billable nature, real production data creation, and limits. Annotations (readOnlyHint=false, destructiveHint=false) are consistent. Adds context about post-creation steps (calendar events, campaign brief note).

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?

Well-structured with sections (When to use, Pre-calls, Parameters, Notes). However, some repetition (ethical use appears twice) and the Notes section contains actionable steps that could be integrated.

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

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

Complete for a complex tool with 11 parameters (7 required) and no output schema. Covers pre-calls, parameter validation, limits, and post-creation actions. No output schema needed as description covers return behavior.

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%, but description adds meaning: handler generation from name (uppercase, alphanumeric, max 20), best practices (set create_in_calendar: true, sync_with_winners: true), and validation rules (dates must be future).

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 sweepstakes programmatically' and lists required fields (name, type, handler, dates, times). It distinguishes from siblings like update_sweepstakes and delete_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?

Explicitly explains when to use (creating new), critical prerequisites (know current date, confirm with user), limits (max 3 active, 10 total), and pre-calls (get_plan, fetch_sweepstakes, fetch_timezones). Also warns against bulk creation.

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 behaviors beyond annotations: assign_to behavior (all admins if omitted), matching semantics (case-insensitive names, exact emails), HTML formatting restrictions, and spacing rules. 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?

Highly repetitive: the same introductory phrase and formatting rules appear multiple times. The markdown section duplicates the description. Could be condensed to 1-2 clear paragraphs without loss of 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?

Covers all necessary aspects: creation action, parameter details, constraints, when-to-use, and edge cases like admin assignment. Lacks output schema but not critical for a creation tool. Minor redundancy does not harm completeness.

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

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

Schema coverage is 100% with good parameter descriptions. The description repeats this info and adds minor behavioral context for assign_to, but does not significantly enhance parameter understanding 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 'Create a new support ticket with title, description, and priority level.' It distinctly separates this creation tool from siblings like delete_ticket or resolve_ticket, 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?

Explicitly advises to 'Search fetch_documentation first; only open a ticket if docs do not solve the question.' Also provides critical rules about not fabricating admin names and only assigning to admin-level users, guiding appropriate usage.

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 a non-read-only, non-idempotent, non-destructive mutation. Description adds auth requirements, HTML formatting rules, and parameter defaults, going beyond 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?

Description is lengthy and repeats the same HTML formatting rules multiple times, 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?

Covers auth, formatting, and parameter details, but lacks any mention of the return value or response format (no output schema). Adequate but not 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?

Schema coverage is 100%, so baseline is 3. Description repeats schema info without adding significant new meaning beyond what's already in the input 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?

Clearly states 'Create a new internal To-Do item' with a specific verb and resource. Distinct from siblings like fetch_todos, delete_todo, and update_todo.

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 ADMIN ONLY and that non-admins receive 403 error. Provides parameter validation details, but does not contrast with sibling tools like create_note or create_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?

The description adds significant behavioral context beyond annotations: it warns that deletion is permanent and irreversible, and instructs to always confirm with the user. However, there is a contradiction with the annotation idempotentHint: true, as the description implies non-idempotent behavior.

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

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

The description is somewhat repetitive, with the key information presented both in a brief paragraph and again in markdown sections. It is front-loaded with important details, but could be more concise by avoiding duplication.

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 parameter, no output schema), the description adequately covers prerequisites (fetch events), the destructive nature, and confirmation recommendation. It does not describe post-deletion behavior, but this is minor. The overall context is 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?

Schema coverage is 100% and the schema already describes the event_token parameter as 'The event token to delete (UUID format)'. The description merely repeats this without adding further semantics or usage details, so it meets the baseline but does not exceed it.

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

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

The tool name 'delete_calendar_event' clearly indicates the action. The description states 'Permanently delete a calendar event', specifying the verb and resource. It also instructs to use fetch_calendar_events first, distinguishing it from sibling tools like update_calendar_event.

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 tells when to use this tool (after fetching events to get the event token) and includes a warning that the action is irreversible, implying confirmation needed. It does not explicitly state when not to use it, but the guidance 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?

The description adds behavioral context beyond annotations: it details what happens (removes from S3 and database, frees quota, irreversible). Annotations already set destructiveHint: true, but the description elaborates on the consequences, which is valuable.

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 and uses clear structure (header, when-to-use, parameters, notes). However, there is redundancy: the first paragraph repeats the markdown section. Could be 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 simple destructive operation with one parameter and high schema coverage, the description is complete. It covers all necessary context: what action, consequences, prerequisites (file_token from fetch_files), and the need for user confirmation. No output schema is needed.

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

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

Schema description coverage is 100% for the single parameter (file_token). The description does not add new semantic info beyond what is in the schema; it only repeats the schema description. Baseline 3 applies.

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

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

The description clearly states the action: 'Permanently delete a file from the user's Drive.' It uses a specific verb (delete) and resource (file), and the destructive nature is emphasized. It distinguishes from sibling tools like upload_file, send_file, or fetch_files, which are non-destructive.

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: 'ALWAYS ask for explicit user confirmation before calling this tool.' It warns about irreversibility and advises explaining consequences to the user. This provides clear when-to-use and when-not-to-use 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 indicate destructive, but description adds 'irreversible', user confirmation requirement, and specific restrictions. Adds significant behavioral context beyond 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?

Well-structured with headings, front-loaded purpose. Slight redundancy between first sentence and 'When to use' section, but overall clear and efficient.

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

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

No output schema, and description omits return value or error behavior. Pre-calls and restrictions are clear, but missing info on what happens after delete.

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. Description repeats parameter info (UUID format) but does not add new semantic meaning beyond schema.

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

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

Clearly states 'Permanently delete a group from a sweepstakes' with specific verb and resource. Distinguishes from siblings like delete_sweepstakes, create_group, and fetch_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, prerequisites (fetch_sweepstakes, fetch_groups), and warnings about restrictions (primary, locked, groups with participants). Lacks explicit mention of alternatives like update_group, but strong guidance overall.

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 include destructiveHint: true, but the description adds context by stating 'Permanently delete,' 'WARNING: This action cannot be undone,' and labeling it 'DESTRUCTIVE — IRREVERSIBLE.' It also advises user confirmation, going beyond the annotation to clarify the behavioral impact.

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 repetitive, stating the purpose twice (first sentence and then the markdown section). While front-loaded with key warnings, it could be more concise to avoid 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?

The tool is simple with one parameter and no output schema. The description covers the core action, prerequisite, irreversibility, and user confirmation requirement. It lacks details on error cases (e.g., missing note or permissions) but is adequate given the annotations.

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

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

Schema coverage is 100%, and the description's parameter explanation ('note_token (string, required) — The note token to delete (UUID format)') matches the schema's description exactly. No additional meaning is added, so 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 'Permanently delete a note,' providing a specific verb-resource pair. It distinguishes from siblings like update_note and fetch_notes by emphasizing deletion. The prerequisite step of using fetch_notes further clarifies the purpose.

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

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

The description explicitly instructs to 'Use fetch_notes first to get the note_token' and warns 'Always confirm with the user before calling.' It also includes a prominent warning about irreversibility, guiding appropriate usage and when to avoid 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 indicate destructiveHint=true and readOnlyHint=false. Description adds strong warning: 'WARNING: This action cannot be undone.' and notes 'DESTRUCTIVE — IRREVERSIBLE.' 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?

Well-structured with sections: description, When to use, Pre-calls, Parameters, Notes. Front-loaded with main purpose and warning. Mostly concise, though slightly verbose in places.

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?

Comprehensive coverage for a destructive tool: pre-calls, parameter validation, user confirmation requirement. Even without an output schema, the description provides sufficient context for safe 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?

Schema coverage is 100% (both parameters described with UUID format). Description repeats parameter names and types but adds no new semantic meaning beyond what schema already provides. 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?

Clearly states 'Permanently delete a participant from a sweepstakes.' Uses specific verb (delete) and resource (participant), distinguishing from sibling tools like add_participant, fetch_participants, get_participant.

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 advises to use get_participant first to verify details before deleting. Lists pre-calls required (fetch_sweepstakes) if needed. Warns that action is irreversible and to confirm with user.

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 annotations (destructiveHint=true), the description repeatedly emphasizes that deletion is permanent, irreversible, and requires user confirmation. It provides clear warnings: 'WARNING: This action cannot be undone' and 'DESTRUCTIVE — IRREVERSIBLE. Always confirm with the user.' 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 longer than necessary due to repetition (e.g., the first sentence appears again in the 'When to use' section). While the structured format (headers for pre-calls, parameters, notes) aids readability, conciseness could be improved by merging redundant statements.

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 all essential aspects: purpose, required pre-calls, parameter details (though schema already covers), destructive behavior, and user confirmation guidelines. No output schema exists, so return values are not needed. It provides complete guidance for an AI agent to safely and correctly invoke 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?

With 100% schema coverage, baseline is 3. The description adds value by explaining how to obtain the required tokens ('use fetch_rules first to get the rules_token', 'fetch_sweepstakes if the user gave you a sweepstakes name') and validates the UUID format. This guidance helps an AI agent properly prepare inputs.

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

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

The description clearly states the action ('Permanently delete'), the resource ('official rules document'), and the context ('from a sweepstakes'). It also instructs to use fetch_rules first to obtain the required token, making the purpose unambiguous and distinct from siblings like create_rule or update_rule.

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 dedicated 'When to use' section and explicitly lists pre-calls required (fetch_sweepstakes if needed, fetch_rules to get rules_token). It also warns about irreversibility. However, it does not explicitly contrast with alternative tools (e.g., update_rule), though the destructive nature is clearly indicated.

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 destructiveHint=true and idempotentHint=true. The description adds context: irreversibility warning, status constraint (only pending), and explicit destructive label. This enriches the annotation hints 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 overly verbose with significant repetition between the initial paragraph and the markdown section. Sentences like 'Use them internally for tool chaining but present only human-readable information' add unnecessary verbosity. Could be condensed to 2-3 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?

While the description covers prerequisites and constraints, it fails to mention the return value or response format. Given no output schema, this omission leaves the agent uncertain about what to expect after deletion. The openWorldHint in annotations is not leveraged.

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 have descriptions in the schema. The description repeats the UUID format and adds a pre-call requirement for sweepstakes_token, but does not provide additional semantic depth beyond what the schema already offers.

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 'Delete a pending scheduled drawing' with a specific verb and resource. It distinguishes from siblings by specifying the resource type, though it doesn't explicitly differentiate from other delete tools. The constraint on pending status 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 use fetch_scheduled_drawings first to obtain the schedule_token, and mentions a pre-call for sweepstakes_token if needed. It specifies that only pending drawings can be deleted and warns about irreversibility. This provides clear when-to-use and alternative 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?

Repeatedly warns of destructiveness and irreversibility, adding context beyond annotations (e.g., need for explicit confirmation, prohibition of bulk operations). No contradiction.

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

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

The description is highly repetitive, with the same warnings and instructions appearing in multiple sections (main description, sub-section, notes). Could be condensed to a single clear paragraph.

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 one parameter, no output schema, and annotations covering destructive nature, the description fully covers pre-calls, validation, and usage warnings.

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 coverage, the description adds value by explaining how to obtain the token via fetch_sweepstakes, though it mostly restates 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 it permanently deletes a sweepstakes and all associated data. It distinguishes from siblings like pause_sweepstakes by emphasizing irreversibility.

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 says to use fetch_sweepstakes first to get the token, and provides strong guidance: always confirm with user, never batch delete, and refuse bulk requests.

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: 'This action cannot be undone', 'Only open tickets can be deleted', and a note to confirm with the user. These details align with the destructiveHint=true annotation and provide actionable 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 well-structured with clear markdown sections. It is front-loaded with the primary purpose and each sentence adds value. No redundant or unnecessary text.

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

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

For a simple one-parameter destructive tool, the description covers all necessary aspects: purpose, prerequisite, parameter guidance, and warnings. Given the annotations already provide safety hints, the description is fully complete.

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

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

Schema description coverage is 100% with a clear description of case_id. The description adds practical context on how to obtain the parameter value via fetch_open_tickets, which helps the agent. However, it does not add new semantic meaning beyond the schema.

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

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

The description clearly states it permanently deletes an open support ticket. It specifies the verb 'delete' and the resource 'ticket', and distinguishes from siblings like resolve_ticket which does not delete. The condition 'open' is highlighted.

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_open_tickets first to obtain case_id, and notes that only open tickets can be deleted. It also provides a strong warning about irreversibility and advises confirming with the user.

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 significant context beyond annotations: it emphasizes irreversibility ('cannot be undone') and admin-only requirement. No contradiction with annotations (destructiveHint: true, readOnlyHint: false, idempotentHint: true).

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 but contains redundancy (e.g., irreversible warning repeated in first sentence and again in the # delete_todo section and Notes). Could be condensed without losing clarity.

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

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

For a destructive tool with one parameter and no output schema, the description covers all essential aspects: admin requirement, irreversible nature, and confirmation advice. It is complete enough for safe 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 coverage and only one parameter (todo_token), the description repeats the schema (UUID format) but does not add new meaning. 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 action: 'Permanently delete a To-Do item.' It uses a specific verb and resource, and among sibling tools (e.g., delete_calendar_event, delete_file), this tool is uniquely identifiable.

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 warns that the action is irreversible and admin-only, guiding the agent to confirm with the user and expect 403 for non-admins. It does not compare directly with alternatives, but the specificity is sufficient.

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

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

Discloses key behaviors beyond annotations: it's a production operation selecting real winners, uses weighted random selection, cannot draw from paused/archived sweepstakes. Annotations indicate non-destructive, non-readonly, and open world; description aligns and adds operational detail.

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

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

Well-structured with clear sections (When to use, Pre-calls, etc.), but contains redundancy (first paragraph repeated in 'When to use'). For the complexity of the tool, length is acceptable, but slight trimming would improve 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?

Given no output schema, the description covers post-drawing steps (fetch_winners, update notes, create event) and reminds about web-interface actions. However, it lacks explicit description of the return value, leaving a minor gap for agents to infer behavior.

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 restates parameter names and types but adds minimal new meaning beyond schema. While it offers usage guidance (e.g., validating how_many_winners >= 1), it doesn't significantly enhance parameter understanding.

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 draws winners from a sweepstakes immediately, specifying the verb 'draw' and resource 'winners'. It distinguishes itself from siblings like fetch_winners (which retrieves results) and schedule_drawing (which schedules) by emphasizing immediate action and real winner selection.

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 provides pre-calls (fetch_sweepstakes, fetch_groups) and critical guidelines ('ALWAYS confirm with the user'). It lists parameter validation steps and post-drawing actions, giving comprehensive when-to-use and when-not-to-use 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?

Adds value beyond annotations by specifying result limit (up to 10) and behavior when search is omitted. Annotations already indicate readOnly, idempotent, openWorld; description doesn't contradict.

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?

Description is concise but contains redundant repetition (same info in main description and subheadings). Could be streamlined.

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

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

Given the tool's simplicity (1 optional param, no output schema), the description adequately explains behavior and usage. Annotations provide safety 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?

Schema coverage is 100%, and description repeats the parameter description from schema. No additional meaning beyond what schema already provides.

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

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

Description clearly states the verb (search), resource (US telephone area codes), and scope (by code number or state name). It distinguishes 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?

Explicitly says when to use (search by code or state, or get all). Does not explicitly exclude alternatives but provides clear context for its own usage.

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, indicating a safe, non-destructive read operation. The description adds no additional behavioral context such as authentication requirements, rate limits, or return format details.

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

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

The description is short but contains redundancy: the first two sentences are repeated under a markdown heading. While not verbose, the duplication wastes space and could be streamlined.

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

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

Despite no parameters, the tool has no output schema, so the description should elaborate on the return format or structure of 'aggregated usage data'. It fails to provide this, leaving the agent uncertain about the response.

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

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

With zero parameters, the baseline is 4. The description correctly avoids parameter explanations since none exist, and the schema coverage is 100% (no parameters to describe).

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

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

The description clearly states it fetches monthly and yearly billing consumption totals, specifying 'for your account' and mentioning aggregated data from billing transactions and data transfers. However, it does not differentiate from the sibling tool 'fetch_billing_transactions', which likely handles individual 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 lacks guidance on when to use this tool versus alternatives. It does not specify exclusions, prerequisites, or mention related tools like 'fetch_billing_transactions' for granular data.

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

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

Annotations already provide readOnlyHint, idempotentHint, openWorldHint, and destructiveHint. The description adds behavioral context beyond annotations by specifying that results are sorted by creation date (newest first) and include invoices, amounts, and status. However, it does not disclose potential pagination or limits.

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

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

The description is very concise, using two sentences to convey the core action and result details. Information is front-loaded. The slight redundancy (same sentence in heading) does not detract significantly.

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 no parameters and no output schema, the description covers key output aspects (invoices, amounts, status, ordering). However, it fails to mention potential incompleteness (contradicting openWorldHint), no info on authentication or account scope. The claim 'all' may mislead.

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

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

There are no parameters, and schema description coverage is 100%, so baseline is 3. The description adds no input parameter semantics, which is acceptable given no parameters exist. It adds value by describing output fields but not input meaning.

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

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

The description clearly states it retrieves billing transactions with specific fields (invoices, amounts, status) and sorting order (newest first). The verb 'fetch' and resource 'billing_transactions' are precise, distinguishing it from sibling tools like 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 heading 'When to use' is present but not elaborated; the description implies usage for account billing but provides no explicit guidance on when to choose this over alternatives or any 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?

Consistent with readOnlyHint and idempotentHint; adds that events are returned with details and that they should be used internally for chaining, enhancing transparency beyond 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?

Text is repeated (markdown header + paragraph), causing redundancy; still front-loaded but could be 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?

No output schema, but description explains return values (dates, times, location, status) and usage; sufficiently complete for a simple read-only tool with no parameters.

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?

No parameters exist (0 params), so baseline 4 applies; description need not add parameter info.

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 calendar events for your account' with details, distinguishing from singular 'get_calendar_event' and 'create_calendar_event'.

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 advice on using returned data internally and presenting human-readable info, but lacks explicit comparison to alternative tools or conditions for use.

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

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

Annotations already indicate readOnly, idempotent, not destructive. Description adds that returns summary info only, pagination (20 per page), and search support. Good additional context.

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

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

Content is repeated (first paragraph and markdown section are identical). Could be trimmed. Structure is clear but not optimally 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 no output schema and all optional params, the description adequately explains what is returned (summary info) and what to use for full details. Pagination defaults are clear.

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 4 parameters are fully described in the schema (100% coverage), and the description adds case-insensitivity for search, valid platform values, and priority meanings (Low, Medium, High).

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 fetches closed/resolved support tickets with pagination and search, and distinguishes from get_ticket (full details) and fetch_open_tickets implicitly.

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 guides to use get_ticket for full details, and lists filtering options. Lacks direct comparison to fetch_open_tickets but differentiates via 'closed/resolved' and sibling names.

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, destructiveHint. Description adds useful details: result limit of 10, bilingual names, and that omitting search returns all. 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?

Very concise with front-loaded key info. However, there is minor redundancy: the same text appears in the brief description and again in the 'When to use' section.

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 lookup with one optional parameter and no output schema, the description covers inputs, behavior, and result characteristics adequately. Could mention default ordering or pagination, but not critical.

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. Description adds examples (e.g., '+34', 'US') which are helpful but largely redundant with schema description. Adds minimal extra meaning.

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

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

Description clearly states the action (search countries), resources (name, dial code, ISO abbreviation), and constraints (max 10 results, English/Spanish names, omit for all). Distinguishes from siblings like fetch_states or 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?

Provides clear context: when to search vs. omit to get all. However, it does not explicitly mention when not to use or compare to alternatives among sibling fetch 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. Description adds that it fetches records with specific fields but no additional behavioral traits beyond annotations. 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?

Well-structured with markdown sections, but somewhat repetitive (first sentence appears twice). Could be more concise, but overall efficient and front-loaded with key info.

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?

Completeness is adequate for a simple fetch tool with one parameter. Describes what is returned but lacks details on pagination or output structure. With openWorldHint, perhaps pagination should be mentioned.

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 of sweepstakes_token as UUID. The description adds value by explaining how to obtain the token via fetch_sweepstakes, which is helpful 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?

Clearly states it gets data transfer records for a specific sweepstakes, listing included fields. Implicitly distinguishes from siblings by mentioning prerequisite fetch_sweepstakes, but does not explicitly differentiate 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?

Provides explicit when-to-use and pre-calls required sections, including the exact condition to call fetch_sweepstakes first. Also lists parameters to validate, giving clear guidance for correct invocation.

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, which inform the agent of safe, repeatable behavior. The description adds value by specifying the maximum limit of 10 documents per page, clarifying pagination constraints 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 appropriately structured with a clear purpose and parameter section, but it contains redundancy: the same sentence about pagination and search appears twice. It could be more concise without losing information.

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

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

For a simple fetch tool with three optional parameters and no output schema, the description covers the core functionality: pagination, search, and default/max values. It adequately prepares the agent to invoke the tool, though it does not describe the structure of returned documents.

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

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

Schema description coverage is 100%, with each parameter already described in the input schema. The description restates this information in a structured format but does not add new meaning, such as expected formats or examples, 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 'Get help and support documentation articles' and specifies pagination and search capabilities. However, it does not explicitly differentiate from other fetch_ tools among siblings, such as fetch_files or fetch_groups, missing an opportunity to highlight its unique resource type.

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

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

The description mentions 'When to use' but only restates the purpose. It lacks explicit guidance on when not to use this tool or mention of alternative tools, leaving the agent to infer usage context from the name alone.

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 that files are sorted by creation date newest first, which is useful but not critical behavioral context.

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

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

The description is concise, with two sentences and a focused 'When to use' section. Every sentence provides value, and the key information is 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 simple list operation with two optional parameters and no output schema, the description adequately covers what the tool does and what data it returns. It could mention pagination metadata, but overall it is 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 coverage is 100%, and the description repeats the same parameter information from the schema (defaults, max). No additional semantic meaning is added beyond what is already in the input 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 'List all files in the user's Drive' with specific attributes (storage usage, categories, pagination). It is a distinct operation among sibling 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?

The description includes a 'When to use' section that explains the tool's purpose. However, it does not explicitly mention when not to use it or compare to alternative file-related tools like upload_file or get_file_url.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. Description adds behavioral context about using groups internally and presenting only human-readable info, which is useful beyond 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?

Description is somewhat repetitive with the first sentence echoed in the markdown section. Could be more concise by removing 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?

Given single parameter fully described and annotations covering safety, the description is fairly complete. Lacks details on return format, but the tool is simple and the context about groups' purpose 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% and description matches the parameter exactly (UUID format). No additional semantic value added 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?

Clearly states 'Get all groups from a sweepstakes' with specific verb and resource. Distinguishes from sibling tools like create_group and delete_group by indicating it's a fetch operation.

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_sweepstakes first to obtain the sweepstakes_token, and advises on when the token is needed instead of a name. Also provides guidance on internal tool chaining vs presenting human-readable info.

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=true, etc.), the description reveals automatic decryption and reverse chronological order, adding valuable behavioral context.

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

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

Three sentences, no wasted words. Front-loaded with the core action. Example of effective 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 zero-parameter, read-only tool with comprehensive annotations, the description covers purpose, results, ordering, and usage guidance. No 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?

No parameters exist, so schema coverage is 100%. The description adds no parameter details, which is appropriate. Baseline score of 4 applies.

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

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

The description clearly states 'Get all notes for your account', using a specific verb and resource. It distinguishes from sibling 'get_note' by indicating it returns all notes, and adds ordering and decryption details.

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 guidance on internal use and presentation of results ('Use them internally for tool chaining but present only human-readable information'). However, no explicit comparison to alternatives like 'get_note' or when not to use.

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

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

Annotations already declare readOnlyHint and destructiveHint; description adds that it returns summary info and supports pagination, enhancing transparency.

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

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

Well-structured with markdown headers and front-loaded information, though the parameters section repeats the schema, making it slightly redundant.

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

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

Lacks return format details and total pages info, which is important given no output schema; otherwise covers main functionality.

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 description repeats schema text verbatim without adding extra meaning beyond what the schema already provides.

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

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

The description clearly states it fetches open support tickets with pagination and search, distinguishing it from siblings like fetch_closed_tickets and get_ticket.

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 guidance that it returns summary info and suggests using get_ticket for full details, but does not explicitly state when not to use this 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 indicate safety traits (readOnly, idempotent, non-destructive). The description adds critical behavioral details: pagination (20 per page), sorting (newest first), search/filter capabilities, and the prohibition on fabricating data, providing substantial value beyond 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 into clear sections (brief, when to use, pre-calls, parameters) and is front-loaded with the most critical info. Every sentence serves a purpose without 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?

The description covers usage, parameters, and behavioral notes thoroughly. However, since there is no output schema, some details about the exact output structure (e.g., fields returned) are missing, which is a minor gap for a listing tool with many siblings.

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

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

Schema coverage is 100%, but the description adds cross-parameter constraints (start_date requires end_date) and format hints (UUID). This extra context raises the score above the baseline of 3.

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

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

The description uses a specific verb 'Get a paginated list of participants' and clearly identifies the resource (sweepstakes). It distinguishes from sibling tools like get_participant and add_participant, making the tool's unique role evident.

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

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

The description explicitly states when to use the tool (after fetch_sweepstakes) and when to use alternatives ('For full participant details, use get_participant'). It also includes a strong anti-hallucination directive and pre-call requirements.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds context about fetching primary and secondary rules and required prerequisite, aligning with annotations. No contradiction.

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

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

The description is well-structured with a header and sections, but it repeats the opening sentence. Front-loads purpose effectively. Could be slightly 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 simple fetch tool with no output schema, the description adequately explains what is returned (primary and secondary rules) and the necessary pre-call. Missing details on return format, but 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?

Schema description coverage is 100%, and the description mentions 'UUID format' which is already in the schema. The description adds no additional meaning beyond what the input 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 gets 'all official rules for a sweepstakes including primary and secondary rules,' with a specific verb and resource. This distinguishes it from sibling tools like create_rule or delete_rule.

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_sweepstakes first to obtain the sweepstakes_token and lists a pre-call requirement. No explicit exclusions or when-not-to-use, 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 mark it as read-only, idempotent, and non-destructive. Description adds that it returns all scheduled drawings regardless of status, sorted by creation date (newest first), and hints at output fields (dates, times, status, winner counts). 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?

Contains redundant repetition: the same description appears both in the top-level description and under the '## When to use' heading. The structure with sections is clear, but the redundancy 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?

Given no output schema, the description explains the return behavior (sorted, all statuses) and provides guidance on using results. Pre-call requirements are covered. Annotations cover safety. Minor gap: doesn't specify if pagination is supported, but likely acceptable for a simple fetch.

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 single parameter described as 'The sweepstakes token (UUID format)'. The description repeats this exact phrase, adding no new semantic information 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?

Clearly states the verb ('Get all scheduled drawings') and resource ('sweepstakes'), and distinguishes from sibling tools like fetch_sweepstakes by noting it uses the sweepstakes_token. No ambiguity.

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 provides a 'Pre-calls required' section. Also advises to use results internally for tool chaining and present only human-readable information.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool returns full names and abbreviations but no additional behavioral traits beyond what annotations cover.

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 but contains a redundant markdown header that repeats the same sentence. It could be more concise by removing the duplicate section.

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 no output schema, the description adequately explains the output (full names and two-letter abbreviations). For a simple, parameterless tool, this is complete and 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?

There are zero parameters and schema coverage is 100%. The description does not need to add parameter details. Baseline for 0 params is 4, and the description provides context about the return content.

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 US states including DC, Puerto Rico, and territories, with full names and abbreviations. This is a specific verb-resource combination that distinguishes it from siblings like fetch_countries.

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' header but merely repeats the purpose. It does not provide explicit guidance on when not to use or mention alternative tools like fetch_countries for non-US locations.

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 context beyond annotations by instructing to use tokens internally for tool chaining and present only human-readable information to the user. Annotations already declare readOnlyHint=true, idempotentHint=true, etc., so the description complements them without contradiction.

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

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

The description is front-loaded and clear, but the second paragraph is an exact duplicate of the first, introducing unnecessary redundancy. Removing the repetition would improve 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?

Without an output schema, the description gives a general idea of what is returned (list, details, specific fields like names, dates, statuses) but lacks a full specification of the response structure, which would be helpful for an agent.

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

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

There are no parameters, so the schema provides full coverage (100%). The description adds value by describing the return content (list of sweepstakes with details), which is not captured in the input 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 all sweepstakes associated with your account,' specifying a verb (get/fetch) and a resource (sweepstakes). This distinguishes it from sibling tools like fetch_participants or fetch_rules.

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

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

The description implies usage for listing all sweepstakes and provides guidance on token handling, but it does not explicitly state when to use this tool versus alternatives like get_sweepstakes (if it existed) or other fetch tools. No exclusions or comparisons are provided.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds the default timezone rule and the specific fields returned, which provides useful context but does not drastically expand behavioral knowledge 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 somewhat repetitive (the first sentence appears twice) and includes markdown formatting that could be streamlined. Key information is front-loaded, but conciseness could be improved.

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

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

Given the tool has no parameters and no output schema, the description covers the main purpose, usage guidance, and a default behavior. It lacks explicit details on return format (e.g., list or map), but it is still fairly complete for the tool's 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?

There are no parameters, so schema coverage is 100%. The description adds meaning by explaining what the tool returns, which is sufficient for a parameterless tool.

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

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

The description clearly states the tool fetches all available timezones with specific attributes (IANA identifiers, abbreviations, UTC offsets). It uses a specific verb 'get' and resource 'timezones', and it is easily distinguishable from sibling 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?

The description explicitly says 'Use this tool whenever a timezone needs to be determined for any operation' and provides a default fallback. While it doesn't mention when not to use it or list alternatives, the guidance 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 indicate readOnlyHint=true and destructiveHint=false. The description adds the critical behavioral fact that it's admin-only, with a 403 for non-admins. No contradictions, and it provides useful context beyond 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 repetitive, with a full markdown section duplicating the first paragraph and the entire parameter list already in the schema. Important info is front-loaded, but the redundancy harms 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?

Despite having 10 optional parameters and no output schema, the description does not explain the return format (e.g., list of todos, pagination metadata) or behavior like default sorting. Error handling beyond 403 is missing. The tool is not fully contextualized for an agent.

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

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

Schema coverage is 100%, so baseline is 3. The description in the markdown section repeats parameter descriptions verbatim from the schema, adding no new meaning. It does not explain parameter interactions or validation rules 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 retrieves all To-Do items with pagination, search, and filters. It explicitly mentions admin-only access, distinguishing it from other fetch tools like fetch_calendar_events. The verb 'Get' and resource 'To-Do items' are specific.

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

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

The description explicitly warns that admin privileges are required and non-admins get 403 error, guiding when to use. However, it does not compare to alternatives like create_todo or delete_todo, nor does it state when not to use it.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds that it includes credits, debits, and payment details but does not disclose further behavioral aspects like pagination or limits.

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

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

The description is a single sentence that conveys the core purpose without any extraneous formatting or repetition. It is appropriately front-loaded and 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 has no parameters and no output schema, the description adequately explains the content of the transactions. However, it could mention whether all transactions are returned or if there is pagination.

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

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

There are no parameters, so the schema coverage is 100%. The description does not need to add parameter semantics, and the baseline is 4.

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 purpose: fetching wallet transactions including credits, debits, and payment details. It uses a specific verb and resource but does not explicitly differentiate from similar siblings 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?

The description provides no guidance on when to use this tool versus alternatives. In the context of siblings like fetch_billing_transactions, an agent might be unsure which to choose.

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. Description adds sorting behavior and internal chaining note, which goes beyond annotations. 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?

Description is somewhat repetitive (e.g., repeated in markdown and 'When to use'). Though front-loaded, it could be more concise without losing clarity.

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

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

No output schema, so description should explain return format. It mentions winners sorted by draw date and suggests fields like names, emails, draw dates, but lacks specifics on pagination metadata or total count.

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 descriptions identical to those in the description. Description does not add additional meaning beyond the schema, so 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 gets winners from a sweepstakes with pagination, sorted by draw date most recent first, and supports search. It distinguishes itself from siblings like fetch_sweepstakes and draw_winners by specifying prerequisites and usage.

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: 'Use fetch_sweepstakes first to get the sweepstakes_token.' Includes section 'Pre-calls required' and advises internal chaining. Lacks explicit when-not-to-use but effectively guides 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 read-only, idempotent behavior. The description adds value by disclosing a result limit of 10, case-insensitive search, and return fields (city/state). This enhances transparency beyond structured 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 contains redundant repetition: the same information is stated twice (first paragraph and 'When to use' section). It could be condensed into a single sentence without loss of 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?

For a simple read tool with one parameter and comprehensive annotations, the description sufficiently covers purpose, usage, and partial return structure. It lacks output schema but hints at 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% with full parameter description. The description repeats that but adds no new semantic detail. Baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Search' and the resource 'US zip codes', specifying searchable fields (zip code, city, state name). It distinguishes from sibling tools like fetch_areacodes and fetch_states by focusing on zip codes.

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 implies usage for zip code searches but does not explicitly exclude alternatives like fetch_states or fetch_areacodes. No guidance on when not to use is provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds that it returns company details, address, and business settings, but does not disclose additional behavioral traits like stability, permission requirements, or variability despite openWorldHint being true.

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

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

The description contains a redundant markdown heading and a repeated sentence. While the core message is concise, the repetition wastes space. Could be shortened to a single 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?

For a simple read-only getter with no parameters and standard annotations, the description adequately explains the return value. It does not cover edge cases or error conditions, but this is acceptable given the tool's simplicity and existing annotations.

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

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

With zero parameters and 100% schema coverage, the description does not need to elaborate on parameters. Baseline for 0 parameters is 4, and the description adds no superfluous parameter info.

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 the action 'Get' and the resource 'business information for a Sweeppea account'. It specifies the return content (company details, address, business settings), distinguishing it from sibling tools like get_profile or get_calendar_event.

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

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

No guidance on when to use this tool versus alternatives. It does not mention prerequisites, scenarios where this tool is preferred, or any exclusions. The description is purely functional without 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, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral context by specifying the prerequisite workflow (use fetch_calendar_events first), which 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 includes redundant sections (e.g., 'When to use' repeats the first sentence). It could be more concise by removing duplication, but it is still relatively short.

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

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

Given the tool's simplicity (one parameter, no output schema) and rich annotations, the description provides sufficient context including workflow hints. It is complete enough for an agent to understand 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?

Schema coverage is 100%, and the description repeats the parameter name, type, and description from the schema without adding new semantic meaning. 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's purpose: 'Get a single calendar event by its token.' It also differentiates from siblings by referencing 'fetch_calendar_events' as a prerequisite, which is distinct from other event-related tools.

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

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

The description explicitly instructs when to use the tool: after 'fetch_calendar_events' to obtain the event token. This provides clear workflow guidance and context for use.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by stating what the tool returns ('field names, types, and whether they are required'), which is not in the annotations. No side effects or errors are mentioned, but the provided context is sufficient for an agent to understand the tool's behavior.

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

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

The description is well-structured with a brief opening, a 'When to use' section, 'Pre-calls required,' and 'Parameters to validate before calling.' Every sentence is purposeful with no redundancy. It is concise yet comprehensive, earning a top 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?

Given the tool's simplicity (1 parameter, no output schema), the description covers the key aspects: purpose, usage, pre-requisites, parameter validation, and return values. It does not mention error scenarios or response size, but for a straightforward discovery tool, the coverage is complete enough.

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

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

The input schema has 100% description coverage for the single parameter (sweepstakes_token) with a clear description. The tool description repeats the parameter's UUID format and validates it, adding minimal new semantics beyond the schema. Baseline of 3 is appropriate as the description does not significantly enhance understanding of the parameter beyond what is already 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 form fields for a sweepstakes entry page,' specifying the action (get) and the resource (form fields). It also provides workflow context by mentioning pre-call (fetch_sweepstakes) and subsequent use (before add_participant), distinguishing it from related tools.

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

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

The description explicitly states when to use the tool: 'Call this before add_participant to discover required fields' and 'Use fetch_sweepstakes first to get the sweepstakes_token.' It also lists a pre-call requirement for when the user provides a name instead of a token, giving clear usage instructions.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds value by listing the specific configuration sections returned (display, colors, etc.), providing behavioral context beyond 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 a summary, list of returned sections, and sections for pre-calls and parameters. Some redundancy (list repeated twice), but overall clear and efficient.

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

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

Given the single parameter and no output schema, the description fully covers what the tool does, what it returns, and how to use it in context with other tools. No 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 coverage is 100% with a description for sweepstakes_token. The description restates the UUID format requirement, adding no additional semantic information beyond the schema. Baseline score of 3 is appropriate.

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

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

The description clearly states it retrieves entry page settings for a sweepstakes, specifying the resource and action. It distinguishes from the sibling update_entry_settings by noting it should be used before updating.

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_sweepstakes first to obtain the sweepstakes_token, and recommends using this tool before update_entry_settings. Provides clear context for 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 declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds behavioral details: short-lived URL, embedded Content-Type/Content-Disposition headers, no data transfer cost, default expires_in of 900 seconds, and default mode of 'preview'. This provides useful 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 structured with a main sentence and then a redundant 'When to use' section that repeats the first sentence. The 'Parameters to validate before calling' section mirrors the schema. Some duplication could be removed for 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?

Given the lack of an output schema, the description should describe what is returned (e.g., a URL string or structured object). It mentions generating a URL but does not specify the response format or possible error conditions. The tool is simple, but the missing return information is 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 description coverage is 100%, so the baseline is 3. The description repeats parameter info but adds minor value by stating 'Get via fetch_files' for file_token, which introduces a dependency. For mode and expires_in, it restates schema info without additional depth.

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 generates a short-lived presigned S3 URL for downloading or previewing a file from the user's Drive. It uses a specific verb ('generate') and resource (presigned S3 URL), and the context distinguishes it from siblings like 'send_file' or 'upload_file'.

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 merely restates the purpose. It does not explicitly contrast with alternative tools like 'send_file' or 'fetch_files', nor does it provide when-not-to-use guidance. The usage context is implied rather than explicitly stated.

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds that content is automatically decrypted, which is a useful behavioral detail not in the schema or 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 repetitive, stating the same information multiple times. It could be more concise without losing clarity.

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

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

For a simple tool with one parameter and no output schema, the description covers purpose, prerequisite, and an extra behavioral detail (decryption). It is 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?

Schema coverage is 100%, and the description repeats the parameter information. It adds context about using fetch_notes to obtain the token, but no additional semantic details 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 'Fetch a single note by its token', using a specific verb and resource. It distinguishes from siblings like fetch_notes (which retrieves multiple notes) and other note manipulations.

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 advises to 'Use fetch_notes first to get the note_token', providing a clear prerequisite. No exclusion criteria are mentioned, but for a simple fetch, this is adequate.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds crucial caution against hallucinating data and instructs to report missing results accurately, which is valuable beyond 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 contains repetition (first paragraph nearly identical to 'When to use' section). It is longer than necessary but well-structured with headings. It could be trimmed 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 single-fetch tool with annotations covering safety and idempotency, the description provides complete guidance: pre-requisite calls, parameter validation rules, behavioral guardrails against hallucination, and instructions for presenting results to users.

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 the important constraint that at least one of participant_token, email, or phone must be provided, which is not explicit in the schema. It also reinforces format hints (UUID, 10 digits) already present in schema, providing marginal added value.

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

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

The description clearly states the verb ('Fetch full details'), resource ('single participant'), and scope ('by token, email, or phone'), and distinguishes from sibling 'fetch_participants' which lists multiple participants.

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 guides to use 'fetch_sweepstakes' first to obtain the token, and directs to 'fetch_participants' for listing. Also specifies that at least one search parameter is required, giving clear context for when to use this 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 declare readOnly, idempotent, and non-destructive behavior. The description adds context about return content (pricing, limits, features, usage), which is helpful but does not reveal additional behavioral traits 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 short but contains redundancy: the main sentence appears twice, once in the initial description and again in the 'When to use' section. It could be more concise without repetition.

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