Andrii Co. Notary & Apostille Assistant

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

Annotations are minimal (readOnlyHint false, destructiveHint false). The description adds that the appointment is bound to the account and requires sign-in, but does not detail side effects (e.g., confirmation, locking of slots) or error conditions. It provides moderate behavioral context 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 only two sentences, front-loading the core purpose in the first sentence and key usage guidance in the second. Every word is necessary; no fluff.

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 5 parameters, no output schema, and a complex workflow (two modes, prerequisite), the description covers the most essential aspects. It misses error handling and return value expectations, but these are partially mitigated by the schema and annotations.

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

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

Schema description coverage is 100%, and the description adds critical context: scheduled_at must come from search_availability's startUnix, and address is required for 'mobile' service. It clarifies the 'call me' option. This adds 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 clearly states the action ('book'), the resource ('notary/apostille appointment'), and scope ('signed-in customer, bound to their account'). It distinguishes from siblings like search_availability (prerequisite) and mentions a special case ('call me to 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 explicit when-to-use guidance: 'Call search_availability first and pass a slot's startUnix as scheduledAt (omit for a call me to schedule request).' It also states the prerequisite of sign-in. However, it does not explicitly exclude alternative tools like request_booking or explain when not to use it.

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 indicate destructiveHint=true and readOnlyHint=false. The description adds that the operation is limited to the customer's own bookings and requires authentication, providing useful context 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?

Two brief sentences convey all necessary information without redundancy. Every word adds value.

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 tool with one parameter and no output schema, the description is complete: it explains the action, constraints (own bookings, status, authentication), and provides all needed 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?

The input schema has 100% description coverage for the single parameter. The description does not add additional meaning beyond what is already in the schema, meeting the baseline expectation.

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 action (cancel), resource (bookings), and scope (own, pending or scheduled). It differentiates from siblings like reschedule_booking and book_appointment.

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 specifies when to use (for pending or scheduled bookings) and a prerequisite (requires sign-in). It does not explicitly exclude other scenarios or mention alternatives, but the context is clear.

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

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

Annotations already declare readOnlyHint=true, so the description's main behavioral addition is 'No sign-in needed' and the specifics of returned statuses (including Pacific time and merge/cancel scenarios). It does not cover rate limits, idempotency, or error handling, but the annotations reduce the burden.

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, no redundancy. The main purpose is front-loaded, and every sentence adds distinct value (status types, timezone, no sign-in needed, usage trigger).

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 simplicity (1 param, no output schema, read-only), the description covers the necessary: statuses, timezone, and accessibility. It does not specify the exact return format (e.g., JSON structure) but as there is no output schema, it is acceptable for this use case.

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 single parameter 'reference' has 100% schema coverage. The description adds meaningful context: 'also accepts the token from the emailed confirm link,' which clarifies alternate accepted values beyond the schema's description.

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 tool checks the status of a previously submitted request by reference ID, listing specific statuses (confirmed/scheduled, rescheduled, cancelled, merged) and noting Pacific time. It distinguishes from sibling tools like 'book_appointment' and 'my_bookings' by focusing on request-level status.

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

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

Explicitly says 'Call this whenever the customer asks about their request's status or whether anything changed since it was submitted.' It implies when to use and mentions 'No sign-in needed' as context, though it does not explicitly exclude alternative tools for related use cases (e.g., 'my_bookings' for booking status).

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 indicate readOnlyHint=true and openWorldHint=true. The description adds value by explaining the output (resolved location, precision status) and reinforcing the read-only nature, going beyond what annotations provide.

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 exceptionally concise: two sentences that front-load the primary action and key constraints. No superfluous text.

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

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

Even without an output schema, the description clearly states what the tool returns (resolved location and booking precision flag). For a simple validation tool, this suffices, though exact field names would add further clarity.

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%. The description supplements the schema by specifying the Washington state service area and clarifying the 'service' parameter's defaults and possible values ('notary' or 'apostille').

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 ('Check') and resource ('address'), clearly stating the tool's function: verify service area eligibility, resolve location, and indicate booking precision. This distinguishes it from sibling tools like book_appointment or search_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 explicitly marks the tool as 'Read-only; no booking,' providing clear context for when to use it (e.g., before booking). While it does not list alternatives, the purpose is unambiguous given the sibling tool 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, so the description's 'Pure, no side effects' is consistent and adds minor reinforcement. It also provides internal logic (document categories) beyond annotations, offering good 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?

The description is concise (three sentences), front-loaded with the main purpose, and every sentence adds value. No wasted 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?

Given no output schema, the description adequately explains the tool's behavior and hints at output content (DIY path and offer). It is sufficient for a query tool with three well-documented parameters.

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

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

Schema coverage is 100% with clear parameter descriptions. The tool description does not add any additional parameter semantics, so 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 clearly states the tool checks document qualification for apostille and outlines specific document categories (certified vital records, private documents, federal documents). It distinguishes from sibling tools (e.g., request_apostille) by being a query-only requirement checker.

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 use for checking apostille requirements but does not explicitly state when to use this tool versus alternatives or provide when-not scenarios. It lacks direct guidance on 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, and the description reinforces this with 'pure calculation, no side effects'. It adds context about being 'server-authoritative' and 'before shipping', which goes beyond the annotation. No contradictions.

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 key purpose. No unnecessary words. Efficient and scannable.

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 absence of an output schema, the description could mention the return format, but the core purpose and constraints are clear. Parameters are well-documented in the schema. The description is sufficient for an agent to understand when and how to use 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?

The input schema has 100% description coverage for all 6 parameters. The description itself does not add any additional meaning about the parameters; it only describes the overall tool purpose. 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?

Description clearly states verb 'Get', resource 'price estimate', and specifies it's server-authoritative, USD, before shipping, and has no side effects. This distinguishes it from sibling tools like request_price_match.

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?

While the description implies usage (call for a price estimate before shipping), it does not explicitly state when to use this tool versus alternatives or provide exclusions. The context of 'before shipping' and 'pure calculation' offers clear guidance, but lacks explicit when-not or alternative recommendations.

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, so description adds context about the content (prices, payment options) beyond annotations. No contradictions.

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 concise sentences, front-loaded with key information, 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?

Despite no output schema, the description adequately explains what the tool returns (services, prices, payment options). Could mention it returns a list, but sufficient.

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

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

No parameters exist and schema coverage is 100%. The description does not need to add anything 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 clearly states it provides the full service catalog for Washington State notary & apostille, including prices and payment options. This is specific and distinguishes it from sibling tools like get_price_quote or search_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?

Explicitly advises calling this tool when the customer asks about services or payment methods, and notes it is optional if server instructions suffice. This provides clear when-to-use 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 have readOnlyHint=true. The description adds 'Ranges, not guarantees; no side effects', which provides additional behavioral context beyond annotations, confirming read-only and output nature.

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 fluff. First sentence explains what it does, second provides usage guidance. Every sentence earns its place.

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

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

Given 4 params, high schema coverage, no output schema, the description covers purpose, usage, and safety. Could optionally mention output format, but not required for completeness.

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. The description adds context that shipping can be inferred from destination_country, which is not in the schema. However, it doesn't add much else beyond the schema descriptions.

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 'Estimate typical completion + shipping timing for a service', using specific verb 'estimate' and resource 'turnaround timing'. It distinguishes from siblings like search_availability by noting it provides ranges, not exact times.

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 explicitly says 'For an exact appointment time use search_availability', providing a clear when-not and alternative. It also says 'no side effects', guiding safe usage.

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, so description's 'list' aligns. Adds authentication requirement. No further behavioral details needed for a simple read operation.

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

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

Single sentence, no wasted words, front-loaded with key action and resource.

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

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

For a zero-parameter read-only tool without output schema, the description covers purpose, scope, ordering, and auth requirement—fully adequate.

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?

No parameters in schema (100% coverage), description doesn't need to add param context. Baseline for zero-param tool is 4; scope info is sufficient.

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 clearly states verb (list), resource (own notary/apostille bookings), and ordering (most recent first). Differentiates from siblings like book_appointment or cancel_booking which are mutation 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?

Explicitly notes 'own' bookings and requires sign-in, providing context for when to use. No explicit when-not, but sibling tools imply alternatives for other actions.

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 indicate a write operation (readOnlyHint=false) and non-destructiveness. The description adds valuable behavioral context: it creates a lead (not a final order), no charge until approved, and the notary follows up. No contradictions.

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 exceptionally concise: two sentences, front-loaded with purpose, no redundant information. Every sentence adds distinct value.

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 7 parameters and no output schema, the description covers the core process (lead, follow-up, no charge) and prerequisites. It does not explain return values, but without an output schema, this is acceptable. Slightly more detail on what happens after submission would be helpful.

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

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

With 100% schema coverage, baseline is 3. The description adds useful constraint that at least one of email or phone is required (not enforced by schema) and clarifies the name as 'full legal name'. This goes beyond the schema's descriptions.

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 action 'Submit a mail-in apostille request' and specifies the exact resource type (apostille for already-certified Washington public records like birth/marriage/death certificates). It effectively distinguishes from sibling tools by noting the mail-in, no-notarization scope.

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 this tool (for already-certified Washington public records needing no notarization) and prerequisites (name plus email or phone). However, it does not explicitly name sibling alternatives or state when not to use this tool, losing a point.

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?

Description adds context beyond annotations: it's a non-destructive mutation (creates a lead), not a hold or confirm. Annotations already indicate destructiveHint=false and readOnlyHint=false. The description clarifies it's not a confirmed appointment and that existing_reference modifies an existing request.

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?

Single paragraph with no wasted words. Key information is front-loaded (lead vs confirmed appointment). Each sentence provides essential guidance, making it concise and well-structured for an AI 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?

Given the complexity (10 parameters) and presence of annotations, the description covers the critical aspects: purpose, requirements, slot usage, and modification. It doesn't describe the return value, but without an output schema, the agent can infer from the context. The openWorldHint annotation suggests side effects, which the description addresses.

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 covers 100% of parameters with descriptions. Description adds semantic value by stressing that both email and phone should be collected (not just required name), explaining the origin of desired_time_unix, and clarifying the use of existing_reference. This goes beyond the schema's individual descriptions.

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 clearly states it submits a lead, not a confirmed appointment, and lists the core action (submit a booking request) with distinct resource (booking request) and scope (lead). It differentiates from siblings like book_appointment by emphasizing it's a request that requires follow-up.

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 explicit requirements (full legal name, email/phone) and guidance on using desired_time_unix from search_availability. Tells when to use existing_reference to avoid duplicates. However, doesn't explicitly name alternatives like book_appointment for confirmation, though it implies when not to use this tool.

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 indicate readOnlyHint=false and destructiveHint=false. The description adds that the tool initiates a human-reviewed process that never sets a price automatically, and that a response is given within one business day. This provides useful behavioral context beyond the annotations, though it doesn't detail all side effects (e.g., whether the request is stored or requires login).

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 concise with three sentences that are front-loaded: first sentence states the action, second explains the process, third gives requirements and timeframe. No unnecessary words. It earns its length.

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 has no output schema, the description covers the input requirements, the asynchronous human-review process, the expected response (quote and match decision), and the timeline. It provides enough information for an agent to use the tool correctly without needing additional 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?

All 9 parameters are described in the schema with full coverage (100%). The description restates the requirement for name and contact info but does not add new semantic meaning beyond the schema descriptions. The baseline of 3 is appropriate as the schema already documents the parameters adequately.

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 tool's purpose: requesting a price match from a notary's written quote. The verb phrase 'Ask us to consider matching' specifies the action, and it distinguishes itself from siblings like get_price_quote by noting it's a human-reviewed request, not an automatic price setting.

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 clarifies when to use the tool (when a competitor quote is available), mentions it's a request (not automatic), and provides a timeline. However, it does not explicitly contrast with alternatives like get_price_quote, which is a sibling tool for getting a regular quote. Including a note like 'for a direct quote use get_price_quote instead' would make it a 5.

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

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

Annotations already provide idempotentHint=true and destructiveHint=false. The description adds context about ownership ('OWN bookings') and strict availability check, which go beyond annotations. No contradictions.

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 concise sentences, front-loaded with the action and key constraints. No redundant information. Every word adds value.

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 tool with 2 parameters and no output schema, the description covers purpose, usage constraints, authentication, and availability check. Slightly more detail on success/failure behavior would improve completeness, but it is mostly adequate.

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

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

Schema coverage is 100% with clear descriptions for both parameters (order_id, scheduled_at). The description adds minimal extra meaning beyond the schema, e.g., 'new slot's startUnix', but the schema already conveys similar info. 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 clearly states the action 'Reschedule' on 'one of the signed-in customer's OWN bookings', which is specific and distinguishes it from sibling tools like book_appointment (create) or cancel_booking (delete).

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 indicates when to use (rescheduling own bookings with available slots) and includes the constraint 'Requires sign-in'. However, it does not explicitly state when not to use or provide alternatives, though context from sibling tools implies 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 provide readOnlyHint and openWorldHint. The description adds detailed behavior: returns resolved location, up to 7 recommended slots, per-day booking windows with formula. It also explains service-specific behavior (mobile needs address, office/apostille use our office). 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 a single paragraph but well-structured: purpose first, then validation, response format, usage instruction, and service differentiation. Every sentence adds value with no 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?

No output schema is provided, so the description must fully explain returns. It does: resolved location, recommended slots, booking windows formula. It also explains how to use the result and handles service types. Complete for the tool's complexity.

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

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

Schema coverage is 100% with descriptions. The description adds value by explaining how to use the chosen start with request_booking and clarifying address behavior per service type beyond the schema notes. This extra context justifies a 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?

The description explicitly states 'Find open notary/apostille appointment slots' with a specific verb and resource. It distinguishes from siblings by mentioning validation and slot types, and the sibling tools include booking and area checking, making it clear this is for searching 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 explains when to use the tool (to find slots and validate area). It provides guidance on using the output (pass startUnix to request_booking) and distinguishes between service types. However, it does not explicitly exclude alternatives or state when not to use it, though the context is clear.

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