WaiverFile MCP by usefulapi

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds useful behavior beyond that: it names the GET endpoints, clarifies the two count semantics, and explains how pages_at_page_size is rounded up, though it does not discuss auth or rate limits.

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

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

The description is front-loaded with the core count purpose and avoids unnecessary filler. It is dense because it packs in two counts, sibling pagination context, a formula, and endpoint names, but those details are relevant 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?

There is no output schema, so the description carries the burden of explaining return values; it names record_count, waiver_count, and pages_at_page_size and explains the page calculation. With parameters and safety annotations already covered elsewhere, an agent has enough 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 description coverage is 100%, and the schema already documents start, end, and page_size in detail, including timezone behavior and page_size bounds/default. The description adds only modest meaning by linking page_size to the computed pages_at_page_size value, so 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?

The description states a specific verb and resource: counting waivers in a date range. It further distinguishes record_count from waiver_count and explicitly ties them to sibling tools waiverfile_export_waiver_data and waiverfile_list_waivers, so an agent can tell this apart from listing or exporting waivers.

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

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

It gives clear usage context by explaining that record_count drives export pagination and waiver_count drives list_waivers pagination. It stops short of explicit when-not-to-use guidance or a direct alternative-selection rule, so it is clear but not fully prescriptive.

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 value beyond annotations: 'Sends no email' and the POST /InsertEvent endpoint are not in the structured fields, and the non-idempotency warning explains the consequence ('calling twice creates two events') rather than just restating idempotentHint=false. Doesn't state the return value, though there's no output schema to cover 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?

One dense paragraph, front-loaded with the verb and required fields, then optional fields, then behavioral caveats. Every clause carries information; nothing is padding.

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

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

For a 9-param create tool with no output schema, the description covers optionality, defaults, timezone handling and side effects well. The main gap is that it doesn't say what the call returns (presumably the new event id), which the agent needs to chain into follow-up calls.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds the default for waiver_form_ids ('WaiverFile's own choice') and reiterates the UTC requirement, which the schema only conveys per-field. No added syntax detail beyond the schema.

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

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

Specific verb+resource ('Create a waiver event') with a parenthetical defining what a waiver event actually is (a class, tour or session that collects waivers), which disambiguates it from waiverfile_create_event_category and waiverfile_update_event. Required inputs are named up front.

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

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

Gives clear context for use and points to waiverfile_list_waiver_forms for the default form-selection behavior, with the schema also cross-referencing waiverfile_list_event_categories. It doesn't explicitly say when to use update_event instead of create, but for a create tool the guidance is otherwise strong.

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

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

Annotations already declare idempotentHint=false, so restating non-idempotency is partly redundant, but the description adds the concrete consequence: two calls with the same name produce two distinct categories, which is the actionable detail an agent needs. The endpoint reference (POST /InsertEventCategory) adds traceability. It doesn't cover auth requirements, though for a create with no annotation for permissions that's minor here.

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 plus an endpoint reference, with the purpose front-loaded and the caveat immediately after. The endpoint string earns only marginal value but costs little. No wasted prose.

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

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

For a two-parameter create with full schema coverage this is mostly adequate, but there is no output schema and the description says nothing about the response — notably whether the new category's identifier is returned, which an agent would need for follow-up calls. That gap is 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 100%, so both parameters (name, active with its default) are already documented in the schema. The description adds only the conceptual gloss that the name is a grouping label, not any syntax, constraints, or default behavior beyond what the schema states. Baseline 3 applies.

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

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

