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

With no annotations provided, the description carries full responsibility for disclosing behavior. It clearly states the irreversible nature ('This action cannot be undone.') and explains the preview vs. execute mechanism. However, it omits potential error conditions or side effects, which would have pushed the score to 5.

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 three concise sentences, each with a distinct purpose: state the action, explain parameter usage, and warn about irreversibility. There is no filler or redundancy, and the most critical information is 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 cancellation tool with two required parameters and no output schema, the description covers essential context: what it does, how to use the confirm flag for preview, and the permanence of the action. It does not mention prerequisites like authentication or post-cancellation behavior, but these are less critical for invoking 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?

The input schema already comprehensively describes both parameters (100% coverage), including the preview/cancel semantics for 'confirm' and the source of 'reservationId'. The description's mention of 'confirm=false to preview' adds no new information beyond the schema, meeting 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 starts with a clear verb ('Cancel') and specific resource ('existing reservation'), unambiguously defining the tool's function. It also distinguishes itself from sibling tools like opentable_make_reservation and opentable_get_reservations by its unique cancellation 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 provides explicit usage context by explaining the two-step process: 'Set confirm=false to preview, confirm=true to actually cancel.' This guides the user on how to use the confirm parameter. It does not mention alternative tools, but cancellation has no direct sibling, making the guidance sufficient.

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?

No annotations are provided, so the description carries the full burden. It only states the basic function and adds no behavioral details such as whether it is read-only, requires authentication, or returns nearby time slots. The schema does mention 'Availability is shown for nearby times,' but the description itself provides no transparency beyond the core purpose.

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, concise sentence that front-loads the core purpose. It contains no filler or repetition, every word contributes to understanding the tool's function.

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 moderately simple with four parameters, but there is no output schema and no annotations. The description implies the output (available time slots) but does not explicitly state the return format or any edge-case behavior. It is adequate for basic understanding but could benefit from mentioning what the response contains or typical use scenarios.

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 provides full descriptions (100% coverage) for all four parameters, so the description does not need to add much. It redundantly mentions date and party size but omits time and restaurantId. Since the schema already documents the parameters clearly, the description adds no significant semantic value, but the schema coverage keeps this at baseline 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 clearly states the action ('Check'), the resource ('available reservation time slots'), and the context ('for a restaurant on a specific date and party size'). This distinguishes it from sibling tools like opentable_make_reservation or opentable_search, 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 intended use case (checking availability before booking) is implied by the description and the sibling tool set, but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria. The context makes it fairly obvious, but the description itself offers no direct instruction.

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?

With no annotations provided, the description carries the full burden of disclosing behavior. It mentions 'requires authentication' and 'for the logged-in user', which are useful behavioral traits. However, it does not state whether the operation is read-only, what happens if the user is not authenticated, or what the response format contains, leaving significant gaps.

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 one concise sentence with an additional clause about authentication. Every word contributes to the meaning, and it is front-loaded with the core action. There is no redundancy or filler.

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

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

For a simple, zero-parameter read tool with no output schema, the description is largely complete: it states the operation, the actor, and a key prerequisite (authentication). Minor details like the exact scope of 'upcoming' (e.g., today or future) are unspecified, but the description provides enough context for basic use.

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 tool has zero parameters, so the description need not add parameter details. Per the rubric, 0 parameters provides a baseline of 4, and the description adds no unnecessary parameter information. The schema is trivially fully covered with an empty properties object.

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 all upcoming reservations for the logged-in user.' This clearly distinguishes it from sibling tools like opentable_make_reservation or opentable_cancel_reservation, and it explicitly scopes the action to the user's own upcoming reservations.

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 the tool is for viewing a user's own upcoming reservations and requires authentication, hinting at the need to log in first. However, it does not explicitly tell when to use this tool versus alternatives such as searching for restaurants or checking availability, so usage guidance is only implicit.

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?

With no annotations provided, the description must disclose behavioral traits but only says 'Get', which implies read-only. It does not mention authentication requirements, error behavior, or that it makes no state changes. The verb alone is insufficient for full transparency.

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 concise sentence that is front-loaded with the key action and resource, then lists the main data categories. There is no redundant or filler 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?

There is no output schema, so the description must explain what is returned. It mentions several fields but uses vague terms like 'features' and omits possibly important details (ratings, reviews, contact info). For a simple get tool, it is adequate but not fully comprehensive.

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% (restaurantId is described as 'The restaurant ID or profile URL (from search results)'). The tool description adds no additional parameter guidance, so it meets the baseline but does not exceed 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 ('Get') and a specific resource ('detailed information about a specific restaurant'), and it enumerates the content (description, address, hours, features). This clearly distinguishes it from siblings like search, availability, and reservation 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 explicit when-to-use or alternative guidance in the description. The need to have a restaurant ID is implied by 'specific restaurant' and clarified in the schema ('from search results'), but the description itself does not state a preferred workflow 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?

No annotations are provided, so the description carries full burden. It discloses the core behavior (returns URL and instructions) and user authentication, but does not mention side effects, state changes, or how the URL is consumed. This is adequate but not highly transparent.

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 concise sentences, front-loaded with purpose, then condition. No filler or redundant details.

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 tool with no output schema, the description is reasonably complete: it states what is returned (URL and instructions) and when to use it. Could specify return format more explicitly, but the essential context is present.

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 tool has zero parameters, so the empty schema covers everything. Baseline for 0 parameters is 4, and the description implies no input required. It does not introduce any separate parameter semantics, which 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 a specific action ('Get the OpenTable login URL and instructions') and the resource (OpenTable authentication). It distinguishes from siblings by specifying the trigger condition 'when opentable_status returns not logged in.'

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 provides a usage condition referencing opentable_status, and the alternative (when already logged in) is implicitly clear. This is actionable guidance for when to invoke the 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states that it clears stored session cookies, which implies a mutation of local state. It could add more detail about idempotency or behavior when no cookies exist, but the primary effect is clearly disclosed.

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, consisting of two short sentences. The action is front-loaded in the first sentence, and the usage context is in the second. There is no wasted text or repetition of schema 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?

Given the tool's simplicity—no parameters, no output schema, and no annotations—the description is fully complete. It explains what the tool does, when to use it, and the effect on authentication state. No additional context seems necessary for an agent to invoke it 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?

The tool has zero parameters, and the input schema is an empty object. According to the rubric, a baseline of 4 applies for zero-parameter tools. The description adds no parameter information, which is appropriate since there is nothing to explain.

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 with a specific verb and resource: 'Clear the stored OpenTable session cookies.' It also explicitly states the purpose: 'Use this to log out or reset the authentication state,' which distinguishes it from sibling tools like opentable_login and opentable_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?

The description provides clear guidance on when to use the tool: 'Use this to log out or reset the authentication state.' It gives a direct usage context, though it does not explicitly mention alternatives or when not to use it. Given the tool's simplicity, this is adequate.

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?

With no annotations, the description carries the burden of disclosing behavior. It transparently explains the confirmed booking vs preview distinction and explicitly requires the user to be logged in. However, it does not mention potential failure modes (e.g., unavailability) or the nature of the response after booking, leaving some behavioral aspects undisclosed.

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 three short sentences, each carrying essential information: the core action, the preview/booking toggle, and the login requirement. There is no redundant or extraneous text, making it efficient 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?

Given the lack of an output schema and the tool's side-effectful nature, the description could be more complete by explaining what the tool returns on success or failure. It covers the main workflow and login prerequisite but leaves the agent uncertain about response formats and exceptional cases.

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 provides complete descriptions for all six parameters, including formats and semantics for date, time, partySize, restaurantId, confirm, and specialRequests. The description does not add new parameter details beyond what the schema already states; it only repeats the confirm flag's behavior, so it adds minimal value above 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 uses the specific verb 'Book' and identifies the resource as 'restaurant reservation on OpenTable', making the tool's purpose unmistakable. It also clarifies the confirm parameter's role in preview vs actual booking, which distinguishes it from related tools like availability checking or cancellation.

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 that this tool is for booking or previewing a reservation, and notes the login requirement as a prerequisite. However, it does not explicitly state when to prefer this tool over alternatives such as opentable_check_availability or opentable_cancel_reservation, so it falls short of 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?

No annotations are provided, so the description carries the full burden. It only states the action (search) and filter criteria but does not disclose whether authentication is required, what the response looks like, pagination, rate limits, or any side effects. The behavioral traits are not adequately disclosed.

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 that clearly states the action and key filters. Every word adds value, with no redundancy or filler.

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

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

With 5 parameters, no output schema, and no annotations, the description should provide more context about return values, expected result structure, or how to use results with sibling tools. It lacks any guidance on response format or integration, making it incomplete for a tool of this 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 description coverage is 100%, so the schema already explains all parameters. The description merely lists the same parameter names without adding format, defaults (other than partySize default), or usage nuances beyond the schema. 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 searches for restaurants on OpenTable with specific filter dimensions (location, cuisine, party size, date, time). While it distinguishes from siblings by being the only 'search' tool, it doesn't explicitly contrast with check_availability or get_restaurant.

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 for finding restaurants, but provides no explicit guidance on when to use this tool versus alternatives like check_availability or make_reservation. No exclusions or alternative tool names are mentioned.

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?

No annotations are provided, so the description carries the full burden. It states it returns login status and instructions if not authenticated, which conveys the tool's behavior. However, it does not explicitly state that it is read-only or has no side effects, which is a minor gap for a status/check 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?

The description is two sentences, front-loaded with the main purpose, and includes a useful usage instruction without unnecessary filler. Every word 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 simple status check with no parameters and no output schema, the description provides the essential information: what it does, what it returns, and when to call it. It could add more detail about the exact return format or next steps, but it adequately covers the tool's 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?

The input schema is empty (0 parameters) and schema coverage is 100%, so the description is not required to explain parameters. The baseline for 0 parameters is 4, and the description does not miss any parameter info.

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 'Check if the user is logged in to OpenTable,' which clearly identifies a specific verb and resource. This distinguishes it from sibling tools like opentable_login and opentable_logout, which perform different 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?

It explicitly instructs 'Call this before any other OpenTable operations,' providing clear when-to-use guidance. It does not discuss when not to use it or explicitly name alternatives, but the context is clear and sufficient.

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