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

With no annotations, the description must carry the full behavioral burden; it does disclose one meaningful side effect ('the slot becomes available to other agents immediately') and an ownership authorization constraint. However, it doesn't state whether cancellation is reversible, what happens on an invalid or non-owned booking_id, or whether any confirmation is required — notable gaps for an unannotated mutation.

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

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

Two short sentences, zero filler, with the identity/ownership constraint front-loaded and the downstream effect second. Nothing repeats the tool name unnecessarily.

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 return values need no explanation, and the description covers the essential facts for a one-parameter mutation: whose resource it acts on and what the world looks like afterward. Additional detail on failure modes would help but isn't required 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?

Schema description coverage is 0% for the single parameter, so the description should compensate. The ownership clause adds a real semantic constraint on booking_id (it must reference a booking the caller owns), but the format/origin of the identifier is still unexplained.

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 ('Cancel') and resource ('booking') plus a scope constraint ('owned by the calling agent'), which rules out cancelling other agents' bookings. It doesn't explicitly contrast with the closely related sibling release_hold, so an agent must infer the distinction between releasing a hold and cancelling a committed booking.

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 'previously-committed booking' implies usage after commit_booking, but the description never says when to choose this over release_hold or what to do if the booking is still a hold. Usage is implied rather than stated, and no preconditions or failure conditions are given.

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 full burden and does well: it discloses atomic compare-and-swap behavior, exactly-one-winner semantics, the 409 outranked payload, invitee echo/visibility to the owner, and conferencing link attachment. It leaves idempotency_key semantics and permission/auth expectations unexplained.

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 front-loaded with the core finalize/CAS behavior, then optional fields and conferencing. Three short paragraphs with no wasted sentences; every part adds useful invocation or behavioral context.

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 core commit semantics and conflict behavior are complete, and an output schema exists to cover return values. But for a 7-parameter mutation with no annotations and 0% schema coverage, the description should also explain idempotency_key, metadata, and start/end expectations.

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 0%, so the description must compensate for all parameter meaning. It explains title, invitee shape, and with_conferencing, but omits start/end format expectations, metadata, and critically the idempotency_key, leaving several parameters undocumented.

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 and resource ('Finalize a booking') and adds the distinguishing concurrency semantics: atomic compare-and-swap at slot level, exactly one agent succeeds per race window. This clearly separates it from hold/cancel/approval siblings without needing their schemas.

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

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

The description implies the usage context: commit a slot that is being finalized, with conflict behavior on 409. However, it does not explicitly say when to use this versus create_hold, or when not to use it, so the guidance remains implied rather than explicit.

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 full burden. It discloses the 30-second default TTL, automatic expiration, the promotion path via commit_booking, and the outranked payload when a higher-priority agent already holds the slot. It omits permission requirements and idempotency behavior, but the key lifecycle behaviors are well covered.

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 front-loaded with the core action and TTL, then details optional fields, then conflict behavior. It is efficient with no filler, though slightly dense; a small amount of structure could improve readability.

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 return values needn't be fully explained, but the description helpfully mentions the outranked payload. For a 6-parameter mutation tool with no annotations, the description should explain the required start/end semantics and what idempotency_key does. Its coverage of parameter behavior is incomplete.

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 0%, so the description must compensate. It explains only two of six parameters (title and invitee with its fields) and leaves start, end, metadata, and idempotency_key completely undocumented. Partial coverage with significant gaps warrants a low score.

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: 'Reserve a slot tentatively.' It also explicitly distinguishes this tool from commit_booking by explaining that a later commit_booking promotes the hold. An agent can tell exactly what this tool does and how it differs from the commit sibling.

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 clearly implies the usage pattern: create a hold first, then call commit_booking to finalize. It doesn't explicitly name alternatives for cases where a hold isn't needed, but the flow is unambiguous. No when-not guidance is provided, keeping it below 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?

With no annotations provided, the description carries the burden and discloses key behavior: it is a read operation, it is safe to poll, it never blocks, and it returns status plus reviewer note once resolved. It does not mention authorization, rate limits, or not-found behavior, so it is strong but not fully exhaustive.

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 compact and front-loaded, first stating what is read and then adding the important non-blocking polling behavior. Every sentence adds value with no 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?

The tool is simple, has one parameter, and has an output schema, so return values need not be fully described. The description covers statuses and behavior well. Its main gap is the undocumented approval_id parameter, which is the only notable omission 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?

The schema has one required parameter, approval_id, with 0% description coverage. The tool description refers to 'one approval request' but adds no meaning about the ID format, source, or constraints. With low schema coverage, the description should compensate, but it does not.

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: reading one approval request and its current state. It enumerates the possible states and the reviewer note, making the purpose clear. It implicitly differentiates from wait_for_approval by saying it never blocks, though it does not name that sibling explicitly.

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

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

The phrase 'Safe to poll; it never blocks' gives clear usage context: this is the non-blocking polling option. However, it does not explicitly name or contrast with wait_for_approval, nor does it state when to prefer that alternative.

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 and does add non-obvious behavior: results are filtered through the user's focus blocks, buffer rules, and active holds across sibling agents. It does not spell out the read-only nature beyond the verb 'List', nor permissions or rate limits, but the filtering pipeline is valuable behavioral context.

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

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

It is front-loaded with the core purpose, then adds time-format and filtering details in two compact sentences. Every sentence earns its place with no repetition of the schema.

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

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

An output schema exists, so return shape need not be explained, and the behavioral filtering is covered. However, for a five-parameter tool with zero schema descriptions, the missing semantics for holds, duration, and granularity make the definition incomplete 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 0%, so the description must compensate. It only clarifies that start/end are ISO 8601 strings via the '[start, end)' notation; it says nothing about include_holds (default true), duration_minutes (default 30), or granularity_minutes (default 15), leaving three of five parameters undocumented anywhere.

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 and resource ('List slots open to the calling agent') with an explicit interval scope '[start, end)'. It is clearly distinguishable from the sibling hold/booking/approval tools because it queries availability rather than mutating holds.

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 context is clear: use this to see open slots within a window, and the description notes that results are filtered by focus blocks, buffer rules, and sibling-agent holds. It does not explicitly name alternatives (e.g., create_hold) or state when not to use it, keeping it below 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?

With no annotations, the description carries the full burden. It usefully discloses that a hold has a TTL and that releasing it makes the slot claimable by other agents, but says nothing about idempotency, what happens when the hold_id is expired, already released, or unknown, or whether release requires ownership/auth.

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

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

Two short lines with no filler; the effect (freeing the slot) is front-loaded after the verb. Slightly more could be said without bloating it, but nothing present is wasted.

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

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

An output schema exists, so return values need no explanation, and the one-parameter surface is small. However, for a state-changing tool with zero annotation coverage, missing error/edge-case behavior and the origin of hold_id leave the definition only minimally 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 description coverage is 0% and the single required parameter hold_id is never mentioned in the description. The agent gets no hint that hold_id comes from create_hold's response or what form it takes, so the description fails to compensate for the coverage gap.

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 (release) and resource (a previously-created hold) plus the effect: freeing the slot for other agents before TTL expiry. This implicitly links to create_hold, though it never names a sibling such as cancel_booking to disambiguate.

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 clause 'so other agents can claim the slot before the TTL expires' implies the trigger (you no longer need the slot and want to free it early), but there is no explicit when-to-use, when-not, or comparison against cancel_booking, which is the nearest alternative for undoing a 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?

With no annotations, the description carries the full burden and does reasonably well: it discloses the non-blocking semantics, the required `approvals:request` scope, and the return shape. It omits what happens on expiry, whether duplicate requests are deduplicated, and what ttl_seconds/idempotency_key actually do behaviorally.

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?

Front-loaded with the core action, then a compact parameter gloss and return/scope line. The examples earn their place by fixing the action_type convention. Slightly dense prose in the parameter paragraph, but no 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?

The output schema covers the return values, so restating them is a bonus rather than a requirement. The real gap is that two of five parameters, including the idempotency control that matters for a request tool that can be retried, are left undefined in a tool with zero 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 coverage is 0%, so the description must compensate. It does well for action_type (namespaced lowercase format with three concrete examples), summary (what the reviewer reads first), and evidence (target, amount, exact draft). But ttl_seconds and idempotency_key — both meaningful for an approval request — get no explanation at all.

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

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

Specific verb+resource: 'Open a human sign-off request' plus a key behavioral modifier, 'return immediately'. This implicitly separates it from the blocking sibling wait_for_approval, though the sibling is never named explicitly.

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

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

The phrase 'return immediately' hints that this is the fire-and-forget path and that something like wait_for_approval exists for blocking, but the agent must infer that routing. No explicit when-to-use or when-not-to-use statement, and no mention of prerequisites beyond the scope.

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, so the description carries the load and does it well: it discloses the timeout clamp `[1, 120]`, the poll clamp `[1, 30]`, that the call blocks, and the exact `status: "pending" / timed_out: true` outcome on lapse. What it omits is the failure mode when `approval_id` is invalid or expired-upstream, and whether the blocking call has any side effect on the approval record.

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?

Front-loaded with the verb and the hard bound, and every clause carries information (clamps, pending semantics, stop conditions). Slightly padded by the line-broken formatting and the redundant re-statement that pending means stop after already saying `status: "pending"`.

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 the description needn't enumerate return fields, yet it still explains the two fields that matter for loop control (`status`, `timed_out`) and the stop rule. The gap is the provenance and validity of the required `approval_id`, which an agent must supply correctly to call this at all.

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 0%, so the description must compensate, and it does for two of three params by giving the legal ranges for `timeout_seconds` and `poll_interval_seconds` (bounds the schema's bare numeric types and defaults do not convey). `approval_id` is never explained — notably where it comes from, presumably `request_approval` — which keeps this from a 5.

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

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

Opens with a specific verb and resource ('Wait for a human decision') plus a hard scope bound ('bounded to 120 seconds'). An agent can distinguish this blocking wait from the non-blocking sibling `get_approval` because the description explicitly frames re-calls to either as the continuation strategy.

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?

Gives explicit decision rules: 'Proceed only when the status is `approved` — denied, expired, and pending all mean stop,' which is a clear when-not. It names `get_approval` and `wait_for_approval` as follow-up options but never states the condition that should push an agent to the polling sibling instead of this blocking call, so the alternative selection is left partly 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, the description carries the full burden and does reasonably well: it discloses that this validates credentials (implying an auth-failure path) and enumerates exactly what identity data comes back, including the owner timezone and why it matters. It stops short of saying the call itself has no side effects or what an invalid key returns, but the read-only, zero-parameter nature is evident.

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 core action (confirm the key) followed by the payload. Every clause carries information — credential validation, returned fields, and the rationale for the timezone.

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 return-field details need not be fully spelled out, and the description still summarizes them usefully. For a zero-param read tool this is nearly complete; the only missing piece is the recommended call ordering relative to the availability/booking siblings.

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 takes zero parameters, so there is nothing to disambiguate; the baseline of 4 applies. The description correctly avoids inventing parameter behavior and instead spends its words on the returned identity fields.

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 concrete verb and resource: it validates the configured AGENTDRAFT_API_KEY and returns the calling agent's identity, priority, scopes, and the owner's timezone. That scope is unmistakable and distinct from every sibling (booking, approval, and availability tools), so an agent can select it without ambiguity.

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

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

Usage is only implied: 'so a client can render slots in the owner's zone' hints at a pre-flight/identity check before calling get_availability, but the description never says when to call this versus just calling get_availability, nor that it should be used to verify credentials first. No exclusions or alternatives are named.

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