Skip to main content
Glama

Andrii Co. Notary & Apostille Assistant

get_turnaround_estimate

Read-only

Calculate typical turnaround — apostille processing days plus mailing and delivery legs. Ranges, never guarantees; exact appointment times come from search_availability. Use when the customer asks how long. Accepts: service (e.g. notarization, apostille, apostille_mail, loan_signing), optional tier, shipping, destination_country, ua_lane (withinUkraine | fromUsa — the Ukraine lane when shipping is omitted). Returns staged day estimates; an unknown tier falls back to the standard figure, not an error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tierNoApostille speed tier when service is apostille: expedited | priority | standard.
serviceYesService: notarization | apostille | apostille_mail | loan_signing.
ua_laneNoUkraine delivery lane: withinUkraine (weekly batch, 7–14 days) or fromUsa (direct from the USA, 7–10 days). Fills `shipping` when that is omitted; an explicit `shipping` always wins.
shippingNoDelivery: pickup | us | ukraine | ukraine_direct | international. If omitted, inferred from destination_country (apostille legs default to US shipping) or from `ua_lane` (fromUsa ⇒ ukraine_direct).
destination_countryNoDestination country (used to infer shipping when `shipping` is omitted).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
tierNo
stagesYes
serviceYes
disclaimerYes
howToProceedNo
typicalTotalDaysLowYes
typicalTotalDaysHighYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / shipping / description
      Previous value: -"Delivery: pickup | us | ukraine | international. If omitted, inferred from\ndestination_country (apostille legs default to US shipping)."New value: +"Delivery: pickup | us | ukraine | ukraine_direct | international. If\nomitted, inferred from destination_country (apostille legs default to\nUS shipping) or from `ua_lane` (fromUsa ⇒ ukraine_direct)."
    • addedInput schema / properties / ua_lane
      Added value: +{
      +  "default": null,
      +  "description": "Ukraine delivery lane: withinUkraine (weekly batch, 7–14 days) or\nfromUsa (direct from the USA, 7–10 days). Fills `shipping` when that\nis omitted; an explicit `shipping` always wins.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "description": "Staged day estimates — ranges, never guarantees.",
      +  "properties": {
      +    "disclaimer": {
      +      "type": "string"
      +    },
      +    "howToProceed": {
      +      "type": "string"
      +    },
      +    "service": {
      +      "type": "string"
      +    },
      +    "stages": {
      +      "items": {
      +        "properties": {
      +          "businessDays": {
      +            "type": "integer"
      +          },
      +          "calendarDaysHigh": {
      +            "type": "integer"
      +          },
      +          "calendarDaysLow": {
      +            "type": "integer"
      +          },
      +          "note": {
      +            "type": "string"
      +          },
      +          "stage": {
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "stage"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "tier": {
      +      "type": "string"
      +    },
      +    "typicalTotalDaysHigh": {
      +      "type": "integer"
      +    },
      +    "typicalTotalDaysLow": {
      +      "type": "integer"
      +    }
      +  },
      +  "required": [
      +    "service",
      +    "stages",
      +    "typicalTotalDaysLow",
      +    "typicalTotalDaysHigh",
      +    "disclaimer"
      +  ],
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior: results are ranges and never guarantees, and an unknown `tier` silently falls back to the standard figure rather than erroring — a non-obvious failure mode an agent would otherwise mis-handle.

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 core purpose before the alternative and the parameter recap. The single dense paragraph packs a lot in but every clause carries operational content; it is slightly over-stuffed rather than wasteful.

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 an output schema present, return shape need not be explained, yet the description still notes 'staged day estimates' and the fallback semantics. Combined with explicit alternatives and the range-not-guarantee caveat, an agent has everything needed to call and interpret this read-only estimate tool.

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 description coverage is 100%, so the baseline is 3; the description still adds value by giving concrete `service` examples (notarization, apostille, apostille_mail, loan_signing) and restating that `ua_lane` supplies the Ukraine lane when `shipping` is omitted, plus the unknown-tier fallback. It stops short of documenting destination_country inference beyond a pointer.

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+resource (calculate turnaround) and immediately defines what the estimate comprises: apostille processing days plus mailing and delivery legs. It also separates itself from the sibling search_availability, so an agent can distinguish estimate vs. exact availability 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?

'Use when the customer asks how long' gives an explicit trigger, and 'exact appointment times come from search_availability' names the alternative and the condition that routes to it. The boundary between this tool and the availability lookup is unambiguous.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources