socialloop-mcp

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false). Description adds that this is money-consequential and stamps ticket split, but doesn't detail side effects like status changes or transaction creation. Could be more explicit.

Agents need to know what a tool does to the 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 that front-load purpose and add critical context about unanimity and consequence. 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 the tool's simplicity (one param, no output schema), description covers purpose and consequence. However, for a money-consequential action, it lacks details about error conditions, idempotency, or what happens after acceptance.

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

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

Only one parameter (deal_id) with schema providing length constraints. Description merely repeats 'Requires deal_id' without adding meaning about format, source, or how to obtain it. Schema coverage is 0%, so description fails to compensate.

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

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

Description clearly states the action (confirm deal terms) and the context (as party or admin, activates on unanimity, money-consequential). It distinguishes from siblings like propose_deal, decline_deal, end_deal via naming and behavioral hints.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 for when to use (unanimity required) and who can use (party or admin). Lacks explicit exclusions or comparison to siblings, but implied by tool name and description.

Agents often have multiple tools that could apply. Explicit usage 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 discloses key behavioral traits beyond annotations: sends an invite email, the affiliate gets a tracked code on accept, and it counts against the cap. Annotations already indicate a write operation (readOnlyHint false) and non-destructiveness, but the description adds 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?

Three sentences, 43 words, front-loaded with the core action. Every sentence adds value with no redundancy or fluff.

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

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

Description covers the main action and side effects but omits details on half the parameters (e.g., starts_at, expires_at, code_prefix). No output schema exists, and the description does not mention return value or error handling, leaving gaps for an agent needing full context.

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

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

Schema has 0% description coverage for 9 parameters; description only mentions 'discount and optional commission' generically and notes required 'event_id' and 'email'. Parameters like starts_at, expires_at, code_prefix, discount_type, etc., are not explained, so the description does not sufficiently compensate for the 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?

Description clearly states the action: 'Invite an affiliate/promoter to a live event by email with their discount and optional commission.' It specifies the resource (affiliate/promoter to an event) and the mechanism (email), distinguishing it from siblings like 'add_guest' or 'add_affiliate_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?

Description provides prerequisites ('Requires event_id + email; you must be a host') and a constraint ('Counts against the affiliate plan cap'), but does not explicitly contrast with sibling tools or state when not to use it. The context is clear enough for an agent to infer appropriate 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?

Description adds auth requirement ('you must be a host') beyond annotations. However, it does not disclose potential side effects (e.g., overwriting existing tiers), idempotency, or response shape. Annotations are minimal, so description carries some burden but leaves gaps.

Agents need to know what a tool does to the 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 states purpose and key feature, second lists requirements. No redundant words, efficient and front-loaded.

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

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

Given no output schema and 7 params, description covers purpose, required params, and auth but lacks success behavior, optional commission details, and usage differentiation from sibling tools. 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?

Schema description coverage is 0%, so description must compensate. It mentions required parameters (event_id, affiliate_id, ticket_class_id, discount) and optional commission, but does not explain each parameter's meaning (e.g., discount_type vs discount_value, commission_type). This provides marginal addition but insufficient guidance for 7 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 verb 'extend' and resource 'affiliate to another ticket tier', distinguishing it from siblings like 'add_affiliate' or 'create_promo_code'. It also lists required parameters and a prerequisite (host status), making the purpose unambiguous.

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

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

The description implies usage when adding a tier to an affiliate's promo code but does not explicitly state when to use this tool versus alternatives such as 'create_promo_code' or 'update_affiliate_commission'. No exclusions or alternative tools are mentioned.

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

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

The description discloses key behaviors: codes inherit discount, become immediately redeemable, duplicates skipped with suggestion, and max 500 per call. Annotations (readOnlyHint=false, destructiveHint=false) are consistent with a mutation that is not destructive. 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 purpose and behavior, followed by parameter constraints. Every sentence adds value with no redundancy or fluff.

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

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

The description covers purpose, parameters, and constraints, but lacks information about the return value or response structure. Since there is no output schema, the agent must infer what the tool returns (e.g., list of created codes, count, or errors). This creates a minor gap in completeness.

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

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

Schema description coverage is 0%, so the description must explain parameters. It covers all 5 parameters: event_id, profile_id as required; codes for explicit codes; auto_generate for count; code_prefix as optional. It adds meaning beyond the schema by stating usage patterns ('Give explicit codes and/or auto_generate a count').

Input schemas describe structure but not intent. Descriptions should explain 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 attaches or auto-generates promo codes under a discount profile, with the result being immediately redeemable. It distinguishes from siblings like 'add_affiliate_code' or 'create_promo_code' by specifying the context of a discount profile and the ability to handle multiple 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 provides clear usage context: requires event_id + profile_id and host status, plus limits like max 500 codes and duplicate handling. However, it does not explicitly contrast with similar tools like 'adopt_codes_to_profile' or 'create_promo_profile', which would strengthen 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 (readOnlyHint=false, destructiveHint=false) indicate modification without destruction. Description adds that invitee receives an email and joins on accept, and explains role permissions. This provides 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 sentences, front-loaded with action and key details. No filler; every word serves a purpose.

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

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

Covers purpose, parameters, and requirements. No output schema, so omission of return value is acceptable. 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, description compensates by explaining role enum values and their permissions. Email and event_id are standard; schema defines format and length. Description adds value 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 uses specific verb 'Invite a co-host' and resource 'live event', clearly distinguishing from sibling tools like add_guest and add_staff. No ambiguity.

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

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

States requirement 'Requires event_id; you must be a host.', giving clear context for when to use. Lacks explicit exclusions or comparisons to alternatives, but 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?

Adds behavioral context beyond annotations (invite limit, host requirement) but annotations already indicate non-destructive mutation. 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, no fluff, front-loads purpose and key parameters with essential behavioral notes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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, key parameters, and constraints. No output schema means less to explain, but could mention success response or error cases. Mostly 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?

Lists parameters and gives example for category, but with 0% schema coverage, more detail (e.g., formats of tags, plus_ones_allowed) would help. Adequate but not 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?

Clearly states the verb 'Add' and resource 'guest to a live event's guest list', listing key parameters and distinguishing from siblings like edit_guest, remove_guest, 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?

Provides important context: counts against weekly invite limit and requires host role. No explicit when-not-to-use, but context implies usage constraints.

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

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

Discloses access requirement (host) beyond annotations. Annotations are minimal (no readOnly, destructive, etc.), so description adds some value but does not describe side effects or data impact.

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

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

Single sentence covering purpose and key constraints. Front-loaded with action and scope. Slightly dense but concise; no redundant content.

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

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

With 20 parameters, no output schema, and minimal annotations, the description omits many parameter details, return behavior, and additional constraints beyond host requirement. Incomplete relative to 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?

With 0% schema description coverage, description lists a few fields (category, status, etc.) but does not explain most of the 20 parameters. Agent must infer meaning from names and enum lists, which may be insufficient.

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

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

Explicitly states it adds a physical asset/gear item to a live event's inventory. Names key fields and requirements. Unique among sibling tools, no ambiguity.

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

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

Clearly states required parameters (event_id + name) and access condition (must be a host). Provides context for when to use, though does not explicitly contrast with 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 (readOnlyHint=false, destructiveHint=false) indicate a non-destructive write operation. The description adds that the user must be a host, which is useful. However, it does not disclose what happens on success (e.g., returns meal ID), potential side effects, or the exact effect on the event's culinary plan.

Agents need to know what a tool does to the 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 main purpose and then listing key details. Every word adds value, and there is no redundancy. It efficiently conveys the critical information.

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

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

For a creation tool with 14 parameters and no output schema, the description covers the required fields and main concept but misses some optional parameters. It does not explain return values or how the meal is integrated into the live event, leaving some gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It lists several parameters with examples: 'kind (breakfast/lunch/dinner/snack/special), serve time (required), title, status (planning … served), expected diners, stations, shopping list, estimated cost ($).' This partially covers the 14 parameters but omits tags, notes, place_id, project_id, and description, leaving ambiguity.

Input schemas describe structure but not intent. Descriptions should explain 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: 'Add a meal to a live event's culinary plan' and lists key fields (kind, serve_time, title, etc.). It distinguishes from siblings by specifying the event context and required parameters like event_id, kind, and serve_at.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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: 'Requires event_id + kind + serve_at; you must be a host.' This tells the agent when and under what conditions to use the tool. However, it does not explicitly state when not to use it or mention alternatives like update_meal_menu.

Agents often have multiple tools that could apply. Explicit usage 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 value beyond annotations by indicating the tool creates a place (mutation) and requires host authorization. It does not contradict annotations (readOnlyHint=false, destructiveHint=false). It could further detail change reversibility or conflict handling.

Agents need to know what a tool does to the 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, front-loaded sentence that efficiently communicates purpose, scope, and requirements with no redundant text.

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

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

Given 13 parameters and no output schema, the description provides a solid overview of inputs and authorization. It lacks details on return format, error conditions, or idempotency, but remains functional for an AI 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 listing key parameters (name, structure, sector, lifecycle, build status, parent place, budgets, start date). It adds meaning like 'lifecycle + build status' indicating enums, but misses tags, name_alt, and description fields.

Input schemas describe structure but not intent. Descriptions should explain 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 place/location to a live event, listing specific fields (build site, zone, venue area). It differentiates from siblings like add_space by emphasizing 'live event' context and required host role.

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

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

The description specifies prerequisites (event_id + name, must be host), providing clear context for when to use. However, it does not explicitly mention when not to use or compare with alternatives like add_space, leaving some room for 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?

Discloses key behaviors beyond annotations: immediate application of split terms, no confirmation step, and refusal over existing terms unless replace_existing is true. Annotations are all false, so the description fully covers the behavioral profile.

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

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

Three sentences front-load the main action, then detail the split terms effect and refusal logic, and end with required IDs. 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 action, side effects (split terms), conditions (refusal/replace), and required inputs. Lacks mention of return value or confirmation, but no output schema exists. For a mutation tool, this is adequate.

Complex tools with many parameters or behaviors need more documentation. 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 adds meaning by naming required parameters and explaining the effect of replace_existing. It compensates for the silent schema, though it doesn't describe each parameter's type or constraints beyond 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 'Add a community member to a partner profile' with a specific verb and resource, and adds unique behavior (split terms apply immediately, refusal logic). This distinguishes it from sibling tools like add_guest, add_affiliate, and add_role.

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

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

Provides explicit required parameters (community_id, profile_id, member_uid) and a condition (refuses unless replace_existing: true). However, it does not explicitly compare with alternative tools or state when not to use.

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

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

Annotations show readOnlyHint=false and destructiveHint=false, consistent with a write operation. Description adds authorization requirement (must be host) and required fields, providing 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?

Single, well-structured sentence with examples and key 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 15 parameters, no output schema, and 0% schema description, the description covers core concepts but omits details on return value and several parameters (e.g., experience_series, place_ids, talent_ids). Adequate but not thorough.

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

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

With 0% schema description coverage, the description partially compensates by listing key fields (title, status, types, duration, start time, linked talent/places, rider, production needs) and hinting at status enum. However, it does not explain all 15 parameters or their 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 the tool adds a programming item (curated experience) to a live event, listing example types and fields. It distinguishes from sibling tools like add_schedule_item by specifying 'curated experience', but does not explicitly contrast with similar 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?

Specifies required fields (event_id, title) and authorization (must be host), implying context. No guidance on when to use this versus alternatives like add_schedule_item or add_production_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 provide minimal behavioral hints. The description adds authorization context ('you must be a host') but does not elaborate on side effects, response format, or whether creation is reversible. This is adequate but not rich.

Agents need to know what a tool does to the 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 provides context, a parameter list, and requirements. It avoids redundancy but could be better organized (e.g., separating the parameter list into bullets).

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 11 parameters and no output schema, the description is adequate but lean. It covers the essential purpose and prerequisites but lacks detail on return values, state transitions (e.g., whether the event must be 'live'), or relationship to sibling tools.

Complex tools with many parameters or behaviors need more documentation. 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 enumerates some parameters ('Name, description, category, priority, status, deliverable, dates') but omits 'tags,' 'notes,' and the specific date formats. It does not explain constraints like maxLength or enum values, leaving agents underinformed.

Input schemas describe structure but not intent. Descriptions should explain 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'), the resource ('production project'), and the context ('on a live event'). It distinguishes the tool from siblings like 'add_task' or 'add_role' by positioning it as the container for those elements ('tasks, roles, vendors, and budget').

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 critical prerequisites: 'Requires event_id + name; you must be a host.' It implies this tool is used before adding tasks/roles (by saying it's the container), but does not explicitly contrast with alternatives or spell out 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?

Description adds behavioral context beyond annotations: the role is 'accountable' and references other entities, and a host permission is required for creation. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).

Agents need to know what a tool does to the 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: first sentence defines purpose, second covers prerequisites. Every word earns its place.

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

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

Adequately covers purpose, prerequisites, and role nature. Lacks details on return value (no output schema) or failure behavior, but for a creation tool with 6 parameters, the description is reasonably complete.

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

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

Schema coverage is 0%, so description must compensate. It lists parameter groups ('Name, description, category, notes') and highlights required ones, but omits 'tags' and does not explain the semantics or format of each parameter 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 verb 'Add', resource 'production role', and context 'to a live event', with examples of accountable roles (Stage Manager, Catering Lead). It distinguishes from sibling add_* tools by specifying that these roles are referenced by tasks/vendors/receipts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 lists required parameters (event_id, name) and authorization condition ('you must be a host'). However, it does not contrast with similar sibling tools like assign_role, leaving some ambiguity about when to use which.

Agents often have multiple tools that could apply. Explicit usage 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 (mutation). The description adds an authorization constraint: 'you must be a host.' It does not contradict annotations and provides useful behavioral 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?

Two sentences with no redundancy. The purpose and key requirements are front-loaded. 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 11 parameters, no output schema, and many sibling tools, the description adequately covers the core functionality, prerequisites, and optional fields. It lacks detail on return values or type enum, but is complete enough 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 coverage is 0%, so the description must compensate. It lists required and notable optional parameters (end, lane, cue number, project, talent) but omits explanation for notes, type, description, project_id, talent_ids. Partial help, but incomplete for 11 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 run-of-show cue/schedule item to a live event, specifying the resource (cue) and action (add). It distinguishes from siblings like add_guest or add_inventory_item by focusing on event scheduling items.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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: requires event_id, title, start_at, and that the user must be a host. It does not explicitly compare to alternatives, but the context and sibling names make the use case clear.

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

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

Beyond annotations (which show readOnlyHint=false), the description adds that the address is 'stamped onto events at booking confirm' and hours are 'soft policy'. However, it does not detail exact side effects, authorization nuances, or idempotency.

Agents need to know what a tool does to the 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 a single packed sentence plus two short statements. It front-loads the purpose and key attributes. However, the first sentence could be split for better readability.

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

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

Given 11 parameters, no output schema, and minimal annotations, the description covers most relevant fields but omits the 'description' parameter and does not discuss return values or error conditions. It provides adequate context 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?

With 0% schema coverage, the description compensates by listing many fields (name, location_name, floor, capacity, etc.) with brief explanations. But it misses the 'description' field and does not explain formats for complex types like photos or hours.

Input schemas describe structure but not intent. Descriptions should explain 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 bookable venue Space (room/floor)' with a specific verb and resource. It lists the main fields and notes admin-only access. However, it does not explicitly distinguish this tool from siblings like update_space or set_space_status.

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

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

The description mentions 'Admin-only' and 'Requires community_id + name', giving basic context. But it lacks explicit guidance on when to use this tool versus alternatives (e.g., update_space for modifications) 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?

Annotations indicate this is a write operation (readOnlyHint=false) and not destructive. The description adds useful context ('Spans all your events') and a prerequisite ('Requires a connected account'), but lacks details on error handling, idempotency, or behavior on duplicates.

Agents need to know what a tool does to the 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—two sentences—and front-loaded with the main action. The first sentence efficiently lists key parameters. No redundant words, but the structure could be slightly improved by separating the prerequisite into a clearer note.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 and no output schema, the description provides enough context for basic use but omits return value, error conditions, and how the sponsor book relates to events. The scope statement helps, but more detail is needed for a fully informed decision.

Complex tools with many parameters or behaviors need more documentation. 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 explaining the tier enum values and mentioning total_committed. However, notes, contact_name, contact_email, contact_phone are not explained individually, only grouped as 'optional contact.'

Input schemas describe structure but not intent. Descriptions should explain 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 sponsor to your sponsor book') and specifies key fields (company, tier, total committed, deliverables, contact). It distinguishes itself from sibling tools like 'add_vendor' by focusing on sponsors and mentioning scope 'Spans all your events.'

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

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

The description includes context ('Spans all your events,' 'Requires a connected account') but does not explicitly state when to use this tool versus alternatives. No 'when-not-to-use' guidance or comparison with related tools like 'accept_deal.'

Agents often have multiple tools that could apply. Explicit usage 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). The description adds that the user must be a host, but does not disclose side effects like notifications, capacity changes, or other mutations beyond adding to the roster.

Agents need to know what a tool does to the 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 that front-load the purpose and immediately convey key requirements. 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?

Given 14 parameters, no output schema, and no schema descriptions, the description provides a useful overview but omits details on return values, optional parameter defaults, and the broader impact of adding talent (e.g., roster updates, integration with other tools).

Complex tools with many parameters or behaviors need more documentation. 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 some fields (name, bio, status, categories, act title, duration, contact, rider). However, several parameters (email, phone, home_base, is_speaker, description, portfolio_url) are not explicitly linked, and 'duration' is ambiguous regarding duration_minutes.

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

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

The description clearly states that the tool adds talent (performer, artist, DJ, speaker) to a live event's roster, specifying the general action and resource. However, it does not explicitly distinguish from sibling 'add_' tools like add_guest or add_event_host, which have different targets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 + name and that the caller must be a host. It does not provide guidance on when to use this tool versus alternatives or what contexts to avoid.

Agents often have multiple tools that could apply. Explicit usage 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 (non-readOnly) and not destructive or idempotent. The description adds that the user must be a host, which is useful. However, it does not disclose side effects, such as what happens if a task with the same title already exists, or any rate limits.

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

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

The description is a single, well-structured sentence that conveys the core functionality and constraints without unnecessary words. It is front-loaded and efficient.

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

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

Given the tool has 4 parameters, 2 enums, no output schema, and moderate complexity, the description covers basic requirements but lacks explanation of return values, error conditions, or behavior with optional parameters. It is adequate but not thorough.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'title, priority, and phase' but does not explain enum values (e.g., what 'explore' priority means) or provide any additional context for the event_id parameter. The description adds minimal meaning beyond the schema.

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

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

The description clearly states the verb 'Add' and the resource 'production task to a live event', and lists key parameters. However, it does not differentiate from sibling tools like add_production_item or add_schedule_item, which could cause 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 states prerequisites ('requires event_id + title; you must be a host') but does not provide guidance on when to use this tool vs alternatives or when not to use it. Usage context is implied but not explicit.

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

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

Annotations provide minimal safety info (destructiveHint=false). The description adds that paid tiers need Stripe and that a host role is required, but does not disclose potential side effects, return values, 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 two short sentences, front-loading the core purpose and then adding key prerequisites. Every sentence 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?

Given 7 parameters and no output schema, the description covers high-level semantics and critical prerequisites but omits full parameter details (e.g., name constraints, description field) and return value information.

Complex tools with many parameters or behaviors need more documentation. 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, capacity, approval, and secret. It mentions event_id as required but omits details for name and description. Parameters are partially but effectively elucidated.

Input schemas describe structure but not intent. Descriptions should explain 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 ticket tier to a live event' with specific verb and resource. It distinguishes from sibling tools like archive_ticket_tier or update_ticket_tier by focusing on creation of a new 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?

The description provides usage context: adding a tier to a live event, requires event_id, and being a host. It mentions prerequisites (Stripe connected for paid tiers) but does not explicitly list alternatives or when not to use.

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

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

Annotations provide minimal behavioral hints (all false). The description indicates a creation operation but does not disclose side effects, idempotency, error handling, or what happens if a vendor already exists. It adds little beyond stating the tool adds a vendor.

Agents need to know what a tool does to the 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 the tool's purpose and key requirements. It is concise and front-loaded, though it could benefit from a slightly more structured format.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 12 parameters, no output schema, and no parameter descriptions in the schema, the description is insufficient. It does not cover return values, error conditions, or detailed parameter semantics, leaving gaps for correct invocation.

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

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

Schema description coverage is 0%. The description lists parameter categories (name, service, pipeline status, etc.) but does not explain individual parameters, their constraints, or how they relate. It lacks sufficient detail for correct parameter usage.

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

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

The description clearly states the action of adding a vendor to a live event's production graph and lists the types of fields included. However, it does not distinguish this tool from similar sibling tools like add_sponsor or add_talent, missing explicit differentiation.

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

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

The description specifies prerequisites: requires event_id and name, and that the user must be a host. However, it does not provide guidance on when to use this tool versus alternatives, nor 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?

Beyond the annotations (which only indicate non-readonly, non-destructive), the description adds behavioral details: adopted codes keep prior usage count, skipped codes are not errors, and the call is limited to 100 codes. This provides meaningful transparency.

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

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

The description is two sentences, no wasted words. First sentence explains the core action, second adds constraints and prerequisites. Information is front-loaded and efficient.

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

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

Given the tool has 3 required parameters and no output schema, the description covers behavior, constraints, and prerequisites well. It implicitly handles error cases by noting skipped codes. Some minor gaps (e.g., no mention of error responses) are acceptable for this level of 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 the description must compensate. It explains that code_ids must be 'standalone' promo codes and that they adopt the profile's discount while keeping usage. This adds semantics beyond the schema's basic field types and 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 clearly states the tool reassigns standalone promo codes into a discount profile, preserving usage count. It distinguishes from siblings like add_codes_to_profile and remove_codes_from_profile by specifying 'standalone' and 'already in a profile' behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 tells when to use (to adopt codes into a profile), lists constraints (max 100, requires host status), and mentions skipped cases (codes already in profile or linked to affiliate). It does not explicitly name alternatives or state when not to use, 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?

The description discloses atomic behavior, refusal of payout submissions, and slot conflict handling. Since annotations (readOnlyHint=false, etc.) provide no safety profile, the description adds necessary behavioral context. It could mention side effects like notifications or event state updates.

Agents need to know what a tool does to the 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, front-loading the main action and following with constraints. It avoids unnecessary detail, though the first sentence is long and could be split for readability.

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

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

With no output schema, missing return value information limits completeness. The description covers purpose, constraints, and conflict behavior but lacks success response details and full explanation of nested parameters like assign_space.

Complex tools with many parameters or behaviors need more documentation. 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 highlights required parameters community_id and event_id, and implies the assign_space object handles venue booking. However, schema coverage is 0% and the description does not explain each parameter in detail, leaving some ambiguity 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 tool approves a pending event submission in an atomic action, covering listing, deal terms, and space booking. It distinguishes from sibling tools like reject_community_event and list_pending_community_events, and specifies the verb and resource exactly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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-not-to-use guidance (refuses payout-routing submissions) and hints at atomicity and conflict handling. It mentions required roles (creator/admin/moderator) but does not compare directly with alternatives like accept_deal or submit_event_to_community.

Agents often have multiple tools that could apply. Explicit usage 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 it's not read-only or destructive. The description adds context: issues comp ticket, notifies, and is capacity-limited. No contradiction.

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

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

Two efficient sentences: first states action and effect, second gives usage guidance. No 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?

Covers prerequisites, required IDs, and authorization. No output schema, but description is adequate for a simple approval tool. Could mention failure cases.

Complex tools with many parameters or behaviors need more documentation. 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 explains that request_id, user_id, ticket_class_id come from list_guest_requests. Adds semantic context but lacks details on constraints or meaning of each parameter.

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

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

The description clearly states the verb 'approve', the resource 'guest request on waitlist', and the effect 'issues a capacity-limited comp ticket and notifies them'. It distinguishes from siblings 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?

Provides explicit instructions: get IDs from list_guest_requests, requires event_id, and must be a host. Could explicitly mention 'deny_guest_request' as alternative but still clear.

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

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

Annotations already indicate it is a write operation (readOnlyHint false) and non-destructive (destructiveHint false). The description adds that it adds the user as a member, but does not cover idempotency, error handling for duplicate approvals, or side effects beyond that.

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

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

Single sentence, front-loaded with the main action, and includes necessary prerequisite information. 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 simple approval tool with two parameters and no output schema, the description covers purpose, prerequisites, and outcome. It lacks guidance on edge cases like idempotency or already-approved requests, but this is acceptable given the tool's simplicity.

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

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

Schema coverage is 0%, so the description must compensate. It mentions community_id and user_id but provides no additional meaning beyond the schema's type and length constraints. With only two required parameters, this is adequate but minimal.

Input schemas describe structure but not intent. Descriptions should explain 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 (approve), the resource (join request), and the effect (adds them as a member). It differentiates from sibling tools like reject_join_request by spelling out the outcome.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 the prerequisite that the user must be creator or admin, which is key context. However, it does not explicitly discuss when not to use it or alternative tools like reject_join_request, but the sibling list implies 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 adds behavioral context beyond annotations: it reveals the termination of member terms prospectively and labels the action as 'Terminal'. Annotations already indicate destructiveHint=true, so the description enriches the agent's understanding of consequences.

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

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

The description is a single, front-loaded sentence that efficiently conveys the core action, consequence, and required parameters. Every word 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?

Given the tool's simplicity (2 params, no output schema, destructive), the description covers the basic purpose and required inputs. However, it omits expected outcomes (e.g., success/failure), error conditions, or effects on related entities, leaving some gaps for an agent to infer.

Complex tools with many parameters or behaviors need more documentation. 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 only states that community_id and profile_id are required, without explaining their roles or constraints. No additional semantics like format, source, or validation rules are provided.

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

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

The description clearly states the action ('Archive') and the resource ('partner profile'), and distinguishes it from sibling tools like create_partner_profile, update_partner_profile, etc. The phrase 'ends every member's terms prospectively' adds specific scope.

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

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

The description specifies required parameters ('Requires community_id + profile_id') and notes the tool is 'Terminal', implying irreversible action. However, it does not explicitly state when to use this tool over alternatives (e.g., update_partner_profile) or provide contextual cues for appropriate usage scenarios.

Agents often have multiple tools that could apply. Explicit usage 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: notes reversibility ('Reversible'), which is critical since destructiveHint=true might imply permanent destruction. Also clarifies scope ('live event you manage'). 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, no filler. Action first, then key traits (reversible, prerequisites). Efficient and easy to parse.

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

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

Covers main behavioral aspects (action, reversibility, prerequisites). Lacks details about effects on existing ticket sales or whether the tier is hidden vs. soft-deleted. For a simple archive tool, it is largely complete but could be slightly more thorough.

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

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

Schema coverage is 0%, so description carries full burden. Merely states 'requires event_id + tier_id' without explaining their meaning (e.g., what constitutes a valid tier_id? How to obtain them?). 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?

Clearly states the action 'Archive a ticket tier' with the parenthetical 'take it off sale' providing an explicit synonym. Distinguishes from siblings like 'delete_ticket_tier' and 'unarchive_ticket_tier' by mentioning reversibility.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 prerequisites: 'on a live event you manage' and 'you must be a host'. Lists required parameters. Implicitly contrasts with alternatives (e.g., delete_ticket_tier), but does not explicitly state when not to use it (e.g., if tier is already archived).

Agents often have multiple tools that could apply. Explicit usage 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 claims the tool is 'idempotent on the same space+slot', but the annotations set idempotentHint to false, creating a direct contradiction. This reduces transparency as the agent cannot trust the behavioral claim.

Agents need to know what a tool does to the 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 that conveys necessary information without redundancy. Each sentence adds value, but the structure could be improved with bullet points or separate sentences 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?

For a tool with 5 required parameters and no output schema, the description covers behavioral details (atomicity, conflict handling, reassignment logic) and required inputs. It fully explains the tool's operation and 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 adds context for all 5 parameters by stating they are required and mentioning ISO format for times. However, it does not individually describe each parameter's role or constraints beyond what is in the schema.

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

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

The description clearly specifies the verb 'ASSIGN' and the resource: an approved event to a venue Space and slot. It distinguishes this tool from siblings like unassign_event_from_space by describing the core action of booking/reassignment.

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

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

The description provides clear context on when to use the tool (assign/reassign events to a space slot) and notes that overlapping slots in different rooms are acceptable. It implies the tool is for booking, not releasing, but does not explicitly 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 provide minimal behavioral hints (readOnlyHint=false). The description adds that team.memberCount stays in sync and mentions 'host' at the end, implying authorization requirements but not explicitly. It does not discuss rate limits, reversibility, or detailed side effects beyond the count sync.

Agents need to know what a tool does to the 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 and front-loaded with the main purpose, followed by entity-relation mappings. It avoids fluff but could be more structured (e.g., bullet points) to improve readability. Every sentence adds value, though the final 'host' fragment is somewhat ambiguous.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 six required parameters, no output schema, and sparse annotations, the description covers core usage and entity mappings but omits return value, error handling, and authentication details. It is sufficient for a user familiar with the domain but lacks completeness for an AI agent needing clear expectations.

Complex tools with many parameters or behaviors need more documentation. 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 adds significant context: it lists entity types and their corresponding relations, explains member identification (mode_id or name), and notes the op enum values. However, it does not elaborate on event_id, item_id, or the specifics of the member object (e.g., format 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 clearly states the tool assigns a person to a production item, and provides explicit mappings of entity types to their roles (e.g., teams->members/leads). This distinguishes it from sibling tools like 'add_guest' or 'invite_team_member' which operate on different resources.

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

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

The description explains how to identify the member (by mode_id or name) and the operations (set/add/remove). It mentions synchronization of team.memberCount and required parameters. However, it does not explicitly state when to use this tool over alternatives like 'add_profile_member' or 'remove_community_member', 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?

The description mentions 'Stored as a name snapshot', which hints at behavior, and lists required parameters. However, it does not disclose side effects, permissions needed, or idempotency. Annotations provide no additional hints (readOnlyHint false, destructiveHint false), so the description carries the burden but is incomplete.

Agents need to know what a tool does to the 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 sentences) but the second sentence is fragmented ('Stored as a name snapshot. op set/add/remove.'). It lacks clear structure and the term 'host' is unclear. Could be more readable without sacrificing length.

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

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

Given the tool's complexity (5 parameters, 6 entities, 3 ops) and no output schema, the description is too minimal. It omits return values, error handling, and full behavioral context. An agent would struggle to use it correctly without additional information.

Complex tools with many parameters or behaviors need more documentation. 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 minimal parameter context beyond listing names. It notes 'Stored as a name snapshot' for role_id but does not explain op, entity, item_id, or event_id formats or semantics. The cryptic 'host' at the end is confusing. This does not compensate for the poor 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 verb 'assign' and the resource 'role to production item,' specifying the entity types (tasks, receipts, etc.) and distinguishing between single and multiple items. It also lists the operations (set/add/remove). This provides a specific purpose that differentiates from generic role management 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 does not explicitly state when to use this tool versus alternatives like add_role. It mentions 'op set/add/remove' but provides no guidance on choosing among them or when not to use the tool. No prerequisites or exclusions are given.

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

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

Discloses important behaviors beyond annotations: counts against plan cap, skips duplicates/invalid rows with reasons, maximum of 500 codes, and host requirement. 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 concise sentences conveying all critical information without redundancy. Essential details are front-loaded and each 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 good annotations and schema structure, the description lacks details on the complex array parameter and does not mention return values. Given no output schema, the description is insufficient for an agent to fully understand usage.

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

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

Schema has 0% description coverage. Description only explains event_id and the high-level concept, but provides no details about the 'codes' array structure, its required sub-fields (code, discount_type, etc.), or their 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 specifies the action (create), resource (promo codes), and scope (up to 500 on a live event). It differentiates from sibling tools like 'create_promo_code' by highlighting batch capacity and skip behavior.

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

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

Provides clear context: use for bulk creation on live events, requires event_id and host status. However, it does not explicitly state when to use this vs. alternatives or provide exclusion criteria.

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

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

Description discloses that the tool sends emails and counts against the affiliate plan cap, which adds behavioral context beyond annotations. Annotations only indicate readOnlyHint=false and destructiveHint=false, so the description compensates well, though idempotency and error handling are not discussed.

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

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

Two efficient sentences with no filler. The first sentence gives the core purpose and limits; the second adds side effects and requirements. Perfectly front-loaded.

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

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

With 9 parameters, no output schema, and no parameter descriptions, the description is incomplete. It covers only the core function and required parameters, leaving optional parameters undocumented. For a tool with this complexity, more detail is needed.

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

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

Schema description coverage is 0%. The description only mentions event_id and emails as required but provides no explanation for the other 7 parameters (starts_at, expires_at, code_prefix, discount_type, etc.). Agents are left guessing their meaning, which is 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 (invite), resource (affiliates to a live event), and constraints (up to 200, via email, with shared discount/commission). This distinguishes it from sibling tools like add_affiliate (individual) or send_invitations (general invites).

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 (must be a host, requires event_id and emails) and side effects (counts against plan cap, sends email). It doesn't explicitly state when not to use or compare to 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?

Beyond the annotations (destructiveHint=true), the description adds critical context: 'Irreversible and outward-facing' and lists specific side effects (cleans up invites, affiliates, broadcasts). This fully discloses the behavioral impact beyond what annotations alone provide.

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

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

The description is extremely concise (two sentences) and front-loads the essential action and effects. Every sentence adds value: first the action and cleanup, second the irreversibility 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 the tool has no output schema, the description covers the main purpose, side effects, and prerequisites. However, it lacks any detail about the 'reason' parameter and does not mention what the response or confirmation looks like. For a simple mutation tool, it is close to complete but has a small 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?

The schema has 0% description coverage for its 2 parameters. The description only states that event_id is required, but does not explain the purpose of the 'reason' parameter (maxLength 500). The user must infer from the tool name or schema that reason is optional and likely for display. This is insufficient.

Input schemas describe structure but not intent. Descriptions should explain 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 'cancel' and the resource 'live event', with specific scope 'you manage'. It details the effects (marks cancelled, removes from public discovery, cleans up invites/affiliates/broadcasts), which distinguishes it from sibling tools like update_event or delete_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 includes prerequisites ('requires event_id; you must be a host') and implies use for live events the user manages. However, it does not explicitly say when not to use this tool or name alternative tools among the extensive sibling list for similar actions like archiving or cancelling in a series.

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

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

The description adds valuable behavioral details beyond annotations: 'stops future batches; already-scheduled emails still deliver' and requires host role. No contradiction with destructiveHint=true.

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

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

Two sentences, front-loaded with action, no fluff. 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?

For a simple tool with two required params and no output schema, the description covers the key behavioral outcome and role requirement. Complete enough.

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

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

The description mentions required parameters but does not explain their meaning or format beyond what the schema provides. Given 0% schema coverage, more detail could help, but parameter names are self-explanatory.

Input schemas describe structure but not intent. Descriptions should explain 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 'Cancel', the resource 'invitation send/job', and specifies scope ('running or scheduled', 'stops future batches'). It distinguishes from siblings like 'send_invitations' and 'get_invitation_status'.

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

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

The description indicates when to use (to cancel an invitation job) and prerequisites (event_id + job_id, must be a host). It does not explicitly mention alternatives or when not to use, 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 convey destructiveness; description adds that the invite must be pending and that authorization is host-only, 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, front-loaded with purpose, efficient and to the point.

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

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

Simple tool with clear parameters and no output schema; description covers purpose, usage, authorization, and alternatives; complete for the task.

Complex tools with many parameters or behaviors need more documentation. 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, but description only reiterates required parameters without explaining their meaning or format; parameter names are self-explanatory but minimal added value.

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

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

Description clearly states verb 'cancel' and resource 'pending team/staff invite', and distinguishes from removing an accepted member via demote_staff_to_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?

Specifies when to use (before acceptance), provides explicit alternative (demote_staff_to_guest), and lists requirements (event_id + invite_id, must be 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?

Discloses toggle behavior and ability to undo with checked_in=false, and host requirement. No annotation contradictions; annotations are neutral. Minor gap: no mention of side effects like notifications or state changes beyond the toggle.

Agents need to know what a tool does to the 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, no redundant information. Every sentence serves a purpose.

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

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

Covers core functionality, requirements, and parameter semantics. Missing output schema, but description is sufficient for typical use. Slight lack of post-check-in behavior detail.

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

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

Adds meaning beyond schema: explains checked_in parameter as toggle/undo mechanism. Schema coverage is 0%, so description compensates with usage context. Could elaborate on event_id and guest_id roles.

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

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

Clearly states it checks a guest in/out by toggling ticket status, and distinguishes from siblings like check_in_plus_one by specifying 'a guest' and 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?

Explicitly requires event_id and guest_id, and notes host requirement. Lacks explicit when-not-to-use or alternative tools, but context from siblings suggests check_in_plus_one for plus ones.

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

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

Annotations indicate readOnlyHint=false (write operation) and destructiveHint=false (not destructive). The description adds behavioral context: the tool fails if the plus-one limit is reached, and requires host role. No contradictions with annotations.

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

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

The description is two sentences with no unnecessary words. It places the core action first, then lists requirements and role. Every part 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?

For a simple three-parameter tool with no output schema, the description covers the essential aspects: action, failure condition, required inputs, and user role. It does not mention return value or name match format, but these are minor gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It lists the three required parameters by name but provides no additional semantics, formatting, or examples for event_id, parent_guest_id, or plus_one_name.

Input schemas describe structure but not intent. Descriptions should explain 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 'check in', the resource 'one of a guest's allowed plus-ones', and the scope 'at a live event you manage'. It distinguishes from sibling tools like 'check_in_guest' by specifying plus-one-specific behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 lists required inputs (event_id, parent_guest_id, plus_one_name) and a precondition (you must be a host). It also states the failure condition (at plus-one limit). However, it does not explicitly name alternatives or when to use this tool over others.

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

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

Annotations indicate read-only, idempotent, and non-destructive behavior, which the description reinforces with 'Read-only' and elaborates on the return types (available, hard, soft) and local-time ranges. This adds value beyond annotations by explaining booking semantics (first approval wins) and the soft-listed hours verdict.

Agents need to know what a tool does to the 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 communicates the main purpose and key details, but the use of a semicolon to list statuses makes it slightly dense. It is front-loaded with the primary action.

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

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

The description explains the return values (available, hard, soft, soft-listed-hours verdict) and mentions local-time ranges, providing a solid understanding of the output. Without an output schema, this level of detail is adequate for a query tool.

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

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

The description lists the four required parameters and specifies that times should be in ISO format, but does not clarify what community_id and space_id represent or the expected format of the time strings beyond ISO. Since schema description coverage is 0%, the description provides basic context but lacks depth.

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

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

The description clearly states the tool checks venue space availability for a specific time slot, with explicit details on booking statuses (hard, soft) and verdicts. It distinguishes itself from sibling tools like 'list_bookings' by focusing on availability checking rather than listing all bookings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 parameters (community_id, space_id, start_time, end_time) and implies it should be used before booking, but it does not explicitly state when not to use this tool or suggest alternative tools for other scenarios.

Agents often have multiple tools that could apply. Explicit usage 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, and the description adds that the tool creates the account and returns an onboarding URL. It also mentions the need for a connected account. There is no contradiction. The description provides additional behavioral context beyond annotations.

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

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

The description is three concise sentences, with the main action first, followed by side effects and prerequisites. Every sentence adds value and there is no redundancy or fluff.

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

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

While the description covers the main action and prerequisites, it lacks explanation of the input parameter and the return value (no output schema). Given the tool's complexity (creating a Stripe account), more details about the process or error conditions 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?

The single parameter 'return_path' has 0% schema description coverage, and the description does not explain its purpose or allowed values. Since schema coverage is low, the description should compensate but fails to do so. The parameter is left undocumented in the description.

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

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

The description clearly states the tool gets a Stripe Connect onboarding link, creates the Stripe account, and returns the onboarding URL. It distinguishes from siblings by specifying its role in enabling payouts for ticket sales, which is a unique purpose among many sibling tools.

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

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

The description includes explicit usage guidance: 'Check get_account_status first' and 'Requires a connected account.' This helps the agent know prerequisites and when to call this tool. However, it could be more explicit about when not to use it (e.g., if account already connected).

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

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

Annotations indicate a write operation (not read-only, not destructive). The description adds value by noting the plan cap consumption and host authorization requirement, which are behavioral traits 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?

Two sentences efficiently convey the core purpose, constraints, and key parameters. Could be improved with structured formatting but is already concise and front-loaded.

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

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

Given the complexity (9 params, nested object, no output schema), the description provides high-level purpose and constraints but lacks details on return values, the structure of the 'tiers' parameter, and complete parameter listing. Some gaps remain 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?

The schema has 0% description coverage for 9 parameters, including a complex nested object. The description only lists a few parameters (tiers, code_prefix, max_affiliates, commission, start/expiry) but omits 'profile_name' and does not explain the structure of the 'tiers' object, leaving ambiguity 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 tool creates a reusable 'open' affiliate profile, distinguishing it from 'add_affiliate' for specific individuals. The verb 'Create' and resource 'affiliate profile' are explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 requirements (event_id, tiers, host role) and plan cap constraints. It implicitly distinguishes from 'add_affiliate' for self-join vs specific assignment, but lacks explicit when-not-to-use guidance.

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

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

Annotations already indicate this is a mutation (readOnlyHint=false). The description adds value by mentioning that it counts against a plan cap and requires a connected account, providing useful behavioral context beyond the annotations. There is no contradiction.

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

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

The description is concise with two sentences: the first lists fields, the second adds constraints. It is well-structured and front-loaded with essential information, 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?

The description covers the inputs well but does not explain the return value or error conditions. Given the tool has 8 parameters and no output schema, there is room to provide more context about what happens after creation, such as success confirmation or error 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?

The schema has 8 parameters with 0% description coverage. The description lists the main parameters (name, description, category, privacy, tags, icon/cover) but does not add details like constraints or formats. Given the low coverage, the description should provide more semantic information, but 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 creates a community and lists the fields that can be set. While it distinguishes from 'update_community', it does not explicitly differentiate from other creation tools like 'create_event_draft' or 'create_form', but the purpose is still 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 mentions that creation counts against the community plan cap and requires a connected account, giving some context. However, it does not explicitly state when not to use it or provide alternatives, so the guidance is implied but not thorough.

Agents often have multiple tools that could apply. Explicit usage 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 behavioral context beyond annotations: clicks are counted, link opens specific page types. However, does not disclose potential side effects or whether the operation is reversible. Annotations are neutral so description fills some gaps but not all.

Agents need to know what a tool does to the 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 wasted words. Purpose is front-loaded, efficient delivery of key information. 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?

For a simple creation tool with no output schema, the description covers inputs, behavior, and constraints. Missing any mention of return value or errors, but overall adequate given the tool's complexity and sibling context.

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

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

Despite 0% schema description coverage, the description adds meaning for 'source' (instagram, newsletter), 'campaign' (optional), and implies 'target_type' (public or immersive). 'event_id' is mentioned as required. Compensates well for lack of parameter comments in 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 verb 'create' and resource 'trackable share link', explaining its function (tag with source/campaign, click counting, opens public/immersive page). Distinguishes from numerous sibling tools by specifying the unique purpose of creating a trackable link for live events.

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

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

States prerequisite 'Requires event_id; host only' but does not provide guidance on when to use versus alternatives or when not to use. No mention of when other tools might be more appropriate.

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

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

Annotations already provide idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds valuable context: the draft is private until the claim link is confirmed, and connected users get direct publishing with a manage link. 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 three concise sentences, front-loaded with the core purpose, followed by usage context and the connected-user variant. Every sentence earns its place with no redundant or verbose 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?

The description covers the high-level workflow and return link, but for a tool with 19 params and no parameter descriptions, it is under-specified. It omits parameter semantics, required-field context, and details about the claim link, making it incomplete for reliable use.

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

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

The schema has 19 parameters with 0% description coverage, and the description provides no parameter-level guidance. It does not explain required fields like idempotency_key, event_name, starts_at, visibility, ticket_mode, nor the enum values. This is a significant gap for correct invocation.

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

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

The description clearly identifies the action (create event draft), the resource (event draft), and the unique claim-link mechanism. It distinguishes this tool from siblings like create_event_series and update_event_draft by focusing on draft creation with a claim-link publish flow.

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

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

Explicitly states when to use: 'Use when a user wants to create or publish an event' and notes it works even without a SocialLoop account. It differentiates the connected-user flow but does not explicitly mention when not to use or name alternative tools, so it lacks full 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?

Annotations show readOnlyHint=false, destructiveHint=false, etc. The description adds behavioral details: 'The source becomes occurrence 1; the rest are created on cadence with its tickets/promo/forms replayed.' Also states host requirement. No contradiction.

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

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

Two sentences with no wasted words. First sentence states core function and parameters; second sentence adds critical details about behavior and requirements. Perfectly front-loaded.

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

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

No output schema, but description explains what happens (source becomes occurrence 1, replayed tickets/promo/forms). It covers key aspects for a creation tool, though it doesn't mention how to later manage the series or error conditions.

Complex tools with many parameters or behaviors need more documentation. 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 4 parameters with 0% description coverage. Description explains pattern (daily/weekly/biweekly/monthly) and end (end_after or end_date). It implicitly describes source_event_id but doesn't detail constraints. Provides enough meaning beyond schema.

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

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

The description clearly states the tool's purpose: 'Turn an existing event into a recurring series' with specific pattern and end conditions. It distinguishes from sibling tools like duplicate_event and create_event_draft by focusing on series creation from an existing 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 provides clear usage context: requires source_event_id + pattern and host status. It implies when to use (to create a recurring series) but does not explicitly mention when not to use or alternatives, though siblings like manage_event_series exist for editing.

Agents often have multiple tools that could apply. Explicit usage 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 no destructive or idempotent behavior, and the description adds that creation results in a draft state, linking to a separate activation tool. It does not contradict annotations and provides useful behavioral context beyond the structured fields.

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

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

The description is extremely concise, using only two sentences. It front-loads the core purpose and immediately follows with key constraints and behavioral notes, with no filler words.

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

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

Given the tool's complexity (3 parameters, nested array) and no output schema, the description covers creation, draft state, activation requirement, and host prerequisite. It omits potential error cases or limits but is sufficient for typical usage.

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

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

Schema coverage is 0%, so the description bears the burden. It lists the main parameters (event_id, name) and enumerates question types and their properties (options, required, placeholder). However, it does not fully detail the structure of the questions object or all schema properties, leaving some 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 it creates a registration/intake form for a live event, specifying the verb 'Create' and the resource 'form'. It lists supported question types and distinguishes from related tools like set_form_active and update_form.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 that forms start as draft and require activation via set_form_active, and that the user must be a host. It provides clear when-to-use context but does not explicitly exclude alternative tools or state when not to use it.

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

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

Annotations indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds behavioral context by stating that members added/invited to the profile automatically receive its split terms, which goes beyond the annotations.

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

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

The description is extremely concise: two sentences that convey purpose, an example, prerequisites, and required fields. No extraneous information, and the key points are front-loaded.

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

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

For a tool with 3 parameters, no output schema, and simple annotations, the description covers purpose, prerequisite, required fields, and a behavioral trait. It does not mention return values or error conditions, but it is largely complete for an agent to understand when and how to use it.

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

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

With schema description coverage at 0%, the description compensates by explaining that terms.member_share_pct is a percentage (with example '75%') and lists the three required parameters. It could elaborate on constraints like maxLength for name, but it provides enough semantic context for basic usage.

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

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

The description clearly states that the tool creates a partner profile, which is a named terms-group. It gives a concrete example ('Resident DJs · keep 75%') and explains the auto-assignment of split terms to members. This distinguishes it from update, archive, or list 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 lists prerequisites ('Needs the community's Stripe connected') and required fields (community_id, name, terms.member_share_pct). It implicitly conveys when to use (when creating a new partner profile) but does not explicitly mention when not to use or provide alternative tool names.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, so description adds value by stating 'you must be a host' and explaining that the fields object holds entity-specific details like milestone fields.

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

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

Three sentences, front-loaded with purpose. The first sentence is long but necessary to list entities. 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 6 parameters, the description adequately covers the creation action, requirements, and field usage. Could mention return value or success indication, but overall 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 coverage, the description compensates by explaining name, optional status, notes, and the fields object with an example (milestones {target_date, category, phase}). It does not detail event_id or entity beyond listing, but provides solid 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's purpose: creating a production item in any area of a live event, enumerating entities. While it does not distinguish from siblings directly, it explicitly says 'USE THIS for milestones — a milestone is NOT a task,' offering some differentiation from task creation 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 provides clear context on when to use: for any entity type listed, and requires event_id, entity, name, and host status. It hints at not using for tasks by noting milestone ≠ task, but doesn't fully 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?

The description aligns with annotations (not read-only, not destructive) by stating it creates a promo code. It adds the behavioral nuance that the code can be applied to a live event or draft. However, it does not disclose potential side effects (e.g., duplicate code handling, rate limits) beyond what annotations provide.

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

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

The description is extremely concise with two sentences, front-loading the main action and key parameter choices. Every word adds value, and there is no redundancy.

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

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

For a creation tool with 11 parameters and no output schema, the description covers the essential intent and identifier options but omits details about optional parameters (e.g., applicable_classes, timing). Given the complexity, it provides a minimal viable understanding but lacks completeness for nuanced use.

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

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

The description only adds semantics for event_id, draft_id, edit_token, and discount_type (percent or fixed), but the schema has no parameter descriptions (0% coverage). The remaining 7 parameters (enabled, max_uses, starts_at, expires_at, discount_value, applicable_classes) are not explained, leaving 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 verb 'Create' and the resource 'discount/promo code', and specifies the context (on a live event or unclaimed draft). It distinguishes from sibling tools like bulk_create_promo_codes and create_promo_profile by indicating the target entity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 guidance on using either event_id or draft_id + edit_token, which is helpful. However, it does not specify when to use this tool over siblings like bulk_create_promo_codes or update_promo_code, nor does it cover prerequisites like authentication or ownership.

Agents often have multiple tools that could apply. Explicit usage 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 that it counts against the plan's discount-profile cap, which is not indicated by annotations. Also states the host requirement. Annotations only provide false booleans, so description adds valuable behavioral context.

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

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

Two sentences efficiently convey purpose, usage, and constraints. First sentence front-loads the key information. No redundant or filler content.

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

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

Given the moderate complexity (6 params, nested objects, no output schema), the description covers creation behavior, required fields, auth, and plan limits. It omits the return value but that is acceptable. Overall, it provides sufficient context for an agent to decide and invoke the tool.

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

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

With 0% schema description coverage, the description explains the tiers parameter structure (ticket_class_id → percent/fixed) and groups optional params as 'max uses + schedule'. Adds meaning beyond raw schema, though individual optional params (profile_name, dates) are 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?

Description clearly states the verb 'create' and resource 'promo profile' on a live event, distinguishing it from siblings like 'create_promo_code' and 'update_promo_profile'. It explains the concept (reusable per-tier discount config) and relationship to 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?

Provides clear context: requires event_id and tiers, and user must be a host. Implicitly distinguishes from create_promo_code by describing the profile as something codes attach to. Lacks explicit when-to-use versus alternatives exclusion, but context is strong.

Agents often have multiple tools that could apply. Explicit usage 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 behavioral context beyond annotations by explaining the two different outcomes (close thread vs keep active). Annotations only give basic hints, but description could disclose more side effects (e.g., notifications).

Agents need to know what a tool does to the 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 and key distinctions. 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 main behaviors and scenarios. Lacks details on return values, error handling, or prerequisites beyond deal_id. Adequate for typical use given moderate 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 has 0% description coverage, so description must compensate. It mentions 'optional reason' but does not explain its purpose or usage. The required 'deal_id' is already in schema, adding no new meaning.

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

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

Description uses specific verb 'Decline' and resource 'deal's pending terms', and distinguishes two scenarios (first-proposal vs renegotiation), which clearly differentiates from siblings like 'accept_deal' and 'end_deal'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 on when to use: first-proposal declines close thread, renegotiation keeps deal active. However, no explicit exclusions or alternatives like 'end_deal' for permanent termination.

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

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

Annotations already include destructiveHint=true, confirming destructive nature. The description adds context about permanence and provides an alternative for hiding. 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: first states purpose with examples, second provides alternative and requirements. Front-loaded and efficient, 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?

Covers key aspects: action, entities, alternative, prerequisites. No output schema exists, so return value not expected, but the description could mention irreversibility more explicitly (already implied by 'permanent').

Complex tools with many parameters or behaviors need more documentation. 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 lists the three required parameters and notes the host requirement, but does not elaborate on each parameter's meaning or format beyond what is in the schema. Some value added but limited.

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

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

The description clearly states 'Permanently delete a production item' and lists many entity types, making the action specific. It distinguishes from the sibling tool 'update_production_item' which hides instead of deletes.

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

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

The description explicitly states when to use this tool (for permanent deletion) and when not ('To merely hide it, use update_production_item active:false instead'). It also lists prerequisites: 'Requires event_id + entity + item_id; you 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?

Discloses destructive nature and details code resolution behavior, adding significant context beyond the annotations' destructiveHint. 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, no fluff. First sentence covers purpose and action, second covers requirements. Efficient and well-structured.

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

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

Covers main behavior, parameters, and prerequisites. Lacks mention of return value or success indication, but for a delete operation this is tolerable given no output schema.

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

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

With 0% schema coverage, description fully explains the required parameters (event_id, profile_id) and the action enum (detach vs delete_codes with their effects), filling the gap left by the schema.

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

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

Clearly states it deletes a discount profile and resolves its codes, with specific behavior for 'detach' and 'delete_codes' actions. Distinct from sibling tools like create, update, or list promo profiles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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, profile_id, and host role. Does not compare to alternatives like remove_codes_from_profile, but context is clear enough for use-case selection.

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

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

Annotations already indicate destructiveHint=true. The description adds important context: permanence ('Irreversible') and the conditional logic based on ticket sales, which goes well beyond the annotation alone.

Agents need to know what a tool does to the 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, front-loaded sentence with a dash and semicolon for structure. Every word is necessary; no wasted text. It efficiently conveys action, condition, and 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?

Given no output schema and simple destructive action, the description covers the core behavior, condition, and prerequisites. However, it's slightly ambiguous whether the tool automatically archives if tickets are sold or errors out. This is a minor gap in a otherwise complete description.

Complex tools with many parameters or behaviors need more documentation. 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% (no descriptions in input schema). The description only says 'Requires event_id + tier_id', which adds minimal meaning beyond the parameter names. For a delete tool, the purpose of these parameters is clear from context, but the description should explain that tier_id identifies the ticket tier within the event.

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

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

The description clearly states the action ('Permanently delete a ticket tier') and includes a conditional qualifier ('only if no tickets were sold') that distinguishes it from related tools like archive_ticket_tier. It also specifies required parameters and authorization.

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