intent-hub

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

With no annotations, the description must carry behavioral disclosure. It does disclose the primary effect (slot becomes free) and a notable behavior (not-supported response for certain businesses). However, it does not mention what happens to the hold record, whether the operation is idempotent, or any error behavior beyond the unsupported case. Some meaningful gaps remain.

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, zero filler. The main action is front-loaded, and the limitation is tagged on at the end. 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 2-parameter mutation with no output schema and no annotations, the description covers the core behavior and a key conditional response. It is sufficient for an agent to know when and how to call the tool. It could mention the success response, but that is not required given the lack of output schema.

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

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

Schema description coverage is 100%, so the parameters are fully documented in the schema. The description adds no new semantics beyond restating session/hold context. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description opens with a specific verb and resource: 'Release a held or confirmed slot of this session'. This clearly distinguishes it from sibling tools like hold_slot (which creates holds) and confirm_booking (which confirms). No ambiguity about what the tool does.

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 states when the tool applies (for held or confirmed slots) and gives a specific exclusion: businesses that host their own agent return 'not-supported'. It does not explicitly name alternative tools, but the inverse relationship to hold_slot is implicit. The not-supported condition is a clear usage boundary.

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, and it does so well: it states the call takes no arguments, spends no budget, reads nothing, and only answers the hub's own constants. It also discloses key-based caller identity behavior, leaving no significant side effects hidden.

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?

Three sentences, each earning its place: the first enumerates the return payload, the second establishes invocation safety and cost, the third clarifies the key-based variant. The main value is front-loaded in the opening phrase.

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 having no output schema, the description lists exactly what a caller can expect to receive and covers the important behavioral attributes (no arguments, no budget, no reads). There is no missing information that would prevent 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 tool has zero parameters and the schema already documents that. The description reinforces this ('Takes no arguments') and adds the contextual nuance that calling with a key returns identity information, which is useful despite not being a formal schema parameter.

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 specifies exactly what the tool returns: every tool by name, every resource by URI, every prompt by name, per-client budgets, authentication details, protocol revision, and documentation location. It clearly distinguishes itself from the booking-related sibling tools by being a hub-level discovery endpoint.

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 the client to call this first ('a client that asks it first never has to guess') and clarifies the additional key-based use case. It doesn't explicitly state when not to use it or name alternatives, but no sibling tool overlaps with this discovery function.

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 behavioral burden. It discloses idempotency (confirming twice books once) and the side effect of notifying the business once. It does not mention failure modes or required preconditions, but the core behavioral trait is 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?

Two short sentences, no filler. The main purpose is stated first, and the idempotency note is a valuable addition. Perfectly front-loaded and economical.

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 it's a simple mutation tool and the schema covers parameters, the description is adequate. It doesn't describe return values (no output schema), but for a booking confirmation the effect is clear. It could mention that a valid hold is required, but that is implied by 'Confirm a held slot'.

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 each parameter thoroughly, including the contact format and instruction to ask the customer. The description adds little beyond naming 'name and phone number', which is already in the schema. Baseline 3 applies.

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 (confirm), the resource (a held slot), and the outcome (this is the booking). It distinguishes itself from hold_slot (which creates the hold) and cancel_booking (which cancels), and from get_booking (which reads).

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 'Confirm a held slot' implies it is used after a hold exists, and the idempotency note reassures repeated calls. It does not explicitly name alternatives or when not to use it, but the purpose is clear enough that an agent can infer the correct flow.

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 it delivers: it discloses the conversational protocol, explains complete:true/false semantics, describes the ranked bids structure, and explicitly says an empty bids list is normal. This is substantially more transparent than a generic 'find offers' statement.

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 dense but every clause earns its place: purpose, required input, conversation loop, return semantics, and edge-case behavior are all included without repetition or filler. It is front-loaded with the primary purpose before diving into protocol 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?

Given there is no output schema, the description covers the return contract well: complete, question, bids, outcomes, and the empty-bids case. It also explains how to continue the multi-turn conversation, which is essential for invoking this tool correctly in an agent loop.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that text is the raw user sentence, that session must be carried over from a previous incomplete answer, and that replies go back through text. The selection object gets no additional description-level commentary, but the schema already documents it clearly.

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

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

The description opens with 'Find offers from local businesses for what a person asked for,' stating a concrete action and resource. It also clarifies the tool's parsing role by mentioning trade, town, and day, which distinguishes it from the booking and agent-management siblings.

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 gives clear operational guidance: send the person's sentence as text, reuse the session when following up, and handle complete:false by asking the returned question. It does not explicitly name alternatives or when-not-to-use conditions, but the purpose and workflow are clear enough to avoid confusion with siblings.

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 carry the full burden of behavioral disclosure. It does so by calling the operation 'Read' and describing the state it returns, making clear this is a non-mutating retrieval. It does not cover error behavior or permissions, but for a simple read tool this is adequate.

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 tightly packed sentences: the first states what the tool retrieves, the second states when to use it. Every clause contributes information, and the core action 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?

This is a low-complexity single-parameter read with no output schema, and the description compensates by enumerating the returned state elements (intent, open question, bids, holds). A note on invalid or expired session handling would make it fully complete, but nothing essential is missing for correct invocation.

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

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

The schema already covers the only parameter fully: the session string is documented as 'The session id from an earlier answer' with a pattern and required flag. The description's reference to 'you already have a session id' adds context but not significant new 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 starts with a specific verb and resource: 'Read the state of a session.' It then enumerates exactly what state is included (intent, open question, bids, holds with status and link), which clearly distinguishes this read-only state tool from mutation siblings like cancel_booking and confirm_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?

It gives a clear explicit usage directive: 'Use it to pick up a conversation you already have a session id for.' It does not compare against alternatives or provide exclusions, so it falls just short of a 5, but the intended context is unmistakable.

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 disclosure burden. It reveals that a hold 'blocks a real slot', discloses a rate limit ('three per client per ten minutes'), and specifies the response contents ('Answers the hold, the bid it was made from and... the customer's private booking link'). This is thorough behavioral transparency beyond what any schema could 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?

Three sentences, each with a distinct job: the first gives the core action, the second the return shape, the third the critical constraint. No filler or redundancy; the most important 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 simple two-parameter tool with no output schema and no annotations, the description covers purpose, usage, side effects, rate limits, and return values. An agent has everything needed to decide when and how 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 coverage for parameters is 100% and both 'bid' and 'session' have clear descriptions in the schema. The description only adds contextual framing ('from this session's round') rather than new parameter-level detail, so it meets the baseline but does not elevate it.

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

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

The description states a specific action ('Hold the slot'), the resource ('one bid from this session's round'), the duration ('for ten minutes'), and the context ('before asking for details'). The phrase 'Never call it to browse' further differentiates it from search/browse sibling tools, making the purpose unmistakable.

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 gives a clear when-to-use signal ('before asking the person for their details') and an explicit when-not-to-use exclusion ('Never call it to browse') alongside a budget warning ('three per client per ten minutes is the budget'). However, it does not name any alternative sibling tools, so the routing guidance is slightly less explicit than the top tier.

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 behavioral burden, and it delivers: one-time key revelation ('shown in this answer and never again'), the required auth header format, side effects on hold/cancel budget ownership, and the 3-per-day rate limit. This is rich disclosure of persistence, security, and side-effect behavior.

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 dense but every clause earns its place: purpose, outputs, key handling, sibling routing, budget semantics, and rate limit. Core purpose is front-loaded in the first sentence and later sentences build context in a logical order. Slightly long, but justified given zero annotations and no output 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?

For a one-parameter tool with no annotations and no output schema, the description covers what an agent needs: what is returned (id + key), how to use the returned key, which operations require it, side effects, and rate limits. Minor tension between 'once' and '3 registrations per day' is resolved by the closing sentence, leaving little missing.

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

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

Schema coverage is 100% and the schema's own description already fully explains `name`, including that it is not a secret and not a login. The tool description adds no parameter-level semantics, but none is needed — the schema has done the work, so the baseline 3 applies.

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 operation — registering an agent to obtain its own identity — and names concrete outputs (`agent` id and `key`). It differentiates from booking-related siblings by naming which operations require the key (hold_slot, confirm_booking, cancel_booking) and which do not (find_offers, reading a session).

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 routing guidance: which sibling tools need the key and which do not, plus the operational rule 'register once and keep the key, do not mint one per conversation.' It also discloses the per-client daily limit of 3 registrations, so an agent knows exactly when and how often to call this tool.

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