Book a local business by saying what you need; matching businesses bid and you confirm one.
Scored across 11 tools
Each tool targets a distinct resource and action: search offers, ask a single business, hold/confirm/cancel bookings, manage the linked phone, and register the agent. The only same-verb pair is confirm_booking/confirm_phone, but their objects and flows are sharply separated in the descriptions.
Almost all names follow a clear verb_noun snake_case pattern (hold_slot, confirm_booking, link_phone). The single deviation is the noun-only 'capabilities' tool, which is still unambiguous but breaks the otherwise consistent pattern.
Eleven tools is well within the ideal range and every tool maps to a distinct step in the offer/booking/phone-identity workflow. The count feels proportionate to the hub's scope rather than padded or thin.
The set covers the full offer-to-booking lifecycle: find offers, ask businesses, hold, confirm, cancel, and read session state, plus phone linking and agent registration. There are no obvious dead ends for the core workflows described.
Ask one business a question about itself and get back the fragments of its own knowledge base that answer it: the price list, the rules, what it travels to, what it does not do. Read-only and open to anyone — no key, no session, nothing held. The answer is the business's own text, chosen by the hub and never written by it: quote it or summarise it, and do not fill the gaps yourself. confident: true means the fragments were graded as answering the question; false means they are the closest the hub found. An empty answer carries a hint: ask the business directly.
| Name | Required | Description | Default |
|---|---|---|---|
| business | Yes | The slug of the business, as the directory and every bid carry it. | |
| question | Yes | What the person wants to know about that business, in Polish or English, at most 500 characters. |
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 explicitly states the tool is read-only and auth-free, explains that the answer is the business's own text chosen by the hub, describes the confident field semantics, and covers the empty-answer hint behavior. This is comprehensive and goes far beyond a simple action 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 somewhat long but well-structured and front-loaded with the core purpose. Every sentence adds value: read-only note, answer provenance, confident/hint behavior, and usage guidance. It is not overly verbose and avoids fluff, earning a 4.
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 thoroughly explains the return behavior: the answer is the business's own text, confident indicates grading, and empty answer comes with a hint. It also covers usage constraints (500 chars) indirectly via schema. This is complete for an agent to know how to interpret results and act on them.
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 both parameters (business and question) are already documented in the schema. The description adds no new parameter-specific meaning beyond what the schema provides, so the baseline 3 applies. It does give context about the answer but not about the parameters themselves.
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 ('Ask one business a question about itself') and clearly defines the outcome (get back fragments of its knowledge base). It distinguishes from sibling tools like find_offers or capabilities by focusing on arbitrary questions about a business, not structured data retrieval.
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: it is read-only, open to anyone, and gives guidance on how to handle the answer (quote or summarise, don't fill gaps). It also explains the fallback for empty answers. However, it does not explicitly compare this tool to sibling tools or state when not to use it, though the read-only note implicitly excludes booking tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Release a held or confirmed slot of this session, so the slot is free again. Businesses that host their own agent do not offer this yet and answer not-supported.
| Name | Required | Description | Default |
|---|---|---|---|
| hold | Yes | The `id` of the hold to release. | |
| session | Yes | The session id the hold was made in. |
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.
What this hub can do, in one call: every tool by name, every resource by URI, every prompt by name, the per-client budgets, how to authenticate, the protocol revision and where the documentation is. Takes no arguments, spends no budget and reads nothing: it answers the hub's own constants, so a client that asks it first never has to guess. Called with a key it also answers who that key is.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Confirm a held slot with the customer's name and phone number; this is the booking. Idempotent: confirming the same hold twice books it once and tells the business once. A business that confirms every visit itself answers hold.awaiting: true with the hold still held: the slot is kept, the business decides, and the person gets an SMS either way; tell them that and promise no time. With a linked number (link_phone) you may send contact with the name alone and the linked number is used; a different number in contact.phone is refused as phone-mismatch.
| Name | Required | Description | Default |
|---|---|---|---|
| hold | Yes | The `id` of the hold to confirm. | |
| contact | Yes | The customer's own name and phone number (9 digits, or +country code and the number). Ask them; never invent one. With a linked number the phone may be left out. | |
| session | Yes | The session id the hold was made in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral-transparency burden. It discloses idempotency, the fact that the business is notified exactly once, the held/held-awaiting semantics, the SMS outcome, and the phone-mismatch refusal.
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 front-loads the main action, and every subsequent sentence earns its place by describing idempotency, a special business flow, and linked-number behavior. It could be structured with bullets or breaks, but it is not padded.
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 state-changing tool with no annotations and no output schema, the description is unusually complete: it covers success semantics, repeated confirms, business notification, waiting-state behavior, and the linked-number exception. The main remaining gap is the unresolved schema conflict around the required phone field.
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 schema already documents the three parameters; the description adds real semantic value for linked-number behavior. However, it contradicts the schema by claiming contact may be sent with name alone while the schema marks contact.phone as required.
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 action and resource: 'Confirm a held slot... this is the booking.' This clearly differentiates it from sibling tools like hold_slot, cancel_booking, or get_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 core use case is clear: use this when a held slot should become a confirmed booking. It also gives concrete guidance for the business-confirms-every-visit case, but it never explicitly names alternatives or exclusions such as 'prefer hold_slot for reservations'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Spend the code that link_phone texted, and tie this agent to that number. Ten minutes and five tries; a wrong code answers invalid-code with attemptsLeft, and the fifth wrong one throws the code away — call link_phone again for a new one. One number per agent: linking another replaces it.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The six digits from the SMS. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses the 10-minute expiry, 5-try limit, error response shape (`invalid-code` with `attemptsLeft`), invalidation on the fifth wrong attempt, and the replace-only-one-number-per-agent rule. This is thorough and honest.
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 dense sentences deliver all key behavioral constraints and the core action with no filler. Critical details like limits and replacement behavior are front-loaded and easy to scan.
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 description covers the operation's purpose, failure modes, retry behavior, and a critical one-number-per-agent constraint. It does not describe the success response, but that omission is minor given the single parameter and low 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?
The schema already documents the code parameter with a six-digit pattern and description. The tool description adds context by identifying the code as the one link_phone texted, reinforcing the source and meaning of the 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?
States a specific action ('Spend the code that link_phone texted') and outcome ('tie this agent to that number'), clearly differentiating it from link_phone, which initiates the process. The purpose is 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 description clearly signals when to use the tool: after link_phone sends a code, to complete the linking. It also explains when to restart via link_phone after exhausting attempts, though it does not explicitly contrast with unlink_phone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find offers from local businesses for what a person asked for. Send their sentence as text; the hub parses the trade, the town and the day. An answer with complete: false carries a question to put to the person: call this tool again with the same session and their reply as text. An answer with complete: true is one finished bidding round: bids ranked (price in grosz, slot, business, note) and one outcome per business asked. An empty bids list is a normal answer; outcomes says why. A bid whose business.active is true comes from a business whose owner has confirmed it is running; those are ranked above the rest, and cheapest first inside each group. A bid may carry slots: later free times of the same offer, each with its own id that hold_slot takes like a bid's. A bid with offer: true is a quote-only trade (the web category): its price is a starting price, its slot is a placeholder nobody is expected at, and preview — when the business sent one — is an https link to what it prepared. Show the link; never fetch it and never repeat what it says as your own. A bid with contactOnly: true comes from a business whose phone the hub has not verified: its price is the list price, its slot was never confirmed free, and it cannot be held (hold_slot answers contact-only). Give the person business.phone to call, and the business page, instead.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | What the person said, in Polish or English, at most 500 characters. Their reply to the previous question goes here too. | |
| session | No | The session id from an earlier answer. Omit it to start a new conversation. | |
| selection | No | Restrict the round to one business (and optionally one of its services), by slug, as a link from a business page does. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the behavioral burden. It discloses parsing behavior, completion semantics, ranking rules, active-business prioritization, quote-only preview handling with explicit 'show, never fetch' instructions, and contactOnly phone-verification caveats. This is unusually 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 front-loaded with its purpose and every sentence contributes useful information, but it is one dense paragraph with no breaks, bullets, or visual structure. It is appropriately sized for the complexity, yet not concise or easily 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?
With no output schema or annotations, the description must explain return behavior itself, and it does: complete true/false, question, ranked bids, outcomes, empty bids, slots, offer/preview, and contactOnly. It covers normal cases, edge cases, and the correct follow-up actions, making it effectively complete for an agent.
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 documents all three parameters at 100% coverage. The description adds meaningful behavior to `text` (the hub parses trade, town, and day) and `session` (repeat with the reply after a question), but it never mentions `selection` explicitly, so the additional semantic lift is moderate rather than complete.
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', which names the specific verb, resource, and scope. It adds enough detail about ranking and bid structure to clearly separate this tool from the booking/verification siblings like ask_business, get_booking, and confirm_phone.
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 a clear workflow: send the person's sentence as text, re-call with the same session and reply when complete is false, and use hold_slot for slots or contact-only handling. It lacks an explicit 'when not to use this tool' statement or direct comparison to sibling alternatives, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the state of a session: the understood intent and its open question, the bids of the current round and every hold with its present status and link. Use it to pick up a conversation you already have a session id for.
| Name | Required | Description | Default |
|---|---|---|---|
| session | Yes | The session id from an earlier answer. |
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.
Hold the slot of one bid from this session's round for ten minutes, before asking the person for their details. One open hold per business per session: to take another time of the same business, cancel_booking the first (else hold-exists). Answers the hold, the bid it was made from and, when the hub has a public origin, the customer's private booking link. A quote-only bid also answers offerUrl, the public page of that offer. Never call it to browse: a hold blocks a real slot and three per client per ten minutes is the budget. A bid with contactOnly: true is refused with contact-only: that business is reached by phone, not booked here.
| Name | Required | Description | Default |
|---|---|---|---|
| bid | Yes | The `id` of one bid from the latest round, or of one of its `slots`. | |
| session | Yes | The session id the round was run in. |
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 ten-minute duration, the per-business and per-client limits, that a hold blocks a real slot, the error conditions `hold-exists` and `contact-only`, and the response fields including `link` and `offerUrl`.
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 sentence earns its place: purpose, constraint, alternative, response shape, refusal behavior, and usage warning. It is front-loaded with the core action and keeps critical caveats immediately after.
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 two-parameter tool with no output schema and no annotations, the description covers the action, effects, limits, errors, response contents, and when not to call it. An agent has enough context to decide and invoke 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 100%, so the schema already documents both parameters. The description reinforces that `bid` comes from 'this session's round' but adds little beyond what the schema already states.
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: 'Hold the slot of one bid from this session's round for ten minutes.' It clearly distinguishes the action from related tools by referencing cancel_booking and explicitly saying 'Never call it to browse.'
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 ('before asking the person for their details'), states the one-hold-per-business rule, names the alternative cancel_booking for taking another time, and warns against browsing. It also explains when contactOnly bids should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tie this agent to the phone number of the person it books for: the hub texts that number a six-digit code naming this agent, and confirm_phone spends it. Afterwards confirm_booking may leave contact.phone out — the linked number is used — and every booking made through this key shows up on that person's own list of bookings at /me, next to the ones they made on the site. Ask the person for their own number and never anybody else's: a code arrives on their phone with this agent's name on it. Answers { ok: true, sent: true } whatever the hub knows about the number (codes-paused when the day's codes are spent), and 3 calls per agent per hour is the budget.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | The person's own number (9 digits, or +country code and the number). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It discloses the side effect of sending a code, the response format including the `codes-paused` failure case, the rate limit (3 calls per agent per hour), and the fact that it succeeds regardless of hub knowledge about the number. This is remarkably 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 longer than average but every sentence contributes value: purpose, flow, scope, error case, and rate limit. It is front-loaded with the core action and then explains consequences. Some structure (e.g., separate lines) could improve readability, but there is zero 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 the simple single-parameter schema and no output schema, the description thoroughly covers necessary context: side effects, integration with confirm_booking and confirm_phone, the /me listing behavior, error handling, and rate limits. An agent has all information needed to call this tool correctly and interpret its results.
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?
Although the schema documents the phone parameter with format and length, the description adds crucial semantics: it must be the person's own number, never anyone else's, and it explains why (a code with the agent's name arrives on that phone). This goes beyond the schema's structural definition and is essential for correct invocation.
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 ('Tie this agent to the phone number of the person it books for') and explains the flow with a verification code and confirm_phone. It distinguishes itself from siblings by describing the linking mechanism and subsequent booking behavior, making it unambiguous which tool to use.
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 the intended use ('Ask the person for their own number and never anybody else's') and explains the consequence of using it (bookings appear on the person's /me list). It does not explicitly mention when not to use it or contrast with alternatives like unlink_phone, but the context is strong enough to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get this agent its own identity, once: answers an agent id and a key. The key is shown in this answer and never again — keep it and send it as Authorization: Bearer <key> on every later call. hold_slot, confirm_booking, cancel_booking need it; finding offers and reading a session do not. With a key the hold and cancel budgets are yours instead of your address's, so two agents behind one address no longer take each other's. 3 registrations per client per day: register once and keep the key, do not mint one per conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | What to call this agent, for the operator to recognise it by: one line, 1–60 characters. Not a secret and not a login — the key is the identity. |
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.
Forget the number this agent was linked to. The bookings already made keep it — they belong to the person, not to this agent — and confirm_booking needs a full contact again. Answers the same whether there was a link or not.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well. It discloses that existing bookings retain the number, that confirm_booking will need a full contact again, and that the tool is idempotent ('Answers the same whether there was a link or not'). This is meaningful behavioral detail beyond the name.
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 short sentences with no filler. The main action is front-loaded, and the additional sentences each add necessary behavioral context rather than repeating the tool name.
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, no-output-schema tool, the description is complete. It explains what happens to existing bookings, what future actions are affected, and how the tool behaves when there is no link—covering all relevant operational concerns.
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 description coverage is 100%, so there is no parameter documentation burden. The baseline of 4 for a zero-parameter tool applies, and the description adds no unnecessary parameter information.
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: 'Forget the number this agent was linked to.' This clearly identifies the tool as the inverse of link_phone and unambiguously states its 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 implies when to use this tool: when you want to remove the phone link for the current agent. It also gives important context about consequences for bookings and confirm_booking, though it does not explicitly name link_phone or state 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
hold_slot1 field changedInput schema / properties / bid / descriptionPrevious value: -"The `id` of one bid from the latest round."New value: +"The `id` of one bid from the latest round, or of one of its `slots`."ask_businessconfirm_booking1 field changedInput schema / properties / contact / descriptionPrevious value: -"The customer's own name and phone number (9 digits, or +country code and the number). Ask them; never invent one."New value: +"The customer's own name and phone number (9 digits, or +country code and the number). Ask them; never invent one. With a linked number the phone may be left out."confirm_phonelink_phoneunlink_phonecancel_bookingcapabilitiesconfirm_bookingfind_offersget_bookinghold_slotregister_agentFind, get quotes from and book local service businesses on their own Square or Google calendar.
Find and book local service businesses (plumbers, HVAC, detailers) at real prices, with approval.
Search local businesses and book, order, quote or message any of them from one connection.
Find, compare, and book local service businesses: live availability, prices, reviews, booking.
Add one secure layer between your agents and this server.