Specific verb+resource ("Create an event category") with a parenthetical that defines the domain concept ("a label to group events"). It's trivially distinguishable from the sibling waiverfile_list_event_categories, but that distinction comes from the verb itself rather than any explicit contrast.

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 non-idempotency warning implies the workflow (check waiverfile_list_event_categories before creating to avoid duplicates), but the agent must infer that. There is no explicit when-to-use or when-not-to-use statement, and no mention of prerequisites or permissions.

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 read-only, non-destructive profile, so the description is free to add the things annotations cannot: it discloses that results are paged, that the payload is signer PII, and that the response is flattened into columns/rows. It stops short of stating any rate limits or response size ceiling beyond the schema's page_size cap.

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 core is a single dense sentence that front-loads the resource and range, followed by a short PII warning and the endpoint. Every clause carries information, though the parenthetical-heavy first sentence is harder to parse than it needs to be and could be split without loss.

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 paginated read export with no output schema, the description gives enough: row shape, optional column expansion, participant consolidation, and a PII caution. The only real gap is that it does not say whether a total count is returned alongside the page, which the page_index hint about 'the count' only obliquely implies.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning by explaining the output shape each flag produces — custom form fields as extra columns, participants either comma-joined in one column or one row each. That connects consolidate_participants and include_custom_columns to the resulting table, which the parameter descriptions only do in isolation.

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 (flat waiver rows), its scope (a date range) and the exact shape of the returned data, plus the underlying endpoint GET /GetWaiverData. It is clearly a bulk-export counterpart to the per-waiver siblings, but it never names list_waivers or search_waivers, so differentiation is inferred from the 'export' framing rather than stated.

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 export-oriented framing ('the data behind the WaiverFile export', row-shaping flags) implies when this is the right tool, but there is no explicit when-to-use or when-not-to-use guidance and no named alternative among waiverfile_list_waivers, waiverfile_search_waivers or waiverfile_find_waivers_by_reference. An agent must infer the routing from the sibling names alone.

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=true, and destructiveHint=false, so the safety profile is covered. The description adds the endpoint and the requirement for at least one reference id, but does not add much about return behavior, pagination, or matching semantics 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?

The description is three short sentences with no filler. The purpose and the key parameter constraint are front-loaded, and the endpoint is a concise final detail.

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

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

For a read-only lookup tool with no output schema and full schema coverage, the description provides enough context to invoke it correctly, including the minimum requirement for selecting reference fields. It could be slightly richer about result shape or pagination, but the core invocation guidance is complete.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning by explaining that reference_id_1/2/3 correspond to fields attached by an outside booking or reservation system and that reference_id_any matches across all three. This helps an agent choose between the specific and broad reference-id parameters.

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

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

The description states a specific verb and resource: finding waivers by reference ids attached by an outside booking or reservation system. It clearly distinguishes this from sibling list/search tools by focusing on external reference identifiers.

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

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

It explains the key invocation condition: at least one of reference_id_1/2/3 must be supplied, or reference_id_any to search across all three fields. It gives useful context for when the tool applies, though it does not explicitly name or exclude sibling alternatives such as search_waivers.

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=true, so the safety profile is covered. The description adds useful context that this returns personal data of signers and sketches the returned fields, but does not mention pagination, result limits, or authentication requirements.

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, front-loaded fragments state what is returned, flag the privacy implication, and give the endpoint. Every sentence carries information and 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?

With no output schema, the description must at least sketch return values, and it does so by naming signers, signing time, and participants. It also flags personal data, which is important for a read-only data-access tool; only pagination or result-size behavior 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 100%, and the single event_id parameter is already documented in the schema with its pattern and source (waiverfile_list_events). The description adds no further parameter meaning, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: waivers collected for one event, including who signed, when, and participants. The 'for one event' scope implicitly distinguishes it from broader siblings like waiverfile_list_waivers and waiverfile_search_waivers, though no sibling is named.

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 guidance on when to use this tool versus alternatives such as waiverfile_list_waivers, waiverfile_search_waivers, or waiverfile_get_waiver. Usage is only implied by the event-scoped framing, with no exclusions or prerequisites stated.

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, openWorldHint, and destructiveHint=false. The description adds useful context by naming the returned fields and noting the API endpoint, which helps the agent understand the response scope. It does not discuss rate limits or error behavior, but for a simple read-only lookup the added detail is reasonable.

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

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

The description is a single front-loaded sentence naming the resource and returned fields, followed by the endpoint. Every element contributes without wasted text.

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

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

For a zero-parameter, read-only tool with no output schema, the description supplies the essential returned fields and scoping context. No additional parameter or safety details are needed beyond the annotations.

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

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

There are zero parameters, so the baseline is 4. The schema is empty and fully covered, and the description correctly requires no parameter input.

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

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

The description clearly identifies the resource (WaiverFile site / WaiverSite) and the data returned (name, settings, plan information). It is specific enough to distinguish this tool from the sibling waiver and event tools, though it does not explicitly call out 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 context 'this API key belongs to' implies authentication scope and suggests when the tool applies, but there is no explicit guidance on when to use it versus alternatives. Since no sibling overlaps, the implied usage is sufficient for a minimum viable 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 readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds substantive context beyond that: signature and image bytes are never returned, and lite mode omits agreement text and event info, plus the underlying endpoints. It stops short of noting behavior for an unknown or 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?

The return payload is front-loaded in the first sentence, the mode switch follows, and the exclusion note comes last. Three tight sentences with no filler; the trailing endpoint paths are marginal but harmless.

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

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

With no output schema in the structured data, the description takes on the burden of describing the return payload and does so field by field, including what is deliberately omitted. The only gap is error/not-found behavior and whether the waiver must belong to the caller's site.

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

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

Schema coverage is 100%, with both waiver_id (including a UUID pattern) and lite fully documented in the schema. The description's lite explanation duplicates the schema text rather than adding format or edge-case detail, so the baseline 3 applies.

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

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

States a specific verb and resource ("One signed waiver by id") and enumerates what is returned: signer, date signed, participants, form data, event, agreement text. That clearly separates it from the list/search/count siblings that return many waivers. It never names a sibling explicitly, so the differentiation is implied rather than stated.

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 main usage guidance is internal to the tool: "Set lite for only the collected form data" explains which mode to pick. There is no guidance on when to use this versus waiverfile_search_waivers or waiverfile_list_waivers, nor any prerequisite (e.g., needing a waiver id from a search first).

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

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

Beyond the annotations, it discloses that an email is actually sent, what access is granted, that skip_email_if_account_exists suppresses existing-account emails, and that the effect cannot be undone by this server except via the vendor's remove-managers action.

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

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

The description is front-loaded with the core action and includes only relevant details. It is dense but appropriately sized for a destructive, email-sending operation.

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, non-idempotent tool with no output schema and rich parameter schemas, the description covers the critical gaps: approval gating, email delivery, access granted, skip behavior, and irreversibility.

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

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

Schema coverage is 100%, so the schema already documents every parameter. The description reinforces behavior around confirm and skip_email_if_account_exists, but adds little parameter syntax or meaning beyond what the schema provides.

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

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

The description uses a specific verb and resource: invites people by email to manage one event. It also states the resulting access scope (signers and participants), which an agent can distinguish from sibling tools immediately.

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

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

It gives clear prerequisites: the user must approve and confirm=true is required. It does not name alternatives, but no sibling tool overlaps with inviting event managers, so the usage context is sufficiently clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds context the annotations do not: the listing is scoped to 'the site' and returns id/name pairs, which matters because there is no output schema. It adds nothing about ordering or volume of results.

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

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

Three short sentences, front-loaded with purpose followed by use case and endpoint. Every sentence 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?

For a simple read-only list with one optional parameter and no output schema, the description supplies purpose, return shape, site scoping, and intended downstream use. Nothing an agent needs in order to call 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?

Schema description coverage is 100% and the single optional parameter include_disabled is fully documented in the schema. The description says nothing about it, so the schema does all the work; baseline 3 applies.

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

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

The description gives a specific verb and resource ('List the event categories of the site') and states the returned fields (id and name), so the operation is unambiguous. It does not explicitly distinguish itself from the sibling waiverfile_create_event_category, which shares the 'event category' vocabulary, so it falls short of a 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?

It states concrete downstream uses: 'Use the ids to filter events or to put a new event in a category,' which tells the agent when this lookup is needed. No exclusions or named alternative tools are given, so it is clear context without full routing 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, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds real context beyond that — dates are UTC, and each returned event carries id, name, start/end, headcount and spots remaining — but says nothing about result limits or pagination behavior for large ranges.

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: purpose and scope first, then the shape of the returned event, then the timezone constraint and underlying endpoints. No filler, and the most important framing (range + optional category) is front-loaded.

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

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

With no output schema, the description usefully enumerates the fields each event returns, and the UTC note resolves a real ambiguity in the date parameters. The remaining gap is volume behavior — nothing tells an agent whether a wide range is capped or paginated.

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

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

Schema description coverage is 100%, so all three parameters, including the 'pass the next day to include the whole day' caveat and the category UUID format, are already documented in the schema. The description only reinforces that dates are UTC; baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource ('List waiver events') and defines scope precisely: events whose date falls in a range, optionally narrowed to one category. The parenthetical defines what an event is, which helps, but it never names the obvious alternative (waiverfile_list_upcoming_events), so sibling 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?

Gives the one conditional in the tool ('optionally only one event category') and points to waiverfile_list_event_categories as the source of category ids, which is genuinely useful. It does not say when to prefer this over waiverfile_list_upcoming_events or how large a range is reasonable, so usage is implied rather than stated.

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, destructiveHint=false, openWorldHint), so the bar is lower. The description adds genuinely useful context beyond them: dates are UTC and the payload is personal data. It does not mention pagination, volume limits, or whether the response includes anything besides phone numbers.

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

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

Three short sentences, front-loaded with the resource and its filter modes, followed by the UTC/PII caveats. No wasted prose. The trailing endpoint paths are mildly extraneous but short and arguably aid debugging.

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

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

With no output schema, the description does the necessary work of indicating the return payload is phone numbers and that both modes exist, and it flags the PII and UTC concerns. Missing only volume/pagination expectations for a potentially large list.

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

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

Schema description coverage is 100% and the field docs already explain the yyyy-mm-dd/00:00 UTC semantics and the opted_out toggle, so the description largely restates what the schema provides. The only marginal addition is 'Dates are UTC', which the schema also states. 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?

Names the exact resource (SMS marketing subscribers / phone numbers) and the two selection modes (opted-in by date range, opted-out when the flag is set), so the agent knows precisely what comes back. No sibling differentiation is offered, but there is no other SMS-subscriber tool in the sibling list, so that omission costs little.

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 two usage modes: default returns subscribers who opted in during the range, and with opted_out set it returns those who opted out. That is clear context for choosing between behaviors, though it gives no guidance on range sizing, result limits, or when another tool might be preferable.

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=true, so the safety profile is covered. The description adds the UTC framing and the underlying endpoint, but does not say whether past events are excluded or how results are ordered, which are the substantive behavioral questions for an 'upcoming events' tool.

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 compact sentence plus the endpoint, front-loaded with the verb and resource. Nothing wasted, though the bare endpoint adds little for an agent that will not call it directly.

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

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

For a simple two-parameter read tool with a fully documented schema and read-only annotations, this is nearly sufficient. The only real gap is that no output schema exists and the description says nothing about what an event record contains.

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

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

Schema coverage is 100% and the schema already spells out the yyyy-mm-dd 00:00 UTC semantics and the inclusive-end-day trick. The description only restates 'between two dates (UTC)', adding nothing the schema does not already carry.

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: lists waiver events within a date range, with UTC noted. It does not distinguish itself from the sibling waiverfile_list_events, so an agent cannot tell from the description alone which list tool to pick.

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 'for example the next 7 days' phrase implies a typical window, but there is no explicit guidance on when to use this versus waiverfile_list_events or whether it filters to future-only events.

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 read-only, non-destructive, open-world profile, so the description need not restate safety. It adds genuine behavioral context by disclosing the default filter (active only) and naming the underlying endpoints (GET /GetActiveWaiverForms vs /GetAllWaiverForms) that back the two modes. It stops short of describing result ordering or any pagination/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?

Three dense sentences, front-loaded with what is listed and its fields, then the mode switch, then the downstream use of ids. Nothing is redundant with the annotations.

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 a single optional parameter and no output schema, the description carries the return-value burden itself by enumerating the fields returned. It also covers the default mode and the practical follow-up (use ids for events), leaving nothing essential to guess.

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 is a single parameter with 100% schema description coverage, so the baseline is 3. The description mirrors the schema's meaning for include_deleted without adding syntax or edge-case detail.

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 gives a specific verb and resource ("List the waiver forms of the site") and enumerates the returned fields (name, id, collected fields such as email, address, DOB, signature), which sharpens the meaning. It never explicitly distinguishes 'waiver forms' (templates) from the sibling waiver-submission tools like waiverfile_list_waivers, leaving a possible naming confusion to be inferred.

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

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

It states the operating mode clearly: active forms are returned by default and include_deleted switches to all forms including deleted ones. It also tells the agent what to do with the result: "Use the form ids when creating or updating events." No explicit exclusions against sibling list tools are given.

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

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

Annotations already declare readOnly, openWorld, and non-destructive behavior. The description adds useful context beyond annotations: it returns personal data of signers, lite mode reduces payload by excluding agreement text and event info, and it is a GET endpoint.

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

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

The description is short and front-loaded: scope first, then lite mode, then sibling alternatives, then the personal-data warning. Every sentence adds useful selection or safety 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?

The description covers the main behavioral concerns for a date-range list tool, including personal data and lite mode. Since there is no output schema, it could explain more about the return shape, but the schema already documents pagination parameters in detail.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters in detail, including date boundaries and the page_index ambiguity. The description only repeats the lite mode behavior and adds no further parameter semantics.

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

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

The description states the exact resource and scope: a page of waivers signed in a date range. It explicitly distinguishes this from waiverfile_export_waiver_data and waiverfile_count_waivers, so an agent can select it 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?

It gives clear routing for export and count use cases and mentions the lite mode for smaller payloads. It does not explicitly compare against search_waivers or find_waivers_by_reference, but the date-range scope makes the primary use case clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful piece of context — the results contain signer personal data — but says nothing about result volume, pagination, or matching behavior, which matters for an open-world search.

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 fragments with the search scope front-loaded and no filler. The trailing 'GET /SearchWaivers' is mostly API traceability rather than agent guidance, a small amount of dead weight in an otherwise tight definition.

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 single-parameter read-only search with no output schema, the description covers what to search on, what the results contain, and the transport. Only the shape of returned records and any result cap are left unstated, which is a minor gap given the tool's simplicity.

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

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

Schema coverage is 100% and the single parameter already carries a description, so the baseline is 3. The description adds 'phone' as a searchable field and the 200-char/free-text framing, a marginal gain over what the schema states.

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 ('Search signed waivers') and narrows the search dimension to free-text terms covering name, email or phone, which separates it from list_waivers and find_waivers_by_reference. It does not name sibling tools explicitly, so differentiation is implicit rather than stated.

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 phrase 'free-text terms' implies when this tool applies versus a list or reference lookup, but there is no explicit when-to-use/when-not-to-use guidance and no mention of the sibling tools that are the natural alternatives. An agent must infer the choice from the field descriptions.

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?

Despite annotations already flagging destructiveHint=true and idempotentHint=true, the description adds the crucial mechanism: this is a full replacement where omitted fields are reset, empty category_id clears the category, and empty waiver_form_ids silently attaches ALL active forms. That is genuinely non-obvious blast-radius information an agent could not get from annotations alone. It stops short of stating permissions or whether the prior event state is recoverable.

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 destructive replacement rule is front-loaded in sentence two, followed by the read-first remediation, the idempotency note, and the endpoint. Every sentence carries distinct operational information with no filler.

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

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

For a destructive mutation with no output schema, the description covers the two things an agent must know: required fields and reset semantics. It does not say what the call returns or how to verify success, a minor but real gap.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds semantic weight the schema only asserts tersely: it explains WHY five params are required (whole-event replacement) and reinforces the counterintuitive empty-array behavior. It adds framing value beyond field-level descriptions, though a little of it restates 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?

"Update an existing event" states a specific verb and resource, and the body immediately distinguishes it from sibling waiverfile_create_event by describing replacement of an existing event. The named read partner (waiverfile_list_events) further anchors its role in the toolset.

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

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

It gives an explicit workflow: read the event first with waiverfile_list_events, then resend current values for fields you do not intend to change. That names the alternative tool and the exact condition for using it, leaving nothing to inference.

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