lesgooo.fun

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

Annotations already mark this as a non-read-only mutation. The description adds useful behavioral context: the item is added to a shared checklist, so it is visible to all participants, and the action is taken as the participant, implying identity attribution via participant_id and token. It does not cover duplicate handling or failure modes, but these are minor gaps for this operation.

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

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

A single sentence that front-loads the action and resource, followed by a concrete example. Every word earns its place, and the example is useful without bloating the description.

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

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

For a simple 4-parameter mutation with full schema coverage, the description plus schema provide enough to know what the tool does and how to invoke it. It lacks an explicit return-value description and clear alternative-tool routing, but those gaps are minor given the straightforward operation and accessible sibling list.

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

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

Schema coverage is 100%, with descriptions for all four parameters. The description adds only an illustrative example for the text parameter and does not contribute additional semantics for plan, participant_id, or participant_token, so the baseline 3 applies.

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

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

States a specific verb ('Add') and resource ('plan's shared checklist') with a concrete example ('Bring the grill'). The action is clearly distinct from siblings like check_item (marking an item) and get_checklist (reading the checklist).

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 no explicit when-to-use guidance or alternatives. The phrase 'Acts as the participant' hints at contextual use but does not say when to prefer this tool over check_item or get_checklist, nor does it mention any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage 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 indicate non-read, non-destructive, and non-idempotent behavior; the description adds meaningful defaults ('paid_by defaults to the person you act for; split_among defaults to everyone') and the mandatory confirm-before-call behavior. It does not mention response/return behavior, but this is less critical for a mutation with no output schema.

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

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

Two sentences with no filler; the core action and equal-split behavior are front-loaded, and the confirmation requirement is stated in one compact final sentence.

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

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

For a 7-parameter mutation with no output schema, the description covers the essential behavior, defaults, and the required user confirmation, while the schema handles parameter-level detail. It could be slightly stronger by distinguishing itself from record_payment, but it is not materially incomplete.

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

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

Schema coverage is 100%, so all parameters are already documented with descriptions. The description reinforces the split_among and paid_by_participant_id defaults and adds the 'person you act for' nuance, but does not substantially add 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 opens with 'Record a shared expense, split equally,' using a specific verb and object that clearly states the tool's function. Combined with the title 'Add an expense,' it is distinct from siblings like get_expenses (read) and record_payment (payment settlement).

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

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

'Record a shared expense' gives clear context for when the tool applies, and the confirmation instruction ('Always confirm the amount and who shares it with the user first') is an explicit pre-call requirement. It does not explicitly name alternatives or exclusions, but the context is clear enough for selection among the listed siblings.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds meaningful behavioral details beyond those: 'Duplicates are merged' and 'Acts as the participant', which clarify side effects and identity semantics. It aligns with the idempotent hint without contradicting it.

Agents need to know what a tool does to the 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 compact and front-loaded with the main purpose: 'Suggest a place the group can vote on'. The subsequent sentences about optional fields, duplicate merging, and acting as participant each provide value, though 'Give a name...' partially repeats schema details.

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

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

For a simple mutation tool with fully documented parameters, the description is adequately complete. It covers the core behavior, participant context, and duplicate handling. It does not explain return values, but there is no output schema and the tool's result is likely a straightforward confirmation.

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

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

Schema description coverage is 100%, so all six parameters are already documented in the schema. The description restates that address and Google Maps link are optional, but adds no new meaning beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description clearly states the tool's action: 'Suggest a place the group can vote on (Where tab)'. It identifies the resource (a place suggestion) and the context (voting), making its purpose evident. It does not explicitly name the sibling tool vote_place, but the framing implies the distinction.

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

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

The description gives useful context ('the group can vote on', 'Acts as the participant') and indicates that this is a suggestion action rather than a voting action. However, it does not explicitly state when to prefer this tool over alternatives like vote_place, nor does it provide exclusions or alternative routing.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds only the ability to set done to true or false, which is minor additional behavioral context beyond what annotations provide. No contradiction 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 two efficient sentences that front-load the action and include the essential toggle behavior and item_id source. 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?

This is a simple write tool with 80% schema coverage, safety annotations, and no output schema. The description covers the core behavior and data source. It does not detail error conditions or the response format, but given the annotations and parameter descriptions, the agent has enough to call it 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 80% (4 of 5 parameters described), with the 'done' parameter lacking a schema description. The description compensates by explicitly explaining its true/false semantics. It also reinforces that item_id comes from get_checklist, adding value 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 states a specific verb ('Mark'), a specific resource ('checklist item'), and the two states it can set (done: true / done: false). It is clearly distinguishable from sibling tools like add_checklist_item (adds) or get_checklist (reads).

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

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

The description gives clear context for when to use the tool: to toggle an item's done state. It also tells the agent to source item_id from get_checklist, which is a helpful usage hint. However, it does not explicitly name alternatives or situations where this tool should not be used.

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

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

Annotations are all false and therefore do not disclose side effects, so the description carries the burden. It clearly states that a new plan is created, shareable links are returned, and the user may be added as a first participant with a participant_token. This gives an agent meaningful behavioral knowledge beyond the neutral annotations.

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

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

Three short sentences with no wasted words. The core action and return value are front-loaded, the optional behavior is stated next, and the usage restriction closes it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 two-parameter create tool with full schema coverage and no nested objects, the description covers what is created, what is returned, the optional side effect, and when to call it. The lack of an output schema is compensated by explicitly naming shareable links and participant_token.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a useful behavioral detail about your_name by mentioning the returned participant_token, but the schema already documents both parameters adequately.

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

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

States a specific verb ('Create') and resource ('new lesgooo plan'), and goes beyond a generic create by adding 'get its shareable links' and optional participant addition. This separates it from all sibling tools, none of which create a plan.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 an explicit call gate: 'Only call after the user asked for it.' It does not enumerate alternatives or exclusions, but the unique action of creating a plan makes the intended context 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 annotations already declare readOnlyHint=true, and the description's 'Read' is consistent with that. The description does not add much behavioral detail beyond the annotation, such as pagination or error behavior, but it also does not contradict the annotation.

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

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

One short, information-dense sentence. It front-loads the action and resource, then specifies the returned content without any filler.

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

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

For a simple, read-only tool with one fully documented parameter and no output schema, the description is complete enough: it states what is returned and confirms the non-mutating nature consistent with annotations.

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

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

Schema coverage is 100% and the single parameter, 'plan', is already well described in the schema with an example link and id format. The tool description does not need to add more and does not provide extra parameter nuance.

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

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

The description uses a specific verb ('Read') with a clear resource ('the plan's shared checklist') and tells the agent what it will see ('open and done items, with item_id'). This clearly differentiates it from mutation-focused siblings like add_checklist_item and check_item.

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

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

The read-only framing and the content specification make it clear this is the retrieval tool for the checklist. It does not explicitly mention when not to use it or name alternatives, but the sibling set and verb provide unambiguous context.

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

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

The readOnlyHint annotation already establishes the safe, non-mutating behavior. The description adds useful context by enumerating the returned data and noting amounts are in the plan's currency, but it does not go deeper into edge cases or response shape. This is acceptable given the annotation coverage.

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

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

Two short sentences with no filler. The main action and resource are front-loaded, followed by the specific contents of the response and currency context. Every sentence earns its place.

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

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

For a simple read tool with one well-documented parameter and a readOnly annotation, the description fully explains what the tool returns and any relevant currency detail. No missing information would prevent an agent from invoking it correctly.

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

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

The input schema already fully documents the single required parameter, including an example and accepted formats. The description adds no additional parameter meaning, but with 100% schema coverage the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: "Read the plan's shared costs (Splitwise tab)", and enumerates exactly what is returned: expenses, each person's balance, and suggested payments. This clearly differentiates it from siblings like add_expense and record_payment, which are write operations.

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

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

The description makes the read-only context clear, so an agent can tell when to call this rather than mutation siblings. It does not explicitly name alternatives or exclusions, but the resource and read intent are unmistakable.

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

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

Annotations already mark the tool readOnly, and the description adds the incremental-change behavior: passing 'since' returns a list of what changed. It also clarifies that place_id is included for voted places, providing context beyond the schema.

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

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

Two sentences fully convey the tool's purpose, return contents, and optional parameter behavior. It is front-loaded with the core read action and has no filler or repetition.

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

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

For a simple read tool, the description covers what the call returns, how to identify the plan, and how the optional parameter works. With readOnlyHint already annotated and no output schema required, nothing essential 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 coverage is 100%, so the baseline is 3, but the description adds meaning to the 'since' parameter by explaining that it takes a server_time from an earlier call and returns changes since then. This goes beyond the schema's brief ISO timestamp note.

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

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

The description uses a specific verb ('Read') and resource ('a plan'), and enumerates the key contents: title, event details, participants, availability, RSVP, best dates, and voted places with place_id. This clearly distinguishes it from sibling tools like get_checklist and get_expenses.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 — read a plan when you need plan-level details — but does not explicitly state when to use this tool versus alternatives. It does provide one usage-related hint: passing 'since' can retrieve changes since an earlier call.

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

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

Annotations already mark the tool as idempotent and non-destructive, and the description adds concrete behavioral detail: same-name participants are reused, and participant_id plus participant_token are returned. This enriches the annotation without contradicting it. It doesn't mention failure cases, but with annotations present the bar is lower.

Agents need to know what a tool does to the 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 terse sentences, each carrying distinct value: the core action, the idempotency behavior and return value, and a user-confirmation instruction. No redundant phrasing or repetition of schema details.

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

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

The absence of an output schema is compensated by explicitly listing returned fields. The subtle same-name reuse behavior is disclosed, and the user-confirmation requirement covers an important interaction driver. Nothing needed to call the tool correctly seems 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 coverage is 100%, so both parameters are already documented. The description adds value by directing the agent to confirm the name with the user first)Skip, which is user-oriented semantic guidance beyond the schema's string type.

Input schemas describe structure but not intent. Descriptions should explain 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 starts with a clear verb+resource pair ('Join a plan') and adds essential scope ('as the person you act for'). It does not explicitly differentiate from siblings like set_rsvp or create_plan, so it falls short of a 5, but the purpose is 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 provides clear context for when to use the tool – joining a plan on behalf of someone, with the caveat to confirm the name first. It does not state exclusions or name alternatives, so it stops at 'clear context, no exclusions'.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, so the agent knows this is a mutating, non-idempotent operation. The description adds important behavioral context: the amount defaults to the suggested settle-up amount from get_expenses, and it emphasizes 'Only after the money was actually sent,' which is a critical precondition. This goes beyond the annotations and helps the agent avoid premature calls.

Agents need to know what a tool does to the 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 wasted words. The core action is front-loaded, the default behavior is stated, and the critical precondition ('Only after the money was actually sent') is included. Every sentence earns its place.

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

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

For a mutating tool with no output schema, the description covers the essential context: what the tool does, the default amount behavior, and the precondition. It doesn't describe the return value or what happens after recording, but given the simplicity of the operation and the full schema coverage, this is adequate. The only minor gap is not explaining what the response contains, but that's not critical for invoking the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds the key semantic that 'amount' defaults to the suggested settle-up amount, which is valuable. However, it doesn't add much beyond that for the other parameters, which are already well-described in the schema. Baseline 3 is appropriate given full schema coverage.

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

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

The description clearly states the action: recording that the person you act for paid someone back (settling up). It specifies the resource (payment) and the context (settling up a debt), and distinguishes it from expense-related tools by focusing on repayment. The verb 'record' plus the object 'payment' is specific and 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 provides clear context: use this when money was actually sent to settle up. It also mentions the default amount behavior tied to get_expenses, which implies when to use it (after checking expenses). However, it doesn't explicitly state when not to use it or name alternatives like add_expense, though the settling-up framing makes the distinction fairly 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 signal mutation and idempotency, and the description adds meaningful behavioral detail: replace sets exactly the listed days (implying removal of unlisted ones) and modifications require user confirmation. This goes beyond the structured annotation hints without contradicting them.

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

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

The description is two compact sentences with no filler. The core action comes first, followed by the essential mode distinctions and the confirmation requirement—every sentence earns its place.

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

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

For a mutation tool with moderate complexity, the description covers the date format, allowed horizon, mode behavior, and confirmation prerequisite. It does not describe return values, but no output schema is present and the absence is not a blocking gap for invoking the tool correctly.

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

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

With only 60% schema coverage, the description compensates by explaining the two underdocumented parameters: dates (format and allowed range) and mode (default and exact semantics). Participant id/token are already described in the schema, so the description need not repeat them.

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

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

The description states a precise operation—setting which days a person is free—and clearly identifies the resource (availability days). The mode semantics further clarify how the update is applied, and there is no ambiguity with sibling tools like set_rsvp or update_event.

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

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

The description gives clear context for use: availability can only be set for dates between today and two years ahead, and only with user confirmation. It also explains when to use replace versus add/remove, though it does not explicitly contrast the tool with sibling alternatives.

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

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

Annotations already indicate this is a mutating, idempotent, non-destructive operation, and the description adds useful behavioral context: 'clear' removes an existing answer, the answer applies to a single occurrence, and the operation requires user confirmation. This enriches the annotation-only safety profile without contradicting it.

Agents need to know what a tool does to the 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 tight sentences with no filler. The core action and allowed values are front-loaded, followed by the repeating-event nuance and the user-confirmation guardrail. Every sentence carries necessary semantic weight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 mutating RSVP tool with strong annotations and a well-described schema, the description covers all essential invocation concerns: status semantics, occurrence-specific behavior, how to target a repeating event, and the confirmation requirement. No output schema is needed because the tool's return value is not central to selecting or calling it 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 80%, so the schema carries most parameter documentation. The description adds value beyond the schema by explaining the meaning of the status enum, especially that 'clear' removes the answer, and by defining the default behavior of occurrence_date for repeating events with a pointer to get_plan's event.upcoming.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Answer whether the person is coming') and the exact allowed values ('yes', 'no', 'clear'), tying directly to the resource 'rsvp'. It also clarifies the special semantics of 'clear' as removing an answer, which distinguishes the tool's purpose from general event editing or availability 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 gives clear context for when each status and occurrence_date should be used: repeating events default to the next occurrence, and occurrence_date selects a specific one. It also adds the human-gating requirement 'Only with the user's confirmation.' It does not explicitly name alternative sibling tools or exclusions, but the usage context is unambiguous.

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

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

Annotations already indicate destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safe-vs-destructive profile is covered. The description adds meaningful behavioral details beyond annotations: partial updates, empty-string clearing, all-day event handling via omitted start_time, and local-time semantics.

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

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

The description is four short sentences with no filler. Every sentence carries load-bearing guidance: what changes, when it is allowed, time semantics, and patch/clear behavior. The most important scoping statement is front-loaded.

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

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

For a 10-parameter mutation tool, the description and schema together cover purpose, field semantics, partial update behavior, and clearing side effects. A minor gap is the absence of any statement about return values or success/failure behavior, since there is no output schema to fill that in.

Complex tools with many parameters or behaviors need more documentation. 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 70%, so the schema does most parameter documentation. The description adds useful semantics: 'omit start_time for an all-day event', 'Times are local (no time zone)', and the partial-update/clearing rule. This goes beyond the schema's raw patterns and 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 uses the specific verb 'Change' and identifies the resource: 'the shared event everyone sees on the RSVP page'. It enumerates the mutable fields (title, date/time, place, description), which makes the tool's purpose unambiguous and distinguishes it from sibling tools like set_rsvp or create_plan.

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

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

The description gives clear usage context: 'Only after the group agreed', and explains the modification strategy: 'Send only the fields to change; an empty string clears a field.' It does not explicitly name alternatives or state when not to use this tool, so it misses 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?

Annotations already convey idempotency and non-destructiveness, and the description adds the important behavioral constraint 'Only with the user's confirmation,' which is not present in the annotations. It also clarifies that 'clear' removes a prior vote, adding state-change semantics beyond the raw enum.

Agents need to know what a tool does to the 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, both load-bearing: the first states the operation and allowed values, the second states the required human-confirmation condition. No filler or redundant restatement of schema fields.

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

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

For a five-parameter mutation tool with no output schema, the description covers the essential operational semantics: what vote values mean, the source of place_id, and the user-confirmation requirement. It could be slightly more complete by noting the participant token/auth requirement, but the schema descriptions already handle that.

Complex tools with many parameters or behaviors need more documentation. 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 80%, so the baseline is 3, but the description adds real meaning by mapping 'up', 'down', and 'clear' to concrete actions (up-vote, down-vote, remove vote) and by sourcing place_id from get_plan. This goes beyond the schema's bare enum list.

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

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

The description opens with a concrete verb-resource pair: 'Up-vote, down-vote or remove your vote on a place.' It enumerates the exact vote modes and identifies the source of place_id (get_plan), making the tool unmistakable among siblings like add_place or set_rsvp.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 clear context: this tool is for voting on a place after retrieving candidates via get_plan, and it adds the critical precondition 'Only with the user's confirmation.' It does not explicitly name alternatives or exclusions, so it misses the top tier.

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