socialloop-mcp

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

The description discloses important side effects: sends an invite email, creates a tracked code on acceptance, and counts against the affiliate plan cap. Annotations only show readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the description adds value beyond these by detailing behavior.

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

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

The description is concise (a few sentences) and front-loaded with the primary action. Every sentence adds value, though it could be structured better (e.g., separate prerequisite from side effects) and the parameter list could be more explicit.

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

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

The description covers purpose, prerequisites, side effects, and capacity constraints. However, it does not mention the return value (e.g., success status or invite ID) and only partially explains parameters. Given no output schema, the return value omission is a notable gap.

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

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

Schema description coverage is 0%, meaning the description must explain parameters. It only mentions event_id, email, discount, and commission generically, but fails to explain starts_at, expires_at, code_prefix, and the type/value fields. With 9 parameters, this leaves significant gaps.

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 invites an affiliate/promoter to a live event via email with discount and optional commission. It uses a specific verb ('invite') and resource ('affiliate/promoter to a live event'), distinguishing it from sibling tools like 'add_affiliate_code' and 'bulk_invite_affiliates'.

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

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

The description specifies prerequisites ('Requires event_id + email; you must be a host') and mentions the action context. However, it lacks explicit guidance on when to use this over alternatives (e.g., bulk_invite_affiliates), though the naming and single invite nature imply the distinction.

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 are minimal (readOnlyHint=false, etc.), so the description carries the burden. It mentions the mutating action (adds tier to promo code) and an auth requirement (must be host), but lacks details on idempotency, side effects, or error conditions.

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

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

The description is only two sentences and front-loads the main action and requirements. Every sentence adds value, though it could be more structured.

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

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

With 7 parameters and no output schema, the description should explain the result of the operation (e.g., what happens to the promo code) and provide more parameter context. It only gives a high-level overview, leaving gaps for the agent.

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

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

Schema description coverage is 0%. The description only mentions 'event_id + affiliate_id + ticket_class_id + discount' but does not explain the meaning of discount_type, discount_value, commission_type, or commission_value, nor does it clarify the enum values.

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

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

The description clearly states it extends an affiliate to another ticket tier, which aligns with the title 'Add Affiliate Code'. However, the verb 'extend' differs slightly from 'add', and there is no explicit mention of the resource being a promo code, but it's implied.

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 lists required fields and a prerequisite (host), but provides no guidance on when to use this tool versus alternatives like update_affiliate_commission or create_promo_code, which are in the sibling list.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds behavioral context: 'each code inherits the profile's discount and becomes immediately redeemable' and 'duplicates skipped with a suggestion'. No contradictions. Describes the effect beyond the annotations.

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

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

The description is two sentences, front-loaded with the primary action. Every sentence adds value: first sentence states purpose and behavior, second adds constraints and prerequisites. No 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?

Given 5 parameters, 0% schema coverage, no output schema, the description covers the core action, constraints (max 500, duplicates), prerequisites (event_id, profile_id, host role), and behavioral aspects (inheritance, immediate redeemability). Could mention what is returned on success, but overall sufficient for an agent to use correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the relationship between codes, auto_generate, and code_prefix ('Give explicit codes and/or auto_generate a count (optional code_prefix)') and identifies required parameters (event_id, profile_id). However, it lacks explicit details on maxLength, format, or behavior for omitted parameters.

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

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

The description clearly states the tool's purpose: 'Attach or auto-generate promo codes under a discount profile'. It specifies the verb (attach/auto-generate), resource (promo codes under a discount profile), and distinct behavior (codes inherit profile discount, immediately redeemable). Differentiates from siblings like adopt_codes_to_profile or create_promo_code.

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

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

The description provides explicit usage context: 'Give explicit codes and/or auto_generate a count (optional code_prefix); max 500/call, duplicates skipped with a suggestion. Requires event_id + profile_id; you must be a host.' It states prerequisites and constraints, but does not explicitly differentiate from alternatives like adopt_codes_to_profile or bulk_create_promo_codes.

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

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

Discloses invitation process (email sent, join on accept) and role permissions. Annotations already indicate mutation (readOnlyHint=false) and non-destructive behavior. Adds value beyond annotations with invitation 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, front-loaded with main action. Each sentence adds value: purpose, role details, invitation flow, prerequisites. No redundant information.

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

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

Covers purpose, role options, invitation behavior, and prerequisites. Missing details like handling of already-host or non-live events, but sufficient for a simple invite tool. No output schema, so return info not expected.

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 0%, so description must compensate. It defines role semantics (producer vs co_host permissions) but does not describe event_id or email beyond necessity. Partially addresses the gap.

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

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

Clearly states the tool invites a co-host to a live event by email, differentiating roles (producer vs co_host). Distinct from siblings like add_guest or invite_team_member by specifying 'co-host' and 'live event'.

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

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

Provides context: requires event_id and that the caller must be a host. Implicitly contrasts with add_guest for adding a guest. No explicit when-not-to-use or alternatives, but clear enough for typical use.

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

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

The description adds behavioral context beyond annotations: it discloses the side effect of consuming invite quota and the host requirement. Annotations already indicate it's not read-only, so the description enriches transparency without contradiction.

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

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

The description is two sentences, direct and front-loaded. It lists parameters in the first sentence and adds constraints in the second. Every word is necessary and no filler.

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

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

Given 10 parameters, 2 required, and no output schema, the description covers the action, key parameters, and an important side effect. However, it omits output details (e.g., returns guest ID), does not clarify the separate first_name and last_name fields, and does not mention error conditions like duplicate guests or exceeded limits. Some gaps remain.

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

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

Schema description coverage is 0%, so the description must compensate. It lists most parameters (name, email, phone, category, plus-ones, note, tags, ticket tier) and gives an example for category, but it ambiguously says 'name' instead of separating first_name and last_name. It partially adds meaning beyond the schema but not fully.

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 'Add' and the resource 'guest to a live event's guest list', and lists the key fields. It is specific and distinct from sibling tools like add_event_host or add_talent.

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 context: it counts against the weekly invite limit, requires event_id, and that the user must be a host. It does not explicitly state when not to use it or compare with alternatives, but the prerequisites are clear.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds a behavioral requirement ('you must be a host') but does not disclose other behaviors like idempotency or duplicate handling. With annotations present, the description provides some added value.

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

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

The description is a single sentence with a list, efficiently conveying purpose and key fields. It is front-loaded but could be more structured (e.g., separate requirements). No 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 tool with 20 parameters and no output schema, the description lacks return value details, error conditions, and business rules beyond required fields and permission. It is insufficient for full contextual understanding.

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 0%, so the description must compensate. It mentions several parameters (name, category, status, priority, quantity, unit_cost, location, links) with enum examples for status. However, it omits many parameters (tags, phase, url, dimensions, etc.), leaving gaps.

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 adds a physical asset/gear item to a live event's inventory, listing key fields. It distinguishes from sibling tools like add_meal or add_guest by specifying 'inventory' and 'physical asset'.

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 notes required fields (event_id, name) and a prerequisite (must be a host), giving clear context for when to use. It does not explicitly mention when not to use or name alternatives, but the context is sufficient.

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

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

Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive. The description adds that authorization (must be a host) is required, but does not disclose details about side effects, idempotency, or what happens on duplicate calls. Overall, it adds moderate value beyond annotations.

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

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

The description is two sentences long, front-loaded with the action and requirements. Every part adds value: purpose, key fields, and prerequisites. No 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?

Given 14 parameters and no output schema, the description covers the core purpose and required params but lacks details on optional fields, return value, constraints on serve_at, or behavior when the event isn't live. It is adequate but not comprehensive.

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

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

With 0% schema description coverage, the description compensates by listing several parameters (kind, serve_at, title, status, etc.) and their meanings. However, it omits some fields like tags, notes, place_id, and the enum for kind is incomplete (missing brunch and late_night), so it only partially adds meaning.

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

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

The description clearly states the tool adds a meal to a live event's culinary plan, using a specific verb and resource. It lists key fields like kind, serve time, title, status, etc., distinguishing it from sibling tools like add_programming_item or add_schedule_item.

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

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

The description provides context by requiring event_id, kind, and serve_at, and notes that the user must be a host. However, it does not explicitly state when to use this tool over alternatives or when not to use it, lacking exclusion guidance.

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

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

The description indicates a mutable operation ('Add') but does not disclose additional behavioral traits such as whether duplicate names are handled, potential side effects on existing data, or required permissions beyond host status. Annotations are minimal and not contradicted.

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

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

The description is concise, using two sentences to convey the tool's purpose, key fields, requirements, and constraints. It front-loads the core action and resource, with no unnecessary words.

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

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

Despite the tool's complexity (13 parameters, no output schema), the description lacks information about return values, error handling, or how this tool interacts with others. It covers basic functional context but falls short for a comprehensive understanding.

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 0% schema description coverage, the description does not add meaning to individual parameters beyond listing a few field names in parentheses. The schema includes 13 parameters with constraints and enums, but the description provides no guidance on values or formats.

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

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

The description clearly states the action ('Add') and resource ('a place / location to a live event'), listing specific attributes (build site, zone, venue area) and key fields (name, structure, sector, etc.), making it distinct from sibling tools like add_guest or add_sponsor.

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

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

The description specifies required parameters ('Requires event_id + name') and a necessary condition ('you must be a host'), providing clear context for usage, though it does not explicitly mention when not to use this tool or suggest 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 indicate write operation (readOnlyHint=false). Description adds auth requirement ('must be a host') and lists mutable fields, providing context beyond annotations. No contradictions.

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

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

Single sentence with front-loaded purpose and a comma-separated list of capabilities. Efficient but could be better structured for 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?

Provides overview and constraints but lacks detailed parameter descriptions. With 15 parameters and no output schema, the description offers a baseline but not full 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?

Despite 0% schema coverage, the description enumerates 8 of 15 parameters (title, status, types, duration, start time, linked talent/places, rider, production_needs) with examples. Adds meaning but not fully 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?

Clear verb 'Add' and specific resource 'programming item' with examples (workshop, performance, DJ set, ritual). Distinguishes it from generic sibling 'add_*' tools by specifying it's for live events and curated experiences.

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?

Specifies required parameters (event_id, title) and a key constraint (must be a host). Lacks explicit when-not-to-use or alternative tools, but provides actionable guidance for use.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, consistent with creation. The description adds context about live events and host requirement, but does not disclose additional behavioral traits like side effects or reversibility beyond the given hints.

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

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

The description is concise with two sentences. The first sentence states purpose, the second lists fields and requirements, front-loading the core function. Every sentence adds value.

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

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

Given the tool's complexity (11 parameters, no output schema) and many sibling tools, the description provides sufficient context: production project on a live event, host requirement. It does not explain return values but that is acceptable 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 0% schema description coverage, the description lists key fields (name, description, category, priority, status, deliverable, dates) and highlights required ones, adding value. However, it lacks detailed semantics for each parameter, such as allowed values or formats.

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

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

The description clearly states 'Create a production project on a live event' with a specific verb and resource, and distinguishes from siblings by mentioning 'container for tasks, roles, vendors, and budget' and the host requirement.

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

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

It specifies the condition 'Requires event_id + name; you must be a host,' providing clear context for when to use. However, it does not explicitly state when not to use or list alternative tools.

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

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

Annotations are present but minimal. The description adds authorization context but does not disclose creation behavior, uniqueness constraints, or side effects beyond 'add'.

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 concise sentences: first states purpose, second lists fields and requirements. No unnecessary words, front-loaded with action verb.

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 moderate complexity (6 params, no output schema), the description covers purpose, required params, and authorization but omits return value, error conditions, and unique constraints.

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 0% schema description coverage, the description partially compensates by listing 'Name, description, category, notes' and stating required fields, but does not cover all parameters (e.g., tags) or provide detailed semantics.

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

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

The description clearly states the tool adds a production role to a live event, specifies the type of role (accountable) and its relationship to tasks/vendors/receipts, which distinguishes it from sibling add tools.

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

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

The description indicates required fields and authorization ('you must be a host'), but does not explicitly state when to use this tool versus alternatives or when not to use it.

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

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

The description discloses the host permission requirement and the nature of adding a schedule item, which is consistent with annotations (readOnlyHint=false). However, it does not elaborate on side effects, duplication handling, or rate limits beyond what the action implies.

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

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

The description is concise, consisting of two sentences that front-load the core purpose and requirements. It avoids unnecessary detail, though a bit more structure (e.g., listing parameter groups) could improve clarity.

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

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

The description covers essential aspects (adds schedule item, requires host, required fields) but does not differentiate well from sibling tool add_programming_item or address error handling. Given the complexity (11 params, no output schema), more context would be beneficial.

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 0% schema description coverage, the description lists key optional parameters (end, lane, cue number, project, talent) and gives examples of 'type' values, but it does not provide detailed semantics for each parameter, such as the meaning of 'lane' or 'cue_number'.

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 adds a run-of-show cue/schedule item to a live event, with specific examples of types (lighting, sound, performance, etc.) and mentions required fields. This distinguishes it from other 'add_*' sibling tools like add_guest or add_inventory_item.

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

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

The description specifies that the tool requires event_id, title, start_at, and that the user must be a host. This provides clear context for when to use it, though it does not explicitly state when not to use it or compare with alternatives like add_programming_item.

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

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

Annotations already indicate it's a mutation (not read-only) and not destructive. The description adds value by specifying a prerequisite ('Requires a connected account') and scope ('Spans all your events'), which are 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?

Two sentences, no waste, front-loaded with verb and resource. Efficiently conveys purpose, key parameters, scope, and prerequisite.

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 8 parameters, no output schema, and 0% schema coverage, the description covers key fields but lacks return value information and does not detail all optional contact parameters. Adequate for a basic mutation tool but not comprehensive.

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

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

The description mentions 5 of 8 parameters (company, tier, total committed, deliverables, optional contact) giving some meaning beyond the schema, but misses details on specific contact fields and notes. Schema description coverage is 0%, so description partially compensates.

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

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

