Cross-references internal Firestore unit listings and securely saves digital signature PNGs to Firebase Storage for parcel management.
Processes incoming parcel label scans using Google Cloud Vision OCR to extract and parse label text.
Schedules and sends automated email alerts for incoming parcels via SendGrid.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Trackkr MCP Server Log an Amazon package for unit 4B and notify the resident."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server that enables AI agents to autonomously manage incoming packages, log parcels, cross-reference unit directories, and track pick-up signatures without physical locker hardware.
Website: https://trackkr.app
Repository: https://github.com/DTLA-Professional-Services-LLC/trackkr-mcp
License: MIT
get_pending_parcels: Fetches the current ledger of uncollected packages, highlights aging stats (5+ days), and returns structured JSON context.
log_incoming_parcel: Accepts parsed text from Google Cloud Vision OCR label scans, cross-references internal Firestore unit listings, and schedules automated email alerts via SendGrid.
release_parcel_with_signature: Updates parcel state to Picked Up, records the timestamp, and securely saves the digital signature PNG layout to Firebase Storage.
Related MCP server: Property MCP Server
Variable | Required | Description |
| Yes | Path to your authorized Firebase service account credentials (or stringified JSON). |
| No | Set to |
npxFIREBASE_CONFIG_JSON="./service-account.json" \
USE_MOCK_OCR="true" \
npx -y github:DTLA-Professional-Services-LLC/trackkr-mcpclaude_desktop_config.json{
"mcpServers": {
"trackkr-mcp": {
"command": "npx",
"args": ["-y", "github:DTLA-Professional-Services-LLC/trackkr-mcp"],
"env": {
"FIREBASE_CONFIG_JSON": "/path/to/service-account.json",
"USE_MOCK_OCR": "true"
}
}
}
}Fetches the current ledger of uncollected packages, highlights aging stats (5+ days), enriches each with occupant contact preferences and notification/telemetry history, and returns structured JSON context.
| Name | Required | Description | Default |
|---|---|---|---|
| businessId | No | Optional tenant businessId filter. When provided, scans only that property. | |
| maxResults | No | Maximum number of pending parcels to return (1-500, default 200). | |
| emitTelemetry | No | When true, emits a STALE_3_DAYS event to parcel_telemetry for newly stale parcels. | |
| thresholdDays | No | Minimum age in days for a Pending parcel to be highlighted in the aging report (1-365, default 5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add useful behavior: aging highlighting at a threshold, enrichment with occupant contact preferences and notification/telemetry history, and a structured JSON return. However, it omits a notable side effect — emitTelemetry defaults to true and writes STALE_3_DAYS events to parcel_telemetry — as well as any permission or volume considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the core action and then the enrichments. Every clause carries information, though the sentence is long enough that the aging/enrichment clauses run together.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless-required read tool with a fully documented schema and no output schema, the description is nearly sufficient: it names the source data, the aging logic, the enrichment, and the return format. Only the telemetry side effect and the meaning of the return payload's structure are left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the four parameters are already fully documented and the baseline is 3. The description's '(5+ days)' loosely corroborates the thresholdDays default and 'notification/telemetry history' hints at emitTelemetry, but adds no syntax, units, or interaction detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb (fetches) and resource (ledger of uncollected packages) plus the transformations applied (aging highlights, enrichment). It does not explicitly contrast with log_incoming_parcel or release_parcel_with_signature, but the read-only listing nature is unambiguous, so an agent can place it without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no exclusions, and no mention of the sibling tools that write parcels. The operational scenario is only weakly implied by 'current ledger of uncollected packages', which falls short of the explicit routing the 4-5 band requires.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| qty | No | Number of parcels in this delivery (integer between 1 and 99). | |
| notes | No | Optional staff or carrier notes (maximum 1,999 characters). | |
| unitId | No | Optional explicit Firestore unit document ID under businesses/{businessId}/units/{unitId}. | |
| photoUrl | No | Public HTTPS Firebase Cloud Storage URL of the package photo. | |
| businessId | Yes | Tenant business identifier (must match the authenticated property businessId, 1-128 alphanumeric/dash/underscore chars). | |
| occupantId | No | Optional explicit occupant ID within the matched unit. | |
| rawOcrText | No | Raw OCR text extracted from a shipping label or envelope (up to 10,000 characters). | |
| typeOfMail | No | Package category: "letter" | "envelope" | "small box" | "big box" | "furniture/appliances" | "other". | small box |
| dateReceived | No | Optional ISO date received in YYYY-MM-DD format (defaults to current UTC date). | |
| timeReceived | No | Optional time received string (e.g. "2:30 PM", defaults to current UTC time). | |
| pickupMessage | No | Optional custom pickup location instruction included in the resident notification email (maximum 100 characters). | |
| trackingNumber | No | Optional explicit carrier tracking number (UPS 1Z..., Amazon TBA..., USPS, or FedEx). | |
| idempotencyMode | No | Behavior when the same (trackingNumber + unitId) was already logged within the last 4 hours ("merge" | "reject"). | merge |
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.
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.
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.
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.
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.
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.
Updates parcel state to Picked Up, records the pickup timestamp and recipient name, securely saves the digital signature PNG layout to Firebase Storage, and emits a PARCEL_RELEASED telemetry event.
| Name | Required | Description | Default |
|---|---|---|---|
| parcelId | Yes | Firestore parcel document ID under businesses/{businessId}/parcels/{parcelId}. | |
| businessId | Yes | Tenant business identifier owning the parcel (1-128 alphanumeric/dash/underscore chars). | |
| pickedUpBy | Yes | Full name of the resident or authorized person who signed for and collected the parcel (1-120 characters). | |
| datePickedUp | No | Optional pickup date in YYYY-MM-DD format (defaults to current UTC date). | |
| releaseNotes | No | Optional audit note recorded in PARCEL_RELEASED telemetry (maximum 500 characters). | |
| signatureUrl | No | Trusted HTTPS Firebase Cloud Storage URL of the captured recipient signature PNG. | |
| timePickedUp | No | Optional pickup time string (defaults to current UTC time). | |
| signatureBase64 | No | Base64-encoded PNG signature image (up to 2MB decoded). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose real side effects: a state mutation, timestamp/recipient recording, Firebase Storage persistence, and a telemetry event. It omits, however, idempotency/re-release behavior, permission requirements, and whether an existing signature is overwritten.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that leads with the primary state change and enumerates the side effects in sequence. It is slightly dense but every clause earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter mutation with no annotations and no output schema, the description covers the effects but not the operational details an agent needs: how signatureUrl and signatureBase64 relate, defaults for datePickedUp/timePickedUp, and failure/retry behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all eight parameters are already documented in the schema; baseline is 3. The description loosely maps to pickedUpBy, the timestamp fields, and the signature input but adds no format, default, or signatureUrl-vs-signatureBase64 relationship detail beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Updates... to Picked Up) plus the concrete side effects: recording timestamp/recipient, storing the signature PNG, and emitting PARCEL_RELEASED telemetry. The purpose is unambiguous, though it never names or contrasts with the siblings get_pending_parcels or log_incoming_parcel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no prerequisites (e.g. the parcel must already be logged via log_incoming_parcel), and no mention of alternatives. The 'state to Picked Up' phrasing hints at the terminal lifecycle step but leaves the agent to infer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.1.0get_pending_parcelslog_incoming_parcelrelease_parcel_with_signatureScored across 3 tools
Each tool targets a distinct parcel lifecycle stage: viewing pending parcels, logging incoming parcels, and releasing parcels with signature. There is no meaningful overlap in purpose or resource, so an agent can easily select the right tool.
All tool names use snake_case with a leading verb and a parcel-related noun (get_pending_parcels, log_incoming_parcel, release_parcel_with_signature). The pattern is predictable, and the third tool's modifier does not disrupt readability.
Three tools is lean but reasonable for a focused intake-to-release workflow. It is slightly under-scoped for a parcel-tracking domain that likely benefits from additional query and update operations.
The core lifecycle is covered: log incoming, list pending, and release with signature. However, there are notable gaps such as getting a parcel by ID, listing full history/all parcels, updating parcel details, canceling/deleting, and managing notifications or units.
AI open-house assistant for agents: sign-in kiosk + automated, consent-aware follow-ups.
Verified location-bound retail evidence for AI agents, delivered by human field workers.
Give AI agents secure access to your email via private aliases with dedicated mailbox storage.
Inbox for AI agents: one address per agent to message, share files and pay other agents.
