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

The description usefully discloses non-obvious behavior: a baseline is stored on first call and subsequent calls diff against a local snapshot of ids, times and status. But that is directly at odds with the idempotentHint=true annotation — repeated calls with identical arguments return different results (first call = full baseline, later calls = deltas only), so the declared idempotency is misleading. The readOnlyHint also understates the persistent local snapshot write.

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 return content and followed by the stateful mechanics. 'Small local snapshot of ids, times and status' is a borderline implementation detail but it earns its place by explaining why repeats differ.

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

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

With no output schema, the description must explain return shape, and it only names categories of change — it does not say how a change is represented, whether the first call returns all current appointments as 'new', or what an empty result means. For a stateful delta feed with no output schema, that gap matters.

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 both parameters carry their own bounds and defaults, so the schema carries the semantics. The description adds no guidance on how days_back/days_ahead interact with the snapshot window (e.g. whether widening the window produces a larger diff), so it neither helps nor hurts.

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

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

Specific verb-and-resource framing: it enumerates what counts as a change (new, moved, cancelled, otherwise changed) so the agent knows this is a calendar delta feed rather than a listing. It does not distinguish itself from the closely named sibling calendar_changed_dates, leaving that boundary to inference.

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

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

Implied usage is conveyed by 'since the last call' and 'the first call stores a baseline', which tells the agent this is a polling/delta tool. However there is no explicit guidance on when to prefer this over calendar_agenda or calendar_changed_dates, nor any warning about the statefulness affecting repeat invocation strategy.

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, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered by structured data. The description contributes the one thing annotations don't: what the returned record contains (services, staff, client, price). It says nothing about caching or the meaning of the 'fresh' flag's effect on results, which leaves a gap given a cache-skipping parameter exists.

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

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

One short sentence with no filler, so nothing is wasted, but it is under-specified rather than economical — it reads as a title restatement rather than a front-loaded statement of a verb and scope.

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 with rich annotations and no output schema, an agent can probably invoke it correctly. However, the description is the only place return shape could be elaborated, and it gives just four field names without indicating completeness, error behavior, or cache semantics.

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 both parameters are documented in-schema ('appointment_uid from the calendar', 'Skip the local cache'), so the baseline is 3. The description adds no format, sourcing, or effect semantics 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 resource (a single appointment) and enumerates its embedded entities (services, staff, client, price), which signals a single-record fetch rather than a list. But it is a noun fragment with no verb, and it never explicitly differentiates itself from siblings like calendar_agenda, appointment_payment_details, or appointment_changes_feed.

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

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

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g. needing an appointmentUid sourced from the calendar), and no statement of what happens with an unknown UID. The agent must infer everything from the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not disclose that results may be cached (relevant because the `fresh` parameter exists), nor what the returned 'state' consists of.

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-loaded with the resource content. It is efficient, though the brevity comes at the cost of specificity rather than being a model of informative concision.

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

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

This is a simple one-appointment read with full annotation coverage and complete schema descriptions, which lowers the burden. But with no output schema, the description should say more about the shape of the returned payment state and its relationship to sibling payment tools; it only lists field categories.

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 (appointmentId and fresh) are already documented in the schema. The description adds no extra meaning about the appointmentId source or the cache-bypass tradeoff, 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 specific data returned (deposit, payment, tip, refund) and scopes it to a single appointment, which is more informative than a tautology. However, it is a bare noun phrase with no verb, and it does not distinguish itself from close siblings such as appointment_details or payment_rows, leaving the agent to infer the difference.

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

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

There is no guidance on when to use this tool versus appointment_details, payment_rows, or booking_charges. No prerequisites, exclusions, or selection criteria are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the 'from today on' starting boundary but says nothing about the local cache implied by the `fresh` parameter or whether results can be stale – useful mutation/staleness context is left implicit.

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 the scope front-loaded and no filler. Slightly held back by the noun-phrase form, which makes the action ('list these') implicit rather than stated.

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 full schema coverage and annotations, most of what an agent needs to call it is present. Without an output schema, however, the description gives no hint of what a 'request' contains (customer, service, requested time), which would help an agent decide appropriateness.

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 `fresh` and `days_ahead` are documented in the schema itself. The description's 'from today on' only loosely relates to `days_ahead` and does not clarify the default 31-day window, so it adds nothing beyond the schema 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?

The description identifies the resource precisely (appointments awaiting salon confirmation or decline) and the temporal scope (from today on), which is more specific than the title alone. It stops short of a verb-based statement like 'list' and doesn't name a distinguishing sibling such as appointment_changes_feed or calendar_agenda.

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?

'Appointments that wait for the salon to confirm or decline' implicitly signals the use case (reviewing pending booking requests), and 'from today on' scopes it. There is no explicit when-to-use/when-not-to-use statement and no named alternative for getting accepted or past appointments.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds nothing beyond restating the resource — no mention of pagination behavior, the local cache implied by the 'fresh' parameter, or result ordering. With annotations doing all the work, the description contributes no behavioral context.

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?

It is a single short fragment with zero waste, but it is terse to the point of under-specification rather than efficient structure — no verb, no lead-in telling the agent what the call does. Brevity here costs clarity.

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

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

For a paginated list tool with no output schema, the description should convey what each returned record represents (appointment plus charge?) and how results are scoped/filtered. It only names the population. Annotations cover safety, but the agent still lacks enough to know what it will receive and how to page sensibly.

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 80% (page, per_page, fresh, date_from all documented), so baseline 3 applies. The description does not elaborate on any parameter; notably the undocumented 'query' parameter is left ambiguous in both schema and description. Adequate but no added value.

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 fragment identifies the resource domain — appointments awaiting checkout or carrying booking charges — which does differentiate it from payment-centric siblings like checkout_transactions and payment_rows. However it is a bare noun phrase with no verb, so an agent must infer that this is a list/retrieval operation rather than an action. Purpose is discernible but not crisply 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?

There is no when-to-use guidance and no alternative is named. The description does not tell the agent whether to prefer this over appointment_payment_details, checkout_transactions, or payment_basket when investigating outstanding charges. The only implicit signal is the 'waiting for checkout' framing.

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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is clear. The description adds useful auth scoping by saying these are businesses the logged-in user can open, but it does not disclose caching behavior or return shape.

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

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

The description is a single efficient sentence with the verb and scope front-loaded. Every part of the sentence contributes to identifying the tool.

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

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

For a low-complexity list tool with full parameter schema coverage and clear read-only annotations, the description is largely sufficient. It could be slightly richer by mentioning cache behavior or expected output, but no output schema is present and the core selection information is covered.

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

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

The schema fully documents the single optional parameter, fresh, as 'Skip the local cache'. The description adds no additional parameter semantics beyond the schema, so the baseline score of 3 is appropriate given 100% schema description coverage.

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

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

The description states a specific verb and resource: 'Lists' and 'businesses'. It also gives scope with 'the logged-in user can open in the panel', which helps distinguish it from sibling tools like business_profile or business_features, though it does not explicitly name those alternatives.

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

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

The description says what the tool does but does not explain when to use it instead of alternatives such as business_profile, business_features, or business_visibility. There is an implied use case, but no explicit when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context of its own — it says nothing about the shape of returned amenities, ordering, or the caching behavior implied by the 'fresh' parameter.

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?

It is a single short sentence with no redundancy, but that brevity reflects under-specification rather than discipline; there is nothing front-loaded beyond the tool's own name.

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 is the only place to learn what an 'amenity' record contains and how results are returned, and it says nothing. For a data-fetching tool with no return-value documentation, this is a meaningful 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 100% and the single optional 'fresh' parameter is documented in the schema as 'Skip the local cache'. The description adds nothing beyond that, but with full schema coverage the baseline of 3 applies.

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

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

The sentence 'Amenities shown on the business profile' essentially restates the tool name and title without adding discriminating detail. It hints that the resource is business-level, but an agent gets no more than it would from the name plus the sibling list.

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, no prerequisites, and no reference to the closely related sibling business_features, which an agent could easily confuse it with. Usage must be fully inferred from the name.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds only 'grouped by category' as return-shape context and says nothing about the local-cache behavior that the `fresh` parameter implies, nor about the scope or cost of the 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?

One short fragment with zero waste, but it is under-specified rather than concise; there is no front-loaded verb or scope statement to orient the agent in the first few words.

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

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

There is no output schema, so the description must convey what comes back, and 'grouped by category' is the only hint. It never explains what a booking rule is, what the categories are, or whether results are paginated or business-wide, leaving an agent unable to predict the response.

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

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

Schema coverage is 100% and the single `fresh` parameter is described there as skipping the local cache, so the schema does the work. The description adds no further meaning about caching or freshness; 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 (booking rules) and adds a structural hint (grouped by category), but it is a noun fragment with no verb, so it never says whether it reads, lists, or creates anything. A reader can infer retrieval from the annotations, not from the text, and nothing distinguishes it from adjacent business_* configuration tools.

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

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

There is no statement of when to use this tool, when not to, or which sibling answers a related question. With business_no_show_protection and business_features among many adjacent config tools, routing is left entirely to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds no behavioral context of its own — notably it never mentions that results can come from a local cache and be bypassed, which is the one behaviorally interesting trait of this tool.

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

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

One short sentence, front-loaded with the resource and the returned status values, with no filler. Nothing is padded or buried.

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

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

There is no output schema, and the description only loosely characterizes the return as a set of features with on/off/available states; it does not say whether this is a list, a map, or per-panel grouping. For a read-only, single-optional-param tool this is adequate but not 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?

With a single optional parameter and 100% schema description coverage, the schema already explains 'fresh' as skipping the local cache. The description contributes nothing about it, 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 a specific resource (panel features) and the information returned (on/off/available for this business), which is clearer than a tautology. It does not, however, distinguish itself from adjacent siblings such as business_integrations or business_accounts, so an agent must infer the 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?

There is no statement of when to call this tool, no prerequisites, and no named alternative. The only hint is the implicit 'check feature availability' reading, which the agent must supply itself.

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, idempotentHint, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds no behavioral context beyond the title, such as whether it returns cached vs. live data, what 'state' means, or any auth/rate-limit considerations.

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

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

The description is only a noun fragment and is under-specified rather than efficiently concise. It is not front-loaded with an actionable verb or scope, so the brevity does not earn its place.

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

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

This is a simple read-only tool with one optional parameter and no output schema, so a short description could work, but 'integrations and their state' leaves key questions unanswered, including what integrations are returned, what state values mean, and how results are structured.

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 one optional parameter, 'fresh', and schema description coverage is 100%, so the schema already explains that it skips the local cache. The description adds no additional meaning, which is acceptable given the schema's completeness.

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 is essentially a restatement of the tool name and title: 'Online booking integrations and their state.' It names the resource but gives no verb (list, get, fetch) or scope, so an agent cannot confidently distinguish it from sibling business_* tools such as business_features or business_accounts.

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

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

There is no guidance on when to use this tool, when not to use it, or what alternative to choose. The agent must infer its role solely from the name and sibling list.

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, idempotentHint, openWorldHint, and destructiveHint=false. The description adds only a scope phrase and says nothing about caching (the 'fresh' parameter implies a local cache) or what is returned. With annotations carrying the safety profile, the description contributes almost no additional behavioral context.

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?

At six words it is concise, but it is an under-specified fragment rather than a front-loaded statement of purpose. There is no sentence structure to organize the information, and the brevity costs essential 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 read-only settings-retrieval tool with rich annotations and a fully documented single parameter, the description is too thin. It does not explain the 'per service' scope versus the single 'fresh' parameter, nor what the tool returns, leaving the mismatch unresolved.

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 one parameter ('fresh') with 100% schema description coverage, so the schema fully documents it. The description's phrase 'per service' does not map to any parameter and could confuse an agent looking for a service identifier. Baseline 3 applies when the schema does the heavy lifting.

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

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

The phrase names a specific resource domain (deposit and cancellation fee settings per service), which is more informative than the title. However, it is a noun fragment with no verb, so it does not state whether the tool reads, updates, or configures anything, and it does not distinguish itself from the sibling business_booking_rules.

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

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

The description offers no when-to-use guidance, no prerequisites, and no mention of alternatives such as business_booking_rules or business_features. An agent must infer invocation context solely from the name and annotations.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds nothing beyond that — no hint that results are tenant-scoped, no mention of cache behavior or why an agent might bypass the local cache, and no indication of what the response contains.

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

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

One fragment, zero waste, but the brevity is under-specification rather than efficiency. Nothing is front-loaded because there is essentially no content to order.

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

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

For a single-parameter read tool with strong annotations and no output schema, the description still leaves the essential question unanswered: whose settings (the authenticated user's, the business's, or both) and in what shape they come back. It is complete enough to guess at, not complete enough to call with confidence.

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

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

There is a single optional parameter with 100% schema coverage ('fresh' — 'Skip the local cache'), so the schema carries the semantics fully. The description neither elaborates on nor conflicts with it; baseline 3 applies when schema coverage does the heavy lifting.

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

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

The description restates the tool name/title almost verbatim — 'Staff and owner notification settings' names the resource but supplies no verb (get/list/update) and no scope statement. The only marginal addition over the title is the mention of 'staff and owner', which does not tell an agent what the call actually does.

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

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

There is no when-to-use guidance whatsoever, no prerequisites, and no reference to alternatives. An agent cannot tell from this text how this differs from siblings such as panel_notifications, business_pos_settings, or business_integrations that also expose per-tenant configuration.

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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond that, such as what settings are returned, whether POS authentication is required, or how caching behaves despite the 'fresh' parameter.

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

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

The description is a single front-loaded fragment with no filler. However, it is too terse to be appropriately sized for a tool whose purpose and return behavior need clarification.

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 settings tool with annotations covering safety and a fully documented optional parameter, the description is minimally sufficient to identify the resource. It still leaves gaps about what the settings include and offers no output guidance despite there being no output schema.

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% for the single 'fresh' parameter, which is documented as 'Skip the local cache.' The description does not add meaning 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?

The description restates the title/resource ('checkout and payment settings of the business') without a specific verb or scope detail. It does not explicitly say this retrieves or lists settings, making it close to a tautology of the title 'Checkout settings'.

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

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

There is no guidance on when to use this tool versus siblings such as business_booking_rules, business_notification_settings, payment_summary, or checkout_transactions. The intended context 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile and indicating an open-world read. The description adds almost nothing beyond that: it does not explain caching (despite the 'fresh' parameter), permissions, return format, or what 'open in the panel tab' means behaviorally. With annotations carrying the safety burden, the description should still add context but does not.

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

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

The description is a single, short sentence with no wasted words. It is front-loaded but the phrase 'open in the panel tab' is vague and could be clearer; still, it is appropriately sized for a simple tool.

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

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

The tool is simple (one optional parameter, no output schema) and annotations cover safety and openness. The description identifies the resource but does not explain what 'core data' includes, what the return values look like, or how it differs from related business_* tools. Given the absence of an output schema and many siblings, more specificity would be 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 description coverage is 100%, and the single optional parameter 'fresh' is documented in the schema as 'Skip the local cache'. The description does not mention this parameter or how it affects behavior, but the high schema coverage establishes a baseline of 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 ('business') and suggests it returns 'Public profile and core data', so the general purpose is inferable. However, it lacks a clear verb and does not distinguish this tool from numerous sibling business_* tools such as business_features, business_visibility, or business_amenities. The phrase 'open in the panel tab' is ambiguous and adds little clarity.

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

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

There is no guidance on when to use this tool versus the many sibling business_* tools. No alternatives are named and no conditions or exclusions are provided. An agent must guess based on the name alone.

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

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

The annotations already state readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds no behavioral context beyond restating the broad topic, such as whether it returns cached data, how freshness works, or what the response shape may be. No contradiction exists, but the description contributes little beyond annotations.

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

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

The description is a single short sentence fragment with no filler, and it is front-loaded. It is concise, though its terseness borders on under-specification rather than helpful brevity.

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

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

For a simple read-only tool with full schema coverage and annotations, the description is minimally adequate. It does not clarify the return semantics or differentiate the tool from adjacent business-related siblings, but the structured fields cover safety and parameter details.

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 only one parameter, and its schema description ('Skip the local cache') fully documents it at 100% coverage. The description does not mention the fresh/cache parameter, but the schema already carries that meaning, so the baseline score 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 identifies the domain: marketplace visibility and bookability. However, it is a noun phrase rather than a verb+resource statement, and it does not clarify whether the tool returns a boolean status, a listing record, or eligibility details. It is understandable but not sharply actionable.

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

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

There is no guidance on when to call this tool, when not to call it, or which sibling tools to use instead. Related siblings such as business_profile, business_features, and business_booking_rules are not mentioned, leaving routing entirely 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/idempotent/non-destructive, yet the description still adds real behavioral facts: long ranges are split into windows and read sequentially with pauses, and safe mode caps a range at 92 days. That 92-day constraint materially affects how an agent should chunk requests. It stops short of 5 because it doesn't hint at response shape or whether the pause means slow/large responses.

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 scope first, then the operational caveat about windowing/92-day safe mode, then the filter options. The status legend is dense but earns its space as the only decoding available. 'With a pause' is slightly vague but otherwise no waste.

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

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

For a 5-parameter read-only list tool with no output schema, the description covers range limits, chunking behavior, and both filter dimensions, which is most of what an agent needs to call it correctly. The 'fresh'/cache-bypass parameter and any notion of result volume are left to the schema and inference.

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 genuinely useful meaning the schema lacks: the single-letter status codes are fully decoded (A accepted, W waiting, C canceled, D declined, F finished, N no-show, M modified, O prepayment awaiting, P proposed, R rejected, V unverified), which the schema only types as a 1-character string. It does not explain 'fresh' or the staff_id semantics, holding it at 4.

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?

Opens with a specific resource list (appointments, reserved time, time off) and a date-range scope, so the agent knows exactly what data comes back. It does not contrast itself with close siblings such as calendar_month or calendar_changed_dates, so it falls short of a 5.

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

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

Usage is only implied – the presence of from/to and the status/staff filters suggests 'use this to review a date range,' but there is no explicit when-to-use or when-to-prefer-an-alternative guidance (e.g., versus calendar_month for a month view or the change feed for deltas).

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, idempotentHint=true, destructiveHint=false, so the safety profile is covered by structured data and the description need not restate it. The description adds a modest hint that this is a polling/sync endpoint, but does not explain caching behavior, ordering, or what a "change" means — the only cache-related detail ("fresh") lives in the schema, not the description.

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?

It is a single short sentence with no filler, which is good, but it is front-loaded with an ambiguous noun rather than a verb, and the trailing clause "as the panel polls them" is vague jargon that occupies space without resolving the core ambiguity.

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

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

There is no output schema, so the description carries the burden of saying what is returned, and it does not — the shape of a "date with changes" entry is never described. For a delta/polling endpoint where callers must know how to interpret the result and whether to pass the returned value back as a new timestamp, this is a significant 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 100%, so both parameters (timestamp with its Unix-seconds note, and the fresh cache-bypass flag) are already documented in the schema. The description's phrase "since a Unix timestamp" echoes the schema rather than adding format, granularity, or edge-case semantics. 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 ("dates with calendar changes") and the filtering dimension ("since a Unix timestamp"), but never uses a clear verb and leaves "dates" ambiguous — it is unclear whether this returns calendar days, appointment records, or change markers. It also fails to differentiate from the very similar sibling "appointment_changes_feed", so an agent cannot confidently tell the two apart.

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 indication of when to use this tool versus the many calendar siblings (calendar_month, calendar_agenda, appointment_changes_feed). The phrase "as the panel polls them" hints at a sync use case but is not framed as guidance or as an exclusion criterion.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds nothing beyond them — it does not mention the local cache that the 'fresh' parameter implies, nor what the counters represent or how they are scoped.

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

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

A single front-loaded sentence with no filler or redundancy. It is sized appropriately for prose, though its brevity reflects under-specification rather than economy of 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 4-parameter tool with no output schema and no annotations explaining return structure, the description leaves the key questions unanswered: what a 'counter' is, whether results are aggregated per day or per resource, and how caching affects freshness. An agent cannot confidently predict the response shape.

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%, with start_date/end_date documented as first/last day of the month and resource_ids explained as a staff/station filter, so the schema carries the parameter burden. The description adds no format, default, or interaction detail (e.g. that start/end must span exactly one month).

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 a resource domain (month view of the calendar) and hints at the payload ('counters and bookings'), which partially separates it from calendar_agenda. But 'counters' is undefined jargon and there is no clear verb specifying whether it retrieves, aggregates, or lists.

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

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

No indication of when to prefer this over calendar_agenda, calendar_open_slots, or calendar_changed_dates, and no stated prerequisites such as a required date range or resource scoping. The agent must infer the month-vs-agenda split from the tool name alone.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds real value beyond them by disclosing the computation basis (shifts, time off, bookings) and that results are derived locally, which explains the existence and effect of the 'fresh' cache-bypass parameter.

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, no waste, with the core computation and scope front-loaded before the usage cue. Nothing could be removed without losing signal.

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 availability query with no output schema, an agent has enough to call it correctly: date, duration, optional staff filter, and the knowledge that results are locally derived. It stops short of describing the shape of the returned slots, but the derivation sentence largely implies it.

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

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

Schema coverage is 100%, so all five parameters are already documented with patterns, bounds and defaults. The description only echoes scope ('one date', 'per staff member') and adds no format, interaction or defaulting detail 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?

States a specific verb+resource+scope: free time per staff member for a single date, computed from shifts, time off and bookings. This is clearly distinct from listing tools like calendar_agenda or staff_schedule, though 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?

"Use it before proposing a time to a client" gives one concrete workflow cue, which implies the tool's role in a booking flow. However, there is no explicit when-not guidance and no alternatives named (e.g., calendar_agenda for existing bookings, staff_schedule for raw shifts).

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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds no behavioral context of its own — notably it never mentions that the `fresh` flag bypasses a local cache, which is the one genuinely non-obvious behavioral trait of this tool and is only hinted at 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?

A single short sentence-fragment with no filler or redundancy. It is efficiently sized, though it leads with a noun phrase rather than an action verb, so the operation is not 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 full schema coverage and a rich annotation set, the description is minimally adequate. It usefully previews the returned fields (text, channel, audience, automation settings) in the absence of an output schema, but omits error behavior for invalid ids and the cache-freshness tradeoff an agent must decide on.

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% (templateId with a regex pattern, fresh described as "Skip the local cache"), so the baseline of 3 applies. The description mentions "template" but adds no meaning about the id format, the cache behavior, or what happens when an unknown id is 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?

The phrase "One campaign template" identifies the resource and implies a single-record retrieval, which distinguishes it from list-style siblings like campaign_groups or campaign_schedule. However, there is no explicit verb (fetch/get/retrieve) and no direct naming of a sibling, so the agent must infer the operation from the annotations and the required templateId.

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

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

The description gives no when-to-use guidance, no prerequisites, and no mention of alternatives. An agent seeing campaign_estimate, campaign_groups, campaign_schedule, and campaign_sms_balance alongside this tool gets no textual help choosing among them.

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, idempotentHint, and destructiveHint=false, so safety is largely covered. 'Sends nothing' usefully reinforces that no messages are dispatched, which matters for a campaign-named tool. But nothing is said about how cost is computed (segments, per-channel rates), what the response contains, or error behavior for malformed audiences.

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 outputs and immediately followed by the key safety constraint. No filler or repetition of the schema.

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

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

With no output schema and a nested, untyped recipients object, the description should explain the shape of the result (recipient count plus cost, possibly per channel) and how channel_priority influences pricing. It states the outputs at a high level but leaves enough gaps that an agent cannot fully predict the response.

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%, including descriptions for recipients, body_short, and channel_priority, so the schema carries parameter meaning. The description adds no extra semantics such as how channel_priority affects the cost estimate. Baseline 3 applies when the schema already documents every parameter.

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 concrete outputs (recipient count and SMS cost) and the resource (a campaign), so an agent knows exactly what it gets back. It doesn't explicitly use an estimate/dry-run verb, but 'Sends nothing' disambiguates it from actual campaign sending. Sibling differentiation against campaign_sms_balance or campaign_details is only implicit.

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: 'Sends nothing' suggests the natural pre-send pricing check, but the description never says when to call it, whether it is a prerequisite for campaign creation, or which sibling to use instead. No alternatives 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 declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that automated campaigns and their status are included, but does not mention caching behavior or other operational context beyond the annotations.

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

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

The description is a single compact sentence with no filler and is front-loaded with the resource being returned. It is slightly fragmentary and could more clearly state the operation, but it is appropriately sized.

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

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

For a simple read-only tool with one optional parameter and full schema coverage, the description covers the core resource and an included field. However, it does not resolve the naming ambiguity between 'campaign_groups' and 'campaign templates,' nor does it clarify the return shape in the absence of an output schema.

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 only one optional parameter, 'fresh,' and the input schema has 100% description coverage for it ('Skip the local cache'). The description adds no further meaning, which is acceptable given the schema's completeness.

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 identifies a specific resource, 'All message campaign templates,' and notes included data such as automated campaigns and 'automated_status.' However, it avoids an explicit verb like 'list' and does not distinguish itself from sibling tools such as campaign_details or campaign_schedule.

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

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

The description gives no explicit guidance on when to use this tool versus siblings like campaign_details or campaign_schedule. The word 'All' implies a broad listing, but the description does not state exclusions, prerequisites, or alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds nothing beyond that – no mention of what the schedule window is, what fields are returned, or how the open-world lookup behaves.

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?

It is a single short sentence with no padding, but brevity here comes from omission rather than economy. There is no front-loaded scope or qualifier to anchor the 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?

There is no output schema, so the description should at least indicate what is returned (a list of campaigns with schedule times, status, etc.). It also leaves the cache/`fresh` trade-off and the time window unaddressed, which is insufficient even for a simple list tool.

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

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

Schema description coverage is 100% and the single `fresh` parameter is documented there ("Skip the local cache"). The description adds no meaning on top of that, 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?

"Campaigns scheduled to go out" only rephrases the tool name and title (Scheduled campaigns) rather than stating a verb and resource. It never says it retrieves/lists scheduled campaigns, nor distinguishes it from siblings like campaign_groups, campaign_details, or campaign_estimate.

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

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

No when-to-use, when-not-to-use, or alternative is mentioned. With many campaign siblings present, the description gives the agent no basis for choosing this tool over campaign_details or campaign_groups.

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, idempotentHint=true, destructiveHint=false), so the bar is lower, but the description adds nothing beyond them. It says nothing about the local-cache behavior implied by the 'fresh' parameter or about latency/staleness of the returned balance figures.

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

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

A single compact sentence fragment with no filler, and the most relevant content (limits, used/free, price per part) is front-loaded. It is efficient but verbless, which slightly undercuts its clarity as a standalone definition.

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

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

With no output schema, the description usefully enumerates the fields that come back (limits, used, free messages, per-part price), which is the main thing an agent needs. However, for a cached read tool it omits how the 'fresh' flag changes results, leaving a real behavioral 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?

There is a single optional parameter whose schema description ('Skip the local cache') has 100% coverage, so the baseline is 3. The description does not mention caching or freshness at all, adding no meaning beyond the schema.

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

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

The description enumerates the data the tool surfaces (limits, used/free messages, price per part) but never states the operation — it is a noun phrase with no verb like 'retrieve' or 'get'. An agent can infer it is a read of SMS balance data, but the purpose is implied rather than declared, and no sibling (e.g. campaign_estimate, campaign_details) is referenced for contrast.

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

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

There is no guidance on when to call this tool, no prerequisites, and no mention of alternatives such as campaign_estimate for cost projection. The agent must infer usage purely from the name and the listed data fields.

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, idempotentHint, and destructiveHint=false, so safety is covered. The description adds only "with totals," hinting that aggregated figures are returned — mildly useful context, but nothing about error behavior when a register is not found or what the totals comprise.

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, but it is terse to the point of under-specification rather than efficient density. There is no front-loaded verb or scope statement to anchor the 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?

A two-parameter, single-resource read with fully documented params and rich annotations is simple enough that the definition is barely adequate. With no output schema, the phrase "with totals" is the only hint at return content and remains unelaborated.

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%, with registerId and fresh both documented in the schema, so the baseline of 3 applies. The description adds nothing about the meaning of fresh (cache bypass) or the registerId format 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?

"One cash register with totals" identifies the resource and signals a single-item scope, implicitly contrasting with the plural sibling cash_registers. However, there is no verb and no explicit statement that this retrieves a register, so the agent must infer read semantics from the annotations rather than the text.

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 "One" hints at a single-record lookup versus the cash_registers list, but no when-to-use condition, prerequisite, or alternative is named. With siblings like cash_registers and cash_register_operations in the set, the agent gets only weak routing signal.

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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only that the tool concerns one register, and omits pagination behavior, cache/fresh semantics, and what is actually returned; the word 'operations' is also ambiguous enough to risk suggesting mutation despite readOnly annotations.

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

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

The description is a single short sentence with no wasted words, but its brevity comes at the cost of under-specification. It is front-loaded only in the sense that there is nothing else to read.

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 four-parameter paginated read tool with no output schema, the description is too thin. It does not clarify the return shape, pagination, cache behavior, or whether 'operations' means records versus actions.

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 registerId, page, per_page, and fresh are fully documented in the schema. The description adds no parameter meaning beyond the schema, which is acceptable at the baseline because the schema carries the burden.

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 is a noun phrase ('Cash in and out operations of one register') without a clear verb, so it does not say whether this lists cash movements, returns a register summary, or performs an action. It does not distinguish itself from siblings like cash_register or cash_registers.

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

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

There is no guidance on when to use this tool versus cash_register, cash_registers, or payment tools. The phrase 'one register' hints at single-register scope but does not state how to choose among alternatives.

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

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

The annotations already declare that this is a read-only, idempotent, non-destructive, open-world operation. The description adds useful data context by saying it returns open/closed state, but it does not explain pagination behavior, caching semantics, or what the returned state means.

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

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

The description is short and waste-free, but it is an under-specified fragment rather than a well-structured definition. It lacks the verb and scope information an agent would need before invoking the tool.

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, annotations and schema cover safety and pagination, but the description still leaves important gaps: it does not state a clear action, nor does it clarify the difference from `cash_register` and `cash_register_operations`. With no output schema, the description should do more to explain what the returned state represents.

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 `page`, `per_page`, and `fresh` parameters are already fully documented in the input schema. The description adds no parameter meaning beyond the schema, which is acceptable at the baseline for high-coverage schemas.

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 identifies the resource (cash registers) and adds that it exposes open/closed state, which implies a listing of registers. However, it is a noun phrase with no verb, and it does not distinguish this tool from the singular `cash_register` or `cash_register_operations` 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?

There is no guidance on when to use this tool rather than `cash_register` or `cash_register_operations`. The description gives no context, prerequisites, or exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=true, so safety and idempotency are covered structurally. The description adds two real facts beyond that: newest-first ordering and the panel-enablement prerequisite. It says nothing about pagination semantics (how to page past the 30-item cap) or what a conversation record contains.

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 zero filler; the resource and its ordering come first, and the enablement constraint follows. Every clause carries information an agent would otherwise have to guess.

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 paginated list, annotations and the schema carry most of the load. Still, with no output schema, the description could say what a conversation object contains, and it never clarifies the relationship to chat_messages, which is the most likely source of a wrong tool choice.

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% with two simple pagination parameters (limit, offset) that carry defaults and bounds. The description adds no interpretation beyond the schema, so 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?

Names the resource (client chat conversations) and its ordering (newest first), which is enough to know this returns a conversation list rather than messages. It stops short of differentiating itself from the sibling chat_messages tool, so an agent cannot tell from the description alone which of the two to call for a given need.

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?

"Works only where the panel has client chat enabled" is a useful precondition, effectively a when-not-available rule. However, there is no guidance on when to choose this over chat_messages or chat_quick_actions, leaving the choice to inference from names.

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, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered and the bar is lower. The description adds only that results are "latest" messages of a single conversation; it does not say how ordering works, whether results are paginated, or what happens when the conversation has no messages.

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 six-word sentence with no filler and no buried information. It earns its place, though the brevity borders on under-specification rather than economy.

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

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

There is no output schema, so the description carries the burden of explaining what comes back — message fields, ordering (newest-first?), and whether `limit` truncates silently — and it says nothing about any of this. For a read tool with no output schema and an open-world annotation, that is a meaningful gap.

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

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

Schema coverage is 100%, so channel_id ("Conversation id") and limit ("How many", default 30, max 100) are already documented. The description's phrase "one client conversation" loosely corroborates channel_id but adds no new syntax, format, or ordering semantics 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 names a specific resource (messages of a single conversation) and adds the qualifier "latest", but it is a noun phrase with no verb and no reference to the sibling chat_conversations, which is presumably where you list the conversations themselves. An agent can guess the purpose, but the boundary with the sibling is left implicit.

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

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

No when-to-use guidance, no prerequisites, and no mention of the obvious alternative (chat_conversations for listing conversations). The agent must infer the routing decision entirely from the tool name.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context of its own, such as caching implications of the 'fresh' parameter or what the returned suggestions represent.

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

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

The description is a single short sentence with no wasted words and is front-loaded with the resource being returned. It is concise, though its brevity contributes to other gaps rather than being a structural flaw itself.

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 tool with no output schema, the description does little to explain what 'quick actions' are, what shape the response takes, or how the result relates to a client conversation. The annotations cover safety, but the definition is not complete enough for an agent to understand the return context.

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%, with both parameters documented ('bci_id' as Client id and 'fresh' as Skip the local cache). The description adds no additional meaning beyond the schema, 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 identifies the resource as 'suggested quick actions for a client conversation,' but it omits a clear verb such as 'get' or 'list' and does not distinguish this tool from siblings like chat_conversations or chat_messages. The purpose is inferable but vague.

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

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

There is no guidance on when to use this tool, when not to use it, or which sibling tool to choose instead. The description only names the resource and leaves all usage context to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond that—it does not explain caching behavior, what 'latest' means in edge cases, or what the response contains. It neither contradicts nor enriches the annotations.

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

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

The description is a single front-loaded sentence with no wasted words. It is efficiently structured, though its brevity contributes to under-specification addressed in other dimensions rather than being a conciseness problem itself.

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

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

There is no output schema, so the description should ideally explain what the 'latest receipt' returns—an object, an ID, a URL, or something else. It also omits any mention of the caching behavior implied by the fresh parameter. Given the many checkout-related siblings, the definition leaves too much for an agent to infer.

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

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

Schema description coverage is 100%, and the schema already documents both transactionId and the fresh flag that skips the local cache. The description adds no additional parameter meaning beyond implying a transaction context. With the schema fully covering parameters, a baseline 3 is appropriate.

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

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

The description identifies the resource (the latest receipt) and ties it to a transaction, which gives some specificity. However, it is a noun phrase with no verb, and it does not distinguish itself from sibling tools such as checkout_transaction or payment_rows. An agent can infer that it retrieves something, but selection clarity is limited.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention checkout_transaction, payment_rows, or any other sibling, nor does it state prerequisites or exclusions. The agent must infer usage entirely from the tool name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds that the returned record bundles items, payments, tips and discounts, which is genuinely useful content context but stops short of noting the cache-bypass behavior implied by the 'fresh' parameter.

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

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

One short sentence with no waste, but it is under-specified rather than tight — there is no leading verb or scope statement to front-load. Brevity here costs clarity.

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 describing return contents; it partially does so by naming items, payments, tips and discounts. However, for a single-record lookup it omits what happens when the transactionId does not exist and does not clarify the effect of 'fresh'.

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 both parameters (transactionId, fresh) are documented in the schema, so the baseline is 3. The description adds no meaning about identifier format or what 'fresh' changes about the result.

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 is a noun phrase, not a verb+resource statement, so the agent must infer 'fetch' from the name. It does implicitly distinguish itself from the sibling checkout_transactions by saying 'One transaction', but the purpose is only weakly articulated.

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

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

There is no explicit guidance on when to use this versus checkout_transactions, checkout_last_receipt, or payment_basket. The singular-vs-plural contrast is only hinted at by the word 'One'.

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, idempotentHint and destructiveHint=false, so safety is covered. The description adds nothing beyond that: it does not mention pagination behavior, cache interaction implied by the 'fresh' flag, or what a returned transaction represents. Minimal value beyond structured data.

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

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

A single front-loaded sentence with zero padding. It is short rather than bloated; the weakness is under-specification, which is penalized elsewhere, not verbosity.

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

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

For a five-parameter, open-world, paginated list tool with no output schema, the description says nothing about result contents, paging semantics, or the cache behavior implied by 'fresh'. It does not meet the burden the missing output schema places on prose.

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

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

Schema coverage is 80%, so the four documented params (page, per_page, fresh, date_from) already carry their own meaning. The 'query' parameter is undocumented in both schema and description, and the description makes no attempt to explain what it searches, leaving a real ambiguity unaddressed.

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 nearly restates the title verbatim ('Checkout transactions' + 'for a period'), adding only a vague date scope. It does nothing to distinguish this list tool from the sibling singular 'checkout_transaction', so an agent cannot tell which to reach for without opening schemas.

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

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

There is no statement of when to use this versus the very close sibling 'checkout_transaction', nor any prerequisite or exclusion. The only usage signal ('for a period') is implied by the presence of date_from in the schema, not asserted by the description.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=true; the description adds nothing about behavior, including why the tool is flagged open-world or what the cache/fresh flag implies about freshness of results. Credit here only for not contradicting the annotations.

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

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

It is short, but the brevity is under-specification rather than discipline: a single fragment with no verb and no front-loaded action statement. There is nothing redundant, but nothing earns its place either.

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?

No output schema and no annotation elaboration means the description must carry the burden of telling the agent what is returned and how it relates to signed consents, and it does neither. For a list-style read tool this leaves the agent guessing at the result shape.

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 one optional parameter and 100% schema description coverage, the schema carries the full meaning of 'fresh' (skip the local cache). The description adds no interpretation of its own, 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?

The description is a bare noun fragment, 'Consent form templates.', that restates the title with one added word. It hints at the resource (templates rather than signed consents, implicitly vs sibling consents_signed) but supplies no verb or scope, so an agent cannot tell whether it lists, fetches, or creates templates.

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

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

No indication of when to call this versus consents_signed or any other sibling, and no stated preconditions. The closest sibling is thematically adjacent, which makes the absence of routing guidance a real risk of misselection.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — it doesn't disclose that results are paginated, that a local cache exists (implied only by the 'fresh' param), or what the shape of a consent record is.

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 wasted words, but it is under-specified rather than concise — the terseness removes disambiguating information an agent needs among ~100 siblings.

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 listing tool in a large namespace with a near-identical sibling (consent_forms), the description is not complete enough to route correctly. Annotations and schema are the only reliable signal; the description resolves neither scope nor relationship to the sibling.

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?

All three parameters (page, fresh, per_page) have full schema descriptions with defaults and bounds, so the schema carries the load and a baseline of 3 is appropriate. The description contributes no additional meaning about how paging or cache-skipping interact with consent listings.

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 restates the name/title ('Consents') and appends a minimal scope qualifier ('assigned to clients'), but supplies no verb — it never says this lists or retrieves signed consents, nor how it differs from the sibling consent_forms.

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, when not to, or what the alternative (consent_forms) covers. An agent must guess which of the two consent tools to call.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds nothing behavioral — notably it never mentions the local cache or what the 'fresh' flag changes, even though caching is a real behavioral trait of this 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?

A single front-loaded sentence fragment with zero filler; the content list is the most useful part and comes first. It is terse to the point of being a label rather than a 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?

For a two-parameter read-only tool with full schema coverage and annotations, the description is adequate: it says what the card contains. It leaves out caching behavior and whether the call can fail for unknown ids, but those gaps are minor given the structured fields available.

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 customerId and fresh are fully documented in the schema. The description adds no parameter-level meaning beyond that, which is the baseline case rather than an added-value case.

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 (a single 'full client card') and enumerates its contents — contact data, notes, tags, visit and spending counters — which implicitly differentiates it from the plural sibling customer_cards. It lacks an explicit verb ('retrieve') but an agent can still identify the operation.

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

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

There is no guidance on when to use this versus the many related siblings such as customer_cards (list), customer_visit_history, customer_product_history, or customer_tags. The choice is left entirely 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?

The annotations already establish read-only, idempotent, open-world, and non-destructive behavior, so the description does not need to repeat safety semantics. It adds the useful detail that query searches by name, phone, or e-mail, but it does not mention caching, pagination behavior, or result format.

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

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

The description is a single, front-loaded sentence with no filler. It communicates the primary list behavior first and the optional search behavior second.

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/search tool with fully described parameters and rich annotations, the description is largely complete. It could mention pagination or what card summary fields are returned, but the missing pieces are 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?

Schema coverage is 100%, so page, per_page, and fresh are already well documented in the schema. The description still adds semantic value for query by clarifying that it searches name, phone, or e-mail rather than just saying 'Search text.'

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

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

The description gives a specific verb and resource: it lists client cards and can search them. It clearly distinguishes list mode from query/search mode, though it does not name the singular customer_card sibling or explain how it differs.

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 implies when to use query (to search by name, phone, or e-mail), but it does not explicitly say when to use this tool versus customer_card or loyalty_cards. The usage mode is understandable but not fully guided.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the useful detail that the operation writes to a local file (a side effect outside the API), but says nothing about where the file lands, whether it overwrites, or how large downloads behave. Given annotation coverage, a 3 is appropriate.

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

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

One sentence, front-loaded with the action and resource, with no filler. It is arguably too short for a download tool whose output destination is ambiguous, but nothing in it 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 only two fully documented parameters and annotations carrying the safety profile, the definition is nearly sufficient. The remaining gap is what the agent gets back and where the local file is written, plus how this differs from document_download — meaningful for an agent choosing between two download-style tools.

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

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

Schema description coverage is 100%, so customerId and attachedFileId are already documented with patterns and required status. The phrase 'attached to a client card' weakly reinforces the relationship between the two ids, but adds no format or sourcing detail beyond the schema.

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

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

States a specific verb ('saves') and resource ('a file attached to a client card'), so an agent knows exactly what the tool produces. It does not, however, distinguish itself from the sibling document_download, which by name alone could be the tool an agent reaches for when a file is involved.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the obvious alternative document_download. The only implicit signal is 'attached to a client card', which an agent must infer means customer-card attachments rather than generic documents.

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, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds only "with their sizes," which is a thin hint about return content; it says nothing about caching behavior, whether the list is paginated, or what a group actually contains.

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

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

The one-line fragment is front-loaded and free of padding, so nothing is wasted. However, a bare noun phrase is under-specification rather than disciplined conciseness; there is no structure for an agent to parse beyond the single 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?

The tool is simple (one optional boolean, no output schema, no nested objects) and annotations cover the safety profile, so the description need not be long. Still, it omits what a client group is and what fields come back, leaving the agent to infer the tool's usefulness from the name alone.

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% with a single optional parameter (`fresh`, documented as "Skip the local cache"), so the schema carries the semantics. The description never mentions the cache-freshness option, but with full coverage 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?

"Client groups with their sizes" essentially restates the tool name and title, adding only the hint that size counts are included. There is no verb, no scope statement, and nothing to distinguish it from siblings like customer_tags or campaign_groups that an agent might confuse it with.

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

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

The description gives no when-to-use guidance, no prerequisites, and never names an alternative. An agent has no way to know whether this is the right tool for segmenting customers versus campaign_groups or customer_tags; it must infer everything from the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered without the description. The description adds nothing behavioral: no mention of pagination over the purchase history, no mention of the cache-bypass semantics implied by the `fresh` flag, and no hint at result ordering or volume.

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?

It is a single four-word fragment with no padding, so nothing is wasted. But brevity here comes from under-specification rather than discipline: the one sentence carries no front-loaded scope, return shape, or routing 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 four-parameter list tool with no output schema, the description leaves the agent unable to know what a record contains (a transaction, a product line, a summary?) or how results are ordered. Annotations cover safety, but the remaining gaps are meaningful for correct invocation.

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

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

Schema description coverage is 100%, so customerId, page, page_size and fresh are all self-documented; the baseline of 3 applies. The description does not add meaning to any of them — notably it says nothing about whether results are paginated or what `fresh` changes.

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?

"Products one client bought" conveys a resource (products) and a scope (a single client), so an agent can broadly infer it lists a customer's purchase records. However it never states it is a list/history endpoint, never contrasts with plausible siblings like customer_visit_history or customer_cards, and the phrase is terse enough to be mistaken for a catalog lookup.

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

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

There is no explicit when-to-use, when-not-to-use, or named alternative. The only implied guidance is that a customerId must be known, leaving the agent to guess how this differs from customer_visit_history or payment_rows.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. However, the description adds no behavioral context—it does not mention caching, freshness semantics, result scope, or what the tool returns, despite the 'fresh' parameter relating to cache 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?

The description is a single sentence fragment with no verb and no structural front-loading of the action. It is short but under-specified rather than concisely informative.

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?

Given the simple one-parameter schema and existing annotations, the definition is still too thin: it never says the tool lists tags or describes the return shape, and it provides no context for selecting it among many sibling tools. An agent could guess, but the description is not complete enough for reliable invocation.

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

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

The sole parameter, 'fresh', is fully documented in the schema as 'Skip the local cache'. The description adds no parameter-level detail, but with 100% schema description coverage the baseline score 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 identifies the resource but not the operation; it says 'Tags used on client cards' without stating whether it lists, retrieves, or manages tags. This essentially restates the name and title rather than clarifying what the tool does.

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

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

There is no guidance on when to use this tool versus siblings such as customer_cards, customer_card, customer_groups, or campaign_groups. The agent is left to infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond the basic resource scope, such as pagination behavior, caching semantics, or the effect of state and include_extra_bookings filters.

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

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

The description is a single, front-loaded sentence with no wasted words. It is appropriately concise, though its brevity contributes to gaps in usage and behavioral detail.

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

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

The description states the core return content (past and future appointments for one client), which is useful as there is no output schema. However, it does not mention pagination, caching, or filtering behavior, which are relevant given six parameters and the fresh and state options.

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

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

Schema description coverage is 100%, so all six parameters are documented in the schema itself. The description does not add meaning beyond what the schema provides, but the baseline score of 3 is appropriate when the schema fully covers parameter semantics.

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

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

The description clearly states the resource (appointments) and scope (one client) and clarifies that it covers both past and future visits. It is specific enough to distinguish from generic calendar tools, though it does not explicitly name or contrast with sibling tools like appointment_details or customer_product_history.

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

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

The description gives no guidance on when to use this tool versus alternatives such as calendar_agenda, appointment_details, or customer_product_history. The required customerId parameter implies a per-client lookup, but there are no explicit usage conditions or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the meaningful behavioral fact that the result is a file written locally rather than inline data, but says nothing about where the file lands, its format/extension, whether it overwrites, or any auth/rate constraints.

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

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

A single front-loaded sentence with no filler; the verb and outcome appear immediately. It is efficient, though the brevity leaves the gaps noted in other dimensions unaddressed.

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 two required params, rich annotations, and no output schema, the description carries the burden of describing the returned artifact — yet it only says 'local file' without path, filename convention, or format. An agent knows what the tool does but not what it gets back.

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 only 50% (the kind enum has no description), and the description compensates by enumerating the four document classes that map onto the enum values (cash_register_report, cash_document, invoice_pdf, consent_pdf). The id parameter gets no added meaning beyond the schema's own description, so it is not a 5.

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 a specific verb (saves as a local file) and the concrete resource classes (cash register report, cash document, invoice, consent), which is enough to separate it from retrieval siblings like invoice, cash_register, and consents_signed that return data rather than a file. It stops short of naming a sibling explicitly, so it lands at 4 rather than 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?

The phrase 'as a local file' implies the use case (persist a document to disk rather than read its metadata), so usage is inferable. However, there is no explicit when-to-use/when-not guidance and no mention of the adjacent tools (invoice, cash_register, consent_forms) that return the same underlying records in JSON form.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered elsewhere. The description adds nothing beyond that – it does not explain caching behavior, why the `fresh` flag exists, or what the agent gets back. No contradiction with annotations, so not a 1.

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 words is not conciseness but under-specification; there is no front-loaded verb or object to orient an agent. The brevity saves nothing because the content carries no information beyond the 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 only two params, full schema coverage and no output schema, a little description would suffice – but an agent still cannot tell from the description whether this returns an invoice object, a rendered document, or how it differs from the `invoices` sibling. Annotations cover safety, so the gap is small but real.

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 `invoiceId` and `fresh` are documented in the schema, including the cache-skip semantics of `fresh`), so the baseline is 3. The description contributes no additional parameter meaning, but it does not need to given the schema.

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

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

"One invoice." merely restates the tool name/title in singular form. It never says whether it retrieves, renders, or summarizes an invoice, nor does it explicitly contrast with the sibling tool `invoices` – the singular/plural distinction is the only implicit differentiator an agent must infer.

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

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

There is no guidance whatsoever: no when-to-use, no when-not-to-use, no mention of the sibling `invoices` list tool, and no note that a valid invoiceId is required to fetch a specific record.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds nothing beyond that — notably it never mentions the pagination defaults or the `fresh` cache-bypass behavior, which are the only interesting runtime traits here.

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

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

A single short sentence with no filler, so nothing is wasted — but it is under-specified rather than genuinely concise. There is no front-loaded statement of action or return shape.

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 is the only place to learn that this returns a paginated collection of invoices and what a record contains. It says neither, leaving the agent to infer the return shape from the parameter names.

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% with all three parameters documented (page, per_page, fresh including defaults and bounds). The description contributes no additional semantics, 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?

The description reads as a restatement of the name and title ("Invoices issued in the panel") with no verb saying what the tool actually does — list, fetch, paginate. It also fails to distinguish it from the sibling `invoice` (singular), which an agent would naturally confuse with this one.

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 indication of when to use this tool versus `invoice`, `payment_rows`, `checkout_transactions`, or `booking_charges`. The phrase "issued in the panel" hints at scope but gives no conditions or exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — no indication that results are paginated, that a cache exists or can be bypassed via 'fresh', or what a returned card contains.

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?

It is short, but length here comes from omission rather than efficiency; the single fragment duplicates the title and carries no information. Nothing is front-loaded because there is nothing to front-load.

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

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

For a paginated, cache-aware list endpoint with no output schema, the description supplies neither return shape nor pagination behavior nor the resource's meaning. An agent has essentially no basis for calling it correctly beyond the schema field names.

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 all three parameters (page, per_page, fresh) are documented with defaults, bounds and meaning in the schema itself. The description adds no extra semantics, 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?

"Client loyalty cards." only restates the tool name/title and never supplies a verb, so an agent cannot tell whether this lists cards, fetches one, or returns a template. It is indistinguishable from siblings such as customer_cards and loyalty_program 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?

There is no when-to-use, when-not-to-use, or alternative routing guidance at all. With customer_cards and loyalty_program in the sibling set, the description leaves the agent to guess which endpoint answers a loyalty-card question.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds almost nothing beyond that: it does not explain what 'current' means, what data is returned, or how the 'fresh' caching parameter affects 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?

The description is a single fragment and is too under-specified to be useful. Brevity here reflects missing information rather than efficient communication.

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

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

The tool is read-only with one optional parameter and no output schema, so the description should explain what the tool returns and how it relates to sibling loyalty/card tools. Instead it provides only a vague label, leaving the agent unable to predict the response.

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

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

Schema description coverage is 100%, and the single optional 'fresh' parameter is fully documented in the schema. The description adds no parameter semantics beyond the schema, 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 'The current stamp card program.' is a noun phrase with no verb and essentially restates the title. It does not say whether the tool retrieves, configures, or summarizes the loyalty program, nor how it differs from sibling tools like loyalty_cards or customer_cards.

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

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

There is no guidance on when to use this tool versus alternatives such as loyalty_cards, customer_cards, or customer_card. The agent is left to infer usage entirely from the tool name and annotations.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description usefully adds that results are returned per-day over a whole week (implying a weekly payload), but says nothing about caching behavior, timezone, or how days without hours are represented.

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

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

A single front-loaded sentence with no filler, sized appropriately for a simple two-parameter read tool. Slight redundancy in 'of the business, day by day' 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?

For a simple read tool with rich annotations and no output schema, the description is adequate but leaves gaps: it does not hint at the shape of each day's entry (open/closed, intervals), timezone handling, or what happens when the date falls in a week spanning DST or missing 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 description coverage is 100%, so both 'date' and 'fresh' are already documented. The description's phrase 'week of the given date' reinforces that the date selects a week rather than a single day, which is mild added value, but the schema's own note ('Any day in the week') already carries this.

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 (opening hours) and specifies both granularity (day by day) and window (the week of the given date), which is more precise than the title alone. It stops short of distinguishing itself from any sibling such as calendar_open_slots, so it does not reach 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?

The phrase 'for the week of the given date' implies when the tool applies (fetching hours for a week), but there is no explicit guidance on when to use this versus related calendar or booking-rule tools, and no stated exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered and the description need only add context beyond that — which it does not. Notably it is silent on the one non-obvious behavior in the schema: the `fresh` flag bypasses a local cache, implying this call is normally cached and possibly stale, a fact an agent needs before trusting results.

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

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

One short sentence with zero padding and the resource front-loaded, which is structurally sound. The brevity is under-specification rather than economy, though, so it does not earn top marks.

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 four-parameter paginated feed with no output schema, the description should say what a notification record looks like and whether paging is required to get everything. Instead it says nothing about the return shape, cache/staleness behavior, or which notifications are included, leaving real gaps for a read tool whose results feed into an agent's context.

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%, including the status enum and per_page cap, so the schema already carries parameter meaning. The description adds nothing to it — no clarification of what 'new' vs 'active' vs 'archived' mean, nor when caching makes `fresh` necessary. Baseline 3 applies when the schema does the heavy lifting alone.

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?

It names a specific resource (the notification list) and its origin (the panel bell), which separates it from business_notification_settings and the chat feed siblings. But it is a bare noun phrase with no verb and no scope statement — an agent cannot tell what the list contains, whose notifications they are, or how it differs from chat_conversations beyond guesswork.

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

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

There is no when-to-use guidance at all — no mention of when to reach for this instead of business_notification_settings or chat_conversations, and no note that it returns unread/active items by default. Usage is only implied by the phrase 'notification list'.

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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so safety is fully covered without the description. The only added context is the composition of the payload (deposit, payment and refund records); nothing is said about whether an unknown basketId errors or returns empty, nor about the effect of the documented cache on result freshness.

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

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

One short sentence with no filler, which is appropriately sized in raw terms. But the terseness is partly under-specification rather than economy: the single fragment omits the verb and the lookup key, so brevity costs clarity instead of buying it.

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

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

For a two-parameter read with a fully documented schema, complete annotations, and no output schema, the description is close to sufficient. The gaps are the unstated operation verb and the unexplained relationship between the documented 'fresh' cache flag and the returned data, which an agent would want to know before calling.

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%: basketId has a pattern and 'fresh' documents the cache-skip flag, so the schema already carries parameter meaning. The description adds no format, scoping, or caching detail beyond that, which is the baseline case for a fully documented schema.

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

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

The description names a specific resource and hints at its contents (deposit, payment and refund records), but it is a bare noun phrase with no verb, so the operation (fetch one basket by id) must be inferred from the name and schema. It also does nothing to distinguish itself from adjacent siblings such as payment_rows, payment_summary, checkout_transactions, or appointment_payment_details.

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, no prerequisites, and no mention of any alternative. With five or six payment-related siblings in the list, the absence of any routing guidance leaves the agent to guess based on name similarity alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered elsewhere. The description adds only a vague inventory of returned columns and a screen analogy; it says nothing about pagination behavior, caching (the `fresh` param implies a cache layer), ordering, or result size limits. No contradiction with annotations, but very little incremental disclosure.

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

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

It is a single short sentence, so nothing is bloated, but it is under-specified rather than concise. The trailing UI analogy ('like the panel payments screen') spends the final clause on a reference the agent cannot resolve.

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?

Six parameters, two required, no output schema — the description carries the burden of explaining what comes back and in what form. It gestures at fields but omits pagination shape, whether refunds/partial payments are included, and how results are ordered, which leaves an agent guessing about the row set it will receive.

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 the required date_from/date_till and the `fresh` cache flag) are already documented in the schema. The description adds no formats, defaults, or semantics beyond what the schema states, which is the baseline 3 case.

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 (payments) and hints at returned fields (method, status, amounts), so an agent knows it retrieves payment records. However, the phrasing is a noun phrase rather than a verb+resource, and it does nothing to distinguish itself from close siblings such as payment_summary, checkout_transactions, booking_charges, or payment_basket. The 'like the panel payments screen' analogy points at a UI an agent cannot see.

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

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

No when-to-use, when-not-to-use, or alternative is stated. With roughly a dozen payment-adjacent siblings, the description needed to say why an agent would pick payment_rows over payment_summary or booking_charges, and it does not.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds essentially nothing beyond that: it does not explain the local cache implied by the 'fresh' parameter, how the period/scope interacts with date_from/date_till, or what a 'tile' contains.

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 is front-loaded and wastes no words, but here brevity reflects under-specification rather than discipline. There is room to add one clarifying clause at no structural cost.

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 7-parameter analytics tool with no output schema needs the description to define what the summary contains and how scope interacts with date range and pagination. The description leaves the return shape, the meaning of 'tiles', and the cache behavior behind 'fresh' entirely 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 description coverage is 100%, so per the baseline this scores 3. The description does not clarify the most ambiguous parameter — 'scope' as a 'Period key used by the panel' — nor how scope relates to the optional date_from/date_till range, but it is not obligated to when the schema documents every field.

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

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

The description names the resource ('payments') and the output shape ('summary tiles'), which is more than a bare restatement of the title, but 'summary tiles' is undefined and 'for a period' is too vague to distinguish this from siblings like payment_rows or stats_dashboard. An agent can guess it's an aggregated read, but not what the aggregates are.

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

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

There is no when-to-use guidance, no mention of when to prefer this over payment_rows, checkout_transactions, or stats_dashboard, and no prerequisites stated. The only implicit signal is that 'summary' contrasts with row-level tools, which the agent must infer entirely on its own.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that — notably it never mentions caching behavior, which is the one non-obvious trait here given the `fresh` parameter's cache-busting semantics. No contradiction, but zero added behavioral context.

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?

It is short, but shortness here is under-specification rather than conciseness: there is no front-loaded verb or object statement, and the entire text is two words restating the 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?

For a simple, annotated, one-optional-parameter read tool, the bar is low, but the agent is still left without knowing what a call yields or how it relates to the catalog/category/supplier tools. Annotations cover safety; nothing covers purpose or output shape.

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

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

The description says nothing about the single `fresh` parameter, but schema description coverage is 100% and the schema itself explains it as "Skip the local cache." Baseline 3 applies when the schema carries the parameter documentation.

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 is a noun phrase that simply restates the tool name and title ("Product brands.") with no verb, no scope, and no indication of what is returned. An agent still cannot tell whether this lists brands, retrieves brand details, or maps brands to products, nor how it differs from siblings like product_categories or product_suppliers.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of any alternative tool. With closely related siblings (product_catalog, product_categories, product_suppliers, product_stock_history) available, the absence of routing guidance is a real selection hazard.

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