The description clearly states 'Add a sponsor to your sponsor book', specifies key fields (company, tier, total committed, deliverables, optional contact), and distinguishes from sibling add_* tools by focusing on sponsors.

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 context: 'Spans all your events' and 'Requires a connected account', informing global scope and a prerequisite. Does not include explicit when-not-to-use or alternative tools, but the context is sufficient for an agent.

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

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

Annotations already indicate readOnlyHint=false, so the 'Add' verb is expected. The description adds the host requirement but no further behavioral details (e.g., idempotency, what happens on duplication). No contradiction with annotations.

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

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

The description is a single sentence that efficiently conveys purpose and key fields. It is front-loaded but could be structurally improved by separating prerequisites from the field list.

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 14 parameters and no output schema, the description covers the basic purpose and key fields but lacks return value information and guidance on optional parameters. Adequate but not comprehensive.

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

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

With 0% schema coverage, the description adds meaning by listing fields like bio, status, categories, act title, duration, contact, rider. However, not all 14 parameters are mentioned (e.g., home_base, is_speaker, portfolio_url), so it only partially compensates.

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 adds talent (performer, artist, DJ, speaker) to a live event's roster and lists key fields. It distinguishes from sibling tools like add_guest or add_event_host by specifying the resource type and action.

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

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

The description specifies required parameters (event_id, name) and authorization (must be host), but does not explicitly state when to use vs alternatives or when not to use. Implicit differentiation from siblings exists but could be more direct.

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) and not destructive (destructiveHint=false). The description confirms it creates a task but does not disclose side effects like notifications or return values. Adequate for a simple creation tool but lacks depth.

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

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

The description is a single, well-structured sentence that front-loads the main action and essential details. No redundant words or 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 the tool's simplicity (4 params, no output schema, basic annotations), the description covers the core purpose, required inputs, and role requirement. Missing are error conditions and what the response looks like, but it is reasonably complete for a creation tool.

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

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

Schema description coverage is 0%. The description adds meaning by naming parameters (title, priority, phase) and showing enum values for phase. It also highlights required parameters (event_id, title). However, it does not explain all parameters fully (e.g., priority meanings).

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 'Add', the resource 'production task', and lists key parameters (title, priority, phase). It distinguishes from siblings by specifying it's for live event tasks, among many other 'add' tools.

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

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

The description mentions prerequisites ('Requires event_id + title; you must be a host') but does not explicitly differentiate from similar tools like 'add_production_item'. No when-to-use or when-not-to-use guidance is provided.

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

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

Discloses core behaviors: creation of ticket tier with various optional features (approval, secret code). No contradiction with annotations (readOnlyHint false). Could mention error conditions for paid without Stripe.

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 packed with essential information: function, options, prerequisites, requirements. Front-loaded and 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?

Adequately covers the tool's purpose, parameters, and constraints given no output schema. Could mention typical responses or error cases, but sufficient for an agent to invoke correctly.

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

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

With 0% schema description coverage, the description compensates by explaining price (free/paid), capacity, approval, secret, and event_id. Does not describe 'description' parameter or clarify that 'secret' is a boolean, but covers most meaningful parameters.

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

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

The description clearly states the tool adds a ticket tier to a live event, differentiating from other add tools by specifying free/paid, capacity, approval, and secret code options. It explicitly links to the event management 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?

Provides clear context: requires event_id and host status, also notes Stripe connection for paid tiers. Lacks explicit exclusions or alternatives but effectively guides when to use.

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

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

Annotations are minimal (no hints set), so description carries behavioral disclosure burden. It states the operation is an 'add' (mutation) and mentions host requirement, but lacks details on idempotency, error behavior, or what happens if vendor already exists. No contradiction with annotations.

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

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

Single sentence with dash separation, efficient and front-loaded. No redundant words. Could benefit from a clearer separation of sections (e.g., list of fields vs. requirements).

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 12 parameters and no output schema, the description gives a high-level overview but omits details on return value, error handling, and full parameter coverage. It covers requirements but leaves behavioral gaps.

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

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

Schema has 0% parameter description coverage. The description adds plain-English explanations for most parameters (name, service, status, contact info, itemized list, notes, tags, linked projects) but misses url and point_of_contact. Provides useful context like 'pipeline status' for status field.

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

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

The description clearly states the action ('Add a vendor'), the resource ('production graph'), and lists the fields it can set. It differentiates from sibling 'add' tools by specifying the domain (vendor/supplier for live events) and constraints (requires event_id + name, must be host).

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 some usage guidance: requires event_id + name and host role. However, no explicit comparison to alternatives like add_affiliate or add_sponsor, nor does it clarify when not to use this tool.

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

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

Discloses key behaviors: reassignment, preservation of usage count, skipping of ineligible codes, call limit, and host requirement. Annotations are basic (no destructive or idempotent hints), so description adds needed behavioral context.

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

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

Three sentences, front-loaded with the core action, no redundant words. Each sentence adds distinct value: action, exception, constraints.

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

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

Covers purpose, usage rules, prerequisites, and constraints. No output schema means return values are not required. Lacks mention of error conditions or side effects, but acceptable for a simple mutation tool.

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

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

Schema has 0% description coverage; description mentions all three required parameters but only explains code_ids as 'standalone promo codes.' Lacks detail on event_id and profile_id beyond naming, partially compensating for schema gaps.

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

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

The description clearly states the action ('Reassign existing standalone promo codes into a discount profile') and key behavioral detail ('keeps its prior usage count'), distinguishing it from similar tools like add_codes_to_profile.

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 not to use (codes already in a profile or linked to an affiliate are skipped) and provides constraints (Max 100/call, required parameters, host privilege). However, does not compare directly to sibling tools.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, so the description must disclose side effects. It does so by stating that the tool 'issues them a capacity-limited comp ticket and notifies them', which goes beyond the annotations. No contradictions are present, and the description adds valuable behavioral context about the ticket issuance and notification.

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 concise sentences with no unnecessary words. The main action is front-loaded in the first sentence, and the second provides essential prerequisites and requirements. Every sentence contributes meaning, demonstrating efficient use of space.

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

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

Given the tool has 4 required parameters, no output schema, and no nested objects, the description covers the core functionality (waitlist approval, ticket issuance, notification), prerequisites (source of IDs), and access requirement (must be host). It does not cover potential error cases (e.g., capacity exceeded) or return behavior, but given the tool's simplicity, this is adequate. A slightly longer explanation of what happens on failure would raise the score.

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

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

The input schema has 0% description coverage, so the description must provide parameter meaning. It mentions all four parameters (event_id, request_id, user_id, ticket_class_id) and notes that request_id, user_id, and ticket_class_id come from 'list_guest_requests'. However, it does not explain the purpose or constraints of each parameter individually, leaving some ambiguity (e.g., what ticket_class_id represents exactly). This adds some value but is insufficient for full clarity.

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

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

The description clearly states the tool's purpose: approving someone from the event waitlist, issuing a comp ticket, and notifying them. It uses a specific verb ('approve') and resource ('guest request'), distinguishing it from sibling tools like 'deny_guest_request' and 'list_guest_requests'.

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

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

The description provides explicit context for usage: it operates on the event waitlist/approval queue and requires the user to be a host. It also specifies a prerequisite: obtain request_id, user_id, and ticket_class_id from 'list_guest_requests'. However, it does not explicitly state when not to use this tool or compare it to similar approval tools, which would strengthen the 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 readOnlyHint=false and destructiveHint=false. The description adds that the tool adds a member (mutation) and requires specific roles, providing context beyond annotations. No contradictions.

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

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

The description is a single, well-structured sentence with no extraneous words. It efficiently conveys purpose, prerequisites, and required parameters.

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 is provided, but the description does not mention what the tool returns (e.g., success status, membership object). It also lacks error conditions (e.g., invalid request, not pending). Adequate for a simple action but could be more complete.

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

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

Schema description coverage is 0%, so the definition must compensate. The description mentions required parameters (community_id, user_id) but does not explain their meaning or source beyond the names. Since the names are self-explanatory, this is adequate but not enhanced.

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

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

The description states a specific verb ('approve') and resource ('pending request to join a community'), with the clear outcome ('adds them as a member'). This distinguishes it from siblings like 'reject_join_request' or 'list_join_requests'.

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

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

The description includes a precondition ('you must be its creator or admin'), which tells the agent when it can use the tool. However, it does not explicitly mention alternatives or when not to use it, but the context of 'pending request' 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 indicate destructiveHint=true; description adds 'Reversible' and 'on a live event you manage', providing useful behavioral context beyond annotations.

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

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

Two concise sentences with no extraneous information. Purpose and requirements 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?

Covers key aspects: action, reversibility, prerequisites. With only 2 params and no output schema, it is adequate. Could mention tier must be currently active, but not essential.

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

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

Schema description coverage is 0%. Description only repeats parameter names without explaining their purpose or format. Does not compensate for missing 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?

Clearly states action (archive), resource (ticket tier), context (live event you manage), and notes reversibility. Distinct from siblings like delete_ticket_tier.

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?

Specifies required parameters and host status. Implicitly contrasts with delete_ticket_tier by stating reversible, but does not explicitly say when to use this tool vs 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 provide safety hints (readOnlyHint=false, destructiveHint=false). The description adds behavioral context: supports set/add/remove operations, member identification options, and that team.memberCount stays in sync. It goes beyond annotations but does not detail permissions or conflict resolution.

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 dense with specific information, no filler, and front-loaded with the primary action. Every sentence adds value, efficiently covering entity-relation mapping and operation details.

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

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

For a tool with 6 required parameters (including nested objects) and no output schema, the description covers entity types, member ID, operation, relation, and side effects. Minor gap: the trailing 'host' is unclear, and behavior on duplicate or non-existent members is omitted.

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 0% schema description coverage, the description compensates well by explaining entity types, member identification (name, mode_id, email), op values, and relation types per entity. It adds meaning beyond the schema, making parameter usage clear.

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 assigns a person to a production item, lists multiple entity-relation combinations, and specifies identification methods (mode_id or name). This is specific and distinguishes it from sibling tools like assign_role or add_guest.

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

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

The description implies usage for assigning members to various entities but does not provide explicit when-to-use or when-not-to-use guidance compared to sibling tools like invite_team_member or assign_role. There are no exclusions or alternative references.

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 define non-readonly, non-destructive behavior. The description adds that role assignment is stored as a name snapshot, which provides useful context. However, it does not disclose potential side effects or error conditions, and the phrase 'Requires ... host' is ambiguous.

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

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

The description is short (two sentence fragments) and front-loaded with the primary purpose. It is concise, though the ending 'Requires ... host' feels tacked on and could be integrated better.

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. The description covers the main operation and entity types, but lacks explanation of the 'host' requirement and does not clarify typical use cases or return values. For a 5-parameter tool, more detail would be beneficial.

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 5 parameters with 0% description coverage. The description enumerates values for 'op' (set/add/remove) and 'entity' (tasks, etc.), but does not explain 'item_id', 'role_id', or 'event_id'. While the enum values are clear from the schema, the description adds little beyond listing them.

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

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

Description clearly states the verb 'assign', the resource 'role to a production item', and specifies the applicable entity types (tasks, receipts, vendors, inventory, schedule_items for single; projects for multiple). It distinguishes from sibling tools like 'add_role' (creation) and 'update_staff_role' (staff role update).

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 lists required fields (event_id, entity, item_id, role_id, op) and implies that this tool is used to manage role assignments on production items. It does not explicitly state when not to use or compare with alternatives, but the context is clear.

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

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

The description discloses key behaviors beyond annotations: it is a creation operation (readOnlyHint=false, consistent), handles duplicates/invalid rows by skipping with reasons, and has a plan cap. Annotations already indicate non-idempotent and non-destructive, but description adds context about error handling and capacity limits.

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

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

The description is very concise, consisting of three short sentences that front-load the core action and key constraints. Every sentence adds value: bulk creation, error behavior, plan cap, and prerequisites. No redundant or superfluous content.

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

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

Given the tool's moderate complexity (bulk creation with validation) and the absence of an output schema, the description covers purpose, constraints, error handling, and side effects. It lacks details on the return value (e.g., created codes vs. errors list), which would be helpful but is not critical. Overall, it provides sufficient context for an agent to use the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'event_id' is required and 'codes' array of up to 500 items, and explains error handling for duplicates/invalid rows. However, it does not detail the required subfields within each code object (code, discount_type, discount_value, max_uses), which are in the schema but lack explanations. This leaves semantic gaps for the agent.

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

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

The description clearly states the action: 'Create up to 500 promo codes on a live event in one call'. It specifies the resource (promo codes on an event) and distinguishes from the sibling tool create_promo_code by mentioning bulk creation, up to 500 codes, and error handling behavior (duplicates/invalid skipped with reasons).

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 constraints: 'Requires event_id; you must be a host' and 'Counts against the event's promo-code plan cap'. It implies the tool is for bulk creation, suggesting the alternative of using create_promo_code for single codes. However, it does not explicitly state when not to use it (e.g., on draft events) or compare with other bulk tools.

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

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

The description discloses that it sends invite emails and counts against the affiliate plan cap, which are behavioral traits beyond annotations. It also states the host authorization requirement, adding context not present in annotations (which lack such constraints).

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

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

The description is two sentences: first covers core functionality, second adds constraints and impact. It is front-loaded and concise with no wasted words, though could be slightly more structured.

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

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

With 9 parameters (0% schema coverage) and no output schema, the description leaves many optional parameters unexplained. It does not clarify return value, error handling, or what happens when plan cap is exceeded. Complete given complexity.

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

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

Schema description coverage is 0%, so description must compensate. It mentions required parameters 'event_id' and 'emails', and alludes to 'shared discount/commission' covering discount and commission fields. However, it does not explain optional parameters like 'starts_at', 'expires_at', 'code_prefix', leaving gaps.

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

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

The description clearly states the action: bulk invite affiliates to a live event via email with shared discount/commission. It specifies the resource (affiliates), action (invite), constraint (up to 200), and method (email), distinguishing from single-add tools like 'add_affiliate'.

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

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

The description provides explicit requirements: 'Requires event_id + emails; you must be a host' and mentions counting against plan cap. It implies usage context (multiple affiliates, shared commission) but does not explicitly state when not to use or name alternatives.

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

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

The description goes beyond annotations by describing the irreversible and outward-facing nature, and details side effects (cleanup of invites, affiliates, broadcasts). No contradiction with annotations.

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

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

Two sentences efficiently convey purpose, effects, and prerequisites without redundancy. Every sentence adds value.

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

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

The description adequately covers cancellation semantics and prerequisites. Lacks return value information, but no output schema exists; still, the description is reasonably complete for a destructive action.

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 0% schema description coverage, the description must compensate but only mentions event_id as required, omitting any explanation of the 'reason' parameter, leaving its purpose unclear.

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

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

The description clearly states the action ('cancel a live event') and the resource ('event'), and explicitly lists the effects (removes from discovery, cleans up invites/affiliates/broadcasts), distinguishing it from sibling tools like update_event or duplicate_event.

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

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

The description specifies the prerequisite ('you must be a host') and required parameter ('requires event_id'), providing clear guidance on when to use. It does not explicitly exclude use cases, but the context is sufficient.

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

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

Annotations already declare destructiveHint=true. The description adds valuable nuance: 'stops future batches; already-scheduled emails still deliver.' It also states the host requirement, which is behavioral context beyond annotations.

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

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

Two sentences, zero wasted words, action-first structure. Every sentence contributes meaningful 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 and the tool's simplicity (cancellation only), the description covers purpose, prerequisites, and side effects. Missing response format but not critical for this tool.

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

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

Schema description coverage is 0%. The description only repeats that event_id and job_id are required, adding no extra meaning (e.g., format, examples, how to obtain them). The schema already provides type and length constraints, so the description fails to compensate for the lack of schema descriptions.

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

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

The description clearly states the action ('Cancel') and the resource ('invitation send') and differentiates from siblings like 'send_invitations' and 'cancel_event'.

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

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

It explicitly states prerequisites (event_id + job_id, must be a host) and implies the context (running or scheduled send). No alternatives listed, but the guidance is clear enough.

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

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

Annotations already indicate destructiveHint=true; description adds that the user must be a host and the invite must be pending, providing useful context beyond annotations.

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

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

Two sentences, zero waste, front-loads purpose and condition, then provides alternatives and requirements efficiently.

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

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

For a simple cancel action with 2 required params and no output schema, the description covers purpose, usage context, prerequisites, and alternatives completely.

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 0%, so description must compensate, but it only mentions that event_id and invite_id are required without adding semantic detail (e.g., what each identifies).

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 cancels a pending team/staff invite before acceptance, and explicitly distinguishes it from demote_staff_to_guest for accepted members.

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

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

It specifies when to use (pending invites only), provides the alternative for accepted members, and lists requirements: must be host and need event_id and invite_id.

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 show readOnlyHint=false and destructiveHint=false, description adds toggle behavior. Lacks details on side effects or auth specifics beyond host requirement. No contradictions.

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

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

Two sentences, first sentence states primary action, second adds crucial detail. No wasted words, clearly 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?

No output schema, description does not mention return value. For a simple toggle tool, it covers usage and params but lacks response info.

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

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

With 0% schema description coverage, description adds meaning to checked_in parameter ('Pass checked_in false to undo'). event_id and guest_id are only listed without additional context.

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

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

Clearly states the tool checks in or checks out a guest at a live event, toggling ticket status. Distinguishes from siblings like check_in_plus_one by focusing on the guest themselves.

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?

Specifies when to use (to toggle ticket status) and prerequisites (must be a host). Does not explicitly mention alternatives like check_in_plus_one, but context makes it clear.

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

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

Adds failure condition ('fails if at plus-one limit') and host requirement beyond annotations. Annotations (readOnlyHint=false) align with mutation behavior. No contradictions.

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

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

Single, direct sentence with no wasted words. Front-loads action and constraints.

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

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

Covers authentication and failure condition, but omits success response or return value. For a simple tool with no output schema, description should state what happens on success.

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

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

Description lists required parameters but does not explain their meaning or provide context beyond names. Schema has 0% description coverage, placing burden on description, which is insufficient. For example, parent_guest_id is not explained as the ID of the main guest.

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

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

Description clearly states the verb 'Check in' and the resource 'one of a guest's allowed plus-ones' at an event. It specifies required parameters and failure condition (plus-one limit), distinguishing it from sibling tool check_in_guest.

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?

States 'at a live event you manage' and 'you must be a host', providing context. Implicitly differentiates from check_in_guest by specifying plus-one, but lacks explicit when-not-to-use or alternative comparison.

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 explains that the tool creates a Stripe account and returns an onboarding URL, aligning with annotations (readOnlyHint=false indicates mutation). It adds context beyond annotations by describing the account creation and return behavior, though it doesn't cover side effects like idempotency (already indicated as false in annotations).

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

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

The description is concise at three sentences, front-loading the core purpose and adding essential context without redundant words. Each sentence serves a clear role: purpose, effect, and prerequisite.

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

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

The description covers the tool's main function, effect, and a key prerequisite, but lacks explanation of the 'return_path' parameter and potential error conditions. With no output schema, the return value description ('onboarding URL') is vague, leaving some ambiguity for the agent.

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

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

The description does not mention the sole parameter 'return_path' or its enum values. With schema coverage at 0%, the description fails to compensate by explaining how to use the parameter, leaving the agent to infer from the schema's enum list alone.

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

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

The description clearly states the tool gets a Stripe Connect onboarding link for the host to connect their account and enable payouts. It specifies the verb 'get' (and 'creates') and the resource 'Stripe Connect onboarding link', distinguishing it from sibling tools that handle other tasks like account status checks.

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

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

The description provides a clear prerequisite: 'Check get_account_status first' and 'Requires a connected account.' This tells the agent when to use it (after checking account status) but does not explicitly state when not to use it or list alternatives beyond the referenced 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 show readOnlyHint=false and destructiveHint=false, so creation is expected. The description adds that the profile is reusable, counts against plan cap, and requires host status. This provides useful context beyond the structured data.

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 four sentences, each adding essential information: purpose, settable fields, plan cap, and requirements. No redundancy; front-loaded with the core function.

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 9 parameters, nested objects, and no output schema, the description covers purpose, key parameters, and prerequisites. It explains the shareable link concept and self-join. Lacks detail on return value but meets overall context for decision-making.

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 0% schema description coverage, the description must compensate. It lists optional fields (code_prefix, affiliate cap, commission, start/expiry) and mentions per-tier discount, but omits profile_name and does not detail nested tier structure or constraints. Adds high-level meaning but not enough for full parameter understanding.

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

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

The description clearly states the verb 'Create' and the resource 'reusable open affiliate profile', and distinguishes from the sibling tool 'add_affiliate' for specific persons. It defines a shareable link for self-join, making the purpose concrete.

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

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

The description explicitly says to use this tool for open profiles and to use add_affiliate for specific persons. It also states prerequisites (event_id, at least one tier, must be a host) and mentions the plan cap. Could further compare to other siblings like add_affiliate_code, but the guidance is clear.

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

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

The description adds transparency about plan cap usage and account requirement, which are not in annotations. Annotations lack behavioral details, so these traits are valuable. However, it does not mention reversibility, notification triggers, or admin role assignment.

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 concise sentence that immediately states the purpose. It is efficient but could be slightly more structured (e.g., separating parameter list from constraints). No redundant information.

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

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

Given no output schema and 8 parameters, the description covers core actions and constraints but omits return value, error scenarios (e.g., exceeding cap), and full parameter explanation. It is adequate for basic use but incomplete for complex scenarios.

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?

Given 0% schema coverage, the description explains most parameters (name, description, category, privacy, tags, icon/cover) but misses short_description. Privacy options are clarified (open/private), but icon/cover is ambiguous as two separate URLs. The explanation adds value beyond the schema's property names.

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

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

The description clearly states 'Create a community you own' and lists key fields (name, description, category, privacy). It distinguishes itself from sibling tools like update_community by implying creation vs modification.

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

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

The description mentions prerequisites ('Requires a connected account') and an important constraint ('Counts against your community plan cap'), giving clear usage guidance. However, it does not explicitly contrast with alternatives like create_event_draft or create_affiliate_profile, but the entity difference is obvious.

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

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

The description adds behavioral context beyond annotations: clicks are counted, the link opens a public or immersive page, and it requires event_id and host-only access. Annotations are sparse (readOnlyHint false, destructiveHint false), so the description carries the transparency burden well, though it does not mention idempotency or side effects.

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

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

The description is extremely concise, using two sentences divided into three actionable clauses. It front-loads the main action and each clause adds unique value without fluff.

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

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

Given the tool has 4 parameters, no output schema, and minimal annotations, the description covers purpose and key requirements but does not mention what the tool returns (e.g., the created link URL) or potential error conditions. It is adequate but not fully complete.

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

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

With 0% schema description coverage, the description compensates by explaining the purpose of source (as a tag with examples), campaign (optional), and target_type (public vs immersive page). It adds meaning but does not detail constraints like maxLength or the exact enum values beyond examples.

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

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

The description clearly states the verb 'Create', the resource 'trackable share link' for a live event, and distinguishes itself from siblings like get_share_links (which lists links) by specifying it creates a new link with tracking and source/campaign tagging.

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

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

The description explicitly states requirements: event_id is required, and only hosts can use it. It implies the context of creating links for live events, but does not explicitly mention when not to use or alternative tools, though the context is clear.

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

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

Annotations indicate idempotent and non-destructive mutation. The description adds context beyond annotations by explaining the draft is private until claimed, and the two different return links depending on connection status. No contradictions.

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

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

The description is three sentences, well-structured, and front-loaded with the key action. Every sentence adds value 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?

Given the tool's complexity (19 parameters, no output schema), the description only covers high-level behavior. It lacks details on parameter usage, return format, and handling of optional fields, making it insufficient for a complete understanding.

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 0% schema description coverage and 19 parameters, the description provides no information about any parameter. It does not compensate for the lack of schema 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 clearly states the tool creates an event draft and returns a claim link for publishing. It distinguishes two scenarios based on user connection status, which differentiates it from sibling tools like 'update_event_draft' or 'create_event_series'.

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

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

The description explicitly says 'Use when a user wants to create or publish an event' and explains behavior for both connected and unconnected users. It does not explicitly state when not to use it, but the context is clear enough.

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

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

Describes what happens to the source event and how child events are created with tickets/promo/forms replayed. Annotation contradiction is false. Minor gap: no mention of reversibility or limits beyond end_after max.

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

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

Three sentences, no redundancy, front-loaded with purpose. Every sentence adds value without unnecessary detail.

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

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

Covers main behavior, prerequisites, and replay of event attributes. Lacks details on response shape or error cases, but adequate for a mutation tool with no output schema.

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

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

With 0% schema coverage, the description explains pattern options, end conditions, and the source_event_id role. It adds context that end_after and end_date are alternatives and that the source becomes occurrence 1, which is beyond the schema.

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

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

Description clearly states the verb 'Turn an existing event into a recurring series' and the resource (event series). It distinguishes from sibling tools like duplicate_event and manage_event_series by specifying the exact 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?

States prerequisites (source_event_id, pattern, must be host) and implies use case (making an event recurring). Lacks explicit comparison to alternatives like duplicate_event when only copying is needed.

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 show readOnlyHint=false and destructiveHint=false; the description adds that the form starts as a draft and requires host status, providing useful behavioral context beyond annotations.

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

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

Two concise sentences with no fluff; front-loaded with the core action and key details.

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

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

Given 3 params, no output schema, and nested objects, the description covers purpose, usage context, and key parameter meaning, though it omits return value or error 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?

With 0% schema description coverage, the description compensates by listing required params (event_id, name) and question attributes (types, options, required, placeholder), but does not cover all schema details like canonical_key or constraints.

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

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

The description specifies a clear verb+resource ('Create a registration/intake form on a live event') and lists the question types included, distinguishing it from sibling tools like 'update_form' or 'set_form_active'.

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 states prerequisites (must be a host, requires event_id and name) and hints at the next step (activate with set_form_active), but does not explicitly exclude scenarios or compare to other creation tools.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, so the description correctly implies creation. It adds behavioral context by noting the host requirement and clarifying that a milestone is not a task. However, it does not disclose side effects, rate limits, or what happens when creation fails, beyond what annotations already imply.

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

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

The description is structured with the main purpose first, then entity list, then a usage hint, then prerequisites. It is front-loaded and information-dense without redundancy. One could argue slight verbosity in listing all entities, but it remains efficient for the content conveyed.

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 (6 params, nested object, many entities) and no output schema, the description covers the essence but lacks explanation of the return value or error handling. It adequately informs the agent about invocation but leaves gaps in understanding the full 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 0%, so the description must compensate. It explains the `entity` enum list, notes that `status` and `notes` are optional, and describes the `fields` object with an example (milestones {target_date, category, phase}). This provides meaningful semantics beyond the bare schema types, though not every parameter is fully detailed.

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

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

The description clearly states the verb 'create' and the resource 'production item' in various event areas, listing many entity types. It distinguishes milestones from tasks, which helps differentiate from sibling add_* tools. However, it does not explicitly clarify that this unified tool is the preferred method over specialized siblings like add_task or add_vendor, creating potential confusion.

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 prerequisites (host role, required params event_id, entity, name) and a specific use case (milestones). It lacks guidance on when to use this tool versus the many specialized add_* sibling tools, which is a significant gap for an agent deciding between them.

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 correctly indicates a write operation (create), consistent with annotations (readOnlyHint false). It adds context about association options but does not disclose other behaviors like uniqueness, idempotency, or response format. Given annotations cover basic safety, the description adds moderate value.

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

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

Two sentences with no filler. Front-loaded with purpose and then usage. Every word is informative and necessary. Extremely concise.

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

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

With 11 parameters and no output schema, the description should provide more context about optional parameters, constraints, and side effects. It lacks completeness for effective tool usage, especially for parameters like max_uses and applicable_classes.

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 0%, so the description must compensate. It covers only 5 of 11 parameters (code, discount_type, discount_value, event_id, draft_id, edit_token), omitting enabled, max_uses, starts_at, expires_at, applicable_classes. This leaves significant gaps in parameter understanding.

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

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

The description clearly states the verb 'Create' and the resource 'discount/promo code', specifies types (percent or fixed), and the context (live event or unclaimed draft). It distinguishes itself from siblings like update_promo_code and bulk_create_promo_codes.

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

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

The description explicitly tells the agent to provide either event_id or draft_id+edit_token, which is a clear usage guideline. However, it does not explicitly mention when NOT to use this tool (e.g., for bulk creation) or alternatives, leaving some ambiguity.

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

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

Annotations already indicate the tool is not read-only and not destructive. The description adds value by noting the plan cap constraint, which is beyond what annotations provide. No contradictions.

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

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

The description is two sentences, front-loaded with the core purpose, and contains no superfluous words. Every sentence adds necessary context.

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

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

The description gives a high-level overview suitable for simple tools, but given the nested schema and lack of output schema, it is incomplete. It does not detail the tier structure, max_uses, or schedule parameters, which are critical for correct invocation.

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

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

With 0% schema description coverage and 6 parameters (including a nested object), the description fails to explain any parameter beyond name-dropping 'event_id + tiers'. The schema does not provide descriptions either, leaving agents without guidance on how to fill in the parameters.

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

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

The description clearly specifies the action ('Create a discount (coupon) profile on a live event') and distinguishes the resource from sibling tools like 'create_promo_code' or 'list_promo_profiles' by emphasizing its reusability and config structure.

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 states required inputs ('event_id + tiers') and a prerequisite ('you must be a host'). It also mentions a cap constraint ('counts against your plan's discount-profile cap'), but does not explicitly specify when not to use or list alternatives.

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

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

Annotations already indicate destructiveHint=true, and the description confirms 'Permanently delete', adding context about authorization ('you must be a host') and the broad range of entities. No contradiction, but could elaborate on irreversibility or cascading effects.

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

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

Two sentences, front-loaded with purpose, followed by alternative and requirements. Every sentence serves a purpose with no superfluous wording.

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, entity variety, and three required parameters with no output schema, the description covers purpose, usage guidance, authorization, and entity list. It is nearly complete, though omitting potential side effects on linked items.

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

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

Schema coverage is 0%, but the description lists the three required parameters ('requires event_id + entity + item_id') and enumerates the entity types from the schema enum. This adds value beyond the raw schema, though item_id format is not explained.

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 production item' and lists all entity types, distinguishing it from hiding via update_production_item. The verb 'delete' and resource 'production_item' are specific and clear.

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

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

The description provides explicit when-to-use (permanent deletion) and when-not-to-use (hiding), with an alternative: 'use update_production_item active:false instead'. It also states prerequisites (event_id, entity, item_id) and authorization (must be a host).

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

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

Beyond the destructiveHint annotation, the description details the two resolution modes for codes: 'detach' (keeps codes standalone) and 'delete_codes' (deletes unused, disables used). It also clarifies the requirement to be a host and the required IDs. 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, front-loaded with the core action. Every word adds value: first sentence defines purpose and modes, second lists requirements. 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?

Given no output schema and three parameters, the description covers purpose, behavior, parameters, and prerequisites. It is sufficient for an agent to correctly invoke the tool.

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

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

Despite 0% schema description coverage, the description explains all three parameters: event_id and profile_id are required, and action (enum) with clear meaning of each option and default ('detach'). This fully compensates for the lack of schema descriptions.

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

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

The description clearly states it deletes a discount profile and resolves its codes, distinguishing between two actions ('detach' and 'delete_codes'). It uses a specific verb ('delete') and resource ('discount profile'), and the differentiation from sibling tools like update_promo_profile or remove_codes_from_profile is implicit.

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

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

The description provides a key prerequisite ('you must be a host'), which helps decide when to use. However, it does not explicitly state when not to use or mention alternatives (e.g., remove_codes_from_profile for removing codes without deleting the profile). This leaves some ambiguity for the agent.

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?

Description adds 'Irreversible' and the conditional deletion logic beyond annotations' destructiveHint=true. Could mention more about impacts but sufficient.

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 concise sentences with no redundancy. Front-loads purpose and key condition.

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 delete tool with simple params and no output schema, description covers condition, irreversibility, prerequisites, and alternative. Complete for its complexity.

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

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

Schema coverage is 0% but description mentions required parameters and their necessity. Does not elaborate on formats or constraints beyond schema.

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

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

Description clearly states the tool deletes a ticket tier permanently with a condition on ticket sales. It distinguishes from siblings like archive_ticket_tier and update_ticket_tier.

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 (no tickets sold) and when to use archive instead. Also specifies requirements: event_id, tier_id, host role.

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

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

Annotations already indicate destructiveHint: true. Description adds that it removes role and demotes to guest while retaining the spot, and requires host status. No contradictions. Some side effects not disclosed, but sufficient given 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 short sentences with no wasted words. Front-loaded with the action. Extremely concise and easy to parse.

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

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

Covers purpose, prerequisites, authority, and outcome. Missing return value or error handling, but no output schema exists. Adequately complete for a simple mutation tool.

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

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

Schema has 0% description coverage. Description mentions parameter names and context ('requires event_id + user_id'), implying their roles but not defining them explicitly. Acceptable for a two-parameter tool.

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

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

Description clearly states the verb 'remove' and 'demote', identifies the resource as a staff member on a live event, and specifies the outcome (they keep their spot). This distinguishes it from siblings like promote_guest_to_staff and remove_guest.

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

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

Explicitly says 'Requires event_id + user_id; you must be a host', giving clear prerequisites and authority. However, it does not explicitly state when not to use the tool or compare to alternatives like update_staff_role.

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 rich behavioral context beyond annotations: releasing the held slot back to the tier, freeing the person to re-register, and sending an email. This aligns with the destructiveHint annotation and provides concrete side effects.

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

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

Two sentences that convey action, effect, prerequisite, and requirement with no redundant words. Front-loaded with the 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?

Given no output schema, the description fully explains the tool's behavior (slot release, re-registration, email), prerequisite (list_guest_requests), and required parameters. It is complete for an agent to use correctly.

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

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

The description references event_id and request_id but does not explain the 'reason' parameter at all. With 0% schema description coverage, the description should have covered all parameters; the omission of 'reason' leaves a significant gap.

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

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

The description clearly states the action ('deny'), the resource ('guest request on waitlist/approval queue'), and the specific effects (releases slot, frees to re-register, emails). It uniquely identifies the tool among siblings like 'approve_guest_request' and 'list_guest_requests'.

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

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

The description provides explicit prerequisites: 'Get request_id from list_guest_requests' and 'Requires event_id + request_id; you must be a host.' It lacks explicit when-not-to-use guidance but is clear enough for correct selection.

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

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

The description discloses what is copied and what is not, and that it creates a new draft. Annotations provide little behavioral info, so the description adds valuable context beyond readOnlyHint and destructiveHint.

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

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

The description is concise (three sentences) and front-loaded with the core purpose. Every sentence adds value 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?

The description covers what the tool does and its parameters but does not explain the return value (e.g., whether it returns the new draft ID or success status). For a tool with no output schema, this is a notable gap.

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

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

Schema coverage is 0%, but the description explicitly mentions source_event_id as required and new_start_date/new_end_date as optional. However, new_name is not described, and the description does not explain the format or constraints of date parameters beyond what schema provides.

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

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

The description clearly states it duplicates an event's setup into a new draft, listing specific copied fields (name, description, etc.) and explicitly noting what is NOT copied (guests/RSVPs/sales). This differentiates it from sibling tools like create_event_draft or update_event.

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

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

The description specifies prerequisites (source_event_id required, user must be a host) and mentions optional parameters (new_start_date/new_end_date). However, it does not explicitly compare to alternatives or state when not to use this tool.

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

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

Annotations indicate this is a write operation (readOnlyHint false). Description adds that user must be a host, which is a behavioral constraint not in annotations. No contradictions.

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

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

Two sentences, front-loaded with core action and fields, second sentence adds constraints. No unnecessary words; every sentence adds value.

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

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

With 10 parameters and no output schema, the description covers key aspects: editable fields, constraints (only guest-list, not tickets), and requirements (IDs, host). Lacks detail on return value, but output schema is absent so not required per rules. Sufficient for agent understanding.

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 0%, but description lists all editable fields (name, email, phone, category, plus-ones, note, tags) and explicitly mentions required event_id and guest_id. This provides mapping for parameters beyond the schema's constraints.

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

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

Description clearly states it edits a guest-list entry, lists specific editable fields (name, email, phone, category, plus-ones, note, tags), and distinguishes from purchased tickets. Verb 'edit' with explicit resource and scope.

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

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

Provides context: only guest-list entries (not tickets), requires event_id and guest_id, and user must be a host. Does not explicitly compare to sibling tools, but given the sibling list, the distinction from ticket-related tools is clear.

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

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

Annotations provide readOnlyHint and destructiveHint. Description adds 'Read-only' and mentions return of download link, but doesn't disclose potential limits or additional behaviors beyond annotations.

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

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

Two concise sentences front-loading purpose, output, and requirements. No 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?

Covers input, output (CSV + download link), and prerequisites. No output schema but describes return value. Contextually complete for a simple export tool.

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

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

Schema coverage 0%, description mentions parameter names but does not elaborate on their meaning or format. Names are self-explanatory but limited added semantic value.

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

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

Clearly states the verb 'Export', resource 'form responses', output format 'CSV' with structure details, and required parameters. Distinguishes from sibling tools like list_form_responses by specifying CSV download.

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

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

Explicitly requires event_id, form_id, and host status. Implies usage context for CSV download vs listing. Lacks explicit when-not-to-use but is clear enough.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about the CSV fields, optional filter, and return link, which goes beyond the annotations. No contradiction exists.

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

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

The description is two sentences long, front-loading the core action and key details. Every part adds value without redundancy.

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

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

The tool returns a download link, but no output schema is provided. The description lists the exported fields and notes the optional filter. For a CSV export, this is mostly complete, though the response format (the link) could be explicitly mentioned.

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

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

With schema description coverage at 0%, the description adds meaning by stating that event_id is required and category is an optional filter. This compensates for the lack of schema descriptions, though the exact format of the filter is not detailed.

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 exports a live event's guest list as a downloadable CSV and returns a download link. It lists the specific fields included, distinguishing it from other guest-related tools like list_guests or check_in_guest.

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

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

The description explicitly mentions the required event_id and that the caller must be a host. It also labels the operation as read-only, providing clear usage context. While it does not explicitly state when not to use it, the purpose is specific enough to avoid confusion.

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

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses server-side rendering, no file upload needed, the default use of event name as hero title, and the AI-image limit. No contradiction with annotations.

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

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

The description is a single paragraph of around 70 words, front-loaded with purpose. It effectively conveys all key points but could be slightly more structured with bullet points for 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 moderate complexity and absence of output schema, the description covers AI limit, server-side rendering, host requirement, and default title. It lacks mention of return value (e.g., success status or URL), but overall is sufficiently detailed for selection and invocation.

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

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

Schema coverage is 0%, but the description adds meaning for 'prompt' by specifying what to include (vibe, palette, imagery, energy). For 'event_id', it notes that it's required. It does not elaborate on 'include_title', but its optional boolean nature is clear.

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

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

The description clearly states it generates a brand-new cover image for an event from a text prompt, specifying the verb 'generate' and the resource 'event cover'. It distinguishes from sibling tools like 'refine_event_cover' and 'set_event_image' by focusing on AI generation from a prompt.

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

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

The description gives clear context for use: it works from a text prompt, requires event_id and host role, counts against AI-image limit. It implicitly contrasts with tools requiring file upload. However, it does not explicitly state alternatives or when not to use it.

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

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

Adds value beyond annotations (readOnlyHint, idempotentHint) by emphasizing read-only nature and listing exact data fields. No contradictions.

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

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

Two efficient sentences; first provides high-level purpose, second lists details. No extraneous 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?

No output schema, but description thoroughly lists what the status includes (plan caps, Stripe status, add-ons). Provides sufficient context for a read-only tool.

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

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

Zero parameters with 100% schema coverage, so description does not need to explain parameters. Baseline of 4 is appropriate.

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

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

Clearly states 'Get your account status' and enumerates specific components: plan, subscription, Stripe connection, payouts/charges, weekly-invite add-on, plan caps. Distinct from sibling tools which mostly create, update, or list entities.

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

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

Specifies 'Requires a connected account' and notes it's read-only. No explicit alternatives given, but since no other tool provides account status, the context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds the host requirement and specific output fields, enhancing transparency beyond annotations.

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

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

Two sentences, front-loaded with action, no redundant words. Every sentence adds value.

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

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

Despite no output schema, the description enumerates the returned fields thoroughly. It covers input requirement, permissions, and output structure, making it complete for the tool complexity.

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

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

The single parameter (event_id) is described minimally ('Requires event_id') with no additional semantic detail. The schema fully covers the type and constraints, so baseline 3 applies.

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

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

The description clearly states it retrieves a live event's revenue, listing specific data points (net actually paid, tickets sold, per-tier breakdown, etc.) and distinguishes it from sibling tools that are for creating/updating/deleting or listing other entities.

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

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

It provides prerequisites (requires event_id, must be a host) and indicates read-only behavior, giving clear context for when to use. It lacks explicit when-not-to-use or alternative tool names but is sufficient.

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