Booking Request

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

No annotations provided. Description explains the liveness filter values and return fields, but does not disclose side effects, rate limits, or authentication requirements.

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 with no wasted words. Purpose is front-loaded, and details follow efficiently.

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 low complexity (1 optional param, no output schema), the description adequately covers the liveness filter and return fields. Minor gap: not specifying return format or types, but likely 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?

The schema already describes the livenessFilter parameter. The description adds valuable context by explaining the meanings of 'live' and 'charter', which goes beyond the schema's simple 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 verb 'Enumerate' and the resource 'Bonis Concierge represented-agent roster'. It lists the specific fields returned, distinguishing it from siblings which are about booking actions.

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 explicit guidance on when to use this tool versus alternatives. Does not mention that for booking-related tasks, one should use request_booking or verify_booking.

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 description provides significant behavioral details: requires Knox Bearer API key, unauthenticated calls rejected; declares what the tool does not do (adjudicate, guarantee, handle payment, represent person); describes the return value (Knox anchor record + C2PA envelope + affidavit). With no annotations, the description carries the full burden and does so well, though it could mention backend persistence or idempotency.

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 of five sentences, efficiently front-loading the primary purpose and then providing limitations and return details. It is concise without unnecessary words, though it could be slightly restructured for readability (e.g., bullet points for key points). It 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 the complexity (8 parameters, no output schema, no annotations), the description covers purpose, return value, authentication, and limitations. However, it lacks details about what happens after a booking request is made (e.g., pending state, notifications), and error conditions beyond unauthenticated. It is adequate but has noticeable gaps.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds some contextual notes (e.g., budgetUsdMax is a discovery field, no payment collected), but these are also present in the schema's descriptions. The description does not provide significant additional meaning beyond the schema, so 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 clearly states the tool's purpose: 'Anchor a booking request for a represented Bonis Concierge agent.' It uses a specific verb (anchor) and resource (booking request). It distinguishes from sibling tools by implying that list_represented_agents is for enumerating agents and verify_booking likely for verification, while this tool is for initiating a request.

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 does not explicitly state when to use this tool versus alternatives. It mentions that the agency does not guarantee acceptance or handle payment, and that unauthenticated calls are rejected, but does not provide clear guidance on when to use request_booking vs list_represented_agents or verify_booking. Usage is implied but not directly addressed.

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 description discloses it's a read operation (no mutation), lists return fields (anchor record, predecessor hash, sequence number, timestamp), and mentions a REST endpoint. With no annotations, it provides reasonable transparency, though it omits potential error cases or rate limits.

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 brief, two sentences, with no unnecessary information. Every sentence adds value, clearly stating the purpose, usage context, and endpoint reference.

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 with one parameter. The description lists return values, compensating for the lack of output schema. However, it does not mention error handling or what happens with an invalid hash, which would be helpful 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% with a detailed description of the 'hash' parameter (pattern, required). The description adds minimal extra meaning beyond the schema, only tying it to a prior call. 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 'Verify an anchored booking-request record', providing a specific verb and resource. It distinguishes from sibling tools 'list_represented_agents' and 'request_booking' by focusing on verification, a distinct action.

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 specifies when to use ('Given a SHA-256 anchor hash from a prior request_booking call') and notes it's public with no authentication. However, it lacks explicit 'when not to use' or alternatives beyond the given context.

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