booking
Server Details
Book a Washington notary or apostille appointment, get a quote, and track it, via AI assistant.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Score is being calculated. Check back soon.
Available Tools
14 toolsbook_appointmentInspect
Book a notary/apostille appointment for the signed-in customer, bound to their account. Call search_availability first and pass a slot's startUnix as scheduledAt (omit for a 'call me to schedule' request). Requires sign-in.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Anything else the notary should know. | |
| address | No | Meeting address (required for "mobile"; omit for office/apostille). | |
| service | Yes | Service: office | mobile | apostille | loan. | |
| scheduled_at | No | The chosen slot's `startUnix` (from search_availability). Omit for a "call me to schedule" request (no time held). | |
| document_count | No | Number of documents. Default 1. |
cancel_bookingDestructiveInspect
Cancel one of the signed-in customer's OWN Pending or Scheduled bookings. Requires sign-in.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The booking's order id (from my_bookings). |
check_request_statusRead-onlyInspect
Check the current status of a previously submitted request by its reference id — whether the notary confirmed/scheduled it (and for when, Pacific time), rescheduled, cancelled, or merged it with another request. No sign-in needed. Call this whenever the customer asks about their request's status or whether anything changed since it was submitted.
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | The reference id returned when the request was submitted (also accepts the token from the emailed confirm link). |
check_service_areaRead-onlyInspect
Check whether an address is inside Andrii Co.'s Washington service area, and get its resolved location + whether it's precise enough to book. Read-only; no booking.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Street address, city, or ZIP to check (Washington State service area). | |
| service | No | "notary" (default) or "apostille" — the service-area rules differ slightly. |
get_apostille_requirementsRead-onlyInspect
Check whether a document qualifies for an apostille and how — certified vital records can be apostilled as-is (mail-in), a private document (diploma/POA) needs a notarization first, federal documents go to the US Department of State. Includes the honest do-it-yourself path AND our offer. Pure, no side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| document | Yes | The document in plain words (e.g. "Washington birth certificate", "university diploma", "FBI background check", "power of attorney"). | |
| issuing_state | No | The US state that issued or notarized it (default Washington). | |
| destination_country | No | The country the apostilled document is for. |
get_price_quoteRead-onlyInspect
Get a server-authoritative USD price estimate (before shipping). Pure calculation, no side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Apostille tier when `apostille`: expedited | priority | standard | mailin. | |
| mobile | No | True if we travel to the customer (adds the flat travel fee). | |
| apostille | No | True to include a Secretary-of-State apostille. | |
| after_hours | No | Mobile only: the chosen slot is after 6pm or on a weekend. | |
| document_count | No | Number of documents (1–20). Default 1. | |
| needs_notarization | No | Set false for a mail-in apostille of already-certified public records (birth/marriage/death certificates) that need no notarial act. |
get_servicesRead-onlyInspect
The full service catalog (Washington State notary & apostille) with prices and the accepted payment options. Optional — the server instructions already summarize the flow; call this when the customer asks about services or payment methods.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
get_turnaround_estimateRead-onlyInspect
Estimate typical completion + shipping timing for a service (apostille processing days, mail-in and delivery legs). Ranges, not guarantees; no side effects. For an exact appointment time use search_availability.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Apostille speed tier when service is apostille: expedited | priority | standard. | |
| service | Yes | Service: notarization | apostille | apostille_mail | loan_signing. | |
| shipping | No | Delivery: pickup | us | ukraine | international. If omitted, inferred from destination_country (apostille legs default to US shipping). | |
| destination_country | No | Destination country (used to infer shipping when `shipping` is omitted). |
my_bookingsRead-onlyInspect
List the signed-in customer's OWN notary/apostille bookings (most recent first). Requires sign-in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
request_apostilleAInspect
Submit a mail-in apostille request (a lead). For already-certified Washington public records that need NO notarization (birth/marriage/death certificates). The notary follows up with where to mail the documents and a quote; nothing is charged until approved. Requires a name and either an email or a phone.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The customer's FULL LEGAL NAME exactly as on their government-issued ID (never a nickname) — apostille filings print it. | |
| No | Email. Collect BOTH an email AND a phone in one question when possible; at least one is required. | ||
| notes | No | Anything else the notary should know. | |
| phone | No | Phone with country code — the notary confirms fastest by phone/SMS. | |
| documents | Yes | What documents, in plain words (e.g. "2 birth certificates for Ukraine"). | |
| existing_reference | No | To ADD these documents to an EXISTING request instead of creating a second one, pass that request's reference id (with the same email/phone so we can verify the customer). Nothing new is created. | |
| destination_country | No | Destination country the apostilled documents are for. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it creates a lead, the notary follows up, and nothing is charged until approved. This aligns with readOnlyHint=false and openWorldHint=true, with no contradictions.
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 four sentences, front-loaded with the main action, then eligibility, then process, then requirements. Every sentence adds value with no excess.
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 7 parameters and no output schema, the description adequately covers eligibility, process, and key parameter nuances. It could mention expected response (e.g., lead ID) but is otherwise complete for a submission tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds critical usage guidance, such as 'FULL LEGAL NAME exactly as on government ID' for name and instructions to collect both email and phone for contact parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool submits a mail-in apostille request for already-certified Washington public records (birth/marriage/death certificates) that need no notarization, distinguishing it from sibling tools like get_apostille_requirements or get_price_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the appropriate documents (already-certified WA records) and that this is a lead with no upfront charge, providing clear context. However, it does not explicitly exclude use cases or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_bookingAInspect
Submit a booking request (a lead — NOT a confirmed appointment; the notary follows up to confirm). Requires the customer's FULL LEGAL NAME and an email or phone (collect both). Pass a chosen slot's startUnix as desired_time_unix (from search_availability). To modify/extend an existing request, pass existing_reference instead of creating a duplicate.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The customer's FULL LEGAL NAME exactly as on their government-issued ID (never a nickname or chat display name) — notarial records and apostille filings print it. Ask if you only know a first name. | |
| No | Email. Collect BOTH an email AND a phone in one question when possible; at least one is required. | ||
| notes | No | Anything else the notary should know. | |
| phone | No | Phone with country code (e.g. +1...). The notary confirms fastest by phone/SMS — ask for it even when an email is known. | |
| address | No | Meeting address — MOBILE ONLY. Office and apostille visits automatically use our Bothell office; omit this for them. | |
| service | Yes | Service: office | mobile | apostille | loan. | |
| desired_time | No | The wanted time in plain words, when no exact slot was chosen (rides the notes; the notary confirms a real time). | |
| document_count | No | Number of documents. Default 1. | |
| desired_time_unix | No | The chosen slot's `startUnix` from search_availability (Unix seconds). Pass it so the request carries the exact wanted time — still a request, never a hold. | |
| existing_reference | No | To ADD to or change an EXISTING request instead of creating a second one (e.g. "also apostille it", "make it 3 documents"), pass that request's reference id here — the same email/phone must be provided so we can verify it's the same customer. Nothing new is created. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states that the tool creates a lead, not a hold or a confirmed appointment, and that the notary follows up. It explains that using existing_reference does not create a new record. While annotations indicate readOnlyHint=false and destructiveHint=false, the description adds context about the non-destructive modification. However, it does not describe the return value or error behavior, which would be valuable.
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 a single, dense paragraph that conveys all key information without redundancy. It is front-loaded with the most important point (lead vs. confirmed). However, it could be slightly more structured (e.g., separate sentences for each capability) to improve scannability.
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 complexity (10 parameters, no output schema), the description covers the workflow effectively: lead creation, parameter dependencies (slot from search_availability), modification via existing_reference, and required customer details. It also addresses potential pitfalls (duplicate requests, missing contact info). The description is sufficiently complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds significant meaning beyond the schema. It explains the purpose of desired_time_unix (linking to search_availability), advises collecting both email and phone simultaneously, clarifies that address is only for mobile services, and details how existing_reference works. These details help the agent use parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool submits a booking request, explicitly distinguishes it from a confirmed appointment ('NOT a confirmed appointment; the notary follows up to confirm'), and specifies the required resources ('customer's FULL LEGAL NAME and an email or phone'). This effectively differentiates it from sibling tools like 'book_appointment'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool (for leads, not confirmed bookings), what inputs are required (full legal name, email/phone), how to pass a chosen slot (desired_time_unix from search_availability), and how to modify an existing request (existing_reference). It also advises to collect both email and phone together, which is practical and clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_price_matchAInspect
Ask us to consider matching a comparable licensed notary's WRITTEN quote. This is a request the notary reviews — it never sets a price automatically. We reply with our own comparable quote and a match decision within one business day. Requires a name and either an email or a phone.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The customer's name. | |
| No | Email — provide an email OR a phone so we can reach them. | ||
| notes | No | Anything else the notary should know. | |
| phone | No | Phone — provide an email OR a phone so we can reach them. | |
| service | Yes | Service: office | mobile | apostille | apostille_mail | loan. | |
| competitor_url | No | Link to the competitor's quote/page, if any (stored for the operator, never fetched). | |
| document_count | No | Number of documents, for our comparison quote. Default 1. | |
| competitor_name | Yes | The competitor's business name. | |
| competitor_price_usd | Yes | The competitor's quoted price, in US dollars. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses that the tool never sets prices automatically and is reviewed by a human, which is critical behavioral info beyond annotations. Annotations indicate readOnlyHint=false (may write) and openWorldHint=true (unexpected effects possible), and description aligns without contradiction.
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, front-loaded with purpose, then key behavioral notes, timing, and requirements. No superfluous words; every sentence adds value.
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 complexity (9 parameters, no output schema), description covers purpose, behavior, timing, and a key requirement. Could be slightly improved by mentioning what the response contains (already hinted), but overall comprehensive.
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 100% with descriptions for all 9 parameters. Description reinforces the requirement for name and either email/phone, but adds limited new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: requesting a price match against a competitor's written quote. It distinguishes from sibling tools like 'get_price_quote' which provide standard quotes, and 'request_booking' which schedules appointments.
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 clear context: it's a manual request reviewed by a notary, with a specific turnaround time. Implicitly indicates when to use (price matching) vs. siblings (getting quotes, booking), but lacks explicit when-not-to-use or alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reschedule_bookingIdempotentInspect
Reschedule one of the signed-in customer's OWN bookings to a new slot's startUnix (strict — the new time must be genuinely available). Requires sign-in.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The booking's order id (from my_bookings). | |
| scheduled_at | Yes | The new slot's `startUnix` (from search_availability). |
search_availabilityRead-onlyInspect
Find open notary/apostille appointment slots — this also validates the service area for the given address. Returns the resolved location, up to 7 recommended slots (each with startUnix), and per-day booking windows: the k-th bookable start is startUnixFrom + k*stepSec for k < startCount. Pass the chosen start's Unix seconds to request_booking as desired_time_unix. "mobile" needs an address; "office"/"apostille" use our office.
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | The address to meet at — required for "mobile"; ignored for "office". | |
| service | Yes | "office" (at our office), "mobile" (we come to you), or "apostille". | |
| document_count | No | Number of documents (drives the appointment length). Default 1. |
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!