Skip to main content
Glama
DTLA-Professional-Services-LLC

Trackkr MCP Server

by DTLA-Professional-Services-LLC
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

log_incoming_parcel

Logs incoming parcels from OCR text or Firebase photo URLs, matches them to listed units, prevents duplicate entries for 4 hours, and schedules resident email alerts.

Instructions

Accepts parsed text from Google Cloud Vision OCR label scans and/or a trusted Firebase Storage photoUrl, cross-references internal Firestore unit listings, enforces a 4-hour idempotent lock on (trackingNumber + unitId), and schedules automated email alerts via SendGrid.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qtyNoNumber of parcels in this delivery (integer between 1 and 99).
notesNoOptional staff or carrier notes (maximum 1,999 characters).
unitIdNoOptional explicit Firestore unit document ID under businesses/{businessId}/units/{unitId}.
photoUrlNoPublic HTTPS Firebase Cloud Storage URL of the package photo.
businessIdYesTenant business identifier (must match the authenticated property businessId, 1-128 alphanumeric/dash/underscore chars).
occupantIdNoOptional explicit occupant ID within the matched unit.
rawOcrTextNoRaw OCR text extracted from a shipping label or envelope (up to 10,000 characters).
typeOfMailNoPackage category: "letter" | "envelope" | "small box" | "big box" | "furniture/appliances" | "other".small box
dateReceivedNoOptional ISO date received in YYYY-MM-DD format (defaults to current UTC date).
timeReceivedNoOptional time received string (e.g. "2:30 PM", defaults to current UTC time).
pickupMessageNoOptional custom pickup location instruction included in the resident notification email (maximum 100 characters).
trackingNumberNoOptional explicit carrier tracking number (UPS 1Z..., Amazon TBA..., USPS, or FedEx).
idempotencyModeNoBehavior when the same (trackingNumber + unitId) was already logged within the last 4 hours ("merge" | "reject").merge

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.0

TDQS

B3.3/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it does deliver unusual value: it discloses the idempotent 4-hour lock keyed on (trackingNumber + unitId), the internal Firestore cross-reference, and the SendGrid email side effect. It omits auth/permission needs, error behavior, and what the caller receives back.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

A single run-on sentence packing four distinct behaviors into one clause chain. It is economical in length but poorly front-loaded and hard to parse; splitting the lock and notification behavior into separate sentences would aid scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter, no-annotation, no-output-schema mutation with external side effects, the description covers the pipeline and the idempotency mechanism but says nothing about return values, failure modes, or required authentication. Adequate but with clear gaps given the tool's complexity.

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 description coverage is 100%, so the schema already documents all 13 parameters including enums and defaults. The description adds only the composite lock key (trackingNumber + unitId), which links two fields meaningfully but does not explain the other eleven. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States the specific resource and action chain: accepts OCR text/photoUrl, cross-references Firestore units, logs the parcel with a lock and notification. Clear what it does, but it never distinguishes itself from siblings get_pending_parcels or release_parcel_with_signature, so an agent must infer the boundary from the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use, when-not-to-use, or alternative routing is given. With two siblings covering pending retrieval and release-with-signature, the description offers no help in deciding which to call for a given task. Usage is only implied by the verb.

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

Deploy Server

Other Tools