veterical

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's 'safe' aligns. It adds the key behavioral trait 'Cross-organization ids fail closed as not found,' which is not in annotations and clarifies error handling for invalid or out-of-scope ids.

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

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

Two sentences, front-loaded with the primary purpose and a concise edge-case note. No filler or redundancy.

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

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

For a simple single-parameter tool with an output schema and comprehensive annotations, the description covers purpose and a critical edge case. It is sufficient for an agent to call it correctly; missing return-format details are already provided by the 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 coverage is 100% and the schema already documents clinicId with format and pattern. The description adds no extra meaning about the parameter itself, though the cross-org note indirectly clarifies invalid id behavior. This meets the baseline for high schema coverage.

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

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

The description clearly states a specific verb and resource: 'Get safe administrative metadata for one clinic in the authenticated Veterical organization.' It distinguishes from plural siblings like list_clinics and from overview or schedule tools by specifying 'administrative metadata' and 'one clinic.'

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 clear context on when to use the tool (retrieving administrative metadata for a single clinic) without explicitly naming alternatives or exclusions. The purpose itself implies usage boundaries, but it doesn't explicitly contrast with siblings like get_clinic_availability or show_clinic_overview.

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

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

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds meaningful value by specifying what the tool returns and, importantly, what it never returns (animal, owner, staff, appointment, or clinical data). No contradiction with 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 two sentences with no filler. The core action and time window are front-loaded, and the data-scope clarification earns its place.

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

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

For a single-parameter read-only tool with an output schema and informative annotations, the description is complete: it defines the time window, data scope, and exclusions. Nothing critical is missing 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%, and the schema fully documents clinicId with type and pattern. The description does not add parameter-specific semantics, so the baseline of 3 is appropriate—the schema already carries the parameter meaning.

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

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

The description uses a specific verb ('Summarize') and resource ('booking window... unassigned capacity by day') and clearly distinguishes this from siblings like get_clinic or get_clinic_schedule_summary by stating it returns only capacity data, never clinical or appointment data.

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 provides clear context for when to use the tool: for the fixed tomorrow-through-fourteen-days booking window and only bounded unassigned capacity. It does not explicitly name alternatives or exclusions, but the description is specific enough that an agent can infer the intended use case.

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 read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral guarantees: results are grouped by UTC day, limited to 31 days, and intentionally exclude appointment identifiers, times, and all clinical fields, which is not visible in the schema or annotations.

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

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

Two sentences with no filler; the core behavior is front-loaded and the privacy/data-scope caveat is placed immediately after. Every clause adds information an agent needs before calling 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 read-only aggregate tool with a rich output schema, full parameter documentation, and strong annotations, the description covers purpose, scope, constraints, and output limitations. Nothing essential is missing for correct tool selection and 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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the effective date-range limit (at most 31 days), the UTC-day aggregation unit, and that clinicId must identify a tenant-owned single clinic.

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?

Description opens with a specific verb and resource: 'Count scheduled records by UTC day' for a single clinic, with a hard 31-day cap. The 'aggregate administrative counts only' clause clearly separates it from detail-returning siblings like list_calendar_events or get_clinic_availability.

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 clear context: use it for aggregate administrative counts over a date range, scoped to one tenant-owned clinic. It does not explicitly name alternative tools or state when not to use it, but the 'never... clinical data' exclusion effectively prevents misuse for detailed schedule or clinical queries.

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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false; the description adds meaningful behavioral constraints by stating that identifiers, references, titles, notes, linkage, and clinical fields are never returned. The word 'bounded' further hints at pagination behavior. No contradiction with annotations 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?

Two sentences with no filler: the first front-loads the tool's scope, and the second adds a privacy/behavioral guardrail. Every phrase earns its place.

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

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

With an output schema present, return-value documentation is not the description's job; the schema covers filters and cursor pagination, annotations cover safety, and the description covers scope and exclusions. It is slightly incomplete only in not naming a sibling alternative or clarifying the title's 'overrides' term, but nothing essential is missing for a read-only list operation.

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%, so the schema already documents startTime, endTime, clinicId, and cursor; limit is self-explanatory from its constraints. The description adds no parameter-level details, just the 'bounded' qualifier, so it provides minimal value beyond the input 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 states a specific verb and resource: 'List bounded, tenant-scoped non-appointment calendar blocks' and gives concrete examples (closures, courses, meetings, days off). It explicitly distinguishes the tool from appointment-related calendar data, which helps an agent separate it from sibling scheduling tools 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?

