Find real businesses and book appointments. Books via Cal.com; imports 12 platforms.
Scored across 9 tools
Most tools have clearly distinct purposes, but a few pairs sit close together: check_booking_link vs import_booking_url (pre-flight vs actual import) and find_business vs verify_business (OSM geosearch vs supply-network directory). The descriptions do explicitly differentiate these, so an agent can resolve them, but the boundaries still require reading the description.
All nine tools use a consistent snake_case verb_noun pattern (check_booking_link, import_booking_url, schedule_appointment, preview_cost, verify_business, get_status, get_outcome, find_business, self_test). No mixing of conventions and verbs are predictable.
Nine tools is well-scoped for a booking pipeline spanning discovery, pre-flight classification, import, cost preview, execution, and async result retrieval. Each tool appears to earn its place without redundancy.
The surface covers a coherent lifecycle: find/verify a business, import and pre-check a booking link, preview cost, schedule, then poll status and fetch the outcome receipt. There is no way to list existing appointments or reschedule as a distinct operation, and functionality is heavily limited to one Cal.com account, but the core booking workflow is covered.
Free, instant pre-flight check for a booking URL. Classifies which booking platform a URL belongs to and tells you whether import_booking_url will accept it, WITHOUT fetching the page or spending money. Returns the platform, the exact smb_id import_booking_url would assign, the channels the booking will route through, and the inferred country. Use it to de-risk a paid booking BEFORE calling import_booking_url + schedule_appointment. [free, no key]
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full http(s) URL to classify, e.g. 'https://cal.com/jane' or… |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds meaningful behavioral context beyond that: it performs no network fetch, incurs no cost, requires no key, and returns a specific set of derived values including the exact smb_id. This tells the agent exactly what side effects to expect (none) and what output to anticipate.
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 adds value: what it does, what it avoids, what it returns, and when to use it. Key behavioral constraints are front-loaded, and the '[free, no key]' tag is a compact useful addition.
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 a single parameter, no output schema, and rich annotations, the description is complete. It names the return fields (platform, smb_id, channels, country), clarifies cost and safety, and situates the tool within the surrounding workflow. An agent has enough to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single url parameter with 100% coverage, including an example. The description does not materially add parameter-level semantics beyond classifying it as a booking URL, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('pre-flight check', 'classifies') tied to a concrete resource (booking URL) and names the downstream dependent tool (import_booking_url). It clearly differentiates itself from sibling tools like schedule_appointment by framing itself as a check that happens before any paid action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use it: 'BEFORE calling import_booking_url + schedule_appointment' and why: to 'de-risk a paid booking'. It also states what it does NOT do ('WITHOUT fetching the page or spending money'), giving the agent clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find real businesses near a place, sorted by distance (nearest of those examined; see result.search). Data: OpenStreetMap (ODbL, (c) OSM contributors); phone, website, hours only when mapped. Coverage varies; community-mapped, NOT verified by us; source=openstreetmap rows cannot be booked. Answers within about 5 s: status partial (search_in_progress) means repeat the call. If OSM is down: retriable 'temporarily unavailable', never invented rows. [free, no key] [beta]
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Instead of location: a city, e.g. 'Muscat, Oman'. | |
| region | No | With city: a state or region. | |
| location | Yes | City/town or ZIP, optionally with country ('Nizwa, Oman'). Geocoded by OSM. | |
| vertical | No | ||
| capability | No | Kind of business: 'dentist', 'cafe', 'plumber'. Use it or vertical. | |
| price_band | No | Supply-network rows only (OpenStreetMap has no prices). | |
| max_results | No | ||
| availability_window | No | Accepted but NOT APPLIED: it does not narrow results (no live calendars). The… |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: discloses ~5s latency, that partial/search_in_progress means the call must be repeated, that an OSM outage yields a retriable 'temporarily unavailable' rather than fabricated rows, and that results are community-mapped and NOT verified by the provider. These are exactly the operational traits an agent needs and none are in the annotations.
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 verb+resource, then grouped caveats (data provenance, latency/status, failure mode, tags). Dense but nearly every clause carries information; the trailing '[free, no key] [beta]' tags are slightly cluttered but useful.
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 8 params, nested objects, and no output schema, the definition adequately covers provenance, retry semantics, latency, and the booking limitation, and points at result.search for ordering. It stops short of describing result fields or pagination, leaving a small gap for a discovery tool.
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 75%, so the schema already carries most parameter meaning (radius_miles default/max, price_band scope, availability_window not applied). The description adds little parameter-specific detail of its own beyond the booking constraint tied to source rows, 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?
Specific verb+resource: 'Find real businesses near a place, sorted by distance', with the result ordering and the fact that sorting covers only examined rows made explicit. This cleanly separates it from siblings like verify_business, call_business, and capture_lead, which act on a business rather than discovering one.
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?
Implied context is present: it is the discovery step ('find real businesses'), and the caveat that source=openstreetmap rows cannot be booked hints at a downstream booking/verification flow. However it never explicitly states when to prefer this over siblings such as verify_business, nor does it name any alternative or exclusion condition, so usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the final OutcomeReceipt for a completed operation. [free, no key]
| Name | Required | Description | Default |
|---|---|---|---|
| operation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds useful context beyond annotations: the operation must be completed, and the call is free with no key required.
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?
One tight sentence plus a bracket note. Every element earns its place, and the core purpose is front-loaded before the access note.
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 single-parameter retrieval tool with strong annotations, the description is mostly complete: it identifies what to pass, when it is valid, and the access requirements. It does not describe the return shape, but no output schema exists and the resource name 'OutcomeReceipt' is reasonably self-descriptive.
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% and the schema only says operation_id is a required string. The description adds context by tying operation_id to the completed operation whose OutcomeReceipt is requested, but it does not specify where the ID comes from or its format.
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 ('Retrieve') and a specific resource ('final OutcomeReceipt') for a 'completed operation'. This clearly distinguishes it from siblings like get_status, which would naturally map to intermediate status rather than the final receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is for retrieving the outcome only after an operation has completed. It does not explicitly name alternatives or exclusions, but the completed-operation condition is a meaningful usage signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the current state of any in-flight async operation by operation_id. [free, no key]
| Name | Required | Description | Default |
|---|---|---|---|
| operation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description only needs to add context. It adds that the operation is free, requires no API key, and applies to in-flight async operations, which provides useful behavioral context beyond the annotations.
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. The primary purpose is stated in one clear sentence, and the cost/auth note is appended succinctly. Every element 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, one-parameter, read-only status tool, the description provides enough to call it correctly: the target resource, the identifier, and the cost/auth constraints. It does not detail the output shape or possible statuses, and it does not explain what happens if the operation is not in-flight, but these are not critical for a basic status query given the 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?
The input schema only specifies 'operation_id' as a string with no description, so the description carries the semantic burden. It clarifies that operation_id references an in-flight async operation and that the tool queries its state, which gives the parameter meaningful context. It could be stronger by explaining how to obtain the operation_id, but it is adequate.
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 specifies a verb ('Query'), a resource ('the current state of any in-flight async operation'), and the key identifier ('operation_id'). It also implicitly differentiates from the sibling 'get_outcome' by focusing on in-flight operations rather than completed outcomes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when you need the current state of an in-flight operation identified by operation_id. It also notes the operation is free and requires no key. It does not explicitly mention exclusions or 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.
Turn a public booking URL into a callable smb_id for send_message and capture_lead. But schedule_appointment only completes on Cal.com bound to our one connected account — the other 11 always fail schedule_appointment honestly, uncharged. Detects 12 platforms (Cal.com, Calendly, Doctolib, Booksy, Fresha, OpenTable, Setmore, Square, Acuity, Schedulista, Squarespace, BookMyCity). Idempotent — calling twice returns the same smb_id. [free, requires key] [limited]
| Name | Required | Description | Default |
|---|---|---|---|
| vertical | No | If omitted, inferred from the booking platform. | |
| booking_url | Yes | Full URL the user supplied. Must point at one of the 12 supported booking… | |
| capabilities | No | Free-form capability tags (e.g., ['haircut','color','blowdry']). | |
| country_code | No | ISO 3166-1 alpha-2 (e.g. 'US', 'FR'); routes compliance on later sends. | |
| business_name | No | If omitted, auto-extracted from the page's <title> or og:title. | |
| contact_email | No | ||
| contact_phone | No | If omitted, the platform integration handles outreach. | |
| idempotency_key | No | Retry key: a 24h replay returns the original receipt, not re-run or charged. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover readOnlyHint=false, idempotentHint=true, openWorldHint=false, destructiveHint=false. The description adds real value beyond these: it discloses the scheduling capability gap per platform, states idempotency semantics ('calling twice returns the same smb_id'), lists the 12 supported platforms, and flags cost ('free') and rate limiting ('[limited]'). This is exactly the kind of behavioral context annotations can't express.
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 purpose, but the sentence about schedule_appointment completing only on Cal.com is dense and syntactically awkward ('only completes on Cal.com bound to our one connected account — the other 11 always fail schedule_appointment honestly, uncharged'). The trailing bracket tags ([free, requires key] [limited]) are cryptic stubs rather than integrated information. Information density is high but structure suffers.
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 an 8-param import tool with no output schema, the description covers platform support, idempotency, cost, rate limits, auth requirement, and downstream-consumer semantics. The main gap is it does not describe the returned smb_id shape or any error semantics when the URL is on an unsupported platform — relevant since there's no output schema to fall back on.
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 88%, so the schema carries the bulk of parameter documentation. The description adds little parameter-level detail beyond the schema except the platform-count constraint on booking_url. Baseline 3 is appropriate when the schema does the heavy lifting and the description does not compensate further.
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?
Clear specific verb+resource: 'Turn a public booking URL into a callable smb_id'. Names the consumer tools (send_message, capture_lead), which distinguishes it from siblings. Lacks a direct contrast to check_booking_link, which is the nearest sibling, but the operation is unmistakably distinct.
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?
Strong routing guidance: states the smb_id is used by send_message and capture_lead, and warns that schedule_appointment only works on a Cal.com account bound to the service (the other 11 platforms fail). That's actionable when/when-not. No explicit mention of check_booking_link as an alternative for pre-flight validation, which would have made it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return an expected cost estimate, latency estimate, and success-probability estimate for a proposed call before execution. Returns the exact price when it is fixed, and a min/max range when the cost depends on channel or outcome. It does not promise an accuracy percentage - check cost_range. [free, no key]
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | The same request body you would pass to the operation | |
| operation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond that: it returns exact prices when fixed, min/max ranges when variable, does not promise accuracy, and requires no API key ('[free, no key]'). No contradiction with annotations.
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 focused sentences with no filler. The first sentence front-loads the core purpose, the second explains the exact-vs-range behavior, and the third adds a crucial caveat plus auth note. Every sentence 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?
The description covers what the tool returns, how pricing varies, and the free/no-key requirement. With no output schema, the return-value description is useful and mostly sufficient. Minor gaps remain around expected operation naming and the exact output shape, but the tool is simple enough that this is not a major deficiency.
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 documents params as 'the same request body you would pass to the operation,' and the description reinforces the 'proposed call' idea. However, the operation parameter is only a bare string with no allowed values or format, and the description does not elaborate on how operations are specified. Schema coverage is exactly 50%, so the description only partially compensates.
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 names a specific verb ('Return') and a precise resource: cost, latency, and success-probability estimates for a proposed call before execution. This clearly distinguishes it from siblings like get_outcome, get_status, or verify_company_record, which address different concerns.
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 this tool is for pre-execution estimation ('before execution') and cautions that accuracy is not promised, directing the user to cost_range. It does not explicitly name alternatives or state when not to use it, but the context is clear enough given the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check availability, book, or cancel via Cal.com. Only completes when the SMB's imported booking link is bound to this deployment's ONE connected Cal.com account; otherwise fails honestly (booking_destination_unmapped) with no charge. No working booking path exists yet for non-Cal.com platforms (voice AI, web form) — those SMBs fail honestly instead of a fabricated confirmation. [from $0.15/call, variable, not charged while no payment rail is on] [async→get_outcome] [limited]
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| action | Yes | ||
| smb_id | Yes | ||
| service | No | ||
| customer | No | ||
| requested_time | No | ||
| idempotency_key | No | Retry key: a 24h replay returns the original receipt, not re-run or charged. | |
| existing_appointment_id | No | Required for cancel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply the generic safety profile (destructive/openWorld/non-idempotent); the description adds concrete failure semantics (booking_destination_unmapped, honest failure instead of fabricated confirmation), the no-charge guarantee, platform limitations, and async behavior. This is exactly the beyond-annotation context an agent needs.
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 verb set, then dense but each clause carries distinct information (precondition, failure mode, platform limit, price, async tag). Slightly overloaded with bracket tags, but no wasted sentence.
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, the description correctly focuses on behavior and failure modes and is fairly complete for a complex, destructive, async tool. Its one real gap is the undocumented parameter surface, which the description leaves entirely to a low-coverage 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 coverage is only 25% across 8 params with nested objects, yet the description explains no individual parameter. It implies the action set and no-charge behavior but never clarifies smb_id, service, customer, requested_time, or how the idempotency_key interacts with the 24h replay.
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 set (check availability, book, cancel) against a specific resource (Cal.com appointment) and the enum matches exactly. It is immediately distinguishable from siblings like check_booking_link or import_booking_url.
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 a clear precondition (the SMB's imported booking link must be bound to the one connected Cal.com account) and routes async callers to get_outcome via '[async→get_outcome]'. It does not, however, say when to prefer check_booking_link or import_booking_url over this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Service health probe: runs 6 internal checks and reports how many passed. Confirms the server is up and responding - it does NOT probe each tool individually. Use to verify connectivity before production use. [free, no key]
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value by disclosing the internal check count (6), the aggregate pass/fail nature, and the free/no-key requirement, which are not in the annotations.
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: it states the core function first, then the limitation, then the use case, then the free/no-key note. Every sentence earns its place with no redundancy.
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, read-only health probe with no output schema, the description covers the essential information: what it checks, what it reports, what it does not do, and when to use it. The only minor gap is not describing the exact output format, but that is not critical for a simple health probe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. The description adds no parameter details because none are needed; the baseline of 4 for zero-parameter tools 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 tool's function: it runs 6 internal checks and reports how many passed, confirming the server is up. It explicitly distinguishes itself from per-tool probing, which differentiates it from sibling tools like get_status or verify_company_record.
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 says to use it to verify connectivity before production use, which gives a clear context. It does not explicitly name alternative tools or state when not to use it, but the 'does NOT probe each tool individually' exclusion provides useful guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up what we know about a business in our supply network: contact channels, capabilities, last verification. A DIRECTORY LOOKUP - it does not contact the business. Supply-network ids only, not osm:... ids. [free, no key] [limited]
| Name | Required | Description | Default |
|---|---|---|---|
| smb_id | Yes | ||
| capability_to_verify | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, non-destructive and closed-world behavior, so the bar is low. The description still adds genuinely new facts: that it performs no contact, the acceptable id namespace, and cost/access tags '[free, no key] [limited]' signaling no credentials but constrained availability. The '[limited]' tag is left undefined, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the lookup scope, then the disambiguating negative, then the id constraint and cost tags - a sensible ordering with no filler sentences. The bracketed tags are terse and functional, though '[limited]' is vague enough to cost a point.
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, the description compensates by naming the returned content (contact channels, capabilities, last verification), and annotations carry the safety profile. The remaining gap is the unexplained capability_to_verify parameter, which an agent may need to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry both parameters. It does document the smb_id namespace constraint ('Supply-network ids only, not osm:... ids'), which is real added meaning. However, capability_to_verify is never explained - no hint of what capabilities exist or what verification means for them - leaving half the 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 ('Look up what we know about a business in our supply network') and enumerates the fields returned (contact channels, capabilities, last verification). It also draws the key boundary against siblings by declaring 'A DIRECTORY LOOKUP - it does not contact the business', which separates it from call_business without opening either schema.
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 clear context for when the tool applies: read-only directory inspection rather than outreach, and id-namespace restriction ('Supply-network ids only, not osm:... ids'). The alternative (call_business) is implied by the negation but never named explicitly, so an agent must infer the routing rather than being told 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.
find_business7 fields changedInput schema / properties / availability_window / descriptionPrevious value: -"Accepted but NOT APPLIED - it does not narrow results. We do not hold live…"New value: +"Accepted but NOT APPLIED: it does not narrow results (no live calendars). The…"Input schema / properties / capability / descriptionPrevious value: -"Kind of business, e.g. 'haircut', 'plumber', 'dentist'. Mapped to OSM tags."New value: +"Kind of business: 'dentist', 'cafe', 'plumber'. Use it or vertical."Input schema / properties / city / descriptionPrevious value: -"Alternative to location: a top-level city, normalised into…"New value: +"Instead of location: a city, e.g. 'Muscat, Oman'."Input schema / properties / location / properties / zip_or_city / descriptionPrevious value: -"City, town, address or postal code, optionally with the country, e.g. 'Nizwa, Oman'. A bare 5-digit ZIP is read as a US ZIP; give any non-US postal code with its country (e.g. '10115, Germany')."New value: +"Town, city, address or postal code, with the country if not US: 'Nizwa, Oman'. A bare 5-digit ZIP is a US ZIP; add the country for any other postal code."Input schema / properties / price_band / descriptionPrevious value: -"Supply-network rows only; OpenStreetMap has no prices."New value: +"Supply-network rows only (OpenStreetMap has no prices)."Input schema / properties / region / descriptionPrevious value: -"Alternative to location: a top-level state/region, normalised into…"New value: +"With city: a state or region."Input schema / requiredPrevious value: -[
- "vertical",
- "location"
-]New value: +[
+ "location"
+]find_business5 fields changedInput schema / properties / capability / descriptionPrevious value: -"Specific service capability required, e.g. 'haircut', 'plumbing',…"New value: +"Kind of business, e.g. 'haircut', 'plumber', 'dentist'. Mapped to OSM tags."Input schema / properties / location / descriptionPrevious value: -"Where to search. Matched against the business's city, state and ZIP as text -…"New value: +"City/town or ZIP, optionally with country ('Nizwa, Oman'). Geocoded by OSM."Input schema / properties / location / properties / radius_miles / descriptionPrevious value: -"Accepted but NOT applied - no coordinates exist, so results are not restricted to this radius. Disclosed back as radius_miles_applied: false."New value: +"Radius in miles (default 3.1, max 25); applies to OpenStreetMap results only."Input schema / properties / location / properties / zip_or_city / descriptionAdded value: +"City, town, address or postal code, optionally with the country, e.g. 'Nizwa, Oman'. A bare 5-digit ZIP is read as a US ZIP; give any non-US postal code with its country (e.g. '10115, Germany')."Input schema / properties / price_band / descriptionAdded value: +"Supply-network rows only; OpenStreetMap has no prices."find_business2 fields changedInput schema / properties / cityAdded value: +{
+ "description": "Alternative to location: a top-level city, normalised into…",
+ "type": "string"
+}Input schema / properties / regionAdded value: +{
+ "description": "Alternative to location: a top-level state/region, normalised into…",
+ "type": "string"
+}find_business2 fields changedInput schema / properties / cityRemoved value: -{
- "description": "Alternative to location: a top-level city, normalised into…",
- "type": "string"
-}Input schema / properties / regionRemoved value: -{
- "description": "Alternative to location: a top-level state/region, normalised into…",
- "type": "string"
-}find_business1 field changedInput schema / properties / location / properties / radius_miles / descriptionPrevious value: -"Accepted but NOT applied. The supply directory holds no coordinates, so no distance filter can be honoured; results are not restricted to this radius. Sending it is recorded and disclosed back as radius_miles_applied: false."New value: +"Accepted but NOT applied - no coordinates exist, so results are not restricted to this radius. Disclosed back as radius_miles_applied: false."find_business1 field changedInput schema / properties / location / properties / radius_miles / descriptionAdded value: +"Accepted but NOT applied. The supply directory holds no coordinates, so no distance filter can be honoured; results are not restricted to this radius. Sending it is recorded and disclosed back as radius_miles_applied: false."find_business6 fields changedInput schema / properties / cityAdded value: +{
+ "description": "Alternative to location: a top-level city, normalised into…",
+ "type": "string"
+}Input schema / properties / location / descriptionAdded value: +"Where to search. Matched against the business's city, state and ZIP as text -…"Input schema / properties / location / properties / radius_miles / defaultRemoved value: -10Input schema / properties / location / properties / radius_miles / minimumAdded value: +0Input schema / properties / max_results / minimumAdded value: +1Input schema / properties / regionAdded value: +{
+ "description": "Alternative to location: a top-level state/region, normalised into…",
+ "type": "string"
+}schedule_appointment2 fields changedInput schema / properties / action / enumPrevious value: -[
- "book",
- "reschedule",
- "cancel",
- "check_availability"
-]New value: +[
+ "book",
+ "cancel",
+ "check_availability"
+]Input schema / properties / existing_appointment_id / descriptionPrevious value: -"Required for reschedule/cancel"New value: +"Required for cancel"find_business1 field changedInput schema / properties / vertical / descriptionRemoved value: -"Service vertical to search within"import_booking_url6 fields changedInput schema / properties / business_name / descriptionPrevious value: -"Optional override. If omitted, the business name is auto-extracted from the…"New value: +"If omitted, auto-extracted from the page's <title> or og:title."Input schema / properties / contact_email / descriptionRemoved value: -"Optional."Input schema / properties / contact_phone / descriptionPrevious value: -"Optional. If omitted, the platform integration handles outreach."New value: +"If omitted, the platform integration handles outreach."Input schema / properties / country_code / descriptionPrevious value: -"ISO 3166-1 alpha-2 (e.g. 'US', 'FR'). Used for compliance routing on later…"New value: +"ISO 3166-1 alpha-2 (e.g. 'US', 'FR'); routes compliance on later sends."Input schema / properties / idempotency_key / descriptionPrevious value: -"Optional client-supplied key for safe retries. Replaying the same key within 24h returns the original receipt - the operation is NOT re-executed and NOT re-charged."New value: +"Retry key: a 24h replay returns the original receipt, not re-run or charged."Input schema / properties / vertical / descriptionPrevious value: -"Best-guess vertical. If omitted, inferred from the platform (e.g., Doctolib ->…"New value: +"If omitted, inferred from the booking platform."schedule_appointment1 field changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Optional client-supplied key for safe retries. Replaying the same key within 24h returns the original receipt - the operation is NOT re-executed and NOT re-charged."New value: +"Retry key: a 24h replay returns the original receipt, not re-run or charged."check_booking_link1 field changedInput schema / properties / url / descriptionPrevious value: -"Full http(s) URL to classify, e.g. 'https://cal.com/jane' or 'https://www.opentable.com/r/acme'."New value: +"Full http(s) URL to classify, e.g. 'https://cal.com/jane' or…"find_business2 fields changedInput schema / properties / availability_window / descriptionPrevious value: -"Accepted but NOT APPLIED - it does not narrow results. We do not hold live calendars for the supply network. The response carries availability_window_applied: false when you send one. To book a specific slot use schedule_appointment with requested_time, which checks real availability."New value: +"Accepted but NOT APPLIED - it does not narrow results. We do not hold live…"Input schema / properties / capability / descriptionPrevious value: -"Specific service capability required, e.g. 'haircut', 'plumbing', 'tax_consultation'"New value: +"Specific service capability required, e.g. 'haircut', 'plumbing',…"import_booking_url4 fields changedInput schema / properties / booking_url / descriptionPrevious value: -"Full URL the user supplied. Must point at one of the 12 supported booking platforms; auto-detected from the host."New value: +"Full URL the user supplied. Must point at one of the 12 supported booking…"Input schema / properties / business_name / descriptionPrevious value: -"Optional override. If omitted, the business name is auto-extracted from the page's <title> or og:title."New value: +"Optional override. If omitted, the business name is auto-extracted from the…"Input schema / properties / country_code / descriptionPrevious value: -"ISO 3166-1 alpha-2 (e.g. 'US', 'FR'). Used for compliance routing on later send_message calls."New value: +"ISO 3166-1 alpha-2 (e.g. 'US', 'FR'). Used for compliance routing on later…"Input schema / properties / vertical / descriptionPrevious value: -"Best-guess vertical. If omitted, inferred from the platform (e.g., Doctolib -> healthcare, OpenTable -> restaurants)."New value: +"Best-guess vertical. If omitted, inferred from the platform (e.g., Doctolib ->…"check_booking_linkfind_businessget_outcomeget_statusimport_booking_urlpreview_costschedule_appointmentself_testverify_businessVerified local businesses, bookable by AI agents: services, prices, availability and appointments.
Discover and book businesses via AI agents.
Agentic CRM for service businesses — bookings, customers, WhatsApp, loyalty, invoicing.
Find local services, check live availability, and book real appointments with consent.
Add one secure layer between your agents and this server.
