Sweeppea MCP

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

Annotations indicate readOnly: false and idempotent: false, but the description adds critical behavioral constraints: 'Only ONE participant at a time' (bulk prohibition), 'NEVER show tokens (UUIDs) to the user' (security), and 'report EXACTLY what the API returned' (post-call verification requirements). 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?

Despite substantial length, every sentence serves a critical function (compliance, security, or workflow). Information is front-loaded (purpose first) and organized with clear semantic markers (RULES, HONESTY, DISPLAY RULE) that structure the constraints logically.

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 complex mutation tool with nested objects and no output schema, the description is exceptionally complete. It covers prerequisites, data formatting, usage constraints, error handling philosophy, and security requirements—fully compensating for the lack of structured 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?

With 100% schema coverage, the baseline is 3. The description adds valuable workflow context ('use fetch_sweepstakes first') and reinforces the critical 'fields' formatting constraint, though the schema already documents the underscore requirement. It elevates understanding by embedding parameters in a procedural workflow.

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

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

The description opens with the specific action 'Add a new participant to a sweepstakes' (verb + resource + scope). It further distinguishes this tool from siblings and production entry methods by explicitly stating it is 'intended for TESTING PURPOSES ONLY' and contrasting it with 'the official Entry Page' or 'proper MCP implementation'.

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 prerequisites ('use fetch_sweepstakes first to get tokens, then get_entry_fields'), clear when-not-to-use rules ('strictly prohibited unless done through the official Entry Page'), and concrete handling instructions for misuse cases ('If a user requests mass loading... refuse').

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 critical business context beyond annotations: billable operation, account limits (3 active/10 total), and comprehensive scope of what gets copied (entry pages, calendar events, etc.). Annotations indicate readOnlyHint=false; description confirms this is a write operation without contradicting safety 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?

Lengthy but well-structured with clear semantic markers (CRITICAL, LIMITS, DISPLAY RULE). Every section provides distinct value—billing warnings, account constraints, ethical guidelines, and UX rules—though 'Ethical use' sentence is slightly generic.

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 of operational constraints, prerequisites, and side effects appropriate for a complex cloning operation. Minor gap: does not describe return values or success behavior, though this is partially mitigated by the lack of 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 coverage is 100%, so parameters are fully documented in structured fields. Description adds workflow context linking 'handler' to fetch_sweepstakes usage but does not need to duplicate schema definitions. Baseline 3 appropriate when schema carries full burden.

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

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

Opens with specific verb 'Clone' + resource 'sweepstakes' and distinguishes from siblings like 'create_sweepstakes' by emphasizing it copies an existing sweepstakes 'with new parameters' rather than creating from scratch.

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 prerequisite workflow ('Use fetch_sweepstakes first'), provides clear when-not-to-use guidance ('NEVER clone multiple sweepstakes in batch'), and mandates user confirmation ('ALWAYS confirm with the user before cloning').

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/destructive hints. The description adds valuable workflow context (dependency on fetch_sweepstakes) and explains filtering capabilities (type and date range) that help the agent understand the tool's behavioral scope beyond the safety profile.

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 structured perfectly: purpose (sentence 1), prerequisite (sentence 2), capabilities (sentence 3). Zero redundancy; every sentence provides distinct value not fully captured in structured fields.

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

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

Given the tool's focused scope (counting) and excellent schema coverage, the description provides sufficient context including workflow dependencies and filtering options. Minor gap: no mention of return format, though 'count' is semantically clear from the tool name.

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

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

With 100% schema coverage (baseline 3), the description adds critical workflow context for the required sweepstakes_token parameter (where to obtain it) and reinforces the filter_type enum values, providing additional selection guidance beyond the schema definitions.

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

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

The description opens with the specific verb 'Get' + resource 'participant counts' + scope 'for a sweepstakes', clearly distinguishing it from sibling tools like fetch_participants (full data) and get_participant (single record).

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 the prerequisite workflow: 'Use fetch_sweepstakes first to get the sweepstakes_token.' This provides clear procedural guidance, though it lacks explicit 'when not to use' comparisons to alternatives like fetch_participants.

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 critical behavioral context beyond annotations: explains the UTC timezone handling of the API server, the date validation logic that may reject 'today' depending on local timezone, and the specific error message text. Annotations indicate it's a write operation (readOnlyHint: false), but the description adds the crucial temporal validation 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?

Perfectly structured with the essential purpose front-loaded in the first sentence, followed immediately by the critical DATE RULE constraint. No filler text; every sentence provides actionable guidance for avoiding API failures. Length is proportionate to the complexity of the 19-parameter tool and the non-obvious date behavior.

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 19-parameter creation tool with no output schema, the description successfully covers the primary functionality, required fields (implied), and critical validation rules. It omits description of the return value or success response, but provides sufficient information for correct invocation. The date handling warning is essential contextual completeness for this specific API 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?

With 100% schema description coverage, the baseline is 3. The description elevates this by adding essential semantic context for the date parameters (UTC interpretation, 'tomorrow or later' rule) that schema field descriptions alone don't convey. It references key parameters (title, dates, location) but doesn't elaborate on less obvious ones like 'repeat_this_event' or 'status' beyond the schema.

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

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

The description opens with a clear, specific action ('Create a new calendar event') and identifies the core resources and fields involved (title, dates, optional details). The 'Create' verb clearly distinguishes this from sibling tools like update_calendar_event, delete_calendar_event, and fetch_calendar_events.

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

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

Provides explicit usage constraints with the 'DATE RULE' section, clearly stating when NOT to use the tool (today's date) and explaining the specific error that will occur ('Cannot Create Events In The Past'). It also prescribes the alternative action (use tomorrow's date) and communication strategy for user interactions.

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 declare mutation safety profile (readOnly=false, destructive=false). Description adds critical workflow dependency (fetch_sweepstakes prerequisite) and business context. Does not elaborate on idempotency implications (annotations show idempotent=false) or failure modes.

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

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

Three sentences total: core purpose, prerequisite workflow, and business rationale. Every sentence earns its place with no redundancy. Front-loaded with the essential action.

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

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

Adequate for a simple 2-parameter creation tool. Covers prerequisites and purpose. Minor gap: does not mention that operation fails if group exists (implied by idempotentHint=false and schema uniqueness constraint) or describe the response.

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

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

Schema coverage is 100%, establishing baseline 3. Description adds value by linking sweepstakes_token to fetch_sweepstakes workflow, but does not elaborate on group_name uniqueness constraints beyond schema text.

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

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

Description opens with specific verb 'Create' + resource 'group' + scope 'within a sweepstakes', clearly distinguishing it from sibling tools like create_sweepstakes (creates the container) and update_group/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?

Provides explicit prerequisite workflow ('Use fetch_sweepstakes first to get the sweepstakes_token') and explains the business purpose ('organize and segment participants'). Lacks explicit 'when not to use' or alternative tool pointers (e.g., update_group for existing groups).

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?

Excellent behavioral disclosure beyond annotations: specifies AES-256-CBC encryption method, detailed HTML validation rules (allowed/forbidden tags), and UI rendering constraints (spacing rules, <br> usage). Annotations confirm write operation (readOnlyHint: false) and non-idempotency, while description explains the actual side effects and constraints.

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

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

Well-structured with implicit headers (FORMAT, NEVER, SPACING) and front-loaded purpose. Length is justified by complex HTML validation requirements. Minor verbosity in spacing explanation ('ugly blank blocks') prevents a 5, but every section provides necessary operational guidance.

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 given the complexity: covers creation semantics, encryption guarantees, input validation rules, and UI/UX formatting constraints. With 100% schema coverage and available annotations, no gaps remain for a creation tool without 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 has 100% coverage establishing baseline 3. Description adds substantial value for the 'content' parameter: specific spacing prohibitions ('<br> '), formatting examples ('<h3>Title</h3><p>Text</p>'), and security context (encryption). Does not explicitly discuss 'pinned' parameter, but schema covers it adequately.

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?

Opens with specific verb 'Create' and resource 'note', clearly distinguishing from sibling tools update_note, delete_note, and get_note. The encryption detail adds specific operational context.

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

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

The phrase 'Create a new note' provides clear context that this is for new note creation only, implying existing notes require update_note. However, it lacks explicit 'when not to use' guidance or direct references to sibling alternatives like update_note.

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 (write operation, non-idempotent), the description discloses critical business logic: primary/secondary rules distinction, short URL mechanics (swpp.me/r/[handler]), Entry Page publishing behavior, and security constraints (never display tokens to users).

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?

Though lengthy (8 sentences), the structure is front-loaded with purpose, followed by prerequisites, then detailed warnings. Each sentence serves a distinct function; the caps formatting for warnings aids scannability despite slight verbosity.

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

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

Given the complex business rules around primary/secondary documents and lack of output schema, the description comprehensively covers prerequisites, side effects, and user communication requirements, though it could briefly note what constitutes a successful creation 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 100% schema coverage establishing a baseline of 3, the description adds valuable workflow context for sweepstakes_token (obtained via fetch_sweepstakes) and implies the content requirements for the document creation process.

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

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

The description opens with a specific verb and resource ('Create a new official rules document for a sweepstakes') and implicitly distinguishes from siblings like update_rule (creates vs updates) and create_rules_wizard (manual process vs wizard).

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 prerequisites ('Use fetch_sweepstakes first', 'call fetch_rules to check'), clear workflow sequencing, and warns about specific business consequences (secondary vs primary rules) requiring user acknowledgment before proceeding.

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 write operation (readOnlyHint: false) with external dependencies (openWorldHint: true). The description adds substantial behavioral context beyond these hints: it discloses the 14-step sequential constraint, server-side template generation ('wizard generates ALL legal text server-side'), primary vs. secondary rules distinction with URL generation behavior, validation constraints (NO PAST DATES RULE), and side effects (Age Gate activation 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?

Despite considerable length, the description is well-structured with clear all-caps headers delineating distinct rule categories (MANDATORY WORKFLOW, NO FABRICATION RULE, etc.). For a 49-parameter wizard with complex validation requirements, the verbosity is justified. Each section serves a critical safety or procedural function, though the density could potentially be overwhelming.

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 absence of an output schema, the description adequately explains post-creation behavior (providing the public rules URL when is_primary: true, warning about secondary rules implications). It covers the full lifecycle from prerequisite data fetching through wizard execution to result handling. Minor gap: it does not describe error states or failure modes, though it emphasizes validation rules that prevent certain errors.

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

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

With 100% schema description coverage, the baseline is 3. The description adds significant value by providing pre-fill instructions ('Pre-fill from get_business'), consolidated enum reference tables for complex fields (method_of_entry, states, min_age), and conditional requirement logic ('Required when states = 4'). While the schema documents individual parameters, the description provides the workflow context for how to populate them correctly.

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

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

The description opens with a specific verb-resource-mechanism triad: 'Generate official sweepstakes rules via the 14-step wizard.' It clearly distinguishes from sibling `create_rule` by emphasizing the wizard workflow and sequential step process (A through N), indicating this is a guided generation process rather than a simple record creation.

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?

Extensive explicit guidance including mandatory prerequisites ('Before calling this tool you MUST call fetch_sweepstakes'), explicit alternative tool references ('To filter by user/workspace, use search_calls_extensive instead' analog here with fetch_rules for checking existing primary rules), and clear prohibitions ('NEVER invent, assume, or fabricate any data'). The MANDATORY WORKFLOW, DISPLAY RULE, and STEP-BY-STEP RULE sections provide unambiguous when-to-use and when-not-to-use 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?

Exceptional disclosure beyond annotations: declares billable financial impact, production data scope, account limits (3 active/10 total), idempotency warnings (batch creation risks), date validation constraints, and display rules (UUID masking). Annotations only indicate read/write status; description provides business-critical operational 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?

Front-loaded with core purpose. Lengthy but justified by high-stakes nature (billable, legal compliance). Uses structural markers (CRITICAL, ALWAYS, LIMITS, DISPLAY RULE) to aid scanning. Minor deduction for generic ethical use paragraph that adds less value than technical sections.

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 for a creation tool lacking output schema. Covers validation rules (dates), resource constraints (account limits), financial impact (billable), safety procedures (confirmation), chaining instructions (fetch_sweepstakes prerequisite), and presentation rules (token masking). No gaps remain for safe operation.

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

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

With 100% schema description coverage, the baseline is 3. The description lists required fields but adds no semantic nuance beyond the schema (e.g., doesn't explain business purpose of 'handler' or implications of boolean flags like sync_with_winners beyond their schema descriptions).

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

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

Opens with specific verb-resource combination ('Create a new sweepstakes programmatically') that clearly distinguishes it from siblings like clone_sweepstakes, update_sweepstakes, and delete_sweepstakes. The parenthetical type mapping (1=SMS, etc.) further clarifies the resource domain.

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 prerequisite ('Before creating, use fetch_sweepstakes'), clear exclusions ('NEVER create multiple sweepstakes in batch'), and safety protocols ('ALWAYS confirm with the user'). Lacks explicit contrast with clone_sweepstakes as an alternative for duplication, preventing a 5.

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

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

Annotations indicate write operation (readOnlyHint=false) and non-idempotency. Description adds substantial behavioral context: HTML sanitization rules (allowed tags), security constraints (no scripts/iframes), assignment logic (defaults to all admins), and UI rendering quirks (avoid <br> ). 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?

Uses clear section headers (ASSIGNMENT, FORMAT, SPACING) to organize dense but necessary constraints. Every sentence provides actionable guidance (security rules, defaults, formatting). Slightly verbose but justified by security and validation requirements; front-loaded with core purpose.

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

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

Comprehensive coverage for a 4-parameter mutation tool with security implications. Addresses creation logic, assignment side effects, input sanitization, and formatting constraints. No output schema exists, so return value explanation is not required per rules. Covers all critical behavioral edges (HTML injection prevention, assignment validation).

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?

Despite 100% schema coverage (baseline 3), description adds critical usage constraints beyond schema: validation rules for assign_to (never guess/fabricate), explicit HTML tag whitelist for description, security prohibitions, and formatting guidance. Elevates understanding of parameter behavior significantly.

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 opens with specific verb+resource combination ('Create a new support ticket') and identifies key parameters (title, description, priority). Clearly distinguishes from sibling tools like update_ticket, resolve_ticket, and fetch_open_tickets through explicit 'Create' framing and new-ticket semantics.

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

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

Provides explicit when-to-use guidance for the optional assign_to parameter ('only use assign_to if the user explicitly provides a name or email'), states default behavior (omission assigns to all admins), and restricts valid values (admin-level only). Could explicitly distinguish from update_ticket for perfect score.

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

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

Excellent disclosure beyond annotations: specifies admin auth requirements, 403 error conditions, UUID/token handling rules ('Never display tokens'), and detailed HTML sanitization constraints. Annotations indicate it's a write operation (readOnlyHint: false), and the description complements this with security and formatting 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?

Front-loaded with purpose and auth requirements. Uses ALL CAPS headers to structure the mixed content (auth rules, display rules, formatting). Slightly verbose regarding HTML formatting specifics, but justified given security implications. No wasted words in the opening.

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 (HTML sanitization, admin restrictions, no output schema), the description covers auth, error modes, content validation, and token handling adequately. Missing only a brief note on the return value structure, though the UUID rule partially covers this.

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 baseline is 3. The description adds value by elaborating on the description parameter's HTML constraints (specific spacing rules like 'Do NOT use <br> ') and implicitly referencing the return value (UUID handling), which compensates for the lack of output 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 opening sentence 'Create a new internal To-Do item' provides a clear verb and resource. However, it lacks explicit differentiation from siblings like create_ticket or create_note, though 'internal' hints at the distinction.

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

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

Explicitly states 'ADMIN ONLY' requirement and warns that 'Non-admin users will receive a 403 Forbidden error.' This is strong prerequisite guidance, though it lacks explicit 'when to use vs create_ticket/create_note' comparisons.

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

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

While annotations already mark destructiveHint=true, the description adds valuable specificity with 'WARNING: This action cannot be undone,' emphasizing permanence beyond generic destructiveness. It also adds workflow context (fetch first) not present in annotations.

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

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

Three sentences are perfectly front-loaded: purpose (sentence 1), prerequisites (sentence 2), and risk warning (sentence 3). No redundancy or waste despite the brevity.

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 schema, presence of comprehensive annotations (destructive, idempotent hints), and lack of output schema, the description fully covers prerequisites, risks, and operational context required 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 establishing a baseline of 3, the description adds semantic value by specifying that the event_token should be obtained from fetch_calendar_events, providing provenance context not present in the schema's UUID format description.

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

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

The description opens with 'Permanently delete a calendar event,' providing a specific verb (delete) and resource (calendar event) that clearly distinguishes this tool from sibling delete operations like delete_group or delete_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?

Explicitly states the prerequisite workflow: 'Use fetch_calendar_events first to get the event_token.' This provides clear temporal ordering and distinguishes correct usage from incorrect direct 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?

Rich disclosure beyond annotations: specifies backend implementation details (S3 storage and database removal), side effects (storage quota freed immediately), irreversibility emphasis, and critical UI constraints (NEVER show tokens to user). Annotations only indicate destructiveness/idempotency; description explains the actual mechanics and consequences.

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?

Perfectly structured with front-loaded warning flags (DESTRUCTIVE — IRREVERSIBLE), followed by action description, side effects, mandatory confirmation rule, and display constraint. Every sentence delivers critical safety or operational information with zero waste.

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

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

Comprehensive for a destructive operation: covers confirmation requirements, backend effects, and display rules. Minor gap: no output schema exists, and description doesn't explicitly state the return value or success response format, though this is less critical given the safety-focused 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?

With 100% schema coverage, baseline is 3. Description adds significant value with DISPLAY RULE specifying UUID handling constraints (internal use only, never show to user), providing UX semantics for the file_token parameter that the schema's technical description doesn't cover.

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?

Explicitly states the specific action (permanently delete) and resource (file from user's Drive), clearly distinguishing it from sibling delete operations (delete_note, delete_group, etc.) by specifying the Drive/file domain.

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?

Contains explicit mandatory precondition 'ALWAYS ask for explicit user confirmation before calling this tool,' providing clear guidance on when it is appropriate to invoke. Also references the token source relationship with fetch_files via the DISPLAY RULE, implicitly guiding parameter acquisition.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds valuable behavioral constraints not in annotations: the three specific categories of groups that cannot be deleted (primary, locked, with participants). It does not contradict annotations. A 4 reflects solid added context, though it could optionally mention the idempotent nature explicitly.

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

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

Three sentences with zero waste: (1) action definition, (2) prerequisite workflow, (3) guardrails/restrictions. Information is front-loaded with the primary action, and every sentence earns its place by providing distinct operational guidance.

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 2-parameter destructive operation with no output schema, the description comprehensively covers prerequisites, token provenance, and deletion restrictions. It lacks only a description of the return value (success indicator), but for a delete operation with destructiveHint=true, this is a minor omission given the rich guardrail documentation.

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

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

With 100% schema description coverage, the baseline is 3. The description adds meaningful workflow context by explaining that sweepstakes_token and group_token must be obtained via fetch_sweepstakes and fetch_groups respectively, which is crucial semantic information for an agent planning tool sequences.

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

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

The description opens with a specific verb ('Permanently delete') and resource ('group from a sweepstakes'), clearly distinguishing this from sibling tools like delete_sweepstakes, delete_participant, or update_group. The scope and destructive nature are immediately apparent.

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 provides a two-step prerequisite workflow ('Use fetch_sweepstakes first... then fetch_groups') and clearly states exclusion criteria ('Cannot delete primary groups, locked groups, or groups with participants'). This gives the agent clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds valuable context beyond these: the prerequisite workflow (fetch_notes first) and the explicit 'WARNING: This action cannot be undone' which reinforces the destructive nature for LLM reasoning. 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?

Three sentences with zero waste: (1) Purpose declaration, (2) Prerequisite instruction, (3) Risk warning. Perfectly front-loaded with the action verb and scoped to the exact resource. Every sentence earns its place in guiding safe invocation.

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

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

For a destructive operation with strong annotations, the description adequately covers purpose, prerequisites, and irreversibility risks. Lacks output description, but no output schema is provided and delete operations typically return minimal confirmation. Sufficient for safe agent operation.

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

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

Schema coverage is 100% with 'The note token to delete (UUID format)' already documenting the single parameter. The description mentions note_token only in the workflow context ('get the note_token') but adds no semantic meaning beyond the schema. Baseline 3 is appropriate given complete schema coverage.

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

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

The description opens with 'Permanently delete a note' — a specific verb (delete) + resource (note) + scope modifier (permanently). It clearly distinguishes from siblings like update_note, get_note, and fetch_notes by emphasizing the destructive, irreversible nature of the 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?

Provides explicit workflow guidance: 'Use fetch_notes first to get the note_token.' This tells the agent exactly when and how to invoke the tool in sequence. Lacks explicit 'when not to use' alternatives, but the irreversibility warning implies caution.

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?

While annotations declare destructiveHint=true and readOnlyHint=false, the description adds critical behavioral context: 'WARNING: This action cannot be undone.' This amplifies the destructive nature beyond the boolean hint and recommends verification workflow. It does not contradict the idempotentHint=true annotation (deleting an already deleted participant remains permanent).

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

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

Two sentences, front-loaded with the core action. First sentence establishes operation and scope; second provides safety warning and prerequisite. Zero redundancy—every word earns its place.

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

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

For a destructive two-parameter operation without output schema, the description adequately covers safety warnings, irreversibility, and prerequisite verification. Minor gap: does not describe success/failure behavior or return values, though this is less critical given the simple schema and clear destructive intent.

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

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

With 100% schema description coverage for both required parameters (sweepstakes_token and participant_token), the schema carries the semantic burden. The description does not explicitly discuss parameter formats or usage, but references 'verify the participant details' which indirectly supports the participant_token parameter. Baseline 3 is appropriate given full schema coverage.

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

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

The description explicitly states 'Permanently delete a participant from a sweepstakes,' providing a specific verb (delete), resource (participant), and scope (sweepstakes). It clearly distinguishes from sibling tools like get_participant or update_sweepstakes.

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

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

Provides explicit workflow guidance: 'Use get_participant first to verify the participant details before deleting.' This establishes a clear prerequisite and implicitly defines when not to use the tool (without verification). The WARNING also signals caution criteria.

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

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

While annotations declare destructiveHint=true, the description adds valuable context with 'WARNING: This action cannot be undone' and emphasizes permanence. It also discloses the dependency on fetch_rules for token procurement.

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

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

Three sentences with zero waste: action definition, prerequisite instruction, and risk warning. Front-loaded with the core purpose and efficiently structured.

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

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

Complete for a destructive operation with no output schema: annotations cover safety profile, schema covers parameters at 100%, and description covers prerequisites and irreversibility. Minor gap regarding cascading effects on sweepstakes status.

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?

Despite 100% schema coverage (baseline 3), the description adds semantic value by explicitly naming 'rules_token' and linking it to the fetch_rules prerequisite, clarifying how to obtain the parameter value.

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

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

Description states the specific action ('Permanently delete'), resource ('official rules document'), and scope ('from a sweepstakes'), clearly distinguishing it from siblings like delete_sweepstakes or delete_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?

Provides explicit prerequisite workflow ('Use fetch_rules first to get the rules_token'), but lacks explicit contrast with alternatives like update_rule for non-destructive modifications.

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?

While annotations declare destructiveHint=true and readOnlyHint=false, the description adds critical UI guidance ('NEVER show tokens to the user') and clarifies the status constraint (pending-only). It reinforces the irreversible nature with 'WARNING: This action cannot be undone.'

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

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

Four sentences efficiently cover: purpose, prerequisite workflow, irreversibility/status constraints, and display rules. Every sentence earns its place with zero redundancy. Information is front-loaded with the core action.

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 this is a destructive operation with clear annotations and complete input schema, the description adequately covers safety warnings, UI presentation rules, and business logic constraints (pending status). Minor gap: doesn't describe error behavior when attempting to delete non-pending drawings.

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?

Despite 100% schema coverage providing basic parameter documentation, the description adds essential workflow context explaining that schedule_token must be obtained from fetch_scheduled_drawings first, and provides handling rules (don't display UUIDs to users).

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

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

The description opens with the specific verb 'Delete' and resource 'pending scheduled drawing', clearly distinguishing it from siblings like delete_sweepstakes or delete_ticket. The 'pending' qualifier is crucial for understanding scope.

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

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

Explicitly states the prerequisite workflow 'Use fetch_scheduled_drawings first to get the schedule_token' and defines clear constraints: 'Only drawings with pending status can be deleted — completed or errored drawings cannot be removed.'

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?

While annotations flag destructiveHint=true, the description adds critical behavioral context beyond these booleans: it specifies exactly what data is destroyed (participants, statistics, automations), emphasizes irreversibility ('cannot be undone'), mandates confirmation workflows showing the sweepstakes name, and prohibits batch operations. This provides the operational nuance the annotations lack.

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?

Six sentences with zero waste. The structure is optimally front-loaded: purpose → prerequisite → safety warning → confirmation requirement → batch prohibition → alternative handling. The use of emphatic formatting (CRITICAL, ALWAYS, NEVER) is appropriate for a destructive operation and does not detract from 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?

Given the destructive nature, single parameter, and lack of output schema, the description is comprehensive. It covers prerequisites, safety guardrails, scope of destruction, and operational constraints (no batching). No gaps remain that would prevent correct invocation.

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

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

With 100% schema coverage, the baseline is 3. The description adds valuable workflow context by instructing to 'Use fetch_sweepstakes first to get the sweepstakes_token,' explaining how to obtain the parameter rather than just its structure. However, it does not add format constraints or validation details beyond the schema's basic type definition.

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

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

The description opens with a specific verb ('Permanently delete') and resource ('sweepstakes'), and immediately clarifies the scope of impact ('all associated data including participants, statistics, and automations'). This clearly distinguishes it from sibling tools like update_sweepstakes or pause_sweepstakes which modify rather than destroy.

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 prerequisites ('Use fetch_sweepstakes first'), mandatory safety protocols ('ALWAYS ask for explicit user confirmation'), and clear prohibitions ('NEVER delete multiple sweepstakes in batch'). It explicitly directs the agent to refuse bulk deletion requests and handle them sequentially instead, leaving no ambiguity about when to use versus avoid 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?

While annotations declare destructiveHint=true and readOnlyHint=false, the description adds critical behavioral context: 'WARNING: This action cannot be undone' emphasizes irreversibility, and 'Only open tickets can be deleted' discloses a business logic constraint not evident in the annotations. Also clarifies the prerequisite workflow.

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 well-structured sentences with zero waste: sentence 1 states purpose, sentence 2 provides prerequisites, sentence 3 delivers warnings and constraints. Information is front-loaded with the core action, and the WARNING capitalizes critical safety information appropriately.

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

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

For a single-parameter destructive operation with no output schema, the description is complete. It covers the action, prerequisites, irreversibility warnings, and state constraints (open tickets only). The annotations handle the safety profile (destructive, idempotent), so the description doesn't need to redundantly explain these traits.

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

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

Although the schema has 100% coverage describing case_id as 'The case number of the ticket to delete,' the description adds valuable semantic context by specifying to 'Use fetch_open_tickets first to get the case_id,' explaining the data provenance and workflow dependency for the parameter.

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

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

The description opens with 'Permanently delete an open support ticket,' providing a specific verb (delete), resource (support ticket), and scope limitation (open). This clearly distinguishes it from siblings like resolve_ticket, update_ticket, and delete_note by specifying both the action permanence and the target state.

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 prerequisite workflow: 'Use fetch_open_tickets first to get the case_id.' Also states the constraint 'Only open tickets can be deleted,' implying when not to use it. Could be improved by explicitly naming resolve_ticket as the alternative for closing tickets without deletion, 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?

While annotations declare destructiveHint=true, the description adds critical behavioral details: irreversibility ('cannot be undone'), authorization requirements ('requires admin privileges'), specific error codes (403 Forbidden), and UI handling rules ('Never display tokens'). This significantly exceeds the annotation coverage.

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

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

Four sentences each serve distinct purposes: action definition, safety warning, authorization constraint, and UI handling rule. Information is front-loaded with the core verb and contains zero redundancy.

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

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

For a destructive operation with authentication constraints, the description comprehensively covers the action, permanent consequences, privilege requirements, error behavior, and parameter handling—sufficient even without an output schema.

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

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

With 100% schema coverage, the baseline is 3. The description elevates this by adding the DISPLAY RULE regarding UUID handling ('use them internally only'), providing important implementation guidance beyond the schema's type definition.

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

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

The description opens with the specific action 'Permanently delete' and identifies the exact resource type 'To-Do item', clearly distinguishing it from sibling tools like update_todo, create_todo, or fetch_todos.

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 the privilege requirement 'ADMIN ONLY' and specifies the failure mode 'Non-admin users will receive a 403 Forbidden error'. Also includes the irreversibility warning 'cannot be undone', establishing clear prerequisites and constraints.

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 significant context beyond annotations: discloses weighted random selection algorithm, production impact ('selects real winners'), and state restrictions (paused/archived). Annotations indicate non-idempotent and non-read-only nature; description confirms with 'production operation' and implied irreversibility. Does not mention retry risks or rate 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?

Front-loaded with core action. Every sentence serves a distinct purpose: prerequisites, critical warning, confirmation requirement, algorithm disclosure, restriction, and display rule. No redundant text despite length. CRITICAL/ALWAYS/NEVER formatting effectively highlights safety concerns.

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 of preconditions, safety constraints, and presentation rules for a complex 6-parameter operation. Minor gap: lacks description of what the tool returns (winner objects, confirmation IDs, etc.), which would be helpful given no output schema exists.

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

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

With 100% schema description coverage, the schema adequately documents all 6 parameters. The description references 'sweepstakes_token', 'group', and 'how_many_winners' in usage context but does not add syntax, format details, or enum explanations beyond what the 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?

States 'Draw winners from a sweepstakes immediately' with specific verb (draw) and resource (winners/sweepstakes). The word 'immediately' effectively distinguishes it from sibling tool 'schedule_drawing', while 'selects real winners' differentiates it from 'fetch_winners'.

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 prerequisites ('Use fetch_sweepstakes first... and fetch_groups'), exclusion criteria ('Cannot draw from paused or archived sweepstakes'), and mandatory safety protocol ('ALWAYS confirm with the user before drawing'). Names specific sibling tools required for preparation.

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 declare readOnly/idempotent/destructive hints. Description adds crucial behavioral context: 'Returns up to 10 results,' which warns the agent of the output limit. However, it slightly conflicts with 'get all area codes' without explaining pagination or the truncation 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?

Three efficient sentences with zero waste: purpose front-loaded, result limit stated, optional parameter behavior clarified. Every sentence earns its place.

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

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

Appropriate for a simple lookup tool: covers purpose, parameter optionality, and result cardinality (up to 10). Lacks output structure details, but given the single parameter and strong annotations, the description provides sufficient context for 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?

Input schema has 100% description coverage, establishing baseline 3. Description echoes schema details (search by 'code number or state name,' optional param) but adds minimal semantic value beyond the schema's own documentation.

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

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

Specific verb (Search) + resource (US telephone area codes) + method (by code number or state name). Clearly distinguishes from siblings like fetch_zipcodes and fetch_states by specifying 'telephone area codes' and 'US' scope.

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

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

Provides explicit guidance on optional parameter usage: 'Omit search to get all area codes.' However, lacks explicit when-not-to-use guidance or comparison to similar geographic lookup tools like fetch_states or fetch_zipcodes.

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 valuable context beyond annotations: specifies time granularity (monthly/yearly), aggregation method (totals/aggregated), and data sources (transactions and transfers). Annotations cover safety profile (readOnly/idempotent), so description appropriately focuses on data semantics.

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

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

Two efficient sentences with zero waste. First sentence establishes core purpose and time scope; second clarifies aggregation method and data sources. Perfectly 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?

Appropriate for a zero-parameter read tool with full annotation coverage. Describes what data is returned (aggregated monthly/yearly totals) despite lack of output schema. Could improve by mentioning return format or pagination, but sufficient for complexity level.

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

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

Input schema has 0 parameters, establishing baseline of 4 per scoring rules. Description correctly focuses on return value semantics rather than non-existent parameters.

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

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

Specific verb (Get) + resource (billing consumption totals) + scope (monthly/yearly). Distinguishes from siblings fetch_billing_transactions and fetch_data_transfer by specifying 'aggregated' totals vs individual transactions/transfers.

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 implied usage context by specifying aggregation level ('aggregated usage data' from transactions/transfers), suggesting when to use this vs detailed sibling tools. However, lacks explicit when-not-to-use guidance or named alternatives.

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

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

Annotations declare read-only, idempotent, and non-destructive traits. The description adds valuable behavioral context not in annotations: default sorting ('newest first') and payload structure hints ('invoices, amounts, and status'). 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?

Two sentences with zero waste. The first sentence front-loads the action and return payload; the second provides sorting behavior. Every clause earns its place.

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

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

For a zero-parameter read operation with rich annotations, the description adequately compensates for the missing output schema by listing return fields. Minor gap: it doesn't mention pagination behavior or historical limits, which are common considerations for transaction listing endpoints.

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

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

Zero parameters present. Per rubric, 0 params = baseline 4. The description correctly requires no parameter clarification, though it implies the operation requires no filters to retrieve 'all' transactions.

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') with a clear resource ('billing transactions') and scope ('all... for your account'). It distinguishes from siblings like fetch_wallet_transactions and fetch_billing_consumptions by specifying the content type ('invoices, amounts, and status').

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 through specificity about what data is returned, but lacks explicit when-to-use guidance or named alternatives (e.g., it doesn't clarify when to use fetch_billing_consumptions vs this tool). Agents must infer applicability from the resource name.

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 valuable behavioral context beyond annotations: it specifies the return payload structure (dates, times, location, status) since no output schema exists, and provides critical DISPLAY RULES about UUID handling that annotations don't cover. No contradictions with readOnlyHint/destructiveHint 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?

Three tightly constructed sentences with zero waste: first establishes purpose, second describes output fields, third provides display constraints. Information is front-loaded with the core action.

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 operation with good annotations, the description adequately covers return value structure and presentation constraints. Minor gap in not mentioning pagination or relationship to singular 'get_calendar_event', but display rules compensate for output schema absence.

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

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

Input schema contains zero parameters, establishing baseline 4 per scoring rules. The description appropriately focuses on return values and display behavior rather than inventing parameter documentation.

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 specific verb 'Get' with clear resource 'all calendar events' and scope 'for your account'. The plural 'events' and word 'all' effectively distinguish it from sibling 'get_calendar_event' (singular), though it doesn't explicitly name the singular alternative.

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

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

No explicit when-to-use guidance is provided versus alternatives like 'get_calendar_event' (singular) or filtering patterns. The description states it gets 'all' events but doesn't clarify if this is appropriate for large datasets or when to use the single-event retrieval instead.

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

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

Annotations cover read-only/destructive/idempotent status. The description adds pagination specifics (20 per page), return value characteristics (summary info only), and a critical display constraint (NEVER show tokens/UUIDs) that isn't captured in structured 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?

Four compact sentences with zero waste: purpose/pagination, alternative tool reference, filtering capabilities summary, and display rule. Information is front-loaded and every sentence earns its place.

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

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

Without an output schema, the description adequately compensates by clarifying that only summary info is returned and directing to get_ticket for full details. It covers pagination behavior and security constraints, though it could briefly mention what fields are included in the summary.

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

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

With 100% schema description coverage, the schema already fully documents all parameters including valid platforms, priority levels, and pagination defaults. The description repeats this information without adding significant semantic depth beyond what's in the schema.

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

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

The description opens with 'Get closed/resolved support tickets,' providing a specific verb and resource. It clearly distinguishes from sibling fetch_open_tickets by specifying 'closed/resolved' and from get_ticket by clarifying this returns summaries only versus full 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?

Explicitly names the alternative tool with specific conditions: 'use get_ticket with the case number to get full ticket details including notes, files, and collaborators.' This clearly guides when to use each 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 declare readOnly/idempotent safety properties, while the description adds crucial behavioral details not present in structured data: the 10-result limit, bilingual naming (English/Spanish), and the specific behavior when omitting the search parameter. 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?

Two tightly written sentences with zero waste. Front-loaded with the primary action (search), followed by return characteristics (limit and languages), and closes with the empty-parameter behavior. Every clause earns its place.

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

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

For a simple read-only lookup tool with strong annotations and no output schema, the description is appropriately complete. It describes the return volume and localization aspects. It could potentially describe the return structure (objects vs strings), but given the tool's simplicity and the sibling pattern, the current level is 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?

With 100% schema description coverage, the schema already fully documents the search parameter including examples (+34, US) and optionality. The description paraphrases this ('international dial code' vs 'dial code') but adds no new semantic information beyond the schema, meeting the baseline for high-coverage schemas.

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 uses specific verb 'Search' with resource 'countries' and clearly defines scope (by name, international dial code, or ISO abbreviation). It effectively distinguishes itself from sibling tools like fetch_states and fetch_areacodes through explicit resource naming.

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 for when to omit the parameter ('Omit search to get all countries'), indicating the tool functions as a full listing when unfiltered. While it doesn't explicitly state 'do not use for US states' vs fetch_states, the resource specificity makes the intended usage clear without explicit exclusion statements.

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

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

Annotations already declare read-only, idempotent, non-destructive nature. The description adds valuable behavioral context by disclosing what data is returned (bytes, payment status, rates), which compensates for the missing output schema. It also clarifies the dependency on fetch_sweepstakes for token acquisition.

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

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

Two sentences with zero waste. First sentence front-loads the action and return payload; second sentence provides the prerequisite. Every word earns its place with no redundancy.

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

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

For a single-parameter read operation with rich annotations, the description is complete. It compensates for the missing output schema by detailing the specific record fields returned, and explains the parameter sourcing. No additional detail needed given 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?

Schema coverage is 100%, establishing a baseline of 3. The description adds semantic value by explaining how to obtain the sweepstakes_token ('Use fetch_sweepstakes first'), providing workflow context beyond the schema's type/format description.

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

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

The description uses specific verb 'Get' with clear resource 'data transfer records' and distinguishes from siblings by specifying unique return data (bytes transferred, payment status, rates). It also scopes the operation to 'a specific sweepstakes', differentiating it from generic list operations.

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 the prerequisite workflow: 'Use fetch_sweepstakes first to get the sweepstakes_token.' This provides clear sequencing guidance relative to the sibling fetch_sweepstakes tool. Lacks explicit 'when not to use' guidance, but the prerequisite instruction effectively defines the entry point.

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 pagination behavior and search scope (title or content) beyond annotations. Does not contradict safety annotations (readOnlyHint: true aligns with 'Get'). Could elaborate on document format or error behavior.

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

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

Three well-structured sentences: purpose first, capabilities second, limits third. No redundancy or filler. Efficient information density.

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

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

Adequate for low complexity (3 simple params, no nesting). Mentions return volume (10 docs) compensating somewhat for missing output schema. Good annotations reduce description burden appropriately.

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. Description maps 'pagination' to page/limit params and 'search' to search param without adding significant new semantic details beyond the schema descriptions.

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

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

Clear verb ('Get') and resource ('help and support documentation articles'). Domain clearly distinguishes from operational siblings like fetch_notes or fetch_groups, though explicit differentiation is absent.

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?

Implies usage through capabilities mentioned (pagination, search by title/content), but lacks explicit when-to-use guidance or comparison to alternatives like internal knowledge bases.

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 sorting behavior (creation date, newest first) and display constraints (NEVER show UUID tokens to users) beyond annotations. Mentions specific return fields (storage usage, categories) helping compensate for missing output schema.

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

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

Three efficient statements: purpose with features, sorting behavior, and display rule. No waste. Front-loaded with core action. ALL CAPS display rule appropriately emphasizes critical constraint.

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?

Good coverage for simple 2-param tool with rich annotations. Mentions key return fields (storage, categories) to compensate for missing output schema. Could clarify pagination defaults beyond schema descriptions.

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 has 100% coverage (page number, files per page). Description mentions 'pagination' conceptually but adds no syntax/format details beyond schema. Baseline 3 appropriate when schema does heavy lifting.

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

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

Specific verb 'List' + resource 'files in the user's Drive' with clear scope (storage usage, categories, pagination). Distinguishes from siblings like delete_file, upload_file, and fetch_notes/groups via resource specificity.

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

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

Clear read-only context from verb 'List' and annotation readOnlyHint=true, but lacks explicit when-to-use guidance versus alternatives (e.g., when to use fetch_files vs send_file or upload_file).

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?

While annotations cover safety profile (readOnly/idempotent), description adds crucial behavioral context: the DISPLAY RULE about never showing UUIDs to users and the business purpose of groups ('organize and segment participants').

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

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

Four sentences with zero waste: purpose (sentence 1), prerequisite (sentence 2), business context (sentence 3), and display constraints (sentence 4). Information is front-loaded and logically ordered.

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

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

For a simple read-only fetch with one parameter, the description is complete: it covers purpose, prerequisites, business context, and critical presentation rules. No output schema exists, but the display rule sufficiently guides result handling.

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 has 100% description coverage for the single parameter. Description mentions the parameter in the usage workflow but does not add semantic detail beyond the schema's 'UUID format' specification, meeting the baseline for high-coverage schemas.

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 opens with specific verb 'Get' + resource 'groups' + scope 'from a sweepstakes', clearly distinguishing it from sibling mutation tools like create_group, 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 states prerequisite workflow: 'Use fetch_sweepstakes first to get the sweepstakes_token', providing clear dependency guidance for proper tool chaining.

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 valuable behavioral context beyond annotations: automatic decryption (security) and reverse chronological ordering (sorting). Also includes presentation constraints about UUID handling. Does not contradict readOnly/destructive 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?

Three well-structured sentences with zero waste: core function first, behavioral details second, display rules third. Every sentence provides distinct value not found in structured fields.

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

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

Despite no output schema, description infers return content via display rules (titles, content, dates) and specifies ordering. Missing only pagination details or explicit return type documentation, which would be ideal for 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?

Zero parameters present, meeting the baseline of 4. The description appropriately requires no parameter explanation since the schema is empty.

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?

Clear specific verb ('Get') + resource ('notes') + scope ('all notes for your account'). The 'all' effectively distinguishes from sibling 'get_note' (singular) and other CRUD operations like 'create_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?

Implicitly guides usage through scope ('all notes'), distinguishing from single-note retrieval. However, it does not explicitly name the sibling alternative (get_note) or state when to prefer filtering over fetching all.

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 cover read-only/idempotent safety profile, while the description adds valuable behavioral context: pagination specifics (20 per page), return type distinction (summary vs full), and critical display constraint ('NEVER show tokens (UUIDs) to the user'). Does not mention rate limits or auth requirements, preventing a perfect score.

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

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

Four tightly constructed sentences with zero waste. Front-loaded with core action, followed by usage guidance, filtering capabilities, and security rules. Each sentence earns its place with specific, actionable information.

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

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

Given no output schema, the description adequately covers the tool's behavior, pagination, filtering options, and relationship to sibling tools. Mentions case numbers are returned (implied by reference to using them with get_ticket). Could enhance by explicitly listing what fields are included in the 'summary' return type.

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

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

With 100% schema description coverage, the baseline is 3. The description mirrors the schema by listing filterable fields (platform, priority) but does not add semantic depth beyond the schema's documentation (e.g., no examples, format guidance, or cross-parameter dependencies).

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 opens with specific verb 'Get' and resource 'open support tickets', clearly distinguishing from sibling fetch_closed_tickets via the 'open' specifier. The first sentence establishes pagination and search capabilities, precisely defining the tool's scope.

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

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

Explicitly states 'Returns summary info only — use get_ticket with the case number to get full ticket details', providing clear guidance on when to use this tool versus the sibling get_ticket. This directly addresses the tool's limitations and redirects to the appropriate alternative for full 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?

Beyond annotations (read-only, idempotent, non-destructive), the description adds pagination behavior (20 per page), sorting rules (creation date, newest first), and critical UI constraints ('NEVER show tokens to the user').

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?

Seven sentences each earn their place: purpose, prerequisite, capabilities, sorting, alternative, data integrity, and display rules. Well-structured and front-loaded with the core action.

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 output schema, the description adequately explains return characteristics (paginated, sorted) and includes essential handling rules for sensitive data (token masking), making it complete for a list-fetching 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 establishing a baseline of 3, the description adds valuable context for 'sweepstakes_token' (prerequisite tool), clarifies search scope ('name, email, or phone'), and explains date filtering intent.

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

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

The description opens with a specific verb ('Get') and resource ('paginated list of participants from a sweepstakes'), clearly distinguishing it from sibling 'get_participant' which provides 'full participant details' for a specific record.

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 prerequisites ('Use fetch_sweepstakes first to get the sweepstakes_token'), clear alternative selection criteria ('For full participant details, use get_participant'), and operational constraints ('NEVER fabricate...').

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, destructiveHint, and idempotentHint. Description adds valuable context about data composition ('primary and secondary rules') and operational workflow (prerequisite call), but does not disclose error behaviors, rate limits, or return structure.

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

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

Two sentences with zero waste: first states purpose and data scope, second states prerequisite. Information is front-loaded and every sentence earns its place.

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

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

For a single-parameter read operation with strong annotations, the description is nearly complete. It covers the resource model (primary/secondary rules) and dependencies. Minor gap: does not hint at return value structure (array vs object) despite absence of 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?

With 100% schema coverage, baseline is 3. Description adds crucial semantic context that the sweepstakes_token must be obtained from fetch_sweepstakes first, which aids the agent in chaining tool calls correctly beyond what the schema UUID format indicates.

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 uses specific verb 'Get' with clear resource ('official rules for a sweepstakes') and scope ('all' including 'primary and secondary'). It distinguishes from sibling fetch_sweepstakes by establishing a dependency (need token from it first).

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 workflow guidance: 'Use fetch_sweepstakes first to get the sweepstakes_token.' This establishes clear prerequisites. Lacks explicit 'when not to use' or differentiation from mutation siblings (create_rule, update_rule), though verb differentiation makes this less critical.

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?

While annotations declare the read-only/idempotent safety profile, the description adds crucial behavioral context: sorting (creation date, newest first), scope (all regardless of status), and a critical DISPLAY RULE prohibiting token exposure to users—essential for correct agent behavior that isn't captured in annotations.

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

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

Four well-structured sentences progress logically from purpose → prerequisites → return behavior → display constraints. Every sentence earns its place with zero redundancy or filler.

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

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

For a simple single-parameter read operation with comprehensive annotations, the description is complete. It covers retrieval logic, sorting, token handling constraints, and prerequisite workflows—sufficient for correct invocation without an output schema.

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

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

With 100% schema coverage, the baseline is 3. The description adds value by contextualizing the sweepstakes_token parameter within the workflow ('Use fetch_sweepstakes first to get...'), clarifying data provenance beyond the schema's type/format documentation.

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

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

The description opens with the specific verb 'Get' followed by the resource 'all scheduled drawings' and scope 'for a sweepstakes', clearly distinguishing it from siblings like schedule_drawing (creation), delete_scheduled_drawing (deletion), and draw_winners (execution).

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 the prerequisite workflow ('Use fetch_sweepstakes first to get the sweepstakes_token'), providing clear sequencing guidance. However, it does not explicitly state when to use alternatives like schedule_drawing vs this fetch tool, though the distinction is implied.

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

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

Annotations declare read-only, idempotent, non-destructive traits. The description adds valuable return value semantics ('Returns full names and two-letter abbreviations') and clarifies the complete dataset scope (including territories) that annotations don't 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?

Two well-structured sentences: first defines scope/operation, second defines return format. Zero redundant words. Information density is high relative to tool complexity.

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

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

Despite lacking an output schema, the description adequately compensates by specifying the return format (full names + abbreviations). For a simple static-data retrieval tool with strong annotations, this is 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?

Input schema has zero parameters, establishing a baseline of 4. The description correctly omits parameter discussion since none exist, focusing instead on return value semantics.

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

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

Description uses specific verb 'Get' with clear resource scope ('US states including DC, Puerto Rico, and US territories'). This effectively distinguishes it from siblings like fetch_countries (global scope) and fetch_areacodes/zipcodes (different data types).

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

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

While it doesn't explicitly name alternatives, the scope definition ('US states including territories') provides clear contextual boundaries that implicitly guide when to use this vs fetch_countries or other fetch_* tools. No explicit exclusions or prerequisites are stated.

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

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

Beyond annotations declaring read-only/idempotent safety, the description adds crucial behavioral constraints: the DISPLAY RULE about hiding UUIDs from users while using them internally for chaining, and the fact that it returns a list with details. 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?

Three sentences with zero waste: purpose declaration, return value specification, and critical presentation constraint. Front-loaded with the essential verb and resource, followed by behavioral rules that prevent UI errors.

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 operation, the description is complete: it specifies the resource scope, return type (list with details), and critical UX constraints regarding token handling that would otherwise be undefined given the lack of 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?

With zero input parameters, the baseline score applies per rubric guidelines. The description correctly requires no additional parameter clarification since the schema is trivially complete (empty object).

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

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

The description opens with a specific verb ('Get') + resource ('sweepstakes') + scope ('associated with your account'), clearly distinguishing this from sibling mutation tools (create_sweepstakes, update_sweepstakes) and specific-item getters.

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?

While it doesn't explicitly name alternatives, stating 'Get all sweepstakes' clearly signals this is a bulk listing operation versus single-item fetchers (e.g., get_participant) or management tools, providing clear contextual scope without exclusions.

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

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

Annotations declare readOnly/idempotent/destructive hints, so description focuses on adding data structure context (IANA identifiers, abbreviations, offsets) and critical fallback behavior (TimezoneId 7 default). Does not contradict annotations and adds actionable operational protocol.

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 total, each earning its place: (1) purpose/data content, (2) usage trigger, (3) default fallback. Front-loaded with core action, no redundancy or filler despite covering operational defaults.

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

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

No output schema exists, so description compensates by describing returned data structure (IANA identifiers, etc.). Absence of formal output schema is partially mitigated, though it could explicitly state the return type (list/array). Sufficient for a simple lookup tool with zero 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?

Input schema contains zero parameters. Per scoring rules, zero-parameter tools receive baseline score of 4. Description appropriately does not invent parameters where none exist.

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 opens with specific verb 'Get' + resource 'timezones' and enumerates exact data fields returned (IANA identifiers, abbreviations, UTC offsets). Clearly distinguishes from sibling fetch_* tools by specifying timezone-specific data formats.

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 instruction ('whenever a timezone needs to be determined for any operation') and includes specific fallback logic ('DEFAULT: If the correct timezone cannot be determined, always use TimezoneId 7'). This operational guidance exceeds basic usage hints.

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 critical behavioral context beyond annotations: admin privilege requirements, specific error modes (403), pagination size (20/page), and output handling constraints ('Never display tokens (UUIDs)'). These auth and display rules are not inferable from annotations or schema, significantly enhancing the agent's understanding of runtime 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?

Three sentences each earning their place: purpose declaration, authorization warning, and display constraint. Uses structural formatting (ALL CAPS labels) to separate distinct concerns. No redundant or filler text; front-loaded with the primary action.

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 given the constraints: covers auth, pagination, filtering, and output display rules despite absence of output schema. Missing only a description of return value structure (list of todo objects), though 'Get all To-Do items' implies the collection nature. Sufficient for correct agent invocation given rich annotations and complete input 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?

With 100% schema description coverage, the schema carries the full load of parameter documentation. Description categorizes parameters as 'advanced filters' but adds no syntax details, validation rules, or semantic relationships (e.g., month requiring year) beyond what the schema already provides. Baseline score appropriate when schema is comprehensive.

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 opens with specific verb 'Get' and resource 'To-Do items', clearly distinguishing from sibling mutation tools (create_todo, update_todo, delete_todo). Explicitly scopes functionality with 'pagination (20 per page), search, and advanced filters', leaving no ambiguity about the tool's read-only list 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 states 'ADMIN ONLY' prerequisite and warns that 'Non-admin users will receive a 403 Forbidden error', providing clear authorization constraints. Lacks explicit comparison to singular getter alternatives (e.g., get_note vs fetch_notes pattern in siblings), though the fetch prefix convention is consistent with other list operations in the toolset.

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 operation as read-only, idempotent, and non-destructive. The description adds value by disclosing the transaction types included (credits, debits, payment details) but does not mention pagination behavior, result ordering, or time-range limitations.

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, efficient sentence that front-loads the action and resource. The phrase 'including credits, debits, and payment details' earns its place by clarifying the data scope 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?

With no output schema provided, the description partially compensates by listing transaction content types but fails to describe the return structure, format, or whether results are paginated. Given the simple, parameter-less nature of the tool, this is adequate but incomplete.

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

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

The input schema contains zero parameters. Per scoring guidelines, 0 parameters establishes a baseline score of 4. The description correctly implies no filtering is required by stating 'Get all wallet transactions'.

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 wallet transactions and specifies the content scope (credits, debits, payment details). However, it does not explicitly differentiate from the sibling tool 'fetch_billing_transactions', which could cause confusion about which financial transaction tool to use.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'fetch_billing_transactions' or 'fetch_billing_consumptions'. No prerequisites, filtering capabilities, or usage constraints are mentioned.

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

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

Adds significant behavioral context beyond annotations: sorting order (draw date, most recent first), search filter scope (email or phone), and critical DISPLAY RULE about token masking. Annotations cover safety (readOnly/idempotent) but description adds UI/UX constraints and data handling rules.

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

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

Four sentences with zero waste: purpose front-loaded, followed by prerequisite chain, behavioral details (sorting/search), and display rule. Every clause provides unique value not replicated in structured fields.

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

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

Strong coverage for a read operation with good annotations and complete input schema. Mentions specific return fields (names, emails, draw dates) in display rule context, though could explicitly document full return structure since no output schema exists.

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%, establishing baseline 3. Description maps conceptual features (pagination, search) to parameters but does not add syntax details, validation rules, or format examples beyond the schema definitions.

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

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

Specific verb-resource combination ('Get winners from a sweepstakes') with clear scope (pagination). Distinguishes from sibling fetch_sweepstakes by requiring that tool's output token (sweepstakes_token), establishing the correct chain.

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 prerequisite stated ('Use fetch_sweepstakes first to get the sweepstakes_token'). Describes when to use via sorting and search capabilities. Lacks explicit differentiation from draw_winners sibling (does not state 'use this to retrieve existing winners, not to generate new ones').

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 cover safety profile (readOnly, idempotent, non-destructive). The description adds valuable behavioral constraints not in annotations: the 10-result limit and the specific return payload details ('city and state details'). This helps the agent understand output cardinality and content.

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

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

Two efficient sentences with zero waste. First sentence covers input capabilities, second covers output constraints and content. Information is front-loaded and appropriately sized for a single-parameter lookup tool.

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 low complexity (1 parameter, flat structure, no output schema), the description is complete. It covers the search domain, input flexibility, result cardinality limit, and return data contents. The annotations adequately cover operational safety aspects.

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

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

With 100% schema description coverage, the schema already fully documents the 'search' parameter ('Search term: zip code, city name, or state name'). The description reinforces these acceptable input types but does not add semantic meaning beyond what the schema provides, warranting the baseline score.

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 provides specific verb ('Search'), resource ('US zip codes'), and scope ('by zip code, city, or state name'). The specificity of 'US zip codes' clearly distinguishes this tool from siblings like fetch_areacodes, fetch_states, and 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?

While no explicit alternatives are named, the description provides clear contextual differentiation through specificity ('US zip codes' vs other geographic entities). An agent can easily infer when to use this versus fetch_areacodes or fetch_states based on the resource being sought.

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 declare readOnlyHint, idempotentHint, and destructiveHint, covering safety and mutation behavior. The description adds value by disclosing the semantic content of the return value ('company details, address, and business settings') since no output schema exists. It does not mention rate limits, caching, or the 'openWorld' nature of the call.

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

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

The description consists of two efficient sentences with zero redundancy. The first sentence establishes the operation and scope, while the second sentence immediately describes the return payload, respecting the front-loaded structure principle.

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 (no parameters) and rich annotations covering behavioral traits, the description is nearly complete. It compensates for the missing output schema by describing the returned data structure. A minor gap remains regarding the implicit 'current authenticated account' scope limitation.

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 contains zero parameters. Per the evaluation rules, this establishes a baseline score of 4. The description correctly does not invent parameters, maintaining consistency with the empty schema.

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

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

The description clearly states the verb (Get) and resource (business information/company details) and lists specific return fields (address, settings). However, it does not explicitly differentiate from the sibling tool `get_profile`, which could confuse agents about whether to use this for user profile data vs. business account data.

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

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

The description provides no guidance on when to use this tool versus alternatives like `get_profile` or `get_plan`. It also fails to clarify that this tool retrieves data for the currently authenticated account only (implied by zero parameters), which is critical context given siblings like `get_participant` likely require specific IDs.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds workflow context (token provenance) but does not disclose return format, error cases, or rate limits beyond what structured fields 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?

Two sentences with zero waste: first establishes purpose, second provides prerequisite instruction. Front-loaded and appropriately sized for a single-parameter read operation.

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 getter with 100% schema coverage, rich annotations (4 hints), and clear sibling differentiation, the description provides sufficient context despite lacking an output schema.

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

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

Schema coverage is 100% with complete parameter documentation. The description reinforces the token parameter and adds context about where tokens originate, meeting the baseline for well-documented schemas.

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

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

The description states the specific action ('Get'), resource ('calendar event'), and lookup method ('by its token'), clearly distinguishing it from sibling fetch_calendar_events which returns multiple events.

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

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

Explicitly states the prerequisite workflow: 'Use fetch_calendar_events first to get event tokens,' providing clear guidance on when to use this tool versus its list-fetching sibling.

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

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

While annotations cover safety profile (readOnly, idempotent, destructive), the description adds crucial behavioral context about return values ('Returns field names, types, and whether they are required') which compensates for the missing output schema.

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

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

Three sentences with zero waste: purpose statement first, prerequisites/workflow second, return value disclosure third. Every sentence earns its place with high information density.

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

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

Given the simple single-parameter input and rich annotations, the description achieves completeness by documenting the return structure (compensating for no output schema) and mapping the tool's role in the sweepstakes entry workflow.

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 baseline is 3. The description adds semantic value by explaining where the sweepstakes_token originates ('Use fetch_sweepstakes first to get...'), providing provenance context beyond the schema's type/format documentation.

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

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

The description opens with a specific verb ('Get') and resource ('form fields for a sweepstakes entry page'), clearly distinguishing it from generic field getters and sibling tools like fetch_sweepstakes or add_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?

Provides explicit workflow sequencing: 'Use fetch_sweepstakes first to get the sweepstakes_token' establishes prerequisites, and 'Call this before add_participant to discover required fields' clarifies when to use this tool versus its sibling.

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

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

Annotations already establish read-only, non-destructive, idempotent behavior. The description adds valuable behavioral context: a detailed enumeration of what configuration is returned (colors, AMOE, geolocation, etc.) and the critical DISPLAY RULE about token handling. Does not mention rate limits or caching, but covers the essential operational 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?

Four sentences each serving distinct purposes: (1) purpose definition, (2) prerequisite workflow, (3) return value specification, (4) usage sequence and security rule. No redundancy despite covering 14+ configuration categories in the return description.

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 output schema, the description comprehensively details the return payload (listing all configuration categories). Combined with annotations covering safety properties and explicit workflow guidance, the description provides complete context for 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, the baseline is 3. The description elevates this by adding the DISPLAY RULE about never showing the UUID token to users, which adds crucial semantic meaning about parameter handling and security beyond the schema's type definition.

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

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

The description opens with a specific verb-resource pair ('Get entry page settings for a sweepstakes') and clearly distinguishes this from siblings: it references fetch_sweepstakes (prerequisite) and update_entry_settings (write counterpart), while the resource name differentiates it from get_entry_fields.

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

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

Provides explicit prerequisites ('Use fetch_sweepstakes first'), workflow sequencing ('Use this before update_entry_settings'), and a security constraint ('DISPLAY RULE: Never display tokens...'). The guidance covers when to use it and how to handle sensitive 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?

Adds critical context beyond annotations: 'note content is automatically decrypted' reveals a transformation behavior not indicated elsewhere. Also provides security constraint 'DISPLAY RULE: Never display tokens...' which governs output handling. No contradiction with readOnly/destructive hints.

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

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

Four sentences each earn their place: (1) core purpose, (2) prerequisite workflow, (3) decryption behavior, (4) security rule. No redundancy, appropriately front-loaded, zero wasted words.

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

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

For a single-parameter read tool with good annotations covering safety, the description adequately covers purpose, prerequisites, decryption behavior, and security constraints. Absence of output schema is mitigated by the decryption disclosure.

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%, documenting note_token as a UUID. Description references the token but adds no format, syntax, or semantic details beyond the schema. The workflow hint ('Use fetch_notes first') is usage guidance, not parameter semantics.

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

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

Description opens with specific verb 'Fetch' + resource 'single note' + scoping 'by its token'. Clearly distinguishes from sibling 'fetch_notes' (list operation) by specifying 'single' and referencing the sibling as a prerequisite.

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 workflow guidance: 'Use fetch_notes first to get the note_token' provides clear prerequisite and ordering relative to sibling tool. Also distinguishes from mutating siblings (create_note, update_note, delete_note) by being a read operation.

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?

While annotations declare read-only/idempotent status, the description adds crucial LLM-specific behavioral constraints: anti-hallucination rules ('NEVER fabricate, invent, or hallucinate'), empty result handling ('report exactly that — do not guess'), and security/display protocols ('NEVER show tokens (UUIDs) to the user'). These are high-value behavioral disclosures beyond the structured 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?

Despite multiple sentences, every clause earns its place: purpose, validation constraint, prerequisites, sibling alternatives, anti-hallucination guardrails, null-handling, and display rules. Information is front-loaded with the core action, followed by operational constraints and behavioral guidelines in a logical progression.

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 lookup tool with 4 parameters and no output schema, the description is remarkably complete. It covers input validation, workflow prerequisites, sibling distinctions, error handling (empty results), and presentation layer requirements. No gaps remain that would impede correct agent 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, the baseline is 3. The description adds valuable semantic grouping by labeling email/phone/participant_token as 'search parameters' and stating the validation constraint 'At least one search parameter is required,' clarifying the logical OR relationship that the schema's required array doesn't fully express.

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

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

The description opens with a specific verb ('Fetch') and resource ('participant'), clarifying this retrieves a single record (not a list) and specifying the lookup methods ('by token, email, or phone'). It effectively distinguishes from sibling tools by contrasting with 'fetch_participants' for listing.

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 prerequisites ('Use fetch_sweepstakes first to get the sweepstakes_token') and provides a direct alternative ('For listing participants, use fetch_participants instead'). This creates clear decision boundaries for when to select this tool versus siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context by specifying exactly what data is returned (pricing, limits, features, usage), which compensates for the missing output schema. 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?

Two efficiently structured sentences with zero waste: first declares purpose, second declares return value. Every word earns its place.

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

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

Given zero parameters and strong annotations, the description is nearly complete. It effectively compensates for the missing output schema by listing the specific data categories returned (pricing, limits, features, 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?

Tool has zero parameters, which per rubric establishes a baseline of 4. No parameter documentation is required.

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

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

Description uses specific verb 'Get' with clear resource 'plan details' and domain context 'Sweeppea subscription'. It clearly distinguishes from siblings like get_business, get_profile, or get_participant by specifying the plan/pricing domain.

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?

Description provides no explicit guidance on when to use this tool versus alternatives (e.g., when to use get_plan vs get_business), nor does it mention prerequisites like requiring an active subscription 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 cover safety profile (readOnly, idempotent, non-destructive). Description adds valuable behavioral context by specifying return payload contents (name, email, account settings), which is essential given the lack of an output schema. Does not mention rate limits or side effects, but covers the critical gap of what data is retrieved.

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

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

Two sentences with zero waste: first defines the operation and domain, second specifies return values. Information is front-loaded and appropriately sized for the tool's simplicity.

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 appropriately compensates by listing representative return fields (name, email, account settings). Annotations provide safety metadata. Minor gap: could clarify if this retrieves the authenticated user's profile or allows fetching arbitrary users, though empty schema implies current 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?

Zero parameters present. Per rubric guidelines, zero-parameter tools receive baseline score of 4. Description correctly implies no inputs are needed to retrieve the current user's profile.

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

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

Specific verb 'Get' + resource 'user profile information' + scope 'Sweeppea account' clearly identifies the tool's function. Distinguishes from siblings like get_business (organization), get_participant (sweepstakes entrant), and get_ticket (support) by specifying 'user profile' for the account holder.

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?

Description provides no guidance on when to use this tool versus alternatives (e.g., get_business for company details) or prerequisites such as authentication requirements. No 'when-not' exclusions or workflow context 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 cover the safety profile (readOnly, idempotent), but the description adds valuable behavioral context: it lists the specific data returned (notes, files, collaborators, statistics) and provides critical display rules about hiding UUIDs and showing only human-readable fields.

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

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

Three tightly structured sentences each serve distinct purposes: (1) definition, (2) workflow guidance, (3) presentation constraints. No redundancy or filler; information density is high.

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 (single param, read-only) and strong annotations, the description is nearly complete. It compensates for the lack of output schema by enumerating the returned data categories and adds UI-level constraints rarely seen in tool descriptions.

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

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

With 100% schema description coverage for the single 'case_number' parameter, the schema already fully documents the input. The description mentions 'case number' but doesn't add semantic detail beyond the schema, which is acceptable given the high coverage baseline.

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

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

The description opens with a specific verb ('Get') + resource ('full details of a support ticket') + identifier method ('by case number'), clearly distinguishing this single-ticket retrieval from sibling list operations like fetch_open_tickets.

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

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

Explicitly prescribes the workflow: 'Use fetch_open_tickets or fetch_closed_tickets first... then use this tool,' directly naming the sibling discovery tools and establishing clear sequencing guidance.

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

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

Annotations declare readOnly/idempotent/safe properties. The description adds valuable behavioral context beyond annotations: specifically that it validates API key correctness and tests credential functionality, which helps the agent understand the specific validation logic performed.

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

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

Two sentences with zero waste. First sentence establishes purpose (verify connection, validate key); second provides usage guidance (test credentials). Perfectly front-loaded and appropriately sized for the tool's simplicity.

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

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

Given zero parameters, rich annotations (readOnly, idempotent, destructive flags), and the tool's simple diagnostic nature, the description is sufficiently complete. Minor gap: does not describe return value format, though this is partially mitigated by the explicit validation purpose stated.

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

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

Input schema has zero parameters. Per calibration rules, zero-parameter tools receive a baseline of 4. The description appropriately requires no parameter explanation since the tool operates as a simple credential probe with no 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 uses specific verbs ('Verify', 'validate') with clear resources ('connection to Sweeppea API', 'API key'). It clearly distinguishes this diagnostic utility from the 60+ sibling CRUD and business logic tools (create_sweepstakes, add_participant, etc.).

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

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

Explicitly states when to use: 'Use this to test if your credentials are working correctly.' Provides clear context for credential validation scenarios. Lacks explicit 'when-not-to-use' or named alternatives, though none exist among siblings for this specific health-checking function.

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, establishing the safety profile. The description adds context that the output is a 'greeting message' (content type), but does not elaborate on response format, rate limits, or side effects 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?

Single sentence with zero waste. Every word earns its place: 'Returns' (verb), 'simple Hello World greeting message' (scope and content). Front-loaded and appropriately sized for a trivial utility tool.

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 low complexity (1 optional parameter, no nested objects), presence of comprehensive annotations, and absence of an output schema, the description is sufficient. For a basic greeting utility, stating what it returns is complete; no further behavioral details or return value documentation is necessary.

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

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

With 100% schema description coverage (the 'name' parameter is fully documented as optional), the baseline score is 3. The description itself does not mention parameters or provide examples, but relies entirely on the schema for parameter semantics, which is acceptable given the complete 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?

Specific verb ('Returns') and resource ('Hello World greeting message') clearly distinguish this utility function from the extensive list of business-logic siblings (create_sweepstakes, delete_participant, etc.). The description immediately communicates this is a simple greeting utility versus the complex CRUD operations available.

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?

Description provides no guidance on when to use this tool versus alternatives, nor does it indicate its typical use case (likely testing/health checks). Unlike the high-scoring example that explicitly named alternative tools, this description merely states what the tool does without contextual usage guidance.

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

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

Annotations cover technical safety (destructive=false, idempotent=true). Description adds valuable business logic beyond annotations: confirms data preservation, specifies 'inactive status' state change, and discloses participant entry blocking—critical behavioral context for agent decision-making.

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, zero waste. Front-loaded with core action ('Pause a sweepstakes...'), followed by prerequisite, then behavioral impact. Each sentence serves a distinct 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?

Given single-parameter simplicity and comprehensive annotations, description is complete. Covers action, data safety, prerequisites, and business effects. No output schema exists, but none is needed for this state-change operation.

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

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

Schema coverage is 100% so baseline is 3. Description adds workflow context for the sweepstakes_token parameter by instructing agents to fetch it first, providing usage semantics beyond the schema's type definition.

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?

Excellent specific verb ('Pause') + resource ('sweepstakes') combination. Distinguishes from siblings by specifying 'inactive status' (vs unpause_sweepstakes), 'preserving all data' (vs delete_sweepstakes), and temporary nature (vs update_sweepstakes).

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

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

Provides explicit prerequisite workflow ('Use fetch_sweepstakes first to get the sweepstakes_token'). Explains clear behavioral outcome ('Participants will not be able to enter while paused'), giving agents the context to know when this tool is appropriate.

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

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

Annotations cover safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true). Description adds valuable workflow context about prerequisites but does not elaborate on side effects like notifications or status transition 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?

Two sentences with zero waste: first establishes purpose, second provides prerequisite. Efficiently front-loaded and appropriately sized for the tool's complexity.

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

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

Given the single parameter, complete schema coverage, and presence of annotations, the description adequately covers the tool's functionality. Slight deduction for not clarifying the difference between 'close' and 'resolve' or mentioning return behavior despite lacking 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 coverage is 100% with complete case_id documentation including format example. Description references the parameter in the usage instruction but does not add semantic meaning beyond what the schema already provides, warranting the baseline score.

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 provides specific verbs ('Close/resolve') and resource ('open support ticket'), clearly distinguishing from siblings like create_ticket, update_ticket, and fetch_closed_tickets by specifying the 'open' state and resolution 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?

Explicitly states the prerequisite workflow: 'Use fetch_open_tickets first to get the case_id', providing clear sequencing guidance and implicitly defining when to use this tool over others.

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