Surfing Dog

Request a booking

request_booking

Idempotent

Without start: a service's free times, from the business's own inbox; nothing is sent. With start: ask the inbox to book that time for your person. A priced service first answers with its terms: show them to your person, and send terms_sha only after their yes. Only for a listed business with an inbox, only when your person asked you to contact it; the business answers by email, at the address your person agreed to give.

Input Schema

Name	Required	Description
`from`	No	Without start: the first day to show free times for (today when left out).
`notes`	No	Anything the business should know.
`start`	No	When your person wants it to start, from this tool's free times. Leave it out to see them first.
`domain`	Yes	The business's domain, as search_businesses or get_business gave it, like bikes.example.
`consent`	No	Needed with start: true only when your person agreed to give this business their email address.
`contact`	No	Needed with start: where the business can answer.
`service`	Yes	The service's name, as get_business lists it, or its id from this tool's answer.
`language`	No	The language your person wants the answer in, as a tag like en, pt or pt-BR.
`terms_sha`	No	The confirm.terms_sha of the last answer, sent only after your person said yes to its summary.
`party_size`	No	How many people it is for, when that matters.

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.

Changed29 schema fields changedOct 31, 2026

removedInput schema / $schema

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

removedInput schema / properties / from / 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])))$"

removedInput schema / 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|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"

removedInput schema / title

Removed value: -"MCP request_booking: 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 request_booking: structuredContent"

AddedOct 20, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true), the description discloses what is and isn't transmitted ('nothing is sent' without start), how the business responds (by email, at the address the person agreed to), and the consent/terms confirmation flow. This is the kind of context annotations cannot carry.

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 dense sentences, front-loaded with the mode split before the terms/consent caveats. Every clause carries information, though the phrasing is compressed to the point of being slightly elliptical ('the business answers by email, at the address your person agreed to give').

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?

For a 10-parameter, nested, open-world mutation tool the description covers the risky parts: consent, terms confirmation, inbox prerequisite, and channel of response. With annotations and an output schema present, remaining gaps (idempotency behavior on retry, when party_size/language matter) are minor rather than blocking.

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 the baseline is 3, but the description adds workflow meaning the schema cannot: start is selected from this tool's own free times, terms_sha comes from the prior answer's confirm.terms_sha, and consent/contact only apply with start. That linkage materially improves correct parameter use.

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?

The description names a specific verb and resource and cleanly splits its two modes: without start it lists a service's free times (nothing sent), with start it asks the inbox to book. That is enough for an agent to know what it does, though it never contrasts itself with siblings like request_quote or ask_business, leaving the routing boundary implicit.

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

Usage Guidelines5/5

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

Explicit preconditions are stated: 'Only for a listed business with an inbox, only when your person asked you to contact it,' plus the gating sequence for priced services (show terms, send terms_sha only after their yes). It also says what to do with the result (the free-times call is a preview before committing).

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?