F
licenseA
qualityD
maintenanceEnables querying a veterinary clinic's services, summary, and availability from live data.
3
-
Book ShesMyDogLady
Server Details
Book with ShesMyDogLady: services, prices and open times. No key needed.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
TDQS
A4.1/5.0
Scored across 6 tools
Disambiguation5/5
Each tool targets a distinct step or resource in the booking flow: get_business (discovery), check_address (address validation), find_times (availability), book (create), get_booking (status), and cancel_booking (cancel). There is no meaningful overlap—even book vs. get_booking vs. cancel_booking are cleanly separated by action on the booking lifecycle.
Naming Consistency4/5
Five of six tools follow a clear verb_noun snake_case pattern (cancel_booking, check_address, find_times, get_booking, get_business). The lone 'book' is a bare verb with no noun, a minor deviation from an otherwise predictable convention.
Tool Count5/5
Six tools is well-scoped for a booking server, with each tool earning its place across the discovery-to-cancellation workflow. No redundant or filler tools.
Completeness4/5
The surface covers the full booking lifecycle: read business info, validate address, find times, create, check status, and cancel. A reschedule/modify operation is absent, but the descriptions suggest changes to approved bookings are handled outside the tool by design, so this is a minor gap.
Available Tools
6 toolsbookBookAIdempotentInspect
Book one visit for the customer, as a request the business approves (or, for a business that takes its bookings by email, confirms with the customer itself); the answer says what happens next and gives a manage.token to check or cancel it later. The customer is emailed. A new customer books the Meet & Greet first. Ask the customer about the dogs and answer from what they said (booking.petCare on the card): never guess. Confirm the visit, the time and the customer's details with the customer before calling it. idempotency_key is required: choose a new random one for each booking (a UUID without hyphens) and send the same one to retry after a timeout.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes | Who is booking, so the business sees that an agent made the booking and which one. | |
| items | Yes | Exactly one visit. Each visit is booked on its own; add-ons the service takes go in answers.addons. | |
| start | Yes | A start time from `times`, ISO 8601 with an offset, on a whole minute: seconds, when written, are 00 ("2026-10-12T10:00:00-07:00" or "2026-10-12T17:00Z"). It is checked again, and refused with `time_not_open` if it is no longer open. | |
| answers | Yes | What the customer told you about the visit and the dogs. The card's booking.petCare.answers says each key's exact format. Never guess: a question nobody asked is null. | |
| customer | Yes | The person the booking is for. They are emailed that the request was received, and again when the business answers. | |
| idempotency_key | Yes | Required. A key you choose, new for each booking: 32 to 255 letters, digits, dashes or underscores, and RANDOM, never a counter, a word or a pattern (a UUID without hyphens is right; a key with fewer than 8 distinct characters is refused). Calling book again with the same key and customer email answers the first booking again, with the same manage token, instead of making a second one: use it to retry safely after a timeout. |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag a write operation with idempotency and open-world reach. The description adds substantial context: the booking is a request subject to approval, may be email-confirmed, the customer is emailed, a manage.token is returned, and the idempotency_key must be random and reused for safe retries.
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?
The description is a single dense paragraph but leads with the core action. Most sentences earn their place, though the parenthetical about email-based businesses slightly interrupts the flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex nested booking tool with no output schema, the description covers the essential behavioral context: approval flow, email notification, manage token, Meet & Greet prerequisite, and idempotency handling. The schema and annotations fill in the remaining parameter and safety details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters in detail. The description reinforces the 'never guess' rule for answers.dogs and explains the idempotency_key retry behavior, but adds little beyond the schema's own parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Book one visit'. The rest of the description clarifies the outcome (request the business approves, customer emailed) so an agent can distinguish this from sibling booking-management tools like cancel_booking or get_booking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use the tool for a new booking and includes a key precondition: 'A new customer books the Meet & Greet first.' It also instructs the agent to confirm details with the customer before calling, though it does not explicitly name alternatives like find_times.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cancel_bookingCancel a bookingADestructiveIdempotentInspect
Cancel a booking made through this door: withdraws a request still waiting. A booking the business has approved must be changed with the business directly (the answer says how). Ask the customer first.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The booking's `manage.token`, from book. | |
| reference | Yes | The booking's `reference`, from book. |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds real context beyond that: the cancel only succeeds for pending requests, and it instructs the agent to confirm with the customer first — a behavioral constraint not present in annotations.
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 short clauses, front-loaded with the action and its applicability limit. Minor waste in the cryptic parenthetical 'the answer says how' and the odd phrase 'made through this door'.
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 two-parameter mutation with no output schema, the description covers eligibility, the escalation path for approved bookings, and a confirmation requirement. It hints at a return message but does not say what the response looks like; annotations carry the rest of the behavioral burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters (token, reference) are already documented as coming from the book tool. The description adds no syntax, format, or sourcing detail beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('cancel a booking') and narrows the scope precisely: it only withdraws a request still waiting, filtering out bookings already approved. This lets an agent distinguish cancel_booking from book/get_booking without opening any schema.
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 an explicit when-not rule: an approved booking must be changed with the business directly, not through this tool. However, the fallback pointer is vague ('the answer says how') and it names no sibling tool, so the routing guidance is clear but not fully actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_addressCheck an addressARead-onlyIdempotentInspect
Check the dog's address (its home, or where the dog is picked up) before booking. Send it as one line, as fields, or as a place_id saved from an earlier check. The answer says whether Google confirmed it (verdict), the address to book with (send it as answers.address), its place_id (save both for this customer), and whether it is inside the area the business serves. Book when bookable is true; when the verdict is confirm, read the corrected address to the customer first. next says what to do otherwise.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds real value beyond that: it discloses that verification comes from Google, names the response fields (verdict, answers.address, place_id, bookable, next), and instructs the agent to persist place_id per customer. It stops short of describing failure modes or latency.
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?
Front-loaded with the purpose, then send formats, then answer semantics and decision rules — every sentence earns its place. It is dense and leans on backticked tokens, which is efficient but slightly harder to scan than plain prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the full burden of explaining the return — and it does, covering verdict, answers.address, place_id, bookable and next, plus what to do with each. For a single-parameter read tool this is complete.
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?
The nested schema is already detailed, but the description adds operational framing: three interchangeable send formats (one line, fields, or a saved place_id) and the instruction to save and reuse place_id 'for this customer'. It does not add field-level meaning beyond the schema's own naming rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb+resource ('Check the dog's address') with the exact value to the business ('its home, or where the dog is picked up'), and positions it in the booking flow. An agent can tell this apart from sibling 'book' 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly scoped to 'before booking' and gives decision rules: 'Book when bookable is true; when the verdict is confirm, read the corrected address to the customer first. next says what to do otherwise.' This is when-to-use, when-not-to-act, and fallback routing in one place.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_timesFind open timesARead-onlyIdempotentInspect
Find the start times that are open for one visit (a service from the card whose bookable is true), between two dates (at most 14 days). Each time's end includes the minutes the business takes to settle the dog in. Pass windows (the customer's free time from their calendar) to get only the starts that fit both calendars. Returns ISO 8601 times with offsets. Only open times are ever shown.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Last day, YYYY-MM-DD. At most 14 days from `from`, counting both, and at most 60 days from today. | |
| from | Yes | First day, YYYY-MM-DD, in the business's time zone (the card names it). Not in the past. | |
| items | Yes | Exactly one visit. Each visit is booked on its own; add-ons the service takes go in answers.addons. | |
| windows | No | The customer's free time, as intervals with offsets. When given, only starts whose whole visit (its length plus its settling time) fits inside one window come back. Leave out to see every open start. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds real value beyond them by disclosing that a returned time's end already includes the business's settling minutes and that only open times are ever surfaced. It omits nothing critical, though it doesn't cover error behavior or timezone-conflict handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four front-loaded sentences, each carrying a distinct fact (what is returned, the settle-time inclusion, the windows narrowing, the return format). No padding or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description takes on the burden of describing return values and does so ('ISO 8601 times with offsets', only open ones). Combined with a thorough schema and annotations covering safety, an agent has everything needed to call this correctly.
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, and the description earns an increment by re-framing `windows` as 'the customer's free time from their calendar' and stating the both-calendars fitting rule in plain terms. It does not add format detail for `items`, `from`, or `to` beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Find the start times that are open') and constrains the scope to exactly one visit from a service whose bookable flag is true. An agent can immediately separate this availability-lookup from the write-oriented siblings book/cancel_booking without opening a schema.
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?
Explains the key conditional: pass `windows` (the customer's calendar) to get only starts fitting both calendars; omit it to see every open start. It does not name sibling tools or say explicitly to call this before `book`, so routing guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_bookingCheck a bookingARead-onlyIdempotentInspect
Check a booking made through this door: whether it is requested, confirmed, declined or cancelled, and whether it can still be cancelled here.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The booking's `manage.token`, from book. | |
| reference | Yes | The booking's `reference`, from book. |
TDQS
A3.8/5.0
Behavior4/5
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 goes beyond them by disclosing the status values returned and that it evaluates remaining cancellability, which is genuinely useful behavioral context.
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?
A single front-loaded sentence with no filler. The phrase 'made through this door' is slightly idiosyncratic and could read as jargon, which keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the return-value burden and does so by naming the possible booking states and the cancellability result. For a two-parameter read tool with full annotation coverage, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are described in the schema as coming from book (`manage.token` and `reference`). The description adds no format, syntax, or lookup detail, so the baseline of 3 for full schema coverage applies.
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 (check) and resource (a booking), and enumerates the states it reports (requested, confirmed, declined, cancelled) plus whether cancellation is still possible here. This sets it apart from the write-oriented cancel_booking, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the phrase 'whether it can still be cancelled here' hints this is the read step preceding cancel_booking, but there is no explicit when-to-use, when-not-to-use, or named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_businessGet the businessARead-onlyIdempotentInspect
Read the business card: what the business is, the area it serves, its services (which are booked here, how long each visit holds, and what to do about the rest), what a booking needs (the customer's details, the dog's address and what to ask about the dogs, in booking.petCare), that every booking is a request the business approves, the limits and the cancel rule. Call it first.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, non-destructive and closed-world, so the safety profile is done. The description adds genuinely non-obvious domain behavior: that every booking is a request the business approves, that some services are booked here while others are not, and that a cancel rule exists. Useful context beyond the annotations, though it says nothing about return format or 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action, which is good, but the middle collapses several unrelated facts into nested parentheses ('which are booked here, how long each visit holds, and what to do about the rest') that are hard to parse on one pass. The most actionable instruction, 'Call it first', is buried at the very end rather than stated up front.
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 no output schema, the description carries the burden of describing what comes back, and it does so at a reasonable level of detail: services, durations, booking requirements, approval model, limits, cancel rule. Enough for an agent to plan the booking flow, though exact field shapes and list structure remain unspecified.
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?
Zero parameters, so per the rubric the baseline is 4. The description does reference a payload path (booking.petCare) and the kinds of fields a booking needs, but since there is no input schema to enrich, it neither adds nor detracts from parameter semantics.
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+resource ('Read the business card') and enumerates what the card contains: the business, its service area, its services, booking requirements, approval semantics, limits and the cancel rule. That is far more than a restatement of the name. It doesn't name a sibling, but the content makes the read-vs-book distinction self-evident.
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?
'Call it first' is an explicit sequencing directive that tells the agent this tool precedes book/cancel_booking/find_times in the workflow, which is the key usage decision for a parameterless context tool. It stops short of naming alternatives or stating when not to call it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
book1 field changed- changed
Input schema / examplesPrevious value: -[ - { - "agent": { - "name": "Your agent name" - }, - "answers": { - "address": "123 Main St, Poway, CA 92064", - "behavior": { - "disclosed": true, - "has_concerns": false - }, - "claims_prior_meet_greet": false, - "dogs": [ - { - "age_text": "3 years", - "behavior_flags": [], - "behavior_notes": null, - "breed": "Labrador", - "crate_trained": null, - "good_with_dogs": true, - "medical_notes": null, - "name": "Biscuit", - "vaccinated_self_reported": true - } - ], - "interested_services": [ - "bark-n-stroll" - ] - }, - "customer": { - "email": "ada@example.com", - "name": "Ada Lovelace", - "phone": "(619) 555-0123" - }, - "idempotency_key": "replace-this-with-a-fresh-random-key-0000", - "items": [ - { - "slug": "meet-greet" - } - ], - "start": "2026-10-16T10:00:00-07:00" - } -]New value: +[ + { + "agent": { + "name": "Your agent name" + }, + "answers": { + "address": "123 Main St, Poway, CA 92064", + "behavior": { + "disclosed": true, + "has_concerns": false + }, + "claims_prior_meet_greet": false, + "dogs": [ + { + "age_text": "3 years", + "behavior_flags": [], + "behavior_notes": null, + "breed": "Labrador", + "crate_trained": null, + "good_with_dogs": true, + "medical_notes": null, + "name": "Biscuit", + "vaccinated_self_reported": true + } + ], + "interested_services": [ + "bark-n-stroll" + ] + }, + "customer": { + "email": "ada@example.com", + "name": "Ada Lovelace", + "phone": "(619) 555-0123" + }, + "idempotency_key": "replace-this-with-a-fresh-random-key-0000", + "items": [ + { + "slug": "meet-greet" + } + ], + "start": "2026-10-17T10:00:00-07:00" + } +]
- Changed
find_times1 field changed- changed
Input schema / examplesPrevious value: -[ - { - "from": "2026-10-16", - "items": [ - { - "slug": "meet-greet" - } - ], - "to": "2026-10-22", - "windows": [ - { - "end": "2026-10-16T17:00:00-07:00", - "start": "2026-10-16T09:00:00-07:00" - } - ] - } -]New value: +[ + { + "from": "2026-10-17", + "items": [ + { + "slug": "meet-greet" + } + ], + "to": "2026-10-23", + "windows": [ + { + "end": "2026-10-17T17:00:00-07:00", + "start": "2026-10-17T09:00:00-07:00" + } + ] + } +]
2 tool updates
- Changed
book1 field changed- changed
Input schema / examplesPrevious value: -[ - { - "agent": { - "name": "Your agent name" - }, - "answers": { - "address": "123 Main St, Poway, CA 92064", - "behavior": { - "disclosed": true, - "has_concerns": false - }, - "claims_prior_meet_greet": false, - "dogs": [ - { - "age_text": "3 years", - "behavior_flags": [], - "behavior_notes": null, - "breed": "Labrador", - "crate_trained": null, - "good_with_dogs": true, - "medical_notes": null, - "name": "Biscuit", - "vaccinated_self_reported": true - } - ], - "interested_services": [ - "bark-n-stroll" - ] - }, - "customer": { - "email": "ada@example.com", - "name": "Ada Lovelace", - "phone": "(619) 555-0123" - }, - "idempotency_key": "replace-this-with-a-fresh-random-key-0000", - "items": [ - { - "slug": "meet-greet" - } - ], - "start": "2026-10-15T10:00:00-07:00" - } -]New value: +[ + { + "agent": { + "name": "Your agent name" + }, + "answers": { + "address": "123 Main St, Poway, CA 92064", + "behavior": { + "disclosed": true, + "has_concerns": false + }, + "claims_prior_meet_greet": false, + "dogs": [ + { + "age_text": "3 years", + "behavior_flags": [], + "behavior_notes": null, + "breed": "Labrador", + "crate_trained": null, + "good_with_dogs": true, + "medical_notes": null, + "name": "Biscuit", + "vaccinated_self_reported": true + } + ], + "interested_services": [ + "bark-n-stroll" + ] + }, + "customer": { + "email": "ada@example.com", + "name": "Ada Lovelace", + "phone": "(619) 555-0123" + }, + "idempotency_key": "replace-this-with-a-fresh-random-key-0000", + "items": [ + { + "slug": "meet-greet" + } + ], + "start": "2026-10-16T10:00:00-07:00" + } +]
- Changed
find_times1 field changed- changed
Input schema / examplesPrevious value: -[ - { - "from": "2026-10-15", - "items": [ - { - "slug": "meet-greet" - } - ], - "to": "2026-10-21", - "windows": [ - { - "end": "2026-10-15T17:00:00-07:00", - "start": "2026-10-15T09:00:00-07:00" - } - ] - } -]New value: +[ + { + "from": "2026-10-16", + "items": [ + { + "slug": "meet-greet" + } + ], + "to": "2026-10-22", + "windows": [ + { + "end": "2026-10-16T17:00:00-07:00", + "start": "2026-10-16T09:00:00-07:00" + } + ] + } +]
2 tool updates
- Changed
book1 field changed- changed
Input schema / examplesPrevious value: -[ - { - "agent": { - "name": "Your agent name" - }, - "answers": { - "address": "123 Main St, Poway, CA 92064", - "behavior": { - "disclosed": true, - "has_concerns": false - }, - "claims_prior_meet_greet": false, - "dogs": [ - { - "age_text": "3 years", - "behavior_flags": [], - "behavior_notes": null, - "breed": "Labrador", - "crate_trained": null, - "good_with_dogs": true, - "medical_notes": null, - "name": "Biscuit", - "vaccinated_self_reported": true - } - ], - "interested_services": [ - "bark-n-stroll" - ] - }, - "customer": { - "email": "ada@example.com", - "name": "Ada Lovelace", - "phone": "(619) 555-0123" - }, - "idempotency_key": "replace-this-with-a-fresh-random-key-0000", - "items": [ - { - "slug": "meet-greet" - } - ], - "start": "2026-10-14T10:00:00-07:00" - } -]New value: +[ + { + "agent": { + "name": "Your agent name" + }, + "answers": { + "address": "123 Main St, Poway, CA 92064", + "behavior": { + "disclosed": true, + "has_concerns": false + }, + "claims_prior_meet_greet": false, + "dogs": [ + { + "age_text": "3 years", + "behavior_flags": [], + "behavior_notes": null, + "breed": "Labrador", + "crate_trained": null, + "good_with_dogs": true, + "medical_notes": null, + "name": "Biscuit", + "vaccinated_self_reported": true + } + ], + "interested_services": [ + "bark-n-stroll" + ] + }, + "customer": { + "email": "ada@example.com", + "name": "Ada Lovelace", + "phone": "(619) 555-0123" + }, + "idempotency_key": "replace-this-with-a-fresh-random-key-0000", + "items": [ + { + "slug": "meet-greet" + } + ], + "start": "2026-10-15T10:00:00-07:00" + } +]
- Changed
find_times1 field changed- changed
Input schema / examplesPrevious value: -[ - { - "from": "2026-10-14", - "items": [ - { - "slug": "meet-greet" - } - ], - "to": "2026-10-20", - "windows": [ - { - "end": "2026-10-14T17:00:00-07:00", - "start": "2026-10-14T09:00:00-07:00" - } - ] - } -]New value: +[ + { + "from": "2026-10-15", + "items": [ + { + "slug": "meet-greet" + } + ], + "to": "2026-10-21", + "windows": [ + { + "end": "2026-10-15T17:00:00-07:00", + "start": "2026-10-15T09:00:00-07:00" + } + ] + } +]
2 tool updates
- Changed
book1 field changed- changed
Input schema / examplesPrevious value: -[ - { - "agent": { - "name": "Your agent name" - }, - "answers": { - "address": "123 Main St, Poway, CA 92064", - "behavior": { - "disclosed": true, - "has_concerns": false - }, - "claims_prior_meet_greet": false, - "dogs": [ - { - "age_text": "3 years", - "behavior_flags": [], - "behavior_notes": null, - "breed": "Labrador", - "crate_trained": null, - "good_with_dogs": true, - "medical_notes": null, - "name": "Biscuit", - "vaccinated_self_reported": true - } - ], - "interested_services": [ - "bark-n-stroll" - ] - }, - "customer": { - "email": "ada@example.com", - "name": "Ada Lovelace", - "phone": "(619) 555-0123" - }, - "idempotency_key": "replace-this-with-a-fresh-random-key-0000", - "items": [ - { - "slug": "meet-greet" - } - ], - "start": "2026-10-13T10:00:00-07:00" - } -]New value: +[ + { + "agent": { + "name": "Your agent name" + }, + "answers": { + "address": "123 Main St, Poway, CA 92064", + "behavior": { + "disclosed": true, + "has_concerns": false + }, + "claims_prior_meet_greet": false, + "dogs": [ + { + "age_text": "3 years", + "behavior_flags": [], + "behavior_notes": null, + "breed": "Labrador", + "crate_trained": null, + "good_with_dogs": true, + "medical_notes": null, + "name": "Biscuit", + "vaccinated_self_reported": true + } + ], + "interested_services": [ + "bark-n-stroll" + ] + }, + "customer": { + "email": "ada@example.com", + "name": "Ada Lovelace", + "phone": "(619) 555-0123" + }, + "idempotency_key": "replace-this-with-a-fresh-random-key-0000", + "items": [ + { + "slug": "meet-greet" + } + ], + "start": "2026-10-14T10:00:00-07:00" + } +]
- Changed
find_times1 field changed- changed
Input schema / examplesPrevious value: -[ - { - "from": "2026-10-13", - "items": [ - { - "slug": "meet-greet" - } - ], - "to": "2026-10-19", - "windows": [ - { - "end": "2026-10-13T17:00:00-07:00", - "start": "2026-10-13T09:00:00-07:00" - } - ] - } -]New value: +[ + { + "from": "2026-10-14", + "items": [ + { + "slug": "meet-greet" + } + ], + "to": "2026-10-20", + "windows": [ + { + "end": "2026-10-14T17:00:00-07:00", + "start": "2026-10-14T09:00:00-07:00" + } + ] + } +]
2 tool updates
- Changed
book1 field changed- changed
Input schema / examplesPrevious value: -[ - { - "agent": { - "name": "Your agent name" - }, - "answers": { - "address": "123 Main St, Poway, CA 92064", - "behavior": { - "disclosed": true, - "has_concerns": false - }, - "claims_prior_meet_greet": false, - "dogs": [ - { - "age_text": "3 years", - "behavior_flags": [], - "behavior_notes": null, - "breed": "Labrador", - "crate_trained": null, - "good_with_dogs": true, - "medical_notes": null, - "name": "Biscuit", - "vaccinated_self_reported": true - } - ], - "interested_services": [ - "bark-n-stroll" - ] - }, - "customer": { - "email": "ada@example.com", - "name": "Ada Lovelace", - "phone": "(619) 555-0123" - }, - "idempotency_key": "replace-this-with-a-fresh-random-key-0000", - "items": [ - { - "slug": "meet-greet" - } - ], - "start": "2026-10-12T10:00:00-07:00" - } -]New value: +[ + { + "agent": { + "name": "Your agent name" + }, + "answers": { + "address": "123 Main St, Poway, CA 92064", + "behavior": { + "disclosed": true, + "has_concerns": false + }, + "claims_prior_meet_greet": false, + "dogs": [ + { + "age_text": "3 years", + "behavior_flags": [], + "behavior_notes": null, + "breed": "Labrador", + "crate_trained": null, + "good_with_dogs": true, + "medical_notes": null, + "name": "Biscuit", + "vaccinated_self_reported": true + } + ], + "interested_services": [ + "bark-n-stroll" + ] + }, + "customer": { + "email": "ada@example.com", + "name": "Ada Lovelace", + "phone": "(619) 555-0123" + }, + "idempotency_key": "replace-this-with-a-fresh-random-key-0000", + "items": [ + { + "slug": "meet-greet" + } + ], + "start": "2026-10-13T10:00:00-07:00" + } +]
- Changed
find_times1 field changed- changed
Input schema / examplesPrevious value: -[ - { - "from": "2026-10-12", - "items": [ - { - "slug": "meet-greet" - } - ], - "to": "2026-10-18", - "windows": [ - { - "end": "2026-10-12T17:00:00-07:00", - "start": "2026-10-12T09:00:00-07:00" - } - ] - } -]New value: +[ + { + "from": "2026-10-13", + "items": [ + { + "slug": "meet-greet" + } + ], + "to": "2026-10-19", + "windows": [ + { + "end": "2026-10-13T17:00:00-07:00", + "start": "2026-10-13T09:00:00-07:00" + } + ] + } +]
2 tool updates
- Changed
book1 field changed- changed
Input schema / examplesPrevious value: -[ - { - "agent": { - "name": "Your agent name" - }, - "answers": { - "address": "123 Main St, Poway, CA 92064", - "behavior": { - "disclosed": true, - "has_concerns": false - }, - "claims_prior_meet_greet": false, - "dogs": [ - { - "age_text": "3 years", - "behavior_flags": [], - "behavior_notes": null, - "breed": "Labrador", - "crate_trained": null, - "good_with_dogs": true, - "medical_notes": null, - "name": "Biscuit", - "vaccinated_self_reported": true - } - ], - "interested_services": [ - "bark-n-stroll" - ] - }, - "customer": { - "email": "ada@example.com", - "name": "Ada Lovelace", - "phone": "(619) 555-0123" - }, - "idempotency_key": "replace-this-with-a-fresh-random-key-0000", - "items": [ - { - "slug": "meet-greet" - } - ], - "start": "2026-10-11T10:00:00-07:00" - } -]New value: +[ + { + "agent": { + "name": "Your agent name" + }, + "answers": { + "address": "123 Main St, Poway, CA 92064", + "behavior": { + "disclosed": true, + "has_concerns": false + }, + "claims_prior_meet_greet": false, + "dogs": [ + { + "age_text": "3 years", + "behavior_flags": [], + "behavior_notes": null, + "breed": "Labrador", + "crate_trained": null, + "good_with_dogs": true, + "medical_notes": null, + "name": "Biscuit", + "vaccinated_self_reported": true + } + ], + "interested_services": [ + "bark-n-stroll" + ] + }, + "customer": { + "email": "ada@example.com", + "name": "Ada Lovelace", + "phone": "(619) 555-0123" + }, + "idempotency_key": "replace-this-with-a-fresh-random-key-0000", + "items": [ + { + "slug": "meet-greet" + } + ], + "start": "2026-10-12T10:00:00-07:00" + } +]
- Changed
find_times1 field changed- changed
Input schema / examplesPrevious value: -[ - { - "from": "2026-10-11", - "items": [ - { - "slug": "meet-greet" - } - ], - "to": "2026-10-17", - "windows": [ - { - "end": "2026-10-11T17:00:00-07:00", - "start": "2026-10-11T09:00:00-07:00" - } - ] - } -]New value: +[ + { + "from": "2026-10-12", + "items": [ + { + "slug": "meet-greet" + } + ], + "to": "2026-10-18", + "windows": [ + { + "end": "2026-10-12T17:00:00-07:00", + "start": "2026-10-12T09:00:00-07:00" + } + ] + } +]
2 tool updates
- Changed
book1 field changed- changed
Input schema / examplesPrevious value: -[ - { - "agent": { - "name": "Your agent name" - }, - "answers": { - "address": "123 Main St, Poway, CA 92064", - "behavior": { - "disclosed": true, - "has_concerns": false - }, - "claims_prior_meet_greet": false, - "dogs": [ - { - "age_text": "3 years", - "behavior_flags": [], - "behavior_notes": null, - "breed": "Labrador", - "crate_trained": null, - "good_with_dogs": true, - "medical_notes": null, - "name": "Biscuit", - "vaccinated_self_reported": true - } - ], - "interested_services": [ - "bark-n-stroll" - ] - }, - "customer": { - "email": "ada@example.com", - "name": "Ada Lovelace", - "phone": "(619) 555-0123" - }, - "idempotency_key": "replace-this-with-a-fresh-random-key-0000", - "items": [ - { - "slug": "meet-greet" - } - ], - "start": "2026-10-10T10:00:00-07:00" - } -]New value: +[ + { + "agent": { + "name": "Your agent name" + }, + "answers": { + "address": "123 Main St, Poway, CA 92064", + "behavior": { + "disclosed": true, + "has_concerns": false + }, + "claims_prior_meet_greet": false, + "dogs": [ + { + "age_text": "3 years", + "behavior_flags": [], + "behavior_notes": null, + "breed": "Labrador", + "crate_trained": null, + "good_with_dogs": true, + "medical_notes": null, + "name": "Biscuit", + "vaccinated_self_reported": true + } + ], + "interested_services": [ + "bark-n-stroll" + ] + }, + "customer": { + "email": "ada@example.com", + "name": "Ada Lovelace", + "phone": "(619) 555-0123" + }, + "idempotency_key": "replace-this-with-a-fresh-random-key-0000", + "items": [ + { + "slug": "meet-greet" + } + ], + "start": "2026-10-11T10:00:00-07:00" + } +]
- Changed
find_times1 field changed- changed
Input schema / examplesPrevious value: -[ - { - "from": "2026-10-10", - "items": [ - { - "slug": "meet-greet" - } - ], - "to": "2026-10-16", - "windows": [ - { - "end": "2026-10-10T17:00:00-07:00", - "start": "2026-10-10T09:00:00-07:00" - } - ] - } -]New value: +[ + { + "from": "2026-10-11", + "items": [ + { + "slug": "meet-greet" + } + ], + "to": "2026-10-17", + "windows": [ + { + "end": "2026-10-11T17:00:00-07:00", + "start": "2026-10-11T09:00:00-07:00" + } + ] + } +]
2 tool updates
- Changed
book1 field changed- changed
Input schema / examplesPrevious value: -[ - { - "agent": { - "name": "Your agent name" - }, - "answers": { - "address": "123 Main St, Poway, CA 92064", - "behavior": { - "disclosed": true, - "has_concerns": false - }, - "claims_prior_meet_greet": false, - "dogs": [ - { - "age_text": "3 years", - "behavior_flags": [], - "behavior_notes": null, - "breed": "Labrador", - "crate_trained": null, - "good_with_dogs": true, - "medical_notes": null, - "name": "Biscuit", - "vaccinated_self_reported": true - } - ], - "interested_services": [ - "bark-n-stroll" - ] - }, - "customer": { - "email": "ada@example.com", - "name": "Ada Lovelace", - "phone": "(619) 555-0123" - }, - "idempotency_key": "replace-this-with-a-fresh-random-key-0000", - "items": [ - { - "slug": "meet-greet" - } - ], - "start": "2026-10-09T10:00:00-07:00" - } -]New value: +[ + { + "agent": { + "name": "Your agent name" + }, + "answers": { + "address": "123 Main St, Poway, CA 92064", + "behavior": { + "disclosed": true, + "has_concerns": false + }, + "claims_prior_meet_greet": false, + "dogs": [ + { + "age_text": "3 years", + "behavior_flags": [], + "behavior_notes": null, + "breed": "Labrador", + "crate_trained": null, + "good_with_dogs": true, + "medical_notes": null, + "name": "Biscuit", + "vaccinated_self_reported": true + } + ], + "interested_services": [ + "bark-n-stroll" + ] + }, + "customer": { + "email": "ada@example.com", + "name": "Ada Lovelace", + "phone": "(619) 555-0123" + }, + "idempotency_key": "replace-this-with-a-fresh-random-key-0000", + "items": [ + { + "slug": "meet-greet" + } + ], + "start": "2026-10-10T10:00:00-07:00" + } +]
- Changed
find_times1 field changed- changed
Input schema / examplesPrevious value: -[ - { - "from": "2026-10-09", - "items": [ - { - "slug": "meet-greet" - } - ], - "to": "2026-10-15", - "windows": [ - { - "end": "2026-10-09T17:00:00-07:00", - "start": "2026-10-09T09:00:00-07:00" - } - ] - } -]New value: +[ + { + "from": "2026-10-10", + "items": [ + { + "slug": "meet-greet" + } + ], + "to": "2026-10-16", + "windows": [ + { + "end": "2026-10-10T17:00:00-07:00", + "start": "2026-10-10T09:00:00-07:00" + } + ] + } +]
6 tool updates
- First observed
book - First observed
cancel_booking - First observed
check_address - First observed
find_times - First observed
get_booking - First observed
get_business
Related MCP Connectors
Book with Enhanced Intelligence LLC: services, prices and open times. No key needed.
Book with ES Luxury Auto Detailing: services, prices and open times. No key needed.
Free scheduling your agent can book through: live availability, booking, verification, cancel.
Find, compare, and book local service businesses: live availability, prices, reviews, booking.
Related MCP Servers
- AlicenseBqualityBmaintenanceHire specialists by the hour — search, schedule, and pay via MCP protocol.352MIT
- AlicenseAqualityDmaintenanceEnables AI assistants to search for pet sitters, manage bookings, and handle pet profiles through the Rover pet services marketplace. It facilitates direct communication with sitters and service management using Playwright-based browser automation.139 npm2MIT
- AlicenseNot gradedqualityBmaintenanceEnables voice assistants to find nearby service providers, connect users to live video representatives for natural conversation, and handle appointment booking. It also returns confirmed bookings so the assistant can add them to its calendar.MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.