Appty

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

The annotations already flag readOnlyHint=false, destructiveHint=true and openWorldHint=true, and the description adds real content on top: confirm gating, the no-email/completed behavior for past starts, the email sent for future starts, and the explicit "no money moves through the assistant" clarification of the pay-link side effect. It never explains why the operation is flagged destructive (e.g. overwriting an existing booking or overlapping sessions), which is the one behavioral gap.

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?

Five short sentences with no filler, and the most important semantics (preview-then-confirm, then side effects) are front-loaded. Slightly dense on the money/pay-link framing, but every sentence earns its place.

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

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

For a 4-parameter mutation tool with no output schema, the description covers the confirmation contract and the email/side-effect outcomes well. It stops short of describing what the preview actually returns or what happens on conflicts, which the agent would need to interpret the preview call.

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 each parameter (start, confirm, client_id, service_id) is already documented in the schema with equivalent or greater detail. The description adds only marginal framing (the confirm gate, dashboard parity) rather than new parameter meaning, 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?

"Book a client into a service at a start time, the same way the dashboard books" gives a precise verb (book), resource (session/service), and actor (client), and is immediately distinguishable from the sibling tools like cancel_booking, reschedule_booking and find_open_slots.

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 clearly states the preview-first workflow ("Returns a preview first and only acts when confirm=true") and the past-vs-future start distinction, which tells the agent when the write actually happens. It does not, however, name alternatives such as reschedule_booking for moving an existing booking or find_open_slots for slot discovery.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds real context beyond them: a preview-then-confirm two-step, an outbound email to the client, and the clarification that no money moves through the assistant (refunds/fees applied by Appty, client pays remainder on Appty). That is exactly the added behavioral context a mutation tool needs.

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

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

Front-loads the action, then the confirm gate, then the money caveats, so the most important facts come first. The last three sentences all orbit the same 'Appty handles money' point and could be tightened into one without losing meaning.

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, open-world tool with no output schema, the description covers the safety-critical items: the preview requirement, the client email side effect, and where money is handled. It leaves open what the preview contains and what 'reason' is used for, which is a modest gap.

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

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

Schema description coverage is only 33%: confirm is thoroughly documented in the schema (including the string "true" edge case) and the description merely restates that gate, while 'reason' (maxLength 500) is explained in neither place. With low coverage the description should compensate for the undocumented parameters and it does not.

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 ('Cancel one booking') plus the governing policy and a concrete side effect ('email the client'). This is unmistakably distinct from siblings like reschedule_booking, book_session, and list_bookings, so an agent can route without opening any 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 an explicit operational gate: it 'returns a preview first and only acts when confirm=true', which tells the agent exactly how to sequence the call. It stops short of naming when not to use it or pointing to an alternative tool (e.g. reschedule_booking for a date change).

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: the return shape (ISO 8601 with the provider's offset plus a provider-local label) and the hard 31-day window constraint. It doesn't mention auth requirements, rate limits, or behavior for non-public/unknown services.

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, zero filler, with the core purpose front-loaded before the date and return-format details. Every clause 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?

With no output schema, the description correctly compensates by describing the returned start format. Combined with 100% schema coverage on the 5 params, an agent has enough to call it. Missing edge-case behavior (empty results, unknown slug/service, whether a non-public service errors) keeps it from a 5.

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 largely restates schema facts (YYYY-MM-DD format, 31-day max span), and the timezone/label behavior it mentions is already in the timezone parameter's own description. Only the ISO-8601-offset return detail is net-new, and that is a return-value concern.

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 ('Open start times for a public service') and scopes it to a public booking context, which implicitly separates it from the booking/mutation siblings like book_session. It stops short of naming any alternative tool explicitly, so an agent still infers the read-vs-write boundary rather than reading 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?

'using the same slot rules as the booking page' implies the intended context (checking availability before booking), but there is no explicit when-to-use/when-not or routing to book_session or get_provider. Usage is inferable 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description still adds real behavior: it performs an availability check ('start is still open'), confirms nothing is booked, and says payment happens externally on Appty. That is genuine context beyond the structured fields, though it doesn't cover failure behavior when a slot is no longer open.

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 action and its effect, and every sentence earns its place by adding either the availability check, the return value, or the no-booking boundary.

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 present, the description carries the return-value burden and does so ('return a link to the booking page with that service and time selected'). Annotations cover safety and the parameters are fully documented, so nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100%, so all three parameters (slug, start, service_id) are already documented in the schema, including their provenance (find_open_slots, get_provider). The description adds no syntax or format detail beyond that, 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 states a specific verb and resource: verify a slot is open, then return a booking-page link with the service and time pre-selected. It explicitly carves out the boundary against book_session with 'Nothing is booked here,' so an agent can distinguish the two without opening either schema.

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

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

It clearly frames the use case (produce a link for a client to confirm and pay on Appty) and rules out the booking action, which implicitly routes the agent away from book_session. It never names the alternative tool or states an explicit when-not condition, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real value beyond that: it scopes the data as public-facing (the booking page) and explicitly excludes client data, which tells the agent what is safe to surface. It stops short of describing error behavior for an unknown or inactive slug.

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

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

Two sentences, front-loaded with the resource identity and followed by the return-field list; every clause carries information, and the field enumeration is load-bearing given there is no output schema. Slightly list-heavy but not padded.

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

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

With no output schema, the description usefully enumerates the returned fields, and the single required parameter is fully documented in the schema. What is missing is any note on behavior for an invalid slug or an unpublished provider, but for a simple read of one entity this is close to 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 description coverage is 100% and the slug field is documented as 'the part after getappty.com/'. The description only restates 'for a provider slug' without adding format, casing, or slug-resolution semantics, so it does nothing beyond the schema. 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 states a specific resource (a provider's public booking page, keyed by slug) and enumerates the payload: name, headline, time zone, currency, services, upcoming group sessions, booking URL. It contrasts with the sibling set implicitly via 'No client data', which separates it from list_clients/who_owes, but no sibling is named explicitly.

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

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

The word 'Public' and the absence of any session/booking mutation implies this is a read-only lookup of a provider's outward-facing profile, which is enough to infer usage. However, there is no explicit statement of when to reach for this versus get_booking_link or find_open_slots, and no mention of prerequisites or failure cases.

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 readOnly, non-destructive, and closed-world. The description adds real value beyond them: it discloses that results never contain pay or manage tokens, which is a meaningful output-boundary fact that keeps an agent from expecting link credentials here. It stops short of describing ordering or pagination behavior.

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

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

Three short, front-loaded sentences with no filler; the scoping and exclusion facts appear immediately. The opening fragment is clipped enough to read as an incomplete sentence rather than a polished statement.

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 list tool with no output schema, the description covers the key negative fact about returned content but omits the default limit (50, capped at 100) and the purpose of the status filter. An agent can call it correctly, but result-set size and filtering behavior remain under-explained.

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 75%, so the schema already documents from, to, and limit well. The description's "omit from and to for upcoming sessions" largely restates the schema's own note that an omitted from defaults to now, adding only mild practical framing and nothing about the status enum filter.

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 phrase "This provider's bookings" names the resource and scope but supplies no verb of its own — the listing action is only inferable from the tool name and title. It does not distinguish itself from siblings such as find_open_slots or get_booking_link, whose results would overlap with a naive reading of "bookings".

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

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

"Omit from and to for upcoming sessions" gives one concrete default-behavior rule for the time filters. However, there is no guidance on when to choose this tool over siblings like find_open_slots (availability) or get_booking_link (single-booking detail), so the routing decision is only implied.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the returned field set, which is genuine extra context, but says nothing about ordering, pagination/truncation, or whether all clients are returned.

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

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

A single short sentence with no filler, front-loading the resource before the field list. It is a noun-phrase fragment rather than a full sentence, but nothing is wasted.

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

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

With no output schema, enumerating return fields is valuable and partially compensates. However, it omits pagination behavior and result ordering, and gives no usage context, leaving gaps for a listing tool whose siblings overlap on client data.

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 limit (default 50, max 100) and query (case-insensitive name/email match) are fully documented in the schema. The description adds nothing about these parameters, 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 names the resource ('this provider's clients') and enumerates the fields it returns, which lets an agent tell it apart from siblings like list_bookings or who_owes. It never uses an explicit verb, relying on the name/title for the 'list' action, so it falls just 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?

There is no statement of when to use this tool versus alternatives (e.g., who_owes for balances or get_provider for the provider record), and no prerequisites or exclusion conditions. Usage is only implied by the resource name.

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

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

Adds substantive behavior beyond the annotations: the client is not emailed, money does not move through the assistant, and the operation is a preview until confirm=true. These are exactly the side-effect facts an agent needs before mutating a booking, and they are consistent with destructiveHint=true / readOnlyHint=false.

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

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

Four short sentences, front-loaded with the action, then the two behavioral caveats and the confirmation gate. No filler; 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 three-parameter mutation with no output schema, this is complete: it covers the mutation, its side effects (no email, no money), and the two-phase preview/commit contract. Nothing required to call it safely is missing.

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

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

Schema coverage is 67% and the confirm parameter is already documented thoroughly in the schema, including the 'string true' edge case. The description reinforces the confirm gate but adds no syntax or constraint detail beyond the schema, so it sits at the baseline rather than compensating for the undocumented booking_id.

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

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

States a specific verb and resource ('Move a booking to an open slot'), which cleanly separates it from siblings like book_session, cancel_booking, and find_open_slots. An agent can tell what it does and what it does not do (cancel, create) 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 operating context: the slot must be open for the booking's length, and the call is preview-first. It does not name the alternative path (e.g. find_open_slots to obtain a valid new_start) or any when-not-to-use condition, so it stops short of explicit 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 flag destructiveHint=true and openWorldHint=true, but the description adds real behavioral detail beyond them: a preview-first two-step flow gated on strict confirm=true, client-facing email being sent, and the clarification that no funds move through the assistant. That is exactly the context an agent needs before firing a destructive operation.

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

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

Four short sentences, front-loaded with the core action and immediately followed by the preview/confirm safety model. Every clause carries information; nothing is restated from the title or schema.

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

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

For a destructive, schema-rich tool with no output schema, the description covers the essential risk model (preview then confirm), the side effect (email dispatched), and the boundary (no money movement). It stops short of describing what the preview contains or how multiple currencies are surfaced, which is a minor gap.

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

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

Schema coverage is 75% and the schema already documents period, confirm, and booking_ids thoroughly. The description still adds meaning by framing period vs booking_ids as mutually alternative selection modes (id-based or calendar-month) and clarifying the per-currency invoice granularity that no single parameter expresses.

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 precise verb+resource and scope: create one invoice per currency for a client's sessions, by booking id or calendar month, then email it. The 'no money moves through the assistant' clause also distinguishes it in spirit from send_pay_link, so an agent can tell what this tool is 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 invocation context: it returns a preview first and only acts when confirm=true, and it explains the two input modes (by id or by calendar month). It does not explicitly compare itself to siblings like send_pay_link or who_owes, so no exclusion guidance is present.

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

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

Annotations declare the write/destructive profile, and the description adds substantial context beyond them: a preview-first two-step flow gated on confirm=true, the assurance that no money moves, and the fact that only a payment request is sent via Appty. This is exactly the behavioral detail an agent needs before calling a destructive 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?

Four short sentences, each carrying a distinct fact: what is sent, the preview gate, the no-money-movement assurance, and the exclusions. Front-loaded with purpose and 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 mutating tool with no output schema, the description covers purpose, confirmation workflow, scope limits, and side effects. It does not describe what the preview contains, but that is a minor gap given the annotations and 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 description coverage is 100%, so the schema already documents confirm, client_id, and booking_id in detail. The description reinforces the confirm=true gating and the either/or parameter choice but adds no syntax or format detail beyond what the schema provides. 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 ('Email a pay link') and enumerates the two targeting modes (one booking, or a client's unpaid sessions and invoices). An agent can distinguish this from siblings like send_invoice or who_owes without opening any 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 usage context (single booking vs. client-level unpaid items) and explicit exclusions ('Group spots, packages, and fees are not emailed'), which functions as when-not guidance. It stops short of naming an alternative tool such as send_invoice for the excluded cases.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds real context beyond them: results are scoped to 'this provider' and the response is grouped by client and currency, which tells the agent what shape of data comes back.

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

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

Two short sentences with no filler; the core deliverable (unpaid balances, grouped) is front-loaded and the dashboard-equivalence note follows as supporting context.

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-value burden and partially does so by naming the grouping dimensions, but it does not describe fields returned per group or whether zero-balance clients are included.

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?

Zero parameters, so there is nothing for the description to disambiguate — baseline 4 applies. The implicit 'this provider' scoping is stated, which is the only context a parameterless call needs.

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

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

States a specific resource and scope: unpaid balances for this provider, grouped by client and currency. An agent can distinguish it from list_bookings/list_clients without opening a schema, though it never names a sibling explicitly.

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

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

The 'same figures as the dashboard who-owes page' line implies the reporting/collections use case, but there is no explicit when-to-use guidance and no statement of when another tool (e.g. list_clients or list_bookings) would be preferable.

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