Andrii Co. Notary & Apostille Assistant

request_price_match

Request a price-match review of a competitor's WRITTEN quote from a comparable licensed notary — it never sets our price automatically. Use when the customer found a cheaper offer. Requires: competitor_name, competitor_price_usd, service (e.g. office, mobile, apostille), name, and an email or phone. Returns a logged reference and, where computable, our comparable quote; the notary decides within one business day. Fails if the name or a valid contact is missing.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	The customer's name.
`email`	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.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes
`status`	No	Account tools: the booking's status after this call (Pending after book_appointment).
`message`	Yes	Customer-facing outcome; relay it as written — bookings are requests until the notary confirms.
`manageUrl`	No	Guest requests: the emailed confirm/cancel link, when one was minted (null otherwise).
`onAccount`	No	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.
`reference`	No	Request / order reference for check_request_status (guest tools) or my_bookings (account tools).
`appendedToExisting`	No	True when existing_reference was given and the request was extended, not duplicated.
`ourComparableQuoteCents`	No	request_price_match only, when computable.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 6, 2026

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"
+}

First observedJul 21, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description reveals that the notary decides within one business day, that the tool does not automatically set prices, that it returns a logged reference and a comparable quote when computable, and that it fails without a name or valid contact. This is substantial behavioral context beyond the annotations, with no contradiction.

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?

Three dense sentences with no filler; the core purpose and the most important caveat are front-loaded. Every sentence contributes actionable operational information.

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 full schema coverage and an output schema present, the description adds exactly what is missing: when to use it, what happens after invocation, the human-decision timing, and failure conditions. An agent has enough to select, invoke, and set expectations 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 schema already documents all parameters. The description adds meaningful constraints: the email-or-phone requirement, service examples, and the failure condition when contact info is missing, which enriches rather than merely repeats the schema.

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?

Description names a specific action (request a price-match review), a specific target (a competitor's written quote from a comparable licensed notary), and a key scoping caveat: it never sets the price automatically. This distinguishes it from quote and booking siblings even without naming them.

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?

"Use when the customer found a cheaper offer" gives a direct trigger, and the written-quote/comparable-notary qualifiers narrow applicability. It does not explicitly say when not to use it or name sibling alternatives, but the context is clear enough.

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 tools Inspect

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

Need Help?