Your Next Tours

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent mutation, so the safety profile is covered. The description adds a genuinely useful validation rule absent from the schema: at least one of title or body must be filled. It does not address permissions or side effects, so a 3 is appropriate.

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

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

Two tightly packed sentences with the core purpose front-loaded and the constraint appended. The parenthetical clarification earns its place by resolving the inner-body ambiguity, though the density is slightly high.

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

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

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The description covers both parameters, the nested structure, and the validation rule, leaving only usage guidance as a gap.

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

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

Schema description coverage is 0% and the parameters include a nested object, so the description carries real weight. It documents id as the program uuid, enumerates the nested body fields (kind, title, body), and importantly disambiguates the confusingly nested 'body' as the card text. This compensates well for the empty schema despite not covering the maxLength 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?

States a specific verb and resource: 'Add an info/rule card to a program'. The name and description clearly convey the write operation and target entity. However, it does not explicitly differentiate itself from the sibling 'add_template_info_card', leaving the program-vs-template distinction to the name alone.

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?

There is no 'when to use' guidance, no prerequisites, and no mention of alternatives such as 'add_template_info_card' or 'update_program_info_card'. Usage is only implied by the verb 'Add'.

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

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

Annotations already declare the mutation/non-idempotent profile, but the description adds real behavioral context beyond them: the item is 'Copied into trips created from this program' (a lasting side effect), and headsetPolicy null clears the policy. That is meaningful disclosure the annotations cannot express.

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 and front-loaded ('Add a stop/leg to a program'), with the highest-value constraints (at-least-one-of, startTime warning, never invent rules) placed prominently. It is long, but given a nested object and 0% schema coverage most sentences earn their place; a few parenthetical length limits could be trimmed.

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?

An output schema exists, so return values needn't be described, and the description covers the nested headsetPolicy object, enum values, ordering model, and side effects. Nothing an agent needs to invoke this correctly appears 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?

With 0% schema description coverage, the description carries the full burden and does so thoroughly: it documents every body field, the templateId-OR-label 'at least one required' rule (absent from the schema), headsetPolicy null-clearing semantics, the groupThreshold 'applies to groups LARGER than this' meaning, and the sourceUrl-required-when-level=required constraint.

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: 'Add a stop/leg to a program.' The agent immediately knows the operation and the target entity. It does not, however, explicitly distinguish itself from siblings like add_trip_item or add_template_schedule_stop, leaving the program-vs-trip-vs-template distinction 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?

Provides strong conditional usage guidance: do not pass startTime when the time is unknown because ordering comes from dayNumber + insertion order/reorder_program_items, and only set headsetPolicy level=required when a written rule and its https source exist. It never names an alternative tool or an explicit when-not-to-use-this-tool condition, so it falls 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 declare it as non-readOnly, non-idempotent, non-destructive, closed-world. The description restates the operation but adds no behavioral context beyond what annotations provide—no rate limits, no authorization needs, no side effects. The annotations carry most of the burden.

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?

Very concise—two sentences, front-loads the purpose, then lists parameters. No wasted words. However, the parameter list is abrupt and could be better formatted 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 an output schema present, return values needn't be described, but the description fails to cover key contextual details: what an info card is, how it relates to schedules/stops, whether the template must exist, or what happens on failure. For a mutation with nested body object and zero schema descriptions, this is 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 description coverage is 0%, so the schema has no parameter descriptions. The description briefly lists parameter names (id, title, description, triggerType, linkedScheduleStopId) and notes title is required, but adds no format, constraints, or semantics beyond what the schema structure already shows. Baseline for low coverage is lower, but the description does provide some parameter enumeration.

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: 'Add an info card to a template.' This clearly distinguishes it from update_template_info_card and reorder_template_info_cards. Sibling differentiation is implicit through the verb but not explicitly called out, keeping it just below 5.

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

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

No when-to-use guidance, no prerequisites (e.g., must the template exist first?), and no mention of alternatives like add_program_info_card. The agent must infer usage entirely from the 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 cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the bar is lower. The description adds real behavioral context beyond that: headsetPolicy null clears the policy (a mutation side-effect), sourceUrl is REQUIRED when level=required, and rules must not be invented. It stops short of stating permission requirements or duplicate/ordering behavior.

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

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

Front-loaded with the purpose, then a dense param block where every parenthetical earns its place given the zero schema coverage. It is long but not padded, and the nested headsetPolicy rules are grouped logically.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The nested headsetPolicy object is thoroughly specified. Gaps remain around authentication/authorization and what happens when adding a stop that already exists, but nothing essential to invoking the tool correctly 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?

With 0% schema description coverage, the description carries the load and mostly succeeds: it enumerates body fields and gives non-obvious semantics the schema cannot, such as groupThreshold applying to groups LARGER than the value, reason being in the content's language, and the conditional sourceUrl requirement. linkedInfoCardId and linkedSlideIndex are named but their meaning is left unexplained, so it is not fully compensating.

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 ('Add a schedule stop to a template'), which clearly distinguishes it from sibling mutators like add_template_info_card and add_text_slide. It doesn't explicitly name an alternative tool, but the resource is precise enough to route correctly.

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?

There is meaningful conditional guidance embedded in the headsetPolicy block ('Only set level=required when a written rule exists and you have its https source; never invent rules'), but it governs a parameter rather than the tool choice. No explicit when-to-use vs update_template_schedule_stop or delete_template_schedule_stop is provided, so usage is only implied.

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

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

Annotations already declare the non-readonly, non-idempotent, non-destructive, closed-world profile, so the burden is light. The description adds useful behavioral detail beyond them: the new slide is appended ('at the end') and the image-slide channel is closed. It does not mention auth/permission requirements or lifetime of the change.

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, front-loaded with the action and placement constraint, followed by the parameter summary and the exclusion. 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 small mutation tool with an output schema and annotations, this covers what is needed to call it correctly: action, target, placement, params, and the alternative channel for image slides. Only a tighter definition of the id parameter leaves a minor gap.

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

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

Schema description coverage is 0%, so the description should carry more weight than it does. It enumerates both params ('id (uuid) + body { caption }'), but 'id (uuid)' merely restates the schema's format field and never clarifies which entity the id identifies (presumably the template), nor adds any caption 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?

States a specific verb (add), resource (text slide), and target (template), plus positional scope ('at the end'). It immediately distinguishes itself from the many add_* siblings by naming the exact artifact type and constraining it to TEXT slides.

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 explicit negative case: image slides cannot be added here and must come from the app/panel, which routes the agent away from a wrong invocation. It does not, however, point to any sibling tool (e.g. update_slide_caption or reorder_slides) for the adjacent operations.

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 mark this as a non-idempotent write with destructiveHint=false, and the description adds genuinely new behavior: "NO notification is sent," the "headsetPolicy (null clears)" clearing semantic, and the conditional requirement that sourceUrl is present when level=required. It does not mention permissions or authorization needed to modify a trip, but the extra disclosure 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?

Purpose is front-loaded in the first sentence and each subsequent clause adds a real constraint on an otherwise undocumented body. It is dense and long, but with 0% schema coverage the detail is earned rather than padding, so it lands just short of maximal conciseness.

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 nested-object create tool with an output schema (so return values need not be described), the definition covers the body shape, the trickiest nested field, and the notification behavior. Remaining gaps, such as permission requirements or how ordering/day placement behaves, are minor given what is already supplied.

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 annotates id as a trip uuid, gives formats (startTime HH:MM), states the templateId-OR-label relationship, and explains non-obvious semantics such as groupThreshold applying only to groups LARGER than the value and sourceUrl being required when level=required. This is meaning an agent could not recover from the bare 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?

"Add a stop to a trip" states a specific verb and resource, and the resource (trip stop) is distinguishable from siblings like add_template_schedule_stop or add_trip_participant without opening a schema. It stops short of naming the alternatives explicitly, so it is clear but not fully self-differentiating.

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?

Usage is implied by the create-verb framing rather than stated: there is no explicit when-to-use or when-not-to-use guidance and no sibling is named as the alternative. The one substantive guideline, "Only set level=required when a written rule exists... never invent rules," is a field-level rule rather than a routing instruction, so the reader must infer that this is the tool for mutating trip stops.

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

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

Annotations cover safety (destructiveHint=false, idempotentHint=true), but the description adds high-value context beyond them: it does NOT send an email, and it explains the dedup mechanism (same email/phone, or same name absent conflicting contact details) and that the existing participant is returned. This turns a bare idempotency hint into an actionable retry guarantee.

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 dense sentences, front-loaded with the core action, then params, then the no-email caveat and retry semantics. No filler; each sentence carries distinct 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 mutation tool with an output schema (return values needn't be explained) and full annotation coverage, the description supplies the missing pieces: side-effect disclosure (no email), routing to the alternative, and idempotency behavior. Nothing essential for correct invocation is absent.

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, and it does: it enumerates id (trip uuid) plus body fields displayName (required), email, phone. It conveys requiredness and the uuid nature of id, though it adds no format or validation nuance beyond what the schema enforces.

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 ('add a participant to a trip') and explicitly differentiates from the sibling invite_trip_participant. An agent can distinguish the manual-add path from the invite path 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?

Names the alternative (invite_trip_participant) and the exact condition that selects it ('for an invite link'). The manual vs. invite distinction is stated, 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 declare readOnly=false, destructive=false, idempotent=false, and openWorld=false, so the safety profile is covered. The word 'draft' is the one real addition, implying the program is not immediately published, but there is no note on permissions, required auth, or whether a separate publish step follows.

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 front-loaded sentence with the verb and resource first, followed by a compact field list. No filler, though the field list is largely redundant with the schema and could have carried semantics instead.

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?

An output schema exists, so return values need not be described, and annotations carry the mutation/safety profile. However, for a 10-parameter creation tool with zero schema descriptions, the definition leaves parameter semantics and the distinction from create_trip/create_template unresolved, which is the main remaining 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?

With 0% schema description coverage across 10 parameters, the description is the sole source of parameter meaning, yet it merely echoes the schema property names plus constraints already expressed in the schema (max 20 tags, personal|org enum, name required). It adds no format guidance (e.g., ISO language code, country/city conventions) or defaults.

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 ('Create a new travel program') and clarifies the object with '(multi-day trip draft)'. It does not explicitly distinguish itself from the neighboring create_trip and create_template, so the agent must infer the boundary from the resource noun alone.

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

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

No when-to-use guidance, no prerequisites, and no mention of the sibling tools (create_trip, create_template) that an agent might confuse this with. The sentence is entirely a field inventory rather than routing advice.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower, and the description adds genuine context beyond them: creation consumes plan quota, and the 'org' visibility value requires a company owner/manager role. It still omits what happens if quota is exhausted or which visibility/format defaults apply when fields are omitted.

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 purpose is front-loaded in one short sentence, followed by a dense field inventory where each entry carries information the schema lacks (required flag, units, enum values, permission constraint). There is 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 13-parameter creation tool with an output schema (so return values need not be explained) and annotations covering the safety profile, the description covers the required field, value domains, quota impact, and a key auth constraint. Remaining gaps are defaults for omitted optional fields and any relationship to sibling creation 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%, so the schema documents only names and types; the description compensates well by marking name as required, giving units for estimatedDuration (min), and spelling out the allowed values for tourFormat, visibility, and broadcastMode plus the permission constraint on 'org'. It still leaves tourType, category, and routerProfileId semantically 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?

The first sentence states a specific verb and resource ('Create a new tour template'), which is unambiguous and distinct from read/update siblings like get_my_template and update_template. It does not, however, distinguish itself from duplicate_template, which also produces a new template, leaving that routing decision to the agent.

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?

There is no statement of when to use this tool versus alternatives such as duplicate_template (copy an existing one) or create_program. The only contextual guidance is a parameter-level prerequisite ('org only for a company owner/manager') and 'The plan quota applies', neither of which tells the agent when this tool is the right choice.

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 by disclosing lifecycle and visibility behavior: the program's current state is snapshotted, a new trip starts as DRAFT, and it is not listed on the company website until publish_trip is called. These are exactly the non-obvious side effects an agent needs for a create-mutation.

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

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

Three sentences, front-loaded with the core action, then the field list, then the lifecycle note. It is dense but each clause earns its place; the parenthetical field list is slightly cramped 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?

For a 6-param creation tool with 0% schema coverage, the description covers all parameters, the required one, the snapshot/draft semantics, and the publish hand-off. An output schema exists, so return values need not be described; 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 description coverage is 0%, so the description carries the full burden and does: programId is flagged REQUIRED uuid, dates are YYYY-MM-DD, maxParticipants uses null = unlimited, and timezone is an IANA name with an example. This adds format and semantic meaning the schema alone does not convey.

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 ('Create a new TRIP from a program') and immediately distinguishes it from publish_trip and from create_program/create_template by naming the source entity. An agent can identify the operation and its lineage 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?

Provides clear context for use (a trip is always a live instance of a program, program state is snapshotted) and names the follow-up alternative publish_trip for the open-for-sale case. It stops short of stating exclusions such as when to create a program/template instead, so it is clear but not exhaustive.

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

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

Annotations already declare destructiveHint/idempotentHint, but the description goes well beyond them: it specifies the cascade (non-completed trips without participants are deleted), what is preserved (completed trips kept as history, keptCompletedTrips), the side effect on the website draft, and the exact blocking error code itinerary.delete_blocked_by_trips with its details.trips payload. This is rich, non-redundant behavioral disclosure.

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 action, then the cascade and failure semantics; nearly every clause carries real information. It is dense and would scan better as short clauses or bullets, but there is 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 tool with a single required param and an output schema, the description covers the cascade scope, the partial-deletion outcome, the blocking failure mode, and the preserved history. Nothing an agent needs in order to call it safely 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, and it only says "id (uuid)" – information already conveyed by the schema's format/pattern. It does not say which program the id refers to or where to obtain it, so it adds little beyond the structured 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?

States a specific verb and resource ("Delete a travel program") that cleanly distinguishes it from the delete_trip, delete_template, and delete_*_item siblings. An agent can identify the target entity 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?

Gives a clear precondition for invocation and a remedy: deletion stops if an open trip with participants exists, and the agent is told to cancel or complete them first. It also notes publishing is a separate step, but it never compares against a non-destructive alternative (e.g. update_program) for cases where removal is not intended.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds nothing beyond restating the parameter names — no info on irreversibility, permissions, or side effects like card reindexing.

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?

Very short and front-loaded with the operation, though the param listing reads as a compact dump rather than earned prose. No waste, but minimal substance.

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?

A destructive mutation tool with 0% schema coverage and no usage guidance should do more: explain authorization, cascade effects, and when deletion is appropriate. Output schema exists so return values needn't be explained, but the gaps elsewhere are significant.

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 burden but only labels the params (id = program uuid, cardId = uuid). It clarifies id is a program UUID, but provides no constraint, format, or relationship detail beyond the schema's own types.

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 (Delete) and resource (program info card), clearly distinguishing it from siblings like delete_program, delete_program_item, and delete_template_info_card. Lacks deeper scoping detail but the operation 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?

No guidance on when to use this vs alternatives such as update_program_info_card or reorder_program_info_cards, and no mention of prerequisites (e.g., ownership, published-state restrictions). Usage is only implied by the name.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description merely repeats 'Delete' and adds nothing about permanence, cascade effects on ordering, or required permissions, so it earns no credit 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?

Two short sentences, front-loaded with the action, with no filler. It is terse to the point of under-specification rather than 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?

An output schema exists, so return values need no explanation, and annotations carry the safety profile. However, for a destructive two-parameter mutation with zero schema descriptions, the definition leaves provenance of the ids and any usage context unaddressed.

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 carry parameter meaning. It clarifies that 'id' is the program uuid, which is genuinely useful, but 'itemId (uuid)' only restates the format already present in the schema and does not explain what an item is or how to obtain its id.

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 ('Delete a program stop'), which an agent can distinguish from delete_program (whole program) and delete_program_info_card. The slight mismatch between 'stop' in the description and 'item'/'itemId' in the schema adds minor ambiguity, but the intent is clear.

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

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

No statement of when to use this versus alternatives such as update_program_item, delete_program, or reorder_program_items. There are no prerequisites, no exclusions, and no contextual guidance beyond the bare operation.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is fully covered structurally. The description adds nothing beyond this - no note on permanence, whether deletion can be undone, or side effects on slide ordering - so it earns no credit above the annotation baseline.

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 clauses, action front-loaded, zero filler. Every word contributes to identifying the tool and its inputs.

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?

An output schema exists, so return values need not be explained. However, for a destructive, irreversible operation the description is thin - it omits any confirmation, permission, or cascading-effect context an agent should know before invoking a delete.

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 carry the load, and it does partially: it labels 'id' as the template uuid and 'slideId' as the slide uuid, disambiguating two otherwise identical uuid params. It still omits format constraints already enforced by the schema pattern, but the added meaning is real.

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 ('Delete a slide'), which is clear and unambiguous. It doesn't differentiate itself from siblings like update_slide_caption or reorder_slides, but the destructive action is obvious enough for an agent to select it correctly.

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?

There is no when-to-use guidance, no preconditions, and no mention of alternatives. The agent gets no signal about when deletion is appropriate versus reordering or editing a slide.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds genuine value beyond annotations by disclosing that sub-resources are deleted along with the template, which is not inferable 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?

Two short, front-loaded sentences with no filler; the destructive cascade is stated up front and the param note is compact. The 'Params:' shorthand is terse but readable.

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?

An output schema exists so return values need no explanation, and the single param is trivial. However, for a destructive, irreversible-by-design tool the description omits preconditions such as ownership/permission limits or whether published templates can be deleted.

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

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

Schema description coverage is 0%, but there is only one required parameter of an obvious kind. The description restates 'id (uuid)', which is already conveyed by the schema's format/pattern, and adds no syntax, sourcing, or sourcing-of-id 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 (Delete) and resource (your own template), and adds the scope constraint 'your own' plus cascade behavior. It is clear enough to separate from write/update siblings, though it does not explicitly distinguish itself from delete_template_info_card or delete_template_schedule_stop.

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?

There is no when-to-use, when-not-to-use, or alternative routing guidance. The agent must infer that this is the whole-template deletion versus the many sub-resource delete siblings.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered elsewhere. The description adds nothing beyond that – it does not say whether the delete is permanent, what happens to adjacent card ordering, or what authorization is needed.

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, front-loaded with the action and followed by the parameter list. No padding, though the parameter list largely restates the schema.

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?

An output schema exists so return values need not be described, and annotations carry the destructive/idempotent profile. But for a destructive operation sitting in a dense cluster of delete_* siblings, the description omits the disambiguation and side-effect context an agent needs to invoke it confidently.

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, and it does partially: it labels id as the "template uuid", which clarifies scope beyond the bare UUID string in the schema, and confirms cardId is a UUID. However it does not explain the relationship between the two ids or what happens if they mismatch.

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?

"Delete an info card" states a verb and a resource, but the resource is ambiguous given the sibling set contains both delete_program_info_card and delete_template_info_card. The description never says "template", leaving only the tool name to disambiguate.

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

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

No when-to-use guidance, no prerequisites, and no mention of the near-identical sibling delete_program_info_card that an agent must choose between. Usage must be inferred entirely from the name.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: it doesn't say the deletion is permanent, whether it cascades to related schedule data, or what authorization is required. It neither contradicts nor enriches 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 short fragments, front-loaded with the action and immediately followed by the parameters. Nothing is wasted, though the terseness borders on under-specification rather than true conciseness.

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, zero-schema-coverage tool, the description is thin. An output schema exists so return values need no explanation, but the agent still lacks guidance on permissions, cascade effects, and when deletion is appropriate versus updating the stop.

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, and it partly does by labeling id as the 'template uuid' and stopId as an id — a meaningful disambiguation between the two UUIDs. However, it adds no format, constraint, or relationship detail beyond the parameter names already visible 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?

States a specific verb and resource ('Delete a schedule stop'), which is enough to distinguish it from siblings like delete_template, delete_template_info_card, and update_template_schedule_stop. It is clear but does not explicitly say 'template' schedule stop, relying on the name for that 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?

There is no when-to-use guidance, no mention of prerequisites or permissions, and no pointer to alternatives (e.g., update_template_schedule_stop or reorder_template_schedule_stops). The agent gets no help deciding when this tool is the right choice.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds non-derivable traits: the deletion is permanent, no notification is sent to anyone, and it will only succeed on participant-free, non-completed trips. It stops short of covering auth/permission requirements or the failure response, which keeps it just below a 5.

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 critical constraint (permanent deletion) and the routing alternative are front-loaded, and the parenthetical examples add genuine disambiguation rather than filler. It is dense, packing preconditions, alternatives, and the param note into three compact sentences, though slightly cramped.

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 single-param tool with an output schema available, everything an agent needs is present: what is destroyed, permanence, notification behavior, preconditions, and the sibling to use instead. Return values need not be described since an output schema exists.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden; it does by naming 'id (trip uuid)', which resolves which identifier the required field expects. The schema already supplies the uuid format and pattern, so no further syntax detail is needed for a single required param.

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 ('Permanently DELETE a trip') and immediately narrows applicability to wrong/duplicate departures or trips whose program was deleted. It distinguishes itself from the sibling delete_trip_item and from announce_trip_cancellation, so an agent can select it 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 explicit preconditions ('only on a trip that has no (joined) participants and is not completed') and an explicit alternative plus the condition that selects it ('for a trip with participants use announce_trip_cancellation'). This is exactly the when-to-use / when-not-to-use routing an agent needs.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds one genuinely useful piece of behavioral context not in annotations: 'NO notification is sent.' It omits permission requirements, whether the delete is hard or soft, and behavior on a missing item.

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 fragments, action front-loaded, zero filler. Slightly terse rather than over-written, but nothing is wasted.

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?

An output schema exists so return values need not be explained, and annotations cover the destructive/idempotent profile. However, for a destructive mutation the description says nothing about permissions, side effects on ordering, or failure behavior with an invalid itemId.

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% and both params are required, so the description must carry the meaning. It labels id as the 'trip uuid' (useful) but describes itemId only as '(uuid)', giving no indication that it identifies the specific trip stop to remove.

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: 'Delete a trip stop', which is unambiguous against add_trip_item/update_trip_item. It does not differentiate itself from the broader delete_trip or delete_template_schedule_stop siblings, but the action on a trip stop is clear.

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

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

There is no guidance on when to use this versus update_trip_item or set_trip_item_status, nor any prerequisite or exclusion. The agent is left to infer usage entirely from the name.

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

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

Annotations already declare non-readOnly, non-idempotent, non-destructive, closed-world. The description adds genuine value with 'Deep-copy,' signaling that nested content (items, cards, slides) is replicated rather than referenced, and 'create a variant' implying a new entity each call. It still omits what is and isn't copied, whether the source is untouched, and how repeated calls behave.

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 compact sentences with the core action front-loaded and no filler. It is arguably over-terse for a tool with 0% schema description coverage, but nothing is wasted.

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?

An output schema exists, so return values need not be explained. However, for a mutation tool with nested body objects and an undocumented enum, the definition leaves gaps: the visibility semantics, the required-body-but-optional-fields ambiguity, and any authorization requirement on the source program are all unstated.

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 burden, but it only restates the parameter names and types already visible in the schema ('id (uuid) + body { name?, visibility? }'). It adds no meaning: no default naming behavior, no note that visibility falls back to the source program's setting, and no explanation of the personal/org 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?

States a specific verb and resource ('Deep-copy a program') and adds the outcome ('create a variant'), which separates it from create_program and mirrors the sibling duplicate_template. It does not explicitly name create_program as the alternative for a from-scratch program, so it stops short of full sibling 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 never says when to duplicate versus create a new program, nor any precondition (e.g., must own or have access to the source program). 'Create a variant' hints at intent but gives no selection criteria or 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?

Adds real behavior beyond the annotations: sub-resources are deep-copied, the copy receives an automatic name, and the plan quota applies. Annotations only flag it as a non-idempotent, non-destructive write, so this extra context is valuable; it stops short of explaining what visibility does or what happens when the quota is hit.

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 dense sentences, front-loaded with the core action and scope, then the naming behavior and quota caveat. 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?

An output schema exists so return values need no explanation, and the description covers ownership, deep-copy behavior, naming, and quota. The only gap is the meaning of the visibility enum, which affects the resulting template's state.

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

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

With 0% schema description coverage the description must carry parameter meaning, and it names both params (id uuid, body with optional visibility) and marks visibility as optional. However it never explains what 'personal' vs 'org' visibility does, so semantics remain thin.

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 ('Copy your own template ... into a NEW template'), and the parenthetical ownership scope plus the sibling names (update_template, duplicate_program) make clear what is being duplicated and what is not.

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 a clear precondition (your own template or a company template open to you) and routes the agent to update_template for renaming after the copy. No explicit when-not-to-use guidance, but the ownership constraint covers the main eligibility question.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond that by disclosing the data nature ('aggregate counts, not personal identities'), telling the agent this is a privacy-safe aggregate rather than a PII listing.

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 front-loaded sentence that leads with the resource and packs scope, dimensions and data-safety caveat with zero waste. Nothing redundant or padded.

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 an output schema present, return-value detail is unnecessary, and a zero-param read-only tool has little else to explain. The privacy caveat plus dimension list covers what an agent needs, though naming a sibling alternative would round it out.

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 tool takes zero parameters, so the baseline is 4; there is no argument syntax the description needs to explain. Schema coverage is nominally 100% but vacuous given the empty object.

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

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

The description states a specific resource (audience breakdown by country/language/device) with the 'your/participants' scope, so an agent knows this returns aggregate audience demographics. It does not, however, distinguish itself from siblings like get_my_stats or get_my_ratings_summary, which could plausibly overlap in audience-analytics territory.

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?

There is no explicit when-to-use guidance and no named alternative among the many get_my_* siblings. The only routing clue is implicit: 'your audience' suggests a demographic-reporting use case, leaving the agent to infer when this beats get_my_stats.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds only the return content hint (stops/items + info cards), which is modest value beyond the structured fields and the existing 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 short telegraphic fragments with zero waste, front-loading the resource and its payload. It is efficient, though the clipped style trades some readability for brevity.

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

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

With an output schema present, return values need not be explained, and annotations carry the safety profile, so the description is nearly complete. The remaining gap is routing guidance among the dense set of get_/list_ siblings (program vs template vs trip).

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

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

Schema description coverage is 0%, but there is only one parameter and the schema itself declares type string, format uuid, and a strict pattern. The description's 'Params: id (uuid)' merely restates the schema without adding selection meaning, so a baseline 3 is appropriate.

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

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

States a specific verb+resource: retrieving details of a single travel program, and enumerates what it returns (stops/items + info cards). The singular framing implicitly distinguishes it from list_my_programs, but no sibling is named, so differentiation is left 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?

No when-to-use guidance and no alternatives named. It does not tell the agent to reach for list_my_programs to enumerate or get_my_template/get_my_trip for the analogous resources, so routing is entirely implied by the singular name.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that the output is an aggregate summary with specific metrics, which is mild behavioral context. It does not disclose sampling windows, auth requirements, or rate limits, so a 3 is appropriate.

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 sentence that front-loads the subject ("Your ratings summary") and lists the returned metrics. Every word earns its place 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?

With an output schema present, the description need not explain return values in detail, and it does specify the key metrics. The description is complete for a zero-parameter read-only tool, though it could mention the absence of filtering or the 1-5 scale context. Given the output schema and annotations, this is sufficient.

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

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

The tool takes zero parameters, so the baseline is 4. The description accurately conveys that no filtering arguments are needed, consistent with the empty schema. No additional parameter meaning is required.

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

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

The description clearly states a specific verb-resource pair: it returns the user's ratings summary with total count, average score, and 1-5 star distribution. This distinguishes it from list_my_ratings (raw list) and get_my_ratings_trend (time series), but the description doesn't explicitly name those siblings or frame 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?

Usage is implied by the summary nature of the tool, but there is no explicit when-to-use guidance or mention of alternatives like get_my_ratings_trend or list_my_ratings. The agent is left to infer that this returns an aggregate overview rather than raw ratings.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the output is a time series of average stars plus count, which is useful, but it says nothing about default windows, scoping, or rate/aggregation behavior 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?

Two short sentences, front-loaded with the purpose and followed by the parameter summary. The 'Params:' clause largely restates the schema but the enum hint adds minor value; there is little waste.

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

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

An output schema exists, so return-value documentation is not required. The description covers purpose and parameter names, but for a tool sitting among several ratings siblings it should explain when this one is the right pick, which it does not.

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 carry the load. It names both parameters and supplies the enum values for granularity (day|week), but it does not explain what 'days' controls, its default of 30, or how granularity interacts with the window.

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: it returns the user's rating trend, and it even specifies the content (average stars + rating count as a time series). However, it does not distinguish itself from close siblings such as get_my_ratings_summary or list_my_ratings, leaving the agent to guess which ratings tool fits.

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?

There is no explicit when-to-use guidance and no alternatives named. With siblings like get_my_ratings_summary and list_my_ratings in the same namespace, the absence of routing guidance is a real gap.

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

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

Annotations already declare the safe read-only, closed-world profile, so the bar is lower, and the description still adds meaningful behavior: results are aggregates only, individual listener records are never returned, and rating comments are anonymized. It does not cover error or not-found behavior for an invalid id, which keeps it short of a 5.

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 payload contents, and the 'individual listener records are not returned' clause is a high-value negative constraint that earns its place. Minor waste in the closing 'Params: id (uuid)' line, which duplicates the schema.

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 an output schema present and one required param, the definition covers everything needed to invoke it correctly and even pre-summarizes the return shape helpfully. The remaining gap is the origin of the id and behavior on a non-existent session.

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 exists and the schema already supplies its uuid format and pattern, so the description's 'Params: id (uuid)' is largely restatement. It adds no provenance (where the id comes from) or constraints beyond the schema, which is squarely baseline territory.

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 retrieval action and enumerates exactly what comes back (session facts, aggregate participant counts, ratings, translation usage), which clearly separates it from get_my_session_ratings and get_my_stats. The only friction is the opening phrase 'Details of one of your tours', which blurs the session/tour distinction against the get_my_trip sibling.

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?

Usage is implied rather than stated: a detail-by-id fetch for a session already known to exist. There is no explicit when-to-use, no pointer to list_my_sessions as the source of the id, and no guidance on when to prefer the ratings-specific 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 establish this as a read-only, non-destructive call. The description adds one genuinely useful behavioral fact: listener names are omitted from the response, which signals a privacy constraint an agent could not get from annotations. It stops there, saying nothing about pagination or volume of ratings returned.

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 compact clauses, front-loaded with the returned resource, then the privacy note, then the parameter. No filler, though the closing "Params: id (uuid)" adds little beyond the schema.

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?

An output schema exists, so return-value explanation is unnecessary, and annotations cover the safety profile. What is missing is routing among the many ratings-related siblings and disambiguation of the single id, which matters 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%, but there is only one self-evident parameter. The description does no more than restate it as "id (uuid)" and never clarifies whether the id is a session id or a tour id — a real ambiguity given the name says session and the description says tour.

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 resource ("Ratings of one of your tours") and enumerates the returned fields (score, comment, report status), which is more than a tautology. However it conflates "tours" with the "session" naming used in the tool name and title, and gives no distinction from close siblings like get_my_trip_ratings, get_my_ratings_summary, or list_my_ratings.

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?

There is no statement of when to use this tool versus get_my_trip_ratings, list_my_ratings, or get_my_ratings_summary, all of which sit in the same ratings family. The reader must infer the distinction purely from the name and the single required id.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful scoping ('all-time', what metrics are aggregated, duration in seconds), but says nothing about auth/session requirements or refresh behavior beyond what annotations imply.

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

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

A single well-formed sentence that front-loads the resource and then lists the metrics. Every clause earns its place 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?

An output schema exists, so return-value detail is not required, and the annotations cover the safety profile. The description is nearly complete for a read-only aggregate, lacking only usage context relative to its similarly named siblings.

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 tool takes zero parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-parameter tool.

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

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

States a specific verb and resource ('get your own all-time live tour stats') and enumerates the returned metrics (total tours/sessions, total/average participants, total/average duration in seconds). However, with many get_my_* siblings (get_my_ratings_summary, get_my_audience, list_my_sessions) it never distinguishes itself from those alternatives.

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 offers no when-to-use guidance and names no alternatives, despite several plausible siblings that also summarize user data. A reader must infer the context entirely from 'all-time live tour stats' with no exclusions or routing hints.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the composition of the returned template (slides, cards, stops, routes), which is useful payload context, but says nothing about permissions, scoping, or behavior on a missing id.

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 terse clauses, front-loaded with the resource and its contents, with zero filler. Efficient, though the 'Params:' fragment is more note-like than sentence structure.

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?

An output schema exists, so return values need not be described, and read-only annotations cover the safety profile. For a single-parameter read tool the description is complete enough to invoke correctly, with only usage routing left implicit.

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

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

Schema description coverage is 0%, but the schema itself declares a single required string with format uuid, so the parameter is structured. The description restates 'id (uuid)' — matching rather than extending the schema, adding no meaning beyond it.

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 resource ('one template') and enumerates its contents (slides, info cards, schedule stops, routes). 'One template' implicitly distinguishes it from the sibling list_my_templates, but no sibling is named 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?

Usage is only implied: the singular 'one template' plus the required id suggest a fetch-by-id lookup, contrasting with list_my_templates. No explicit when-to-use, when-not-to-use, or alternative routing is provided.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: the roster is deliberately omitted and requires a separate scope, and the response includes derived progress fields rather than raw 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?

Three tight clauses with the payload description front-loaded ahead of the exclusion note and the parameter recap. No filler sentences, though the trailing 'Params: id (uuid)' is redundant with the schema.

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?

An output schema exists, so return values need not be explained, yet the description still previews the payload. Combined with annotations covering safety and the explicit roster exclusion, an agent has everything needed to call this 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 0%, but there is only one parameter and the description restates it as 'id (uuid)', which duplicates the schema's format: uuid rather than adding meaning. There is little else to say about a single identifier, so this is adequate but not additive.

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 a specific verb+resource (single trip's details) and enumerates the payload: stops, info cards, change log, derived progress (day X/Y, completed stops). This distinguishes it cleanly from list_my_trips and get_my_trip_ratings, which are its nearest siblings.

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

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

Explicitly states what is excluded (participant list) and routes the agent to the alternative (list_trip_participants plus the trips:roster scope). It does not state when to prefer this over list_my_trips, but the single-trip-by-id framing makes that 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?

Goes well beyond the annotations (which only cover read-only/openWorld safety) by disclosing that comments are sorted newest-first, that ratings are post-completion and optional, and explicitly that participant NAMES are NOT returned and roster permission is unnecessary. These are substantive behavioral details an agent cannot infer from 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?

A single dense sentence organized as: resource, return fields, sorting, exclusions, and parameter. Every clause earns its place with zero redundancy.

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

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

The output schema exists, so return-shape detail in the description is a bonus rather than a requirement, and the description still fully explains what is returned, its ordering, and the privacy limitation. Nothing an agent needs to invoke it correctly 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?

The description mentions 'id (uuid)' which merely repeats what the schema already documents with a uuid format and pattern; schema description coverage is 0%, meaning the schema field lacks a description, but the type/format is clear. No additional semantic detail about which id (trip id) is required is added, though the context makes it evident.

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 ('trip's participant ratings') and details the exact shape of the return (average, rater count, distribution, comments). It doesn't explicitly differentiate itself from sibling rating tools like get_my_ratings_summary or get_my_session_ratings, but the scope 'trip' is clear.

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

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

Provides clear contextual conditions: ratings are 'given after the trip is completed, optional', and 'trips:roster is not required', signaling when this tool applies. It doesn't name an alternative sibling or state when NOT to use it, so it falls 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?

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The description adds genuine non-obvious context: the token is single-use and no email is dispatched, which explains the non-idempotent and 'destructive' character.

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 punchy sentences, front-loaded with the core action and scope, then the critical behavioral caveat. 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?

An output schema exists so return shape need not be described, and the destructive/non-idempotent traits are disclosed across annotations and description. Only the participantId meaning is left to the schema, a minor gap for a two-param tool.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does partially: it labels id as the 'trip uuid', clarifying that the generic uuid is a trip identifier. It leaves participantId as a bare uuid label, so it compensates but not fully.

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

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

States a specific verb (generate/return), the exact resource (SINGLE-USE invite token), and the target scope (an existing participant). An agent can distinguish this from add_trip_participant and remove_trip_participant without opening the schemas.

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 explicit exclusion 'Does NOT SEND an email -- you share the link yourself' tells the agent what this tool will not do, which prevents a common misuse. It stops short of naming the sibling (add_trip_participant) as the alternative when adding a brand-new participant.

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 give destructiveHint=true and idempotentHint=true; the description usefully nuances this by stating the previously linked magnet is 'not deleted, only unlinked', clarifying that the destructive hint refers to unlinking rather than data loss. It also discloses the auth scope (content:read) needed for the catalog lookup, which annotations do not cover.

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

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

Three tight sentences, front-loaded with purpose, then prerequisites/side effects, then the discovery pointer. No filler and nothing redundant.

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?

An output schema exists so return values need not be explained. The description covers purpose, preconditions, side effects, and catalog discovery, which is nearly complete for a two-param link operation; only explicit inverse-tool routing 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 carry the burden, and it does label both params with meaning: 'id (template uuid)' and 'body { collectibleId (uuid) }'. It identifies which UUID is the template and which is the magnet, though it doesn't detail format constraints beyond uuid.

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 (link) plus resource (ready-made magnet/collectible) and target (template), and immediately distinguishes itself from the image-upload path with '(without uploading an image)'. An agent can separate it from unlink_template_collectible and add_* siblings 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 the precondition (target must be ACTIVE and either a ready-made platform magnet or yours) and routes catalog discovery to list_collectible_catalog. It does not explicitly state when NOT to use it or name the unlink sibling as the inverse operation, so it stops 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the result spans two ownership pools (platform and mine), which is useful scoping context, but says nothing about ordering, pagination behavior, or result shape.

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 compact sentences with no filler, front-loading the resource identity before the filter list. Dense but every clause carries content; only the lack of a listing verb keeps it from a 5.

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?

An output schema exists so return values need not be described, and the description covers most filter axes. But with eight parameters, zero schema descriptions, and pagination parameters unmentioned, an agent still lacks enough to call the tool with full confidence.

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 names six of the eight filters (search, category, country, city, tag, owner) and clarifies the owner enum values (platform|mine). However, it omits page and limit entirely and gives no format/length semantics for the text filters, leaving the compensation incomplete.

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 the resource clearly ('Souvenir magnet (collectible) catalog') and its two scopes (ready-made platform magnets + your own magnets), which distinguishes it from the link/unlink collectible siblings. The verb 'list' is only implied via 'catalog' and the title, but the noun and scope are specific enough for selection.

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 names filterable dimensions but never states when to use this tool, when not to, or what alternatives exist. With no sibling that lists collectibles, the agent must infer usage entirely from the tool name and filters.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond the annotations by disclosing the grouping semantics and what each group reports (session and participant counts), though it says nothing about pagination or result size.

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 waste. The core behavior is front-loaded and the exclusion plus alternative follow immediately.

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?

An output schema exists, so return values need not be explained. The description covers scope, aggregation shape, and the boundary with the sibling tool, leaving nothing an agent needs in order 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?

The tool takes zero parameters, so the baseline is 4. The schema is empty and the description correctly adds no parameter details, since there are none to clarify.

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 resource (past live tour runs) and a specific aggregation (grouped by run with session and participant counts). It explicitly distinguishes itself from list_my_trips, so an agent can pick the right tool 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?

Explicitly states the negative case ('does NOT list scheduled or upcoming trips') and names the alternative (list_my_trips) with the condition that selects it (upcoming departures, dates, capacity, spots left). Nothing is left 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 declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description adds genuine scope context by disclosing that results include both personal and company-shared programs, but says nothing about pagination, ordering or result size 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?

A single compact sentence that front-loads the resource and immediately qualifies it with the shared-scope note. No filler and nothing that could be cut.

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?

An output schema exists, so the description is not obligated to explain return values, and the annotations cover safety. What remains missing is the routing information relative to sibling list tools, which is the one thing an agent would still need.

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 tool takes zero parameters, which sets the baseline at 4. There is no parameter surface for the description to illuminate, and it correctly avoids inventing filter semantics that the empty schema does not support.

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 resource and disambiguates the term 'program' as itineraries/draft trip plans, and defines the scope as the caller's own plus company-shared ones. It does not contrast itself with the nearby get_my_program, list_my_trips or list_my_templates siblings, so the differentiation is only partial.

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

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

No when-to-use guidance is given. The description never says when to reach for this list tool versus get_my_program for a single program, or versus list_my_trips/list_my_templates, all of which sit in the same sibling cluster and would plausibly be confused by an agent.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds non-obvious behavioral context: the result set spans all sessions and, notably, 'Listener names are not returned' — a privacy/return-content constraint not derivable from the schema. It does not mention auth or rate limits, but for a read-only list tool that is acceptable.

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 scope and the sibling exclusion before the filter enumeration. Three sentences, no filler — every clause carries either a routing constraint, a behavioral caveat, or a parameter 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?

With an output schema present, return values need no explanation. All 10 parameters are accounted for via the filter/pagination enumeration, the resource is scoped, and the trip-ratings boundary is drawn — nothing an agent needs to call this correctly 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 only 40%, so the description must compensate, and it largely does: it enumerates every filter with format hints (minRating/maxRating 1-5, hasComment 'true'|'false', flagged 'true'|'false', sort newest|oldest|highest|lowest, dateFrom/dateTo YYYY-MM-DD) and notes pagination via page/limit. It stops short of stating defaults (page=1, limit=20) or the limit cap of 100, which the schema does expose.

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 (List) and resource (ratings) with the exact scope: 'Ratings listeners left after your live tour sessions,' plus 'feed across all your sessions.' It also explicitly names the sibling it is not, get_my_trip_ratings, so an agent can distinguish the two 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?

Clearly routes the agent away from this tool for trip ratings by naming get_my_trip_ratings as the alternative. However, it is silent on the other obvious siblings for this same resource — get_my_ratings_summary, get_my_ratings_trend, and get_my_session_ratings — so the when-to-use-versus-those decision is left 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 declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: ordering ('newest first'), a hard cap ('up to 500'), and an explicit exclusion ('No listener records').

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 dense sentence, front-loaded with the core action and scope, then a colon-delimited field list. Every clause carries information, though the return-field enumeration is somewhat redundant given an output schema exists.

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 read-only, zero-parameter list tool with annotations covering safety and a present output schema, the description supplies the ordering, cap, and scope an agent needs. Nothing critical is missing, though an explicit sibling pointer would improve routing.

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 zero parameters, so there is nothing for the description to disambiguate; the 0-param baseline of 4 applies. No parameter guidance is needed or missing.

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 with clear scope: 'List your own completed tours (sessions)'. The qualifiers 'your own' and 'completed' plus the enumerated return fields make the purpose unambiguous, though it never names a sibling tool to differentiate from get_my_session or list_my_trips.

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

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

No explicit when-to-use or when-not guidance, and no alternatives named (e.g. get_my_session for a single session). Usage is only weakly implied by the described contents. The closest to routing help is the 'No listener records' exclusion.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context by disclosing that org-shared templates are included in results, which the annotations do not convey. It says nothing about ordering, pagination, or result size.

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 terse sentences with the scope statement front-loaded and the filter list compact. Nothing is padded, though the parenthetical about org templates is syntactically awkward and the filter list is left as bare names.

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?

An output schema exists, so return values need not be described, and the read-only annotations cover the safety profile. The remaining gap is filter semantics: with 0% schema coverage, an agent has no basis for constructing a meaningful q/country/city/category query, which is the one thing this description should have supplied.

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% across all five parameters, so the description must compensate and largely does not. It signals that the parameters act as filters, which the schema itself does not state, but gives no meaning for 'q' (search over what fields?), no hint that country/city/category are exact vs partial matches, and no clarification of hasCollectible's true/false semantics.

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

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

Names the resource precisely ('tour templates') and clarifies scope: the caller's own templates plus org templates shared by the active company. This distinguishes it from the singular get_my_template and from list_my_programs/list_my_trips without needing the schema, though it never states the verb 'list' or that results are returned as a collection.

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

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

No when-to-use guidance, no mention of when to prefer get_my_template for a single template, and no prerequisites. The scope sentence implies a browse/overview use case but never states it explicitly.

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

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

Annotations already establish readOnlyHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds substantive behavior beyond that: the status enum values, the null-equals-unlimited capacity convention, and the derived spots-left computation. It does not mention pagination or ordering for a potentially long list.

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 dense sentences with no filler; the resource definition comes first and the routing/usage guidance second. Every clause (status enum, null semantics, spots-left formula) 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?

With an output schema present, the description need not explain return values, yet it adds helpful semantic notes anyway; annotations cover the safety profile. The only shortfall is that the sibling overlap with list_my_departures is left unaddressed, which matters for an agent choosing between them.

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?

There are no input parameters, so the baseline is 4. The description instead characterizes the response fields (status values, capacity semantics), which is useful even though the output schema already carries the authoritative shape.

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 a specific verb (List) and resource (your trips) and defines the resource precisely as 'the scheduled departures of your programs'. It enumerates the returned fields (dates, status, capacity, participantCount), so the agent knows what it gets. It does not, however, distinguish itself from the very similar sibling list_my_departures, which is a real ambiguity given the description's own use of the word 'departures'.

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

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

Explicitly states when to reach for it: 'questions about upcoming departures, availability or spots left', and even gives the spots-left formula. No exclusions or sibling routing are provided, so it does not resolve the overlap with list_my_departures or get_my_trip.

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 cover the safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=false, openWorldHint=true). The description adds value beyond them by disclosing that no participant notification is sent and that the operation is restricted to draft trips, both of which are non-obvious behaviors.

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?

Short and front-loaded: the action and its effect come first, then the notification caveat, then the parameter and precondition. No filler, though the all-caps emphasis and the 'Params: id' line are slightly redundant with structured fields.

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

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

For a low-complexity single-parameter mutation with an output schema, the description covers purpose, effect, non-notification behavior, and the draft-only precondition. It leaves error/response behavior to the output schema and annotations, which is reasonable.

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 carry parameter meaning. It does name the single parameter and its role — 'id (trip uuid)' — which is adequate compensation for a one-parameter tool, though it adds nothing beyond the schema's uuid format/pattern hints.

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 (PUBLISH), the resource (a draft trip), and the resulting state transition (draft -> active) plus its concrete effect: listed on the website and open for booking. This is far more than a restatement of the name and clearly separates it from sibling mutation tools like update_trip.

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 a clear precondition — 'Works only on a draft trip' — and rules out the announcement use case with 'NO notification is sent to participants.' It does not, however, name alternative tools or explain what to do when the trip is not a draft.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new information by revealing that removal is a soft delete ('status=removed') rather than a hard delete, which materially changes how an agent should reason about the operation; it omits auth/permission requirements and any cascade effects.

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

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

Two tightly packed sentences with the operation and its behavioral outcome front-loaded before the parameter list. Nothing is wasted, though restating self-evident parameter names is marginally redundant given the schema.

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