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?

Annotations already flag this as destructive, non-idempotent and open-world, and the description adds meaningful context on top: the approval gate, the preview/confirm requirement, and the fact that a migrate call uses a 'fresh previewMigration reviewHash and stable requestId', which tempers the non-idempotent hint. It also confirms delivery/consent safeguards stay in force, though it never spells out what is actually destroyed or the blast radius of each action.

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

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

Front-loaded with the approval condition, then the four action variants, then the confirmation rule and the guide pointer — a logical order with little filler. It is dense and compressed into a small number of long clauses, which slightly hurts scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 high-risk multi-action mutation with no output schema, the description covers the approval prerequisite, the preview-before-confirm discipline, safeguard guarantees, and points to the workflow guide resource. The gaps are per-action guardrails (what each action irreversibly changes) rather than anything missing about calling 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 coverage at 67% and `payload` being an open free-form object, the description carries real weight by naming the significant keys (flowId, expectedRevision, reviewHash, expectedVersion, expectedCount, requestId, cursor) and tying reviewHash/requestId to specific actions. It still leaves the exact per-action payload contract partially inferential.

Input schemas describe structure but not intent. Descriptions should explain 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 names four concrete operations (activate a reviewed flow, resume a paused flow, startAudience, migrate paused enrollments) mapped to the `action` enum, so the resource and verbs are unambiguous. It does not, however, explicitly differentiate itself from adjacent siblings like edit_email_sequence, inspect_email_sequence, or send_email_campaign.

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

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

It states a real precondition ('With the organizer's explicit approval') and an operational rule ('Show the exact version, emails, people and timing before confirmation'), which implies when this tool is appropriate. But no alternative tool is ever named, and there is no guidance on when to choose activate vs resume vs startAudience vs migrate beyond the one-line enumeration.

Agents often have multiple tools that could apply. Explicit usage 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 already indicate a non-read-only, non-idempotent, non-destructive mutation. The description adds valuable behavioral context: Stripe must be connected for paid tiers, the event must be live, and host authorization is required. No contradiction with annotations.

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

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

Two sentences, front-loaded with the core purpose and followed by critical prerequisites. Every clause adds useful information without redundancy.

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

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

Covers the core behavior, required parameters, key options, and prerequisites. It lacks explicit error conditions and doesn't describe max_per_person/description, but for an 8-parameter mutation tool with no output schema, it is largely sufficient.

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

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

Schema description coverage is 0%, so the description carries the parameter-meaning burden. It explains price (0 = free RSVP), capacity, approval, secret unlock code, and event_id, but does not address max_per_person or description. Partial compensation with clear 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?

Description clearly states the action: adding a ticket tier to a live event, with specific detail on free vs paid, capacity, approval, and secret code options. This distinguishes it from sibling tools like update_ticket_tier, delete_ticket_tier, and list_ticket_tiers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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: paid tiers require Stripe, event_id is required, and the caller must be a host. It does not explicitly mention alternatives or exclusions, but the prerequisites and conditions are strong enough to guide 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 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?

Annotations only flag destructiveHint=true and idempotentHint=false; the description goes well beyond them by disclosing concrete side effects: existing members keep their plan and renewals, scheduled switchers are retained, and affected members are emailed. It also states the authorization requirement, which annotations do not carry.

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

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

Four short sentences, each carrying distinct information: the action, the side effects, the undo path, and the preconditions. The core action is front-loaded and nothing is padding.

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

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

For a destructive two-parameter mutation with no output schema, the description covers what changes, what is preserved, who gets notified, how to reverse it, and who may call it. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 0%, so the description must compensate for two undocumented parameters, and it does not. Saying 'Requires community_id + tier_id' merely restates the schema's required array with no format, ID-source, or lookup guidance.

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

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

States a specific verb and resource ('Take a paid membership tier off offer') with clear scope, and the name is distinguishable from the near-siblings archive_ticket_tier and unarchive_membership_tier. An agent knows exactly what this does without opening the schema.

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

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

Explicitly names the reversal path ('Undo with unarchive_membership_tier') and the permission precondition ('creator or admin only'), which is real routing guidance. It does not spell out when to prefer this over related mutations like cancel_membership or archive_ticket_tier, so it stops short of the top score.

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

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

The description 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?

Goes well beyond the annotations (destructiveHint, readOnlyHint, idempotentHint) by disclosing the critical business consequence "NO REFUND either way", that the member is emailed, that they remain a free member, and the authorization requirement (creator or admin only). This is exactly the extra context annotations cannot convey.

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

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

Front-loads the core action, then the two modes, then the critical no-refund warning, then side effects and requirements. Every sentence carries distinct information with no filler.

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

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

For a destructive mutation tool with no output schema and 0% schema coverage, the description supplies everything needed to call it correctly: mode semantics, refund behavior, side effects, and permissions. Nothing material is missing.

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

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

Schema description coverage is 0%, so the description carries the full burden and does so: it defines the semantics of the "when" enum values including which is the default, and confirms community_id and user_id as required. This fully compensates for the empty 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?

States a specific verb (Cancel) and resource (a member's paid membership) with clear scope ("in a community you run"). It explicitly distinguishes itself from the sibling remove_community_member, so an agent can route correctly without opening either schema.

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

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

Explains both operating modes with their conditions: "period_end" (default) turns renewal off while preserving paid access, and "now" ends access immediately. It also names the alternative tool (remove_community_member) and the condition that selects it, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage 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?

With annotations covering only the safety profile, the description adds substantial operational context: setup enables provider receiving but returns only child MX instructions without touching DNS/sending/tracking, existing reply destinations cannot be replaced, verification auto-refreshes and fails closed after seven days, and no email is sent or permission granted. These are real behavioral traits an agent cannot derive from 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?

Purpose is front-loaded, then prerequisites, then action semantics and caveats, with no filler sentences. The telegraphic fragment style is dense and occasionally hard to parse, but every clause carries 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 two-action, nested-payload tool with no output schema, the description covers the workflow, prerequisites, side-effect boundaries, expiry behavior and a pointer to a guide. It is nearly complete; only explicit sibling routing and return-shape expectations are missing, which is minor since setup's MX output is described.

Complex tools with many parameters or behaviors need more documentation. 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 67% and the payload is an opaque nested object, so the description compensates by naming the required fields (domainId, connected replyDomainId, expectedRevision, stable requestId) and tying them to the setup/verify actions. It also clarifies that identity comes from the connected account, which the schema only hints at.

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

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

States a specific verb+resource (configure a branded email reply domain) and enumerates the two actions, setup and verify, so an agent knows the shape of the operation. It does not explicitly contrast itself with near siblings like inspect_email_reply_domain or configure_email_tracking, leaving some differentiation to inference.

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

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

Gives an implied but clear sequence: connect the child domain through ordinary domain setup first, then use setup, add MX records, then verify. It also notes normal domain allowance applies and points to a workflow guide resource. It stops short of naming alternate tools or stating when not to use this one.

Agents often have multiple tools that could apply. Explicit usage 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, it discloses important behavioral details: setup returns DNS instructions without editing DNS or enabling measurement, existing subdomains cannot be replaced, pending updates have a two-minute lease, and choices apply to future emails without granting recipient consent. It also warns that opens and clicks may include proxies or scanners, which is valuable operational context. No contradiction with the annotations is present.

Agents need to know what a tool does to the 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 but front-loaded and each sentence carries operational information, with no obvious filler. It is somewhat heavy in clauses, but that is justified by the multi-step workflow and the need to convey permissions, retry behavior, and DNS constraints.

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

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

For a complex multi-action configuration tool with no output schema, the description supplies the workflow, prerequisites, constraints, safety caveats, and a MCP guide resource. An agent has enough context to understand the setup-verify-save sequence and the conditions under which save is permitted.

Complex tools with many parameters or behaviors need more documentation. 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 coverage at 67%, the description adds meaningful semantics beyond the schema: all actions require domainId, expectedRevision, and a stable requestId; setup additionally needs trackingSubdomain as one DNS label; save requires explicit clickTracking/openTracking booleans. It covers the main payload expectations well, though it does not fully enumerate every possible verify/save field.

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

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

The description names the specific resource and the three operations (setup, verify, save), and explains what each does in the email tracking measurement flow. It distinguishes this tool from adjacent email configuration/inspection tools by framing it as owner-confirmed measurement setup rather than a passive inspection or unrelated domain setup.

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

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

It lays out a clear ordered workflow: run setup, add returned DNS records externally, then verify before save is allowed. It also gives key conditions and constraints, such as only dns.status verified permitting save and existing tracking subdomains not being replaceable. It does not explicitly name alternative sibling tools or state when not to use this tool, so it falls short of full when/when-not 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?

Goes beyond the annotations by disclosing that this never creates visitor consent, that confirmation must follow an exact reviewed action, and that server keys live only in the web workspace and must never enter tool logs. These are real operational constraints the annotations (readOnly/destructive/idempotent hints only) don't convey.

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

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

Front-loads the action set, then per-action inputs, then safety constraints and the guide link. Every sentence carries information; the security caveat is slightly peripheral to invocation but justifiable for a write tool.

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

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

With no output schema and a nested payload, the description covers the action-dependent requirements, the confirmation precondition, and where to find the fuller workflow. Minor gaps remain on what a successful verify/disable returns, but the caller has enough to invoke correctly.

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

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

Schema coverage is 67% and the payload is an opaque nested object with only a generic description, so the description's per-action requirements (origin/name for create; siteId/revision for verify and disable) add genuine disambiguation 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?

Names three specific verbs (create, verify, disable) against a concrete resource (a website connection), immediately distinguishing it from the read-only siblings inspect_email_websites and inspect_email_website_results. An agent can tell what the tool mutates without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 gating condition ('after confirmation') and that create vs verify/disable need different inputs, plus points to a workflow guide resource. It does not explicitly say when to prefer this over the inspection siblings, but the mutating scope 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 (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description adds substantive behavioral facts: only the list owner may act, existing contacts are not overwritten, normalized duplicates can shrink the final count, and importing grants no email/text permission and sends no messages. These are exactly the side-effect and authorization details an agent needs and would not get from 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?

Dense but efficient: the action and its inputs are front-loaded, followed by authorization, side-effect, and permission caveats in short declarative sentences. Every sentence carries information, with only the resource pointer as a minor tail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 non-idempotent mutation with a nested payload and no output schema, the description covers the critical unknowns — auth requirement, overwrite behavior, count effects, and permission side effects — and points to a workflow resource. It omits what the tool returns or how failures/reviewHash mismatches are surfaced, a minor gap given no output schema exists.

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

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

Schema coverage is 67% and the generic payload description only vaguely mentions 'reviewHash where required.' The description compensates by telling the agent that confirm requires jobId plus the exact reviewHash while cancel needs only jobId, which is more actionable than what the schema conveys, though it does not fully document the remaining payload 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 states a specific verb+resource (confirm/cancel a contact import) and pinpoints the two operating modes with the exact identifying arguments (jobId and reviewHash). It distinguishes this confirmation step from the earlier analysis step it depends on, though it never names sibling tools like inspect_contact_import or import_contacts_to_list explicitly.

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

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

It gives a clear precondition — the organizer must first see the import analysis and confirm — and maps the two branches (confirm with jobId+exact reviewHash, or cancel with jobId). No explicit when-not conditions or named alternatives are provided, so it stops short of a 5.

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

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

Annotations 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?

It adds meaningful behavioral context beyond the annotations: creation counts against a community plan cap and requires a connected account. This helps the agent anticipate side effects and preconditions. There is no contradiction with annotations.

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

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

The description is brief and front-loaded with the action and resource. Every sentence adds relevant information—fields, cap impact, and account requirement—with no filler.

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

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

For a 9-parameter creation tool with a nested object, required fields, and no output schema, the description is incomplete. It does not explain all parameters, success/failure behavior, or output, and relies too heavily on the schema for essential details.

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

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

With 0% schema description coverage, the description carries the burden of parameter explanation. It names a few fields and gives the privacy enum values, but it omits important parameters like home_city and short_description, and provides no detail on required constraints or category enum values.

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

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

The description clearly states the verb ('create'), the resource ('community'), and the ownership aspect ('you own'). It also enumerates the main fields involved, making it easy to distinguish from sibling tools like update_community or list_my_communities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 useful context such as the plan cap and connected-account requirement, implying when this tool is appropriate. However, it does not explicitly name alternatives or conditions for when not to use it, leaving the usage guidance mostly implicit.

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

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

Annotations cover the safety profile (write, non-destructive, non-idempotent), and the description adds genuinely new behavioral context beyond them: the link format, that clicks are counted, that it opens the public event page, and that the caller must be host. It does not state what happens on repeat calls with the same source/campaign.

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

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

Front-loaded with the core action and tightly worded; every clause carries information. The em-dash-delimited clauses make it slightly dense but not wasteful.

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

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

No output schema, so the description reasonably carries return-side context (clicks counted, opens public page). For a 4-param mutation tool it is nearly complete; the only real gap is the undocumented target_type parameter.

Complex tools with many parameters or behaviors need more documentation. 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 source with examples (instagram, newsletter), flags campaign as optional, and names event_id as required, but says nothing about target_type, whose only enum value ('loops') is left unexplained.

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

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

States a specific verb (create) and resource (trackable share link / custom link) with scope ('for a live event') and even the link format. An agent can distinguish it from siblings like get_share_links or update_open_link_config without opening a schema.

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

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

Gives clear preconditions: 'Requires event_id; host only' and scopes the use case to a live event. However, it never names an alternative tool or an explicit when-not condition, so routing guidance is contextual rather than complete.

Agents often have multiple tools that could apply. Explicit usage 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.