Find participating local service providers and book live appointment times.
Scored across 7 tools
The tools form a multi-step booking state machine, and several of them touch the same underlying data: get_service_options overlaps with update_service_request (which already returns availability), and render_service_request_form vs select_service_option vs create_service_booking are easy to confuse without careful reading. The descriptions do an excellent job of prescribing exactly when each is valid, which rescues the set, but the boundaries are genuinely subtle.
All seven tools use snake_case with a clear verb_noun pattern (start_/update_/get_/select_/render_/create_/open_). The verbs map cleanly to lifecycle actions and there is no mixing of conventions.
Seven tools is a well-scoped size for a single-domain booking flow. Each tool corresponds to a distinct step or resource in the request-to-booking lifecycle, with no obviously redundant or filler tools.
The surface covers the full path from intake (start/update), availability (get_service_options), provider selection (select/render), through to booking (create) and post-booking management (open_service_account). Minor gaps exist — cancellation/rescheduling and booking status are delegated entirely to the external account card, so there is no programmatic cancel or status-read tool.
Use only from the protected final card with its one-time authorization after the user presses Confirm. Provider, request, hold, time and protected answers come from server context; do not pass or reconstruct them. This anonymous action completes the booking and must not trigger Connect or phone verification. Safe retries must reuse the same idempotency key.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | ||
| campaign_id | No | ||
| correlation_id | Yes | ||
| idempotency_key | Yes | ||
| anonymous_session_id | Yes | ||
| booking_authorization_token | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real context beyond the annotations: this is an anonymous action, it must not trigger Connect or phone verification, server-context fields must not be passed or reconstructed, and retries must reuse the idempotency key (corroborating idempotentHint=true). It does not describe what the booking mutation destroys despite destructiveHint=true, or any auth/token expiry failure modes.
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?
Four sentences, each load-bearing, with the critical precondition front-loaded and the retry rule last. No filler or restatement of 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?
Output schema exists so return values need no explanation, and annotations cover safety/idempotency, letting the description focus on preconditions and the anonymity constraint. The main gap is the half-documented parameter set, which no structured field covers.
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 0% across 6 params, so the description carries the burden; it explains idempotency_key retry semantics and loosely ties booking_authorization_token to the 'one-time authorization', but source, campaign_id, correlation_id, and anonymous_session_id remain undocumented anywhere. It also warns about server-context values that are not even present as schema parameters, which is useful guidance but not parameter documentation.
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+resource ('create…service booking') and qualifies it as 'the confirmed service booking' that 'completes the booking', which reads distinctly from the prepare/reschedule/select siblings. It stops short of naming which sibling to use for the non-final steps, so differentiation is inferred from the 'final card / Confirm' precondition rather than stated outright.
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 firm precondition: 'Use only from the protected final card with its one-time authorization after the user presses Confirm,' plus a clear exclusion ('must not trigger Connect or phone verification'). It never names the alternative tool for the pre-confirm flow, so routing is strong but not fully closed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refresh availability only when needed, such as when the user asks to check again. start_service_request and update_service_request already return current matching data. Returns aggregated windows and refinement fields without selecting a company or reserving capacity.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds real behavioral context by stating the call does not select a company or reserve capacity, i.e., it has no booking side effects, which goes 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?
Three tight sentences with no filler, each carrying a distinct point (when to refresh, what already returns data, what the call does and does not do). It is slightly front-loaded on usage rather than purpose, which is a minor structural quirk in an otherwise efficient description.
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?
An output schema exists, so return values need not be spelled out, and annotations cover the safety profile; the description's usage routing and no-side-effect note fill the remaining gaps well. The one real omission is any explanation of the request_id input, which neither the schema nor the description supplies.
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?
There is a single required parameter, request_id, and schema description coverage is 0%, so the schema contributes no explanation either. The description never mentions request_id, its expected format, or which request it must reference, leaving the only input 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?
The description conveys the resource indirectly through 'Returns aggregated windows and refinement fields' and the refresh/availability framing, and it names sibling tools (start_service_request, update_service_request) to distinguish its role. It never states plainly 'retrieves the current service options for a request,' so the purpose is clear but stated obliquely rather than as a direct verb+resource.
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 an explicit when-to-use condition ('when the user asks to check again') and an explicit when-not-to-use signal: start_service_request and update_service_request already return current matching data, so calling this afterward is redundant. The alternative data sources are named, which is exactly what routes an agent between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use only when the user explicitly asks to view, reschedule or cancel existing appointments or manage saved addresses. Opens the existing first-party account portal inside a card, never returns customer data. Never call for general questions or new bookings. The customer signs in and makes changes inside the card on MCP Near Me; never ask to connect or reconnect a ChatGPT account, and never request a phone or code in chat. When a live card is displayed, omit prose or use at most one short neutral sentence: use only assistant_message in the customer's language (English: "Details and current status are in the card."). End the reply there. Do not add an introduction, summary, instructions to review or confirm, or claims that a booking is created or not yet created: this text remains after the card changes. Do not repeat companies, dates, times, prices, policies, booking references, status claims, comparisons or next steps outside the card. This applies only to successful card presentation; keep normal intake/choice questions and concise error or unavailable-UI guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | No | view |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations already mark this as read-only, idempotent, and non-destructive, the description adds substantial behavioral context: no customer data is returned, the customer signs in inside the card, and account credentials should not be requested in chat. It also describes how to handle the assistant message after successful card presentation and what text must not 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?
The description is front-loaded with the key usage rule, but it is extremely long and repetitive around response formatting and card presentation constraints. Much of the guidance is useful, but several sentences restate the same point, making it less concise than ideal.
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 rich annotations and the presence of an output schema, the description covers the important behavioral details: when to call, what happens inside the card, data privacy, and how to phrase the assistant message. The only notable gap is explicit parameter semantics for `intent`, but the overall agent guidance is otherwise complete.
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 has 0% description coverage for the single `intent` parameter, so the description must carry that burden. It implies the available actions (view, reschedule, cancel) but does not explicitly document the `intent` parameter, its enum values, or the default value of `view`, leaving the schema to define those mechanics.
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 gives a specific verb and resource: it opens the existing first-party account portal inside a card for viewing, rescheduling, or canceling appointments and managing addresses. It clearly distinguishes this from sibling tools by stating it is for existing appointments, not new bookings or general service questions.
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?
Usage is explicitly constrained: call only when the user explicitly asks to view, reschedule, cancel, or manage saved addresses, and never for general questions or new bookings. The description also explains the authentication flow and when not to ask for account reconnection or chat-based codes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open the protected contact/terms/Confirm card only after company choice. Pass the explicitly chosen company's option_key from current service_options; omit it only for a single option or a previously selected company. When a live card is displayed, omit prose or use at most one short neutral sentence: use only assistant_message in the customer's language (English: "Details and current status are in the card."). End the reply there. Do not add an introduction, summary, instructions to review or confirm, or claims that a booking is created or not yet created: this text remains after the card changes. Do not repeat companies, dates, times, prices, policies, booking references, status claims, comparisons or next steps outside the card. This applies only to successful card presentation; keep normal intake/choice questions and concise error or unavailable-UI guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| option_key | No | Exact option_key from this request's current service_options for the company explicitly chosen by the user. Never infer a choice from price or ordering. | |
| request_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover only the safety profile (read-only, idempotent, closed-world); the description adds genuinely non-obvious behavior: the card is 'live', text persists after the card changes, and the no-prose rule applies only to successful presentation, not to errors. It does not discuss permissions for the 'protected' card, which is the one gap.
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 critical precondition and parameter rule are front-loaded, but the second half is a long, repetitive chain of prohibitions (do not add, do not repeat, do not claim) that restate the same message-discipline rule several ways and inflate the definition.
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?
An output schema exists, so return values need no explanation, and the description covers preconditions, parameter sourcing, and the reply protocol after a successful render. Error/unavailable-UI handling is deferred rather than described, which is a minor omission.
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 50% (request_id is undocumented), so the description carries real weight: it defines where option_key comes from ('current service_options'), which choice it must encode (explicitly chosen company), and two cases where it is omitted. This adds semantics beyond the schema's 'never infer from price or ordering'.
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 concrete action (open/render a confirmation card) plus a precondition (only after company choice), and implicitly separates itself from create_service_booking by forbidding booking claims. The card's identity ('protected contact/terms/Confirm card') is jargon-heavy but decipherable from the title.
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 explicit when-to-call ('only after company choice'), explicit parameter-handling rules (omit option_key only for a single option or a previously selected company), and an explicit scope limit ('applies only to successful card presentation; keep normal intake/choice questions and concise error guidance').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Called only by the protected contact form after an explicit Confirm action. It rechecks the company already chosen in chat, creates a temporary hold and returns the protected contact session. Never use it to present a company picker or on card startup. It does not create a booking.
| Name | Required | Description | Default |
|---|---|---|---|
| option_key | Yes | ||
| request_id | Yes | ||
| idempotency_key | Yes | ||
| expected_state_version | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, but the description adds real context: a temporary hold is created and the protected contact session is returned, while no booking is created. Gaps remain on hold duration/expiry and on failure behavior for state-version conflicts, so not 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?
Four short sentences, each load-bearing: trigger first, then effect, then exclusions, then the non-effect clarification. No redundancy or filler.
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 stateful mutation requiring a version token and idempotency key, the description omits the concurrency/retry contract an agent needs to call it without errors. The return surface is covered by the existing output schema and the when/when-not guidance is strong, so the definition is workable but incomplete.
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 0% across four required parameters, and the description names none of them—no guidance on expected_state_version (optimistic concurrency), idempotency_key (retry safety), request_id, or option_key format. The phrase 'rechecks the company already chosen' only loosely implies option_key, which is not enough compensation for a fully undocumented 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?
States specific actions—rechecking the already-chosen company, creating a temporary hold, returning the protected contact session—attached to a named trigger (the protected contact form after Confirm). It also explicitly negates sibling behaviors ('not to present a company picker', 'does not create a booking'), so it is distinguishable from get_service_options and create_service_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?
Explicit when: only from the protected contact form after an explicit Confirm action. Explicit when-not: never to present a company picker and never on card startup. That is a full routing rule with exclusions, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a new supported service request immediately with the user's full intent and known public facts. Returns the vertical introduction and next intake/matching step, including availability when intake is complete; no separate lookup is needed. Use provider_hint only for an explicitly named company.
| Name | Required | Description | Default |
|---|---|---|---|
| answers | No | ||
| user_intent | Yes | ||
| provider_hint | No | ||
| vertical_hint | No | Optional exact live vertical ID. Omit it when uncertain and let the server classify user_intent. | |
| idempotency_key | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the description only needs to add context. It does add workflow behavior - the call chains into 'the vertical introduction and next intake/matching step' and surfaces availability when intake completes - but says nothing about permissions, failure modes, or how the required idempotency_key is consumed.
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 plus a short parameter rule; the purpose and immediate-effect claim is front-loaded. It is efficient, though the return-value clause is somewhat redundant given an output schema exists.
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?
A mutating, idempotent tool with a nested parameter object and an output schema - so return values need not be described. The description covers purpose, chaining behavior, and one parameter rule, but leaves the mandatory idempotency_key and the required user_intent input unaddressed, which are the two parameters an agent must supply 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 only 20% across 5 parameters (nested answers object), so the description must carry the load. It clarifies only provider_hint ('only for an explicitly named company'); user_intent, idempotency_key, and the answers sub-fields (brand, model, zip_code, appliance_type, problem_description) get no added meaning beyond their bare schema descriptions.
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 ('Start a new supported service request immediately') and clarifies the input posture ('with the user's full intent and known public facts'). It is distinguishable from create_service_booking in spirit, but it never names or contrasts with the closest siblings (render_service_request_form, update_service_request), 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides one concrete routing cue ('no separate lookup is needed') and one narrow parameter rule ('Use provider_hint only for an explicitly named company'). There is no explicit when-not guidance and no alternative tool is named, so usage is implied rather than specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit supplied answers and any chosen selected_time_key with the latest expected_state_version. Omitted optional/conditional fields do not block progress. Returns the updated next_action and current availability; continue directly without get_service_options. choose_service_provider means ask for a company before opening its protected contact card.
| Name | Required | Description | Default |
|---|---|---|---|
| answers | No | ||
| request_id | Yes | ||
| idempotency_key | Yes | ||
| expected_state_version | Yes | ||
| explicitly_unknown_field_ids | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety and idempotency (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower, and the description adds useful workflow behavior: partial submission is tolerated and it returns the updated next_action plus current availability. It does not disclose what happens on a stale expected_state_version (conflict/retry behavior), which is the main risk of an optimistic-concurrency update.
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, front-loaded with the actionable submission rule and return behavior, with the branching clarification last. Wording is compressed and a bit jargon-heavy ('latest expected_state_version', 'do not block progress'), but nothing is filler.
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?
An output schema exists, so return values need not be detailed, yet the description still tells the agent the next_action and availability come back and that no extra options fetch is needed. For a 5-parameter mutation with nested answers at 0% schema coverage, the remaining gap is the unmentioned explicitly_unknown_field_ids and stale-version conflict handling.
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?
With schema description coverage at 0%, the description must carry parameter meaning; it explains selected_time_key ('any chosen selected_time_key', schema says exact key from the service) and expected_state_version must be the latest, and it implies which fields are conditional. It says nothing about idempotency_key, request_id, or explicitly_unknown_field_ids, so a third of the surface stays unexplained.
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 concrete action (submit answers plus an optional selected_time_key against the latest expected_state_version) on a named resource, so an agent can tell it is a state-advancing write on an existing request. It implicitly distinguishes itself from get_service_options, which it tells the caller to skip. It never explicitly contrasts with start_service_request or render_service_request_form, the closest siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives real routing guidance: continue directly without get_service_options, and omitted optional/conditional fields do not block progress, which tells the agent it need not chase every field before calling. 'choose_service_provider means ask for a company before opening its protected contact card' clarifies a downstream branch. No explicit statement of when to prefer this over start_service_request or prepare_service_booking_change.
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.
open_service_account1 field changedOutput schema / properties / result / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "account_url": {
- "type": "string"
- },
- "authentication": {
- "const": "first_party_only",
- "type": "string"
- },
- "intent": {
- "type": "string"
- }
- },
- "required": [
- "account_url",
- "intent",
- "authentication"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "error": {
- "additionalProperties": false,
- "properties": {
- "category": {
- "type": "string"
- },
- "code": {
- "type": "string"
- },
- "correlation_id": {
- "type": "string"
- },
- "details": {
- "additionalProperties": {},
- "propertyNames": {
- "type": "string"
- },
- "type": "object"
- },
- "message": {
- "type": "string"
- },
- "retryable": {
- "type": "boolean"
- }
- },
- "required": [
- "code",
- "category",
- "message",
- "retryable",
- "correlation_id",
- "details"
- ],
- "type": "object"
- }
- },
- "required": [
- "error"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "account_url": {
+ "type": "string"
+ },
+ "assistant_message": {
+ "const": "Details and current status are in the card.",
+ "description": "The only permitted optional caption for the live card. Translate to the customer's language without adding details or instructions.",
+ "type": "string"
+ },
+ "authentication": {
+ "const": "first_party_only",
+ "type": "string"
+ },
+ "intent": {
+ "type": "string"
+ },
+ "presentation": {
+ "const": "interactive_card",
+ "type": "string"
+ }
+ },
+ "required": [
+ "account_url",
+ "intent",
+ "authentication",
+ "presentation",
+ "assistant_message"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "code": {
+ "type": "string"
+ },
+ "correlation_id": {
+ "type": "string"
+ },
+ "details": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "retryable": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "code",
+ "category",
+ "message",
+ "retryable",
+ "correlation_id",
+ "details"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+]render_service_request_form1 field changedOutput schema / properties / result / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "next_action": {
- "enum": [
- "complete_protected_form",
- "confirmed"
- ],
- "type": "string"
- },
- "request_id": {
- "type": "string"
- },
- "state_version": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "user_stage": {
- "const": "confirmation",
- "type": "string"
- }
- },
- "required": [
- "request_id",
- "state_version",
- "user_stage",
- "next_action"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "error": {
- "additionalProperties": false,
- "properties": {
- "category": {
- "type": "string"
- },
- "code": {
- "type": "string"
- },
- "correlation_id": {
- "type": "string"
- },
- "details": {
- "additionalProperties": {},
- "propertyNames": {
- "type": "string"
- },
- "type": "object"
- },
- "message": {
- "type": "string"
- },
- "retryable": {
- "type": "boolean"
- }
- },
- "required": [
- "code",
- "category",
- "message",
- "retryable",
- "correlation_id",
- "details"
- ],
- "type": "object"
- }
- },
- "required": [
- "error"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "assistant_message": {
+ "const": "Details and current status are in the card.",
+ "description": "The only permitted optional caption for the live card. Translate to the customer's language without adding details or instructions.",
+ "type": "string"
+ },
+ "presentation": {
+ "const": "interactive_card",
+ "type": "string"
+ },
+ "request_id": {
+ "type": "string"
+ },
+ "state_version": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "request_id",
+ "state_version",
+ "presentation",
+ "assistant_message"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "code": {
+ "type": "string"
+ },
+ "correlation_id": {
+ "type": "string"
+ },
+ "details": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "retryable": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "code",
+ "category",
+ "message",
+ "retryable",
+ "correlation_id",
+ "details"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+]cancel_service_bookingcomplete_account_linkget_my_service_bookinglist_my_service_bookingsopen_service_accountprepare_service_booking_changereschedule_service_bookingrender_service_request_form1 field changedOutput schema / properties / result / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "next_action": {
- "const": "complete_protected_form",
- "type": "string"
- },
- "request_id": {
- "type": "string"
- },
- "state_version": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "user_stage": {
- "const": "confirmation",
- "type": "string"
- }
- },
- "required": [
- "request_id",
- "state_version",
- "user_stage",
- "next_action"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "error": {
- "additionalProperties": false,
- "properties": {
- "category": {
- "type": "string"
- },
- "code": {
- "type": "string"
- },
- "correlation_id": {
- "type": "string"
- },
- "details": {
- "additionalProperties": {},
- "propertyNames": {
- "type": "string"
- },
- "type": "object"
- },
- "message": {
- "type": "string"
- },
- "retryable": {
- "type": "boolean"
- }
- },
- "required": [
- "code",
- "category",
- "message",
- "retryable",
- "correlation_id",
- "details"
- ],
- "type": "object"
- }
- },
- "required": [
- "error"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "next_action": {
+ "enum": [
+ "complete_protected_form",
+ "confirmed"
+ ],
+ "type": "string"
+ },
+ "request_id": {
+ "type": "string"
+ },
+ "state_version": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "user_stage": {
+ "const": "confirmation",
+ "type": "string"
+ }
+ },
+ "required": [
+ "request_id",
+ "state_version",
+ "user_stage",
+ "next_action"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "code": {
+ "type": "string"
+ },
+ "correlation_id": {
+ "type": "string"
+ },
+ "details": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "retryable": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "code",
+ "category",
+ "message",
+ "retryable",
+ "correlation_id",
+ "details"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+]select_service_option1 field changedOutput schema / properties / result / anyOfPrevious value: -[
- {
- "additionalProperties": {},
- "properties": {
- "arrival_window": {
- "type": "string"
- },
- "next_action": {
- "const": "complete_protected_form",
- "type": "string"
- },
- "option_key": {
- "type": "string"
- },
- "provider_public_name": {
- "type": "string"
- },
- "request_id": {
- "type": "string"
- },
- "service_date": {
- "type": "string"
- },
- "state_version": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- }
- },
- "required": [
- "request_id",
- "state_version",
- "option_key",
- "provider_public_name",
- "service_date",
- "arrival_window",
- "next_action"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "error": {
- "additionalProperties": false,
- "properties": {
- "category": {
- "type": "string"
- },
- "code": {
- "type": "string"
- },
- "correlation_id": {
- "type": "string"
- },
- "details": {
- "additionalProperties": {},
- "propertyNames": {
- "type": "string"
- },
- "type": "object"
- },
- "message": {
- "type": "string"
- },
- "retryable": {
- "type": "boolean"
- }
- },
- "required": [
- "code",
- "category",
- "message",
- "retryable",
- "correlation_id",
- "details"
- ],
- "type": "object"
- }
- },
- "required": [
- "error"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": {},
+ "properties": {
+ "arrival_window": {
+ "type": "string"
+ },
+ "next_action": {
+ "enum": [
+ "complete_protected_form",
+ "confirmed"
+ ],
+ "type": "string"
+ },
+ "option_key": {
+ "type": "string"
+ },
+ "provider_public_name": {
+ "type": "string"
+ },
+ "request_id": {
+ "type": "string"
+ },
+ "service_date": {
+ "type": "string"
+ },
+ "state_version": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "request_id",
+ "state_version",
+ "option_key",
+ "provider_public_name",
+ "service_date",
+ "arrival_window",
+ "next_action"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "code": {
+ "type": "string"
+ },
+ "correlation_id": {
+ "type": "string"
+ },
+ "details": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "retryable": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "code",
+ "category",
+ "message",
+ "retryable",
+ "correlation_id",
+ "details"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+]render_service_request_form1 field changedOutput schema / properties / result / anyOfPrevious value: -[
- {
- "additionalProperties": {},
- "properties": {
- "field_batch": {
- "additionalProperties": {},
- "properties": {
- "conditionally_required": {
- "items": {},
- "type": "array"
- },
- "optional": {
- "items": {},
- "type": "array"
- },
- "required": {
- "items": {},
- "type": "array"
- }
- },
- "required": [
- "required",
- "conditionally_required",
- "optional"
- ],
- "type": "object"
- },
- "known_fields": {
- "additionalProperties": {},
- "propertyNames": {
- "type": "string"
- },
- "type": "object"
- },
- "next_action": {
- "type": "string"
- },
- "request_id": {
- "type": "string"
- },
- "state_version": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "user_stage": {
- "enum": [
- "intake",
- "matching",
- "confirmation"
- ],
- "type": "string"
- },
- "vertical_id": {
- "type": "string"
- },
- "vertical_introduction": {
- "additionalProperties": false,
- "properties": {
- "message": {
- "type": "string"
- },
- "present_once": {
- "const": true,
- "type": "boolean"
- },
- "presentation_order": {
- "const": "lead_same_message",
- "type": "string"
- }
- },
- "required": [
- "message",
- "presentation_order",
- "present_once"
- ],
- "type": "object"
- }
- },
- "required": [
- "request_id",
- "state_version",
- "vertical_id",
- "user_stage",
- "known_fields",
- "field_batch",
- "next_action"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "error": {
- "additionalProperties": false,
- "properties": {
- "category": {
- "type": "string"
- },
- "code": {
- "type": "string"
- },
- "correlation_id": {
- "type": "string"
- },
- "details": {
- "additionalProperties": {},
- "propertyNames": {
- "type": "string"
- },
- "type": "object"
- },
- "message": {
- "type": "string"
- },
- "retryable": {
- "type": "boolean"
- }
- },
- "required": [
- "code",
- "category",
- "message",
- "retryable",
- "correlation_id",
- "details"
- ],
- "type": "object"
- }
- },
- "required": [
- "error"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "next_action": {
+ "const": "complete_protected_form",
+ "type": "string"
+ },
+ "request_id": {
+ "type": "string"
+ },
+ "state_version": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "user_stage": {
+ "const": "confirmation",
+ "type": "string"
+ }
+ },
+ "required": [
+ "request_id",
+ "state_version",
+ "user_stage",
+ "next_action"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "code": {
+ "type": "string"
+ },
+ "correlation_id": {
+ "type": "string"
+ },
+ "details": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "retryable": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "code",
+ "category",
+ "message",
+ "retryable",
+ "correlation_id",
+ "details"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+]render_service_request_form1 field changedInput schema / properties / option_keyAdded value: +{
+ "description": "Exact option_key from this request's current service_options for the company explicitly chosen by the user. Never infer a choice from price or ordering.",
+ "maxLength": 100,
+ "minLength": 10,
+ "type": "string"
+}start_service_request5 fields changedInput schema / properties / answers / properties / appliance_type / descriptionPrevious value: -"Appliance type. Use the exact key appliance_type."New value: +"Appliance type"Input schema / properties / answers / properties / brand / descriptionPrevious value: -"Brand. Use the exact key brand."New value: +"Brand"Input schema / properties / answers / properties / model / descriptionPrevious value: -"Model. Use the exact key model."New value: +"Model"Input schema / properties / answers / properties / problem_description / descriptionPrevious value: -"Problem. Use the exact key problem_description."New value: +"Problem"Input schema / properties / answers / properties / zip_code / descriptionPrevious value: -"ZIP. Use the exact key zip_code."New value: +"ZIP"update_service_request5 fields changedInput schema / properties / answers / properties / appliance_type / descriptionPrevious value: -"Appliance type. Use the exact key appliance_type."New value: +"Appliance type"Input schema / properties / answers / properties / brand / descriptionPrevious value: -"Brand. Use the exact key brand."New value: +"Brand"Input schema / properties / answers / properties / model / descriptionPrevious value: -"Model. Use the exact key model."New value: +"Model"Input schema / properties / answers / properties / problem_description / descriptionPrevious value: -"Problem. Use the exact key problem_description."New value: +"Problem"Input schema / properties / answers / properties / zip_code / descriptionPrevious value: -"ZIP. Use the exact key zip_code."New value: +"ZIP"cancel_service_booking1 field changedInput schema / properties / source / enumPrevious value: -[
- "chatgpt_plugin",
- "chatgpt_ads",
- "ai_search",
- "organic_search",
- "paid_search",
- "provider_referral",
- "direct",
- "test"
-]New value: +[
+ "chatgpt_plugin",
+ "chatgpt_ads",
+ "ai_search",
+ "organic_search",
+ "paid_search",
+ "manual_referral",
+ "provider_referral",
+ "direct",
+ "test"
+]create_service_booking1 field changedInput schema / properties / source / enumPrevious value: -[
- "chatgpt_plugin",
- "chatgpt_ads",
- "ai_search",
- "organic_search",
- "paid_search",
- "provider_referral",
- "direct",
- "test"
-]New value: +[
+ "chatgpt_plugin",
+ "chatgpt_ads",
+ "ai_search",
+ "organic_search",
+ "paid_search",
+ "manual_referral",
+ "provider_referral",
+ "direct",
+ "test"
+]reschedule_service_booking1 field changedInput schema / properties / source / enumPrevious value: -[
- "chatgpt_plugin",
- "chatgpt_ads",
- "ai_search",
- "organic_search",
- "paid_search",
- "provider_referral",
- "direct",
- "test"
-]New value: +[
+ "chatgpt_plugin",
+ "chatgpt_ads",
+ "ai_search",
+ "organic_search",
+ "paid_search",
+ "manual_referral",
+ "provider_referral",
+ "direct",
+ "test"
+]start_service_request7 fields changedInput schema / properties / answers / additionalPropertiesPrevious value: -{}New value: +falseInput schema / properties / answers / propertiesAdded value: +{
+ "appliance_type": {
+ "description": "Appliance type. Use the exact key appliance_type."
+ },
+ "brand": {
+ "description": "Brand. Use the exact key brand."
+ },
+ "model": {
+ "description": "Model. Use the exact key model."
+ },
+ "problem_description": {
+ "description": "Problem. Use the exact key problem_description."
+ },
+ "selected_time_key": {
+ "description": "Exact time key returned by MCP Near Me after the user chooses an arrival window.",
+ "minLength": 1,
+ "type": "string"
+ },
+ "zip_code": {
+ "description": "ZIP. Use the exact key zip_code."
+ }
+}Input schema / properties / answers / propertyNamesRemoved value: -{
- "type": "string"
-}Input schema / properties / vertical_hint / descriptionAdded value: +"Optional exact live vertical ID. Omit it when uncertain and let the server classify user_intent."Input schema / properties / vertical_hint / enumAdded value: +[
+ "appliance_repair",
+ "commercial_kitchen_refrigeration_repair"
+]Input schema / properties / vertical_hint / maxLengthRemoved value: -100Input schema / properties / vertical_hint / minLengthRemoved value: -3update_service_request3 fields changedInput schema / properties / answers / additionalPropertiesPrevious value: -{}New value: +falseInput schema / properties / answers / propertiesAdded value: +{
+ "appliance_type": {
+ "description": "Appliance type. Use the exact key appliance_type."
+ },
+ "brand": {
+ "description": "Brand. Use the exact key brand."
+ },
+ "model": {
+ "description": "Model. Use the exact key model."
+ },
+ "problem_description": {
+ "description": "Problem. Use the exact key problem_description."
+ },
+ "selected_time_key": {
+ "description": "Exact time key returned by MCP Near Me after the user chooses an arrival window.",
+ "minLength": 1,
+ "type": "string"
+ },
+ "zip_code": {
+ "description": "ZIP. Use the exact key zip_code."
+ }
+}Input schema / properties / answers / propertyNamesRemoved value: -{
- "type": "string"
-}get_my_service_booking1 field changedOutput schema / properties / result / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "booking": {
- "additionalProperties": false,
- "properties": {
- "arrival_window": {
- "type": "string"
- },
- "available_actions": {
- "items": {
- "enum": [
- "reschedule",
- "cancel"
- ],
- "type": "string"
- },
- "type": "array"
- },
- "booking_id": {
- "type": "string"
- },
- "provider_public_name": {
- "type": "string"
- },
- "public_booking_ref": {
- "type": "string"
- },
- "service_date": {
- "type": "string"
- },
- "status": {
- "type": "string"
- },
- "timezone": {
- "type": "string"
- }
- },
- "required": [
- "booking_id",
- "provider_public_name",
- "service_date",
- "arrival_window",
- "timezone",
- "status",
- "public_booking_ref",
- "available_actions"
- ],
- "type": "object"
- },
- "next_action": {
- "enum": [
- "view_complete",
- "choose_available_time",
- "review_cancellation"
- ],
- "type": "string"
- }
- },
- "required": [
- "booking",
- "next_action"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "error": {
- "additionalProperties": false,
- "properties": {
- "category": {
- "type": "string"
- },
- "code": {
- "type": "string"
- },
- "correlation_id": {
- "type": "string"
- },
- "details": {
- "additionalProperties": {},
- "propertyNames": {
- "type": "string"
- },
- "type": "object"
- },
- "message": {
- "type": "string"
- },
- "retryable": {
- "type": "boolean"
- }
- },
- "required": [
- "code",
- "category",
- "message",
- "retryable",
- "correlation_id",
- "details"
- ],
- "type": "object"
- }
- },
- "required": [
- "error"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "booking": {
+ "additionalProperties": false,
+ "properties": {
+ "arrival_window": {
+ "type": "string"
+ },
+ "available_actions": {
+ "items": {
+ "enum": [
+ "reschedule",
+ "cancel"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "booking_id": {
+ "type": "string"
+ },
+ "is_active": {
+ "type": "boolean"
+ },
+ "is_manageable": {
+ "type": "boolean"
+ },
+ "is_past": {
+ "type": "boolean"
+ },
+ "provider_public_name": {
+ "type": "string"
+ },
+ "public_booking_ref": {
+ "type": "string"
+ },
+ "service_date": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "timezone": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "booking_id",
+ "provider_public_name",
+ "service_date",
+ "arrival_window",
+ "timezone",
+ "status",
+ "public_booking_ref",
+ "is_active",
+ "is_manageable",
+ "is_past",
+ "available_actions"
+ ],
+ "type": "object"
+ },
+ "next_action": {
+ "enum": [
+ "view_complete",
+ "choose_available_time",
+ "review_cancellation"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "booking",
+ "next_action"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "code": {
+ "type": "string"
+ },
+ "correlation_id": {
+ "type": "string"
+ },
+ "details": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "retryable": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "code",
+ "category",
+ "message",
+ "retryable",
+ "correlation_id",
+ "details"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+]list_my_service_bookings2 fields changedInput schema / properties / status / descriptionPrevious value: -"Use 'active' for reschedule or cancellation requests; otherwise omit to include appointment history."New value: +"Use 'active' for cancellation or rescheduling. It returns only actionable appointments whose arrival window has not ended; omit to include history."Output schema / properties / result / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "active_count": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "bookings": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "arrival_window": {
- "type": "string"
- },
- "booking_id": {
- "type": "string"
- },
- "provider_public_name": {
- "type": "string"
- },
- "public_booking_ref": {
- "type": "string"
- },
- "service_date": {
- "type": "string"
- },
- "status": {
- "type": "string"
- },
- "timezone": {
- "type": "string"
- }
- },
- "required": [
- "booking_id",
- "provider_public_name",
- "service_date",
- "arrival_window",
- "timezone",
- "status",
- "public_booking_ref"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "count": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- }
- },
- "required": [
- "bookings",
- "count",
- "active_count"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "error": {
- "additionalProperties": false,
- "properties": {
- "category": {
- "type": "string"
- },
- "code": {
- "type": "string"
- },
- "correlation_id": {
- "type": "string"
- },
- "details": {
- "additionalProperties": {},
- "propertyNames": {
- "type": "string"
- },
- "type": "object"
- },
- "message": {
- "type": "string"
- },
- "retryable": {
- "type": "boolean"
- }
- },
- "required": [
- "code",
- "category",
- "message",
- "retryable",
- "correlation_id",
- "details"
- ],
- "type": "object"
- }
- },
- "required": [
- "error"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "active_count": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "bookings": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "arrival_window": {
+ "type": "string"
+ },
+ "booking_id": {
+ "type": "string"
+ },
+ "is_active": {
+ "type": "boolean"
+ },
+ "is_manageable": {
+ "type": "boolean"
+ },
+ "is_past": {
+ "type": "boolean"
+ },
+ "provider_public_name": {
+ "type": "string"
+ },
+ "public_booking_ref": {
+ "type": "string"
+ },
+ "service_date": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "timezone": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "booking_id",
+ "provider_public_name",
+ "service_date",
+ "arrival_window",
+ "timezone",
+ "status",
+ "public_booking_ref",
+ "is_active",
+ "is_manageable",
+ "is_past"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "count": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "bookings",
+ "count",
+ "active_count"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "code": {
+ "type": "string"
+ },
+ "correlation_id": {
+ "type": "string"
+ },
+ "details": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "retryable": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "code",
+ "category",
+ "message",
+ "retryable",
+ "correlation_id",
+ "details"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+]Find local services, check live availability, and book real appointments with consent.
Discover local services and availability, then create, track, reschedule, or cancel bookings.
Find, compare, and book local service businesses: live availability, prices, reviews, booking.
Find local services, read availability, and create short-lived booking holds.
Add one secure layer between your agents and this server.
