Surfing Dog

Ask a business

ask_business

Idempotent

Send your person's question to a business's own inbox: only for a listed business with an inbox, and only when your person asked you to contact it. The business answers your person by email, at the address they agreed to give (consent), never by phone. Keep the access_token for your person: it reads the request's state.

Input Schema

Name	Required	Description
`domain`	Yes	The business's domain, as search_businesses or get_business gave it, like bikes.example.
`consent`	Yes	true only when your person agreed to give this business their email address for its answer. Without it nothing is sent.
`contact`	Yes	Where the business can answer. Only an email address and a name: never a phone number.
`message`	Yes	What your person wants to ask, in their words.
`subject`	No	A few words the business sees first.
`language`	No	The language your person wants the answer in, as a tag like en, pt or pt-BR.

Output Schema

Name	Required	Description	Default
`item`	No
`kept`	Yes
`inbox`	No
`times`	No
`answer`	No
`confirm`	No
`outcome`	Yes
`service`	No
`business`	Yes
`replayed`	No
`services`	No
`timezone`	No
`delivered`	Yes
`elsewhere`	No
`status_url`	No
`access_token`	No
`access_token_withheld`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed27 schema fields changedOct 31, 2026

removedInput schema / $schema

Removed value: -"https://json-schema.org/draft/2020-12/schema"

removedInput schema / title

Removed value: -"MCP ask_business: arguments"

removedOutput schema / $schema

Removed value: -"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / description

Added value: +"Every field is described in this tool's outputSchema at https://network.surfingdog.ai/.well-known/mcp/server-card.json."

removedOutput schema / properties / access_token / description

Removed value: -"The inbox gives it once, to read or cancel this request at status_url: keep it for your person only."

removedOutput schema / properties / access_token_withheld / description

Removed value: -"A repeat of a request already delivered: the inbox gives the access token only the first time."

removedOutput schema / properties / answer / description

Removed value: -"The business's own words about the request, from its inbox: tell your person as they are."

removedOutput schema / properties / business / description
```
Removed value: -"The business's domain."
```

removedOutput schema / properties / confirm / properties / summary / description

Removed value: -"The terms in the business's words: show your person this, as it is."

removedOutput schema / properties / confirm / properties / terms_sha / description
```
Removed value: -"Send it back as terms_sha only after your person said yes."
```

removedOutput schema / properties / delivered / description

Removed value: -"Whether the request is in the business's inbox now."

removedOutput schema / properties / elsewhere / description

Removed value: -"Where the business takes this kind of request instead."

removedOutput schema / properties / inbox / description

Removed value: -"The business's own inbox, where the request went."

removedOutput schema / properties / item / description

Removed value: -"The request as the inbox keeps it."

removedOutput schema / properties / kept / description

Removed value: -"What this network keeps of the request."

removedOutput schema / properties / outcome / description

Removed value: -"delivered: in the business's inbox. confirm: nothing sent yet, the terms are for your person to confirm. times: the free times, nothing sent. not_free: that time is not free, nothing sent. refused: the inbox refused it (its words say why). busy: the inbox asked for a pause. failed: the inbox could not be reached. switched_off: the business does not take requests carried by a network. no_inbox: the business has no inbox to carry it to, or its inbox has not said it takes requests carried by a network. not_taken: its inbox does not take this kind of request. elsewhere: it takes this kind somewhere else."

removedOutput schema / properties / replayed / description

Removed value: -"The same request again: the inbox answered as it did the first time."

removedOutput schema / properties / service / description
```
Removed value: -"The service a booking is for."
```
removedOutput schema / properties / service / properties / duration_min / maximum
```
Removed value: -9007199254740991
```
removedOutput schema / properties / service / properties / duration_min / minimum
```
Removed value: --9007199254740991
```

removedOutput schema / properties / services / description

Removed value: -"The services the business books, when service named none of them."

removedOutput schema / properties / status_url / description

Removed value: -"Where its state can be read, with access_token."

removedOutput schema / properties / times / description

Removed value: -"Free times, in UTC; timezone says the business's own, the clock to tell your person."

removedOutput schema / properties / times / items / properties / end / pattern

Removed value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$"

removedOutput schema / properties / times / items / properties / start / pattern

Removed value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$"

removedOutput schema / properties / timezone / description
```
Removed value: -"The business's time zone."
```

removedOutput schema / title

Removed value: -"MCP ask_business: structuredContent"

AddedOct 20, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Adds real behavior beyond the annotations: the answer arrives by email at the consented address, never by phone, nothing is sent without consent, and the access_token must be retained to read request state. These are operational facts the readOnly/openWorld/idempotent hints do not convey.

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

Conciseness4/5

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

Three tight sentences with the core action and eligibility constraints front-loaded. The final sentence about keeping the access_token is useful but phrased slightly cryptically relative to the rest.

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

Completeness4/5

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

With a full input schema, an output schema, and rich annotations, the description covers the remaining burden well: eligibility, consent gating, reply channel, and token handling. Only failure behavior and what the returned state contains are left implicit.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds cross-field meaning: domain must be a listed business with an inbox (as returned by search_businesses/get_business), and consent/contact must reflect a real agreement. It reinforces the email-only constraint on the nested contact object.

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

Purpose4/5

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

States a specific verb and resource: sending a person's question to a business's own inbox. The phrase 'own inbox' implicitly separates it from request_quote/request_booking/room_send, but no sibling is named explicitly, so an agent must infer the boundary.

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

Usage Guidelines4/5

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

Gives clear preconditions: the business must be listed and have an inbox, and the person must have asked to be contacted. That is strong when/when-not guidance, though it never names the alternative tools an agent should pick instead when those conditions fail.

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

All Surfing Dog tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?