CourtReserve MCP by usefulapi

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

Annotations already declare readOnlyHint and destructiveHint=false, so the safety profile is covered; the description adds the meaningful extras: the required ReservationReport (Read) role and the hard 7-day window limit. It does not mention pagination or result-size behavior, which keeps it from 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?

Essentially one front-loaded sentence carrying purpose, constraints, filters and authorization, followed by the endpoint. Dense but no wasted sentences; the single long clause costs it a point on 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?

For a 7-parameter, no-output-schema report, the description covers what is returned (booked vs available per time slot), the time-window limit, the filter dimensions and the auth requirement. Only the exact result shape and pagination/aggregation granularity remain unspecified.

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 it already documents each filter, including the cross-references to list_courts, list_event_categories and list_reservation_types. The description restates the filter categories and the 7-day span but adds no format or resolution detail beyond the schema, 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?

Names the specific report and defines its semantics inline: 'booked vs available time per time slot' for a bounded period. That is materially different from courtreserve_get_court_availability and the other list-based siblings, so an agent can route correctly 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 the operative constraint (period of at most 7 days) and the optional narrowing dimensions (courts, court types, event types, event tags, reservation types), which is clear usage context. It stops short of explicit when-not-to-use guidance or naming an alternative such as get_court_availability.

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/non-destructive, so the description's job is narrower; it still adds useful context — the 31-day range cap, the club's time zone used in the reply, and the authorization role required. It stops short of describing pagination or result ordering, but the added behavioral detail is genuine.

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 what is returned, then constraints, then auth. Parentheticals carry the time zone and range cap without breaking the flow; nothing is 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?

With no output schema, the description does describe the return content (operating hours, booked slots, reply time zone), which is what an agent needs to interpret results. It remains silent on result volume or pagination behavior for a 31-day range, a minor gap given only 4 optional params.

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 each parameter already documents format and the date-vs-range exclusivity. The description only restates the date/range choice and the 31-day bound, adding no format or semantic detail beyond the schema — the baseline 3 for full schema coverage.

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

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

States a specific verb+resource ('Court availability') and enumerates the payload: each court's operating hours plus already-booked time slots for a date or range. This is meaningfully distinct from list_reservations, though the description never names the sibling to sharpen that boundary.

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 real constraint ('at most 31 days') and the required role ('Needs the Reservation role (Read)'), which helps an agent decide feasibility. However it never says when to prefer this over courtreserve_list_reservations or courtreserve_court_utilization, leaving the sibling choice 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 cover the safety profile (readOnly, non-destructive), and the description adds genuinely non-obvious behavior: that a family member id returns the whole family's reservations, and that the Member (Read) role is required. The underlying endpoint is disclosed too. It does not describe pagination behavior itself, leaving that to the schema.

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

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

Three short sentences, front-loaded with what is returned, then the identity rule, then the permission requirement. The field enumeration earns its place; nothing is padded. Slightly telegraphic phrasing ('type, start/end, courts') but efficient.

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

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

With no output schema, the description compensates by listing the returned fields, and it covers the identity and permission prerequisites. For a read-only, five-parameter filtered lookup this is close to complete; only the sibling-selection guidance is missing.

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

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

Schema coverage is 100%, so the schema already documents limit, date bounds and the two id parameters in detail. The description only restates the id choice and the default 'upcoming' window, adding marginal meaning beyond the structured fields. 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 the resource precisely (a member's court bookings and event registrations) and even enumerates the returned fields (type, start/end, courts, event name, players). It is clearly member-scoped, which implicitly separates it from courtreserve_list_reservations, but it never names that sibling to make the distinction explicit.

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

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

'Upcoming (or dated)' and 'give the member id or your own external id' imply the usage context, and the required Member (Read) role is stated. However, there is no explicit guidance on when to prefer this over courtreserve_list_reservations or courtreserve_list_event_registrations, so the agent must infer the 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 cover the read-only, non-destructive safety profile, so the description earns credit for what it adds: a required authorization role (EventRegistrationReport, Read) and an upper bound of 31 days per date window. It omits the response shape and any note about how unpaginated results are signaled, but the essentials beyond annotations are present.

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

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

Three short sentences, front-loaded with the resource and the date axes, then the input constraint, then auth and endpoint. No filler and no repetition of schema field 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?

Covers resource, scope limits, mandatory role, and endpoint, which is sufficient for a read-only list tool with no output schema. The main residual gap is the date string format (the schema declares plain strings with no format), which an agent must guess when constructing filters.

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 a genuinely non-obvious rule: despite zero required parameters in the schema, at least one date pair must be supplied. It also clarifies that the 31-day cap applies per period, which the per-field schema text does not state.

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 ('Cancelled event registrations') plus the two possible axes (cancellation date or event date), which separates it from courtreserve_list_event_registrations and, by domain, from courtreserve_list_cancelled_reservations. It never names those siblings explicitly, so an agent must infer the distinction from the noun phrase 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?

'Give at least one period' and 'at most 31 days each' are concrete usage constraints that prevent a call with no date filters or an over-wide window. However, nothing tells the agent when to prefer this tool over courtreserve_list_event_registrations or courtreserve_list_cancelled_reservations; no alternatives or exclusions are named.

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=true and destructiveHint=false, so the description's added value is the ReservationReport (Read) role requirement, the 31-day window cap, and the underlying endpoint. It does not mention pagination behavior or result ordering beyond what the schema says about truncation.

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 what the tool returns before the period constraints, the role, and the endpoint. No sentence is 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?

With no output schema, the description adequately covers inputs, permissions, and window limits, but it never characterizes the returned rows (shape, ordering, whether cancelled-by/member fields appear). That is a minor gap for a read-only listing tool.

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

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

Schema coverage is 100%, setting a baseline of 3, but the description adds genuine meaning: the 31-day maximum applies per period ('at most 31 days each') and at least one date period must be supplied even though none is schema-required. That materially changes how an agent fills the five optional-looking 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 ('Cancelled court reservations') and clarifies the two filtering dimensions, which distinguishes it from courtreserve_list_reservations. It stops short of naming any sibling explicitly, so an agent must infer the distinction from the 'cancelled' qualifier.

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?

'Give at least one period' supplies a real usage constraint that the schema does not enforce (required params = 0), and the two date-mode framing tells when each filter set applies. There is no explicit statement of when to prefer this over courtreserve_list_reservations or the cancelled event registrations sibling.

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 genuinely new behavioral context: a 31-day maximum per period, the requirement to supply at least one period (not expressed in the schema's required list), and a note about the key's access role gating attendance data. Return-shape/pagination detail is absent, but the limit parameter's schema text covers truncation.

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 report's meaning, then the filtering rules, in three short clauses with no filler. The 'Role: the key's access to attendance data' fragment is slightly cryptic but still short and informative; the raw endpoint path is minor clutter.

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

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

For a 7-parameter read-only report with full schema descriptions and no output schema, the description supplies the key constraints an agent needs: at least one period, 31-day windows, and both bookings and events included by default. It leaves the relationship between the two period families (must both be supplied together?) and default behavior when a family is omitted 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 coverage is 100%, so baseline would be 3; the description earns an extra point by adding constraints the schema does not state — the 31-day cap per period and the 'at least one period' rule that binds the four date parameters together. It also clarifies the two parallel period families (check-in vs reservation), which is the main source of misuse risk.

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 ('check-in report: who checked in to court bookings and events') and names the two filtering axes, so an agent knows exactly what data comes back. It does not explicitly distinguish itself from nearby siblings such as courtreserve_whos_here or courtreserve_list_event_registrations, leaving a small ambiguity.

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

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

'Give at least one period' and 'by check-in period or reservation period (at most 31 days each)' give real preconditions for calling, which is more than most definitions offer. However, there is no explicit when-to-use versus sibling tools (e.g. whos_here for live occupancy), so selection guidance remains inferred.

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 beyond that: the required authorization role and the backing endpoint. It does not go further into pagination or return behavior for the truncated case.

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 clauses, front-loaded with what the tool returns, then the prerequisite and endpoint. Nothing is redundant and every 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 simple read-only lookup with one optional parameter and no output schema, the description covers return fields, authorization, and integration context. Only the truncation/return behavior is left implicit, which is minor.

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 optional parameter and the schema documents it fully (including default 100, max 500, and the truncation notice). The description adds nothing about the limit, 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?

The description opens with a specific verb and resource ('The club's courts') and enumerates the returned fields (id, label, court type, order). It also signals that this is reference data feeding the utilization and blocks tools, which hints at its distinct role among the list_* siblings, though it never names an alternative outright.

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

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

It gives a concrete prerequisite ('Needs the Reservation role (Read)') and states the downstream use case ('Use the ids in court utilization and court blocks'), which tells the agent when this tool matters. It stops short of explicit when-not or alternative-tool 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=true, so the safety profile is covered. The description still adds genuinely useful context beyond them: the required EventCalendar (Read) role and the underlying GET endpoint, which helps an agent anticipate auth failures. It does not mention pagination behavior, though the schema's limit field partially covers 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 fragments that front-load the resource and its examples, then the access requirement. Nothing is padded, though the trailing endpoint path is arguably low-value for an agent and the '(...)' ellipsis is slightly loose.

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 tool with full schema coverage and annotations, the description supplies the resource meaning, example values, and the auth requirement. No output schema exists, but 'with ids' signals the key returned field; pagination/truncation behavior is handled by the limit field's schema text.

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 limit, is_public, and category_id are already fully documented with defaults, bounds, and filter semantics. The description adds no parameter-level detail beyond what the schema provides, 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?

States a specific resource (event categories) with concrete examples (clinics, round robins, tournaments, open play) and notes that ids are returned. The verb 'list' is implied by the name/title and the resource is clearly distinct from list_events or list_event_registrations, though the description itself never contrasts with those 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?

Usage is implied rather than stated: an agent can infer this is the lookup to fetch category ids before filtering events, but the description never says so or names an alternative tool. The only explicit guidance is the 'Needs the EventCalendar role (Read)' prerequisite, which is access-related rather than when-to-use.

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

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

Annotations already cover the safety profile (readOnly, non-destructive), and the description adds what they cannot: the required role/permission and the 31-day window limit that will actually cause calls to fail. It omits anything about result ordering or what happens if all filters are omitted, which keeps it off 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?

Three short sentences, front-loaded with what is returned, then the period constraint, then the permission requirement. Nothing is padded and no sentence restates another.

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 explain the returned fields (member, event, amount paid), and the schema covers limit/truncation messaging. The remaining gap is small: no statement of default ordering or what an unfiltered call returns.

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 each parameter is already documented, setting the baseline at 3. The description adds only the shared 31-day cap on the from/to date pairs and confirms the two boolean includes are optional enrichments; it does not clarify date formats or what happens when both period families are supplied.

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 ('Active registrations for events, clinics and lessons') plus the payload contents (member, event, what was paid). The word 'Active' alone distinguishes it from the sibling courtreserve_list_cancelled_event_registrations, and 'event registrations' separates it from the reservation/check-in list 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?

Gives real preconditions and constraints: the required EventRegistrationReport (Read) role and the rule that each period must span at most 31 days. It does not explicitly say when to pick this over the cancelled-registrations sibling, so it stops short of 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 readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds real context beyond that: the required role scope, the underlying endpoint, and the notable data exclusion ('SSO links are not returned'), which prevents an agent from expecting that field.

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 plus an endpoint reference; the field inventory and the exclusion note come first. Nothing is padded, though the raw endpoint path is marginal value for an agent.

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 8 optional params and no output schema, the description carries the return-shape burden and does so by listing the event attributes returned. Auth scope is stated, and pagination is handled by the schema's limit description, so only minor gaps remain.

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 per-parameter meaning is already documented in structured form. The description echoes the date-range 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 (club calendar events) and the bounding filter (between two dates), then enumerates the returned fields, which signals a flat event listing rather than registrations or waitlists. It does not explicitly contrast itself with siblings like courtreserve_list_event_registrations, but the field list makes the distinction inferable.

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?

'Needs the EventCalendar role (Read)' gives a prerequisite, and category_id points to courtreserve_list_event_categories for lookup. There is no explicit when-to-use/when-not guidance or routing to the sibling registration/waitlist tools, leaving usage largely 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 readOnly, non-destructive, open-world read; the description adds real context beyond them: the required EventRegistrationReport (Read) role, the 31-day cap per period, and the underlying endpoint. It does not describe pagination behavior or what a waitlist record contains, so not 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?

Four short, front-loaded sentences with no filler; the resource is stated first and the constraints follow. The raw 'GET /api/v1/...' path is padding the agent cannot act on, which 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?

Covers auth, the period constraint, and the resource, and the limit/pagination behavior lives in the schema, but with no output schema the description says nothing about what fields a waitlist row returns. Adequate for selecting and calling the tool, thin for interpreting results.

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: the params divide into an event-period pair versus a registration-period pair, each capped at 31 days. That is genuine guidance on how to combine the optional filters, which 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?

Names a specific resource ('People on event waitlists') in a verb-implying list statement, which cleanly separates it from courtreserve_list_event_registrations in the sibling set. It does not explicitly name that sibling as the alternative, so it stops 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?

'Give an event period or a registration period, at most 31 days each' steers which parameter pairs to supply and constrains them, and the role requirement sets a prerequisite. Neither addresses when this tool is preferred over list_event_registrations or what happens if no period is given, so usage is implied rather than routed.

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), so the description's real contribution is the authorization requirement (Family role, Read) plus the underlying endpoint GET /api/v1/family/get. That auth detail is meaningful context an agent cannot get from the structured fields. It stops short of describing pagination behavior, though the limit parameter and its 'rows were left out' note already handle that in the schema.

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

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

Two short sentences, front-loaded with the resource and its returned shape, followed by the access requirement. The endpoint path is arguably redundant given the tool name prefix, but it is compact and not distracting.

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 compensates by naming the fields returned. Combined with the annotation-provided safety profile and the fully documented two-parameter schema, an agent has enough to call this correctly. Only the relationship to sibling family/member listing tools remains 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% — both limit and family_id are fully documented including defaults, maximums, and the underlying field name. The description adds no parameter guidance, so the baseline 3 applies; nothing is missing, but nothing extra is contributed.

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 family accounts') and enumerates the returned fields (family id, name, number, members, membership), which makes the entity concrete. It does not explicitly separate itself from the sibling courtreserve_list_members, so an agent must infer that this is the family/account grain rather than the individual-member grain.

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 prerequisite 'Needs the Family role (Read)' is a useful gating condition, but the description never says when to choose this over courtreserve_list_members or courtreserve_list_membership_types. Usage is only implied by the noun 'families'.

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/non-destructive, and the description adds genuinely useful context on top: an auth requirement (League role, Read scope), the fact that results are paged, and the default value of include_sessions. It stops short of describing page-size limits or the full return envelope, but the behavioral picture is solid for a read 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?

Three short, front-loaded sentences with zero filler: payload shape first, then pagination, then the permission/endpoint constraint. Every clause carries information an agent can act on.

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 carries the burden of return-shape disclosure and does so partially (sessions contain id and name), but it never says what fields a league object itself has or how pagination metadata is surfaced. For a simple read-only list tool with 100% schema coverage and annotations, this is nearly sufficient.

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

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

Schema coverage is 100%, so the baseline is 3, and the description earns a step above it by clarifying the default state of include_sessions and disclosing that sessions come back as only id and name. It adds no detail on page/page_size/league_id beyond what the schema already 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?

The description names the specific resource (the club's leagues) and what comes with it (sessions with id and name when include_sessions is true), plus the endpoint GET /api/v1/league/get. It does not explicitly distinguish itself from the sibling courtreserve_list_league_sessions, so an agent must infer the boundary from the include_sessions clause.

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?

"Needs the League role (Read)" is a real prerequisite that tells the agent when the call will fail, and the include_sessions note implies when to prefer the sessions-expanded variant. But there is no explicit when-to-use / when-not-to-use guidance nor a named alternative for agents who want session detail without league overhead.

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 value beyond that: the required League Read role and the fact that results are paged (with the schema's next_page convention). It stops short of describing ordering or what an empty page means, but the additions are substantive.

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

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

Four short clauses with no filler: scope first, then paging, then auth, then the endpoint. The telegraphic style makes it slightly choppy, but every element earns its place and the most important scoping constraint 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 does the necessary work by naming the return payload (sessions plus optional game days and players), the paging behavior, and the auth requirement. The only gap is that the mutual exclusivity or nesting logic between league_id and session_id is left to the schema wording.

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

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

Schema description coverage is 100%, so all six parameters including page/page_size defaults and the include_players caveat ('use with one session') are already documented. The description only echoes the include options at a high level and adds no format or interaction detail beyond the schema, 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?

Names the resource (league sessions) and its scope precisely: 'for one league or one session, optionally with their game days and registered players.' It is a noun-phrase fragment rather than a verb+resource sentence, but the resource and what is returned are unambiguous. It implicitly distinguishes itself from courtreserve_list_leagues by dealing in sessions, though it never names that 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?

The prerequisite 'Needs the League role (Read)' is real usage guidance, and the id-scoped phrasing ('for one league or one session') implies the filtering choice. However there is no explicit statement of when to use this instead of courtreserve_list_leagues or of any exclusion, so the agent must infer the routing.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description contributes beyond that: the required Member (Read) permission, the explicit exclusion of PIN codes and SSO links from results, and the 30/31-day bound on date-range filters — real behavioral constraints an agent could not infer from 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?

Four dense sentences with zero filler: purpose and returned fields first, then filters, then paging, then the security/return exclusions. Every sentence carries information an agent needs.

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 read tool with no output schema, the description covers return fields, filtering, pagination and auth adequately. The main omission is guidance on the optional include_* enrichment flags, which affect response shape and payload size.

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

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

Schema description coverage is 100%, so the baseline is 3. The description summarizes the filter family (member id, family, exact email, phone, created/updated windows) but adds little syntax the schema does not already carry, and the three include_ratings / include_custom_fields / include_marketing_consent toggles go unmentioned.

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 the club's members') and enumerates the returned fields, so an agent can distinguish it from siblings like courtreserve_list_families or courtreserve_get_member_reservations 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 clear context for invocation: which filters exist, the valid date-window limits, and the paging convention ('pass next_page back as page'). It also names the required Member (Read) role. It stops short of naming alternatives or stating when not to use this tool, so it is a 4 rather than 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description usefully adds the required role (MembershipType Read) and the underlying endpoint, both of which matter for failure diagnosis. It does not add rate-limit or result-format details beyond what the limit parameter already implies.

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 resource and returned fields, followed by usage, permission requirement, and endpoint in three compact sentences. The endpoint string (GET /api/v1/membershiptype/get) is of marginal value to an agent but is short and does not bury the key 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 simple, non-destructive read with full schema coverage and no output schema, the definition covers purpose, use case, and auth prerequisite, which is sufficient to invoke correctly. Nothing essential is missing, though the return shape is only implied by the field 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%, so both parameters (limit, membership_type_id) are fully documented in the schema. The description mentions 'the ids' in the context of filtering the report, but adds no syntax or behavioral detail about limit/pagination beyond what the schema already provides, 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 ('The club's membership types') and enumerates the returned fields (id, name, price, billing, status), which lets an agent tell it apart from siblings like courtreserve_membership_report or courtreserve_list_members. It also signals the relationship to membership_report, so it is not just a restatement of the name.

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?

'Use the ids to filter the membership report' gives a concrete downstream use case, and the cited permission requirement ('Needs the MembershipType role (Read)') clarifies prerequisites. It stops short of explicit exclusions, such as when to call membership_report instead of this tool, so it is not a full 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 already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely useful behavioral context beyond that: the required PromoCodes (Read) role and the underlying GET endpoint, which help an agent predict auth failures and understand this is an unfiltered listing call.

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, zero filler. The returned-field list leads, and the auth/endpoint details follow, so the most decision-relevant information is front-loaded.

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

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

For a simple two-parameter read tool with no output schema, the description covers what comes back, the auth requirement and the endpoint — enough to call it correctly. Only the paging/truncation semantics are left entirely to the schema, which is acceptable at full schema coverage.

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 `limit` and `promo_code_id` fully documented in the schema, including the default/max and the truncation notice. The description adds nothing about either parameter, so the schema does all the work — baseline 3.

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 (the club's promo codes) and enumerates exactly which fields come back (code, name, type, value, dates, limits, applicability), so an agent knows precisely what this returns. It doesn't need sibling differentiation because no other tool in the list touches promo codes, but the verb itself is implied by the tool name 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?

Usage is only implied: 'Needs the PromoCodes role (Read)' is a prerequisite, not a when-to-use rule, and there is no explicit statement of when to call this versus another tool. With no promo-code sibling there's little ambiguity in practice, but the description leaves selection logic 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/openWorld/non-destructive, and the description layers on genuinely new operational facts: a required ReservationReport (Read) role, the underlying GET endpoint, a hard 31-day span per period, PIN codes being withheld from output, and truncation being signalled in the reply. That is exactly the context annotations cannot carry.

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

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

Three tight sentences: resource and scope first, then returned fields, then constraints and auth. The field enumeration is list-like but each item is informational; nothing is redundant with the schema or 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 no output schema, the description carries the return shape (types, courts, times, players, balances, PIN exclusion) and adds the access prerequisite and span limit an agent needs to call successfully. For a 7-parameter read tool, nothing material is left unexplained.

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; the description earns more by grouping the parameters into two distinct concepts — 'the dates played' vs 'created/updated period' — which the terse schema fields (reservations_from/to vs created_or_updated_from/to) do not make obvious. It stops short of explaining date formats or how the two groups combine.

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 active court reservations) and enumerates the payload an agent gets back (type, courts, start/end, players, amounts owed/paid), which goes well beyond the title. It implicitly distinguishes itself from the cancelled-reservation siblings via 'active', but never names them, so an agent must infer the routing.

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?

'Give at least one period' is a real usage constraint that the schema does not encode (required=0), and the 31-day-per-period cap tells the agent how to shape a call. However, there is no explicit when-to-use/when-not language and no reference to alternatives such as courtreserve_list_cancelled_reservations or courtreserve_get_member_reservations.

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 context beyond the annotations: a required Reservation (Read) role and the underlying endpoint, which tells the agent about an auth prerequisite that annotations don't cover. It doesn't say anything about the return shape or ordering, but with readOnlyHint/openWorldHint already declaring the safety profile, this is a solid addition.

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: what you get, then the role requirement and endpoint. No waste and the resource with examples 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?

A simple read-only lookup list with a single well-documented parameter and annotations covering safety; the description covers purpose, auth and endpoint. Only the return shape (id + name fields) is left unstated, 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?

Only one parameter and the schema documents it fully (default 100, max 500, truncation notice), so the schema carries the load. The description mentions nothing about pagination or limits, leaving it at the baseline.

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 precisely and gives concrete examples of what a reservation type is (court booking, lesson, court block), so the agent knows exactly what comes back. It doesn't contrast with any sibling, but no sibling overlaps closely enough to need it.

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: the tool exists to enumerate the lookup values that other reservation tools reference by id. There is no explicit when-to-use or when-not-to-use guidance versus courtreserve_list_reservations or courtreserve_list_courts.

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 genuinely useful context beyond that: the required role, the underlying GET endpoint, and the constraint that at least one period must be supplied — a real behavioral rule that affects callability.

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

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

Four short segments — what is returned, how to filter, the period precondition, and the auth/endpoint footer — with no filler and the most decision-relevant content early. The opening field enumeration runs long, but it substitutes for a missing output schema, so it earns its space.

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

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

For a 10-parameter read tool with no output schema and no required parameters, the description covers the essentials: what comes back, how to narrow results, that a date window is mandatory, and what permission is needed. The one soft spot is the vagueness of 'Give at least one period' — it doesn't state whether one of the four date bounds suffices or whether a from/to pair is expected.

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 real meaning: it groups the date parameters into transaction-date vs reservation-date families and makes explicit that a period is mandatory even though the schema lists zero required parameters. It doesn't clarify the edge case of passing conflicting flags like only_paid and only_unpaid together.

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 (transactions: fees, membership fees, payments, refunds), the two date dimensions it can be scoped by, and enumerates the returned fields including member contact info. It's specific enough that an agent knows this is the transactions ledger rather than reservations or sales aggregates, though it never explicitly contrasts itself with siblings like sales_summary or list_reservations.

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 positive usage conditions clearly: filter by type, paid/unpaid and payment type, and provide at least one period, plus the prerequisite 'Needs the Transactions role (Read).' The missing piece is exclusions — nothing says when to prefer sales_summary or membership_report over this tool, so an agent facing an aggregate question has to infer.

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 genuine context beyond that: the required 'Membership Report role (Read)' permission, the fact that results are paged, and the backing endpoint GET /api/v1/membershipreport/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?

Three tight sentences with zero filler: grain and returned fields first, then filters, then pagination and the auth requirement. Front-loaded so an agent grasps the tool in the first clause.

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 12-parameter, all-optional read tool with no output schema, the description covers what a row represents, that output is paged, and the permission needed. It stops short of describing the response envelope (next_page, totals) but the schema's page description points at next_page, so nothing critical is missing.

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

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

Schema coverage is 100%, so every parameter (including page, page_size, the date ranges and assignment_type) is already documented at the field level. The description only restates the filter families in prose without adding syntax, date format, or interaction rules; baseline 3 is warranted 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 artifact (membership report) with its exact grain — one row per member or family membership — and enumerates the columns returned (status, billing cadence, start/end, next payment, cancellation history). This lets an agent distinguish it from a plain member listing, though it never explicitly contrasts itself with siblings like courtreserve_list_members or courtreserve_list_membership_types.

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 filter dimensions (type, assignment, start/end/next-payment/cancellation dates) imply when the tool is the right choice — when you need report-level data rather than a roster — but there is no explicit when-to-use/when-not or named alternative. The role requirement hints at an access precondition but not at tool selection.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful context beyond annotations: the required role, the 31-day limit, and the scope of returned data (fees plus refunds by category and payment type).

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 tight sentences front-load the purpose and scope, then add the role requirement and endpoint. There is no 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 read-only report with no output schema, the description covers the key facts an agent needs: scope, date constraint, auth requirement, and the breakdown dimensions. It does not describe the response shape in detail, but the main return content is implied by 'paid fees plus refunds by category and payment type'.

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 100% schema description coverage, the schema already documents all three parameters. The description adds the 31-day constraint for the date range but says nothing about include_promo_info, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource ('Detailed sales summary') and clarifies scope (paid fees plus refunds broken down by category and payment type). It is clearly distinguishable from the sibling list_transactions, though it does not explicitly name 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?

It gives a clear usage constraint ('payment period of at most 31 days') and a prerequisite ('Needs the Transactions role (Read)'). It lacks explicit when-not-to-use guidance or named alternatives, but the context is sufficient for correct invocation.

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 context beyond the readOnlyHint/openWorldHint annotations: the required ReservationReport (Read) role, the 31-day maximum window, and that cancelled_only overrides include_cancelled. It stops short of describing pagination or the shape of the reply beyond naming the included fields.

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

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

Three tight sentences, front-loaded with the resource and scope, followed by the window cap and the auth prerequisite. Nothing is wasted and no clause repeats the name or title.

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 name the returned fields (member, court, time) and covers the auth and window constraints, which is enough to call it correctly. Minor gaps remain around the exact reply structure and whether rows are grouped by court or reservation.

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 start/end formats, the 500-row limit and the cancelled_only precedence are already documented in the schema. The description's phrase 'optionally including or only cancelled ones' only restates that, adding no new syntax or edge-case detail, so 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 scope: 'Who is booked in a time window,' and enumerates exactly what is returned (member reservations and event registrations with member, court and time). This differentiates it from siblings like courtreserve_list_reservations or courtreserve_list_event_registrations, which cover only one source.

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 usage context ('for example today'), a hard constraint (window at most 31 days), and a prerequisite (ReservationReport role, Read). It does not, however, explicitly say when to prefer this over courtreserve_get_member_reservations or the separate list_* tools, so routing 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.