Skip to main content
Glama

Andrii Co. Notary & Apostille Assistant

by net.andrii
OverviewDiscussionsAdmin

book_appointment

Schedule an appointment tied to the signed-in customer's account — still a request until the notary confirms it, never guaranteed. PREFER this over request_booking whenever the customer is signed in: only a booking on their own account can later be listed, rescheduled or cancelled through this connector. Guests go through request_booking. Accepts: service (e.g. office, mobile, apostille, loan), scheduled_at — a slot's startUnix from search_availability, omitted for a call-me request — plus address for mobile, notes, document_count. Returns a Pending reference; fails if not signed in.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNoAnything else the notary should know.
addressNoMeeting address (required for "mobile"; omit for office/apostille).
serviceYesService: office | mobile | apostille | loan.
scheduled_atNoThe chosen slot's `startUnix` (from search_availability). Omit for a "call me to schedule" request (no time held).
document_countNoNumber of documents. Default 1.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
statusNoAccount tools: the booking's status after this call (Pending after book_appointment).
messageYesCustomer-facing outcome; relay it as written — bookings are requests until the notary confirms.
manageUrlNoGuest requests: the emailed confirm/cancel link, when one was minted (null otherwise).
onAccountNoTrue when the request was filed on the signed-in customer's own account — they can then list it with my_bookings and change it with reschedule_booking / cancel_booking. Absent or false means a guest request, managed through the emailed link.
referenceNoRequest / order reference for check_request_status (guest tools) or my_bookings (account tools).
appendedToExistingNoTrue when existing_reference was given and the request was extended, not duplicated.
ourComparableQuoteCentsNorequest_price_match only, when computable.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "appendedToExisting": {
+      "description": "True when existing_reference was given and the request was extended, not duplicated.",
+      "type": "boolean"
+    },
+    "manageUrl": {
+      "description": "Guest requests: the emailed confirm/cancel link, when one was minted (null otherwise).",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "message": {
+      "description": "Customer-facing outcome; relay it as written — bookings are requests until the notary confirms.",
+      "type": "string"
+    },
+    "ok": {
+      "const": true,
+      "type": "boolean"
+    },
+    "onAccount": {
+      "description": "True when the request was filed on the signed-in customer's own account — they can then list it with my_bookings and change it with reschedule_booking / cancel_booking. Absent or false means a guest request, managed through the emailed link.",
+      "type": "boolean"
+    },
+    "ourComparableQuoteCents": {
+      "description": "request_price_match only, when computable.",
+      "type": "integer"
+    },
+    "reference": {
+      "description": "Request / order reference for check_request_status (guest tools) or my_bookings (account tools).",
+      "type": "string"
+    },
+    "status": {
+      "description": "Account tools: the booking's status after this call (Pending after book_appointment).",
+      "type": "string"
+    }
+  },
+  "required": [
+    "ok",
+    "message"
+  ],
+  "type": "object"
+}
  2. First observed

TDQS

A4.2/5.0
Behavior3/5

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

The description adds important contextual info: appointments are requests pending notary confirmation, never guaranteed; returns a Pending reference; fails if not signed in. These are useful beyond the annotations, which already set readOnlyHint=false and destructiveHint=false. However, the description doesn't warn about potential side effects beyond creating a pending request, and doesn't explain what happens if confirmation fails or what 'fails if not signed in' entails (error type, partial state). No contradiction with annotations.

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?

The description is compact and front-loaded with the most important decision rule (prefer over request_booking when signed in), followed by parameter highlights and return/error behavior. Every sentence earns its place; no filler.

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?

Given the output schema exists and annotations declare openWorldHint=true, the description covers the key behavioral context: pending status, signed-in requirement, guest fallback, and parameter specifics. It could mention what happens on failure in more detail, but for selecting and invoking the tool correctly, it's nearly complete.

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%, so the schema already documents all parameters. The description adds usage nuance: scheduled_at should be 'a slot's startUnix from search_availability, omitted for a call-me request', and address is for mobile. This adds value, but it largely paraphrases the schema descriptions. Baseline 3 is appropriate.

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?

The description clearly states the action ('Schedule an appointment'), ties it to the signed-in customer's account, and differentiates it from request_booking. It also lists the key parameters (service, scheduled_at, address, notes, document_count) and the return type, making the tool's purpose unmistakable.

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?

The description explicitly instructs to prefer this tool over request_booking when the customer is signed in, and directs guests to request_booking. It also notes that only a booking on the customer's own account can later be listed, rescheduled, or cancelled, providing clear decision guidance.

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

All Andrii Co. Notary & Apostille Assistant toolsInspect
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.

Resources