Skip to main content
Glama

Andrii Co. Notary & Apostille Assistant

by net.andrii
OverviewDiscussionsAdmin

get_price_quote

Read-only

Calculate a server-authoritative USD price estimate before shipping — pure, no side effects, nothing booked. Use when the customer asks about cost. Accepts: document_count, mobile, after_hours, apostille plus tier (e.g. expedited, priority, standard, mailin); set needs_notarization false for already-certified records. Returns amountCents and line items; fails if apostille is true and tier is invalid (with apostille false, tier is ignored).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tierNoApostille tier when `apostille`: expedited | priority | standard | mailin.
mobileNoTrue if we travel to the customer (adds the flat travel fee).
apostilleNoTrue to include a Secretary-of-State apostille.
after_hoursNoMobile only: the chosen slot is after 6pm or on a weekend.
document_countNoNumber of documents (1–20). Default 1.
needs_notarizationNoSet false for a mail-in apostille of already-certified public records (birth/marriage/death certificates) that need no notarial act.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
currencyYes
lineItemsYes
amountCentsYes
howToProceedYes
prepaymentRequiredYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "amountCents": {
+      "type": "integer"
+    },
+    "currency": {
+      "type": "string"
+    },
+    "howToProceed": {
+      "type": "string"
+    },
+    "lineItems": {
+      "items": {
+        "properties": {
+          "amountCents": {
+            "type": "integer"
+          },
+          "label": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "label",
+          "amountCents"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "prepaymentRequired": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "currency",
+    "amountCents",
+    "lineItems",
+    "prepaymentRequired",
+    "howToProceed"
+  ],
+  "type": "object"
+}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description goes beyond the readOnlyHint and destructiveHint annotations by explicitly stating there are no side effects, nothing is booked, the estimate is server-authoritative, it returns amountCents and line items, and it fails under a specific invalid combination of apostille and tier. This is rich, 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences carry purpose, usage, parameter guidance, return behavior, and an edge case without wasted words. The most important safety information is front-loaded, and every sentence earns its place.

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 six optional parameters, a complete input schema, and an output schema available, the description covers all key decision points: when to call, what side effects to expect, key parameter interactions, and failure behavior. No critical context is missing for an agent to invoke this tool 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, but the description adds meaningful cross-parameter semantics: it explains the apostille/tier relationship, notes that tier is ignored when apostille is false, and ties needs_notarization=false to already-certified records. This goes beyond simply restating 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?

The description opens with a specific verb and resource: 'Calculate a server-authoritative USD price estimate before shipping.' It also clarifies this is not a booking ('pure, no side effects, nothing booked'), which distinguishes it clearly from sibling tools like book_appointment, request_booking, and request_price_match.

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?

It explicitly says 'Use when the customer asks about cost,' which gives a clear trigger condition. It does not name alternative tools or explain when not to use it, but the context—comparing against booking and request siblings—makes the intended usage reasonably clear.

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