The phrase 'non-appointment calendar blocks' gives clear context for when this tool applies and excludes appointment/availability data. It does not explicitly name sibling alternatives or state when-not-to-use conditions, but the inclusion/exclusion scope is clear enough for an agent to select it for closures, courses, meetings, and days off.

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

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

Annotations already establish the operation as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by stating the 100-item limit and the categories of data excluded. This gives the agent practical expectations about result scope beyond the structured 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 two sentences with no filler. The core action and resource are front-loaded, and the exclusions are stated compactly. Every sentence contributes useful information.

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

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

For a simple single-parameter listing tool with a read-only annotation and an output schema, the description covers the key operational details: cap of 100, bookable providers, and excluded fields. It does not describe ordering or pagination, but given the simple scope and output schema, this is not a major 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?

The input schema fully documents the only parameter, clinicId, including format and pattern. Schema description coverage is 100%, so the description adds little beyond confirming the clinic context. This meets the baseline of 3 but does not elevate it.

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

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

The description uses a specific verb and resource: 'List at most 100 display names for bookable providers.' It clearly scopes the operation to one tenant-owned clinic and differentiates it from sibling tools like list_clinics by focusing on providers. The exclusion of staff identifiers, contact details, roles, and clinical data further sharpens the purpose.

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 implies when the tool should be used: when display names of bookable providers are needed. It does not explicitly name alternatives or state when not to use it, although the exclusions hint that other tools would be needed for roles, contact details, or clinical data. This is clear context but lacks explicit routing to sibling tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by stating the result is bounded, cursor-paginated, and never includes clinical records, which is behavioral context beyond the schema. However, it doesn't describe what happens on empty results or if there are rate limits, but with annotations present, this is a solid contribution.

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 clear sentence, front-loaded with the primary action and result type. The exclusion of clinical records is stated immediately, preventing misuse. Zero redundancy and efficient use of space.

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

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

Given the tool's low complexity (no required params, simple pagination) and the presence of an output schema (which explains return values), the description is complete. It covers the primary intent, the pagination style, and critical exclusions. An agent knows exactly when and how to invoke 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 50%: the cursor parameter is described as 'Opaque cursor from a prior result' in the schema, which is already sufficient. The limit parameter has no description in the schema, but its meaning is obvious from its name and constraints. The description itself adds no parameter-specific details, which is acceptable since the schema does most of the work, but there is no extra clarification for limit's effect on pagination.

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 specific verb ('List') and resource ('clinics') and explicitly scopes to administrative metadata, distinguishing from the many sibling tools by clarifying it returns metadata only, not clinical records. The phrase 'bounded, cursor-paginated' further adds precision about the result set. Clear differentiation from get_clinic (single clinic) and list_calendar_events (events not clinics).

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

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

Provides clear context: it's for listing administrative metadata for clinics in the authenticated organization, and explicitly excludes animal, owner, appointment, and clinical records, which helps an agent decide not to use it for clinical data. However, it doesn't name specific alternatives for those excluded data types, though the exclusion itself gives useful guidance when to avoid.

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, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it returns 'one bounded page' (pagination behavior), is tenant-scoped, excludes many data categories, and cannot execute payments. This is consistent with the annotations and adds meaningful 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?

The description is two sentences with the core aggregation behavior front-loaded in the first sentence and exclusions in the second. The second sentence is a long list but every item adds important scope or safety information, so it earns its place. It is slightly longer than strictly necessary but remains focused and well-structured.

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

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

An output schema exists, so the return shape need not be spelled out in the description. The description covers aggregation granularity, page bound, tenancy scope, and major exclusions. It does not explicitly explain how limit/cursor control pagination, but the schema documents those parameters and 'bounded page' hints at their role.

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 high (80%), with four of five parameters already documented in the input schema. The description adds only the general notion of a 'bounded page,' which contextualizes limit and cursor but does not detail parameter semantics. The limit parameter lacks a schema description, but its constraints (maximum 100, exclusiveMinimum 0) make its meaning inferable.

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

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

The description opens with a specific verb and resource: 'Aggregate amount and count by currency and operational status' for 'tenant-scoped Veterical payment records.' It clearly distinguishes this from a plain list tool by stating what it returns and what it explicitly does not return, and no sibling tool overlaps with this aggregation behavior.

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 clear contextual guidance: use it when aggregate totals by currency/status are needed, not when transaction-level details such as IDs, dates, or line items are required. It explicitly states the tool 'cannot move funds or execute a payment,' which prevents misuse. It does not name an alternative sibling, but no direct alternative exists among the listed tools.

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 carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description adds genuine behavioral context by disclosing that only three numeric fields are returned and that all free-text/clinical data is excluded — a real boundary beyond what annotations express. No contradiction with annotations.

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

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

Two front-loaded sentences: the first conveys verb, resource, and scope; the second delimits exclusions. The exclusion list is slightly long and the 'Veterical' typo is a minor quality blemish, but there is no wasted content.

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?

Output schema and annotations cover return values and the read-only safety profile. The description covers purpose and exclusions, and the required clinicId is documented in the schema. The main gap is missing pagination/iteration guidance for limit and cursor, though the cursor schema description partially addresses this.

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 adds no parameter-specific meaning. Schema covers clinicId and cursor (67%), but the limit parameter has no schema description and the description does not compensate for it. The description's field enumeration (price, duration, edit time) describes output shape, not 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?

States a specific verb ('List') and a specific resource: bounded numeric catalog configuration for a clinic, restricted to price, duration, and edit time. The explicit exclusion list (names, descriptions, identifiers, patient-linked treatments, etc.) clearly separates it from sibling tools like list_clinics, list_clinic_providers, and list_payments. The 'Veterical' typo is minor and does not undermine 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?

The exclusion sentence gives explicit when-not-to-use guidance: an agent seeking names, descriptions, identifiers, or clinical fields is told this tool will not provide them. However, no alternative sibling tool is named, so the agent must infer which sibling covers the excluded 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=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavioral nuance beyond annotations: it clarifies that returned patient/appointment values are plan caps rather than record counts, and states that certain fields are excluded. This is a meaningful semantic clarification that helps the agent interpret results correctly, though it doesn't describe pagination behavior or response structure (also covered by the output schema).

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

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

The description is two sentences with no filler. The first sentence establishes purpose and scope; the second clarifies semantics and exclusions. All information is front-loaded and every sentence adds value, matching the Tier A standard for conciseness.

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

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

The tool is a simple list operation with pagination and filtering. The description clarifies the nature of the data and exclusions. The output schema exists, so return structure is already documented. Remaining gaps like pagination behavior are minor and covered by the cursor schema. The description is adequately complete for an agent to call the tool correctly.

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

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

Schema description coverage is 67% (cursor and clinicId have descriptions; limit does not). The tool description adds no parameter-specific information, so it does not compensate for the missing limit explanation. However, the parameter names and schema constraints (limit max/min, cursor opaque, clinicId pattern) provide sufficient meaning for a simple pagination/filter tool. Baseline 3 is appropriate given moderate coverage and intuitive params.

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 clear action ('List') and a specific resource ('bounded Veterical plan status and configuration limits') scoped to the authenticated organization. It further differentiates the tool by clarifying that patient/appointment values are plan caps, not record counts, and explicitly lists excluded fields (IDs, billed amounts, payment methods, invoices, processor fields). This distinguishes it from sibling tools like list_payments, making the purpose unambiguous.

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

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

The description implies usage context by enumerating what is excluded (billed amounts, payment methods, invoices, processor fields). An agent can infer that if those details are needed, a different tool such as list_payments should be used. However, it does not explicitly name an alternative or state a direct 'use this when' condition, leaving some inference to the agent.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond those flags: it defines the bounded scope, the aggregation window ('seven-day'), and an explicit privacy guarantee that no individual clinical or personal data is returned.

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

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

The description is two sentences with no filler. The first sentence front-loads the verb, resource, and content categories; the second sentence is a compact but specific list of exclusions. Every clause contributes to selection and invocation decisions.

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

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

With a single fully documented parameter and an output schema present, the description sufficiently defines what the tool returns and what it deliberately excludes. The only minor gap is not naming which sibling tool should be used when individual records are needed, but the negative boundary largely compensates.

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 clinicId parameter is fully documented with a format pattern and description. The tool description does not add any additional semantic detail about clinicId, 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 uses a specific verb ('Render') and names an exact resource ('bounded administrative overview for one tenant-owned Veterical clinic'), then enumerates the content categories: clinic metadata, seven-day schedule counts, provider and unassigned availability counts, and catalog previews. It also includes a strong negative boundary ('never returns individual appointments...'), which clearly separates it from the sibling detail/list 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?

The description makes the context clear: this is for an administrative overview and provides aggregate counts, not individual records. The explicit 'never returns' clause communicates a when-not-to-use signal, though it does not name sibling alternatives such as list_calendar_events or get_clinic_schedule_summary.

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