Skip to main content
Glama

Piloxa – Certified Mail

by com.piloxa
OverviewDiscussionsAdmin

Check what happened to a letter sent through Piloxa

get_certified_letter_status
Read-onlyIdempotent

Answers "has my letter arrived yet" for letters prepared through Piloxa IN THIS SAME CONVERSATION. Returns, for each one: who it went to, the service, the USPS tracking number once USPS has assigned one, whether USPS has accepted it, delivered it or returned it, and when each of those was recorded. Piloxa asks the print and mail provider for a fresh answer when this is called, so it is current rather than remembered. IMPORTANT AND DELIBERATE: it can only see letters this connector prepared in this conversation, because that is the only thing it can identify without a sign-in; it cannot reach a person’s other letters, letters sent from another conversation, or anybody else’s. For those, the person signs in at piloxa.com and opens the letter there. This tool is READ ONLY: it prepares nothing, mails nothing and charges nothing. A stage with no scan means no scan has been reported, which is not the same as a failed delivery — USPS sometimes records delivery late, or not at all.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
referenceNoOptional. The Piloxa reference from the letter’s email receipt, to ask about one letter instead of all of them. A reference from outside this conversation is not found, on purpose.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
foundYes
scopeYesAlways says that only this conversation’s letters are visible here.
mailedYesAlways false: this tool never mails.
chargedYesAlways false: this tool never charges.
lettersYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / letters / items / properties / service / enum
      Previous value: -[
-  "CERTIFIED",
-  "CERTIFIED_ERR",
-  "CERTIFIED_EVIDENCE"
-]New value: +[
+  "CERTIFIED",
+  "CERTIFIED_ERR",
+  "CERTIFIED_EVIDENCE",
+  "CERTIFIED_DEADLINE"
+]
  2. Changed1 schema field changed
    • changedOutput schema / properties / letters / items / properties / service / enum
      Previous value: -[
-  "CERTIFIED",
-  "CERTIFIED_ERR"
-]New value: +[
+  "CERTIFIED",
+  "CERTIFIED_ERR",
+  "CERTIFIED_EVIDENCE"
+]
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, but the description goes further: it explains the tool fetches a fresh answer from the provider, emphasizes it is READ ONLY, and clarifies that a missing scan does not imply failed delivery. This prevents misinterpretation beyond what annotations convey.

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?

The description is thorough and well-organized, front-loading the core purpose, then details, limitations, read-only nature, and scan interpretation. Every sentence adds value, though it is somewhat long; it remains efficient given the complexity.

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, the description need not enumerate return fields. It covers scope, freshness, data boundaries, read-only behavior, and a critical interpretation nuance (no scan ≠ failed delivery). No essential context is missing for an agent to invoke it correctly.

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?

The input schema already provides a full description of the optional reference parameter, achieving 100% schema coverage. The tool description does not add new information about the parameter, so the baseline of 3 applies; no deduction is needed.

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 the exact user question it answers ('has my letter arrived yet') and specifies the resource (letters prepared through Piloxa in this same conversation). It clearly distinguishes from sibling tools prepare_certified_letter and quote_certified_letter by focusing on status retrieval.

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?

Explicitly states the condition for use (letters prepared in this same conversation) and the exclusion (cannot see other letters, other conversations, or others' letters). It even offers the alternative of signing in at piloxa.com for those cases, leaving no ambiguity about when to use this tool.

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

All Piloxa – Certified Mail 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