Track parcels with TrackingMore: detect couriers, create and read trackings, delivery status.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 7 tools
Each tool targets a distinct resource+action: create/delete/get/update/list trackings plus detect_courier and list_couriers. The pairs get_tracking vs list_trackings and detect_courier vs list_couriers are clearly delineated by name and description.
All names follow a consistent trackingmore_verb_noun pattern (create_tracking, delete_tracking, get_tracking, list_trackings, update_tracking, detect_courier, list_couriers). No style mixing.
Seven tools is well-scoped for a shipment-tracking domain, covering the full lifecycle plus courier lookup without redundancy. Each tool earns its place.
Full CRUD is present (create/delete/get/list/update) plus courier detection and listing to support courier_code resolution. No obvious gaps; the deliberate lack of bulk create is documented rather than missing.
WRITE: register ONE shipment so TrackingMore starts tracking it. This uses one credit of the account's plan (credits beyond the plan are billed by TrackingMore as overage): confirm with the user before creating, and never create trackings in bulk. Fails with 'Tracking No. already exists' if it is already registered. Needs the tracking number and the courier code (use trackingmore_detect_courier if unknown). Some couriers need extra fields (postal code, ship date, key). Returns the new tracking with its id. POST /trackings/create.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Free-text note. | |
| label | No | Label to group shipments. It must be a label you created in the TrackingMore dashboard first, otherwise TrackingMore refuses it (meta 4131). | |
| title | No | Short title for the shipment. | |
| language | No | Language code for status text, e.g. en. | |
| order_id | No | Your order id in the shop system. | |
| order_date | No | Order date, e.g. 2026-10-01T10:00:00+00:00. | |
| courier_code | Yes | TrackingMore courier code, e.g. usps, ups, dhl (see trackingmore_list_couriers / trackingmore_detect_courier). | |
| customer_sms | No | Recipient mobile number, with country code. | |
| order_number | No | Your order number for this shipment. | |
| tracking_key | No | Tracking key / phone suffix (needed by some couriers). | |
| customer_name | No | Recipient name. | |
| customer_email | No | Recipient email (TrackingMore can send delivery notifications to it when enabled in the account). | |
| tracking_number | Yes | The shipment's tracking number. | |
| logistics_channel | No | Logistics channel / service name. | |
| recipient_postcode | No | Recipient postcode. | |
| tracking_ship_date | No | Ship date, yyyymmdd (needed by some couriers). | |
| origin_country_iso2 | No | Origin country, ISO 3166 alpha-2. | |
| tracking_postal_code | No | Recipient postal code (needed by some couriers). | |
| tracking_origin_country | No | Origin country for couriers that need it, ISO 3166 alpha-2. | |
| destination_country_iso2 | No | Destination country, ISO 3166 alpha-2. | |
| tracking_courier_account | No | Courier account (needed by some couriers). | |
| tracking_destination_country | No | Destination country for couriers that need it, ISO 3166 alpha-2. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond the annotations by disclosing the credit cost and overage billing, the required user confirmation, the duplicate-registration failure ('Tracking No. already exists'), and the courier-specific extra field requirement. Annotations already carry the write/destructive/non-idempotent safety profile, so the description's job is supplemental and it does it well; it omits only finer points like plan limits or failure recovery.
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?
Front-loaded with the operation class and the core action, then layers cost, preconditions, failure mode, and parameters. Every sentence carries distinct, actionable information with 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 a 22-parameter mutation with no output schema, the description covers the required inputs, the conditional extras, the cost, the confirmation requirement, the error case, and even the return value ('the new tracking with its id'). Nothing an agent needs before calling is missing.
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 coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning: the two required fields, that courier_code comes from detect/list couriers, and that some couriers additionally need postal code, ship date, or key. This links otherwise scattered optional fields to a conditional requirement the schema alone does not express.
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 and resource ('register ONE shipment so TrackingMore starts tracking it') and pins the scope as single-shipment, distinguishing it from trackingmore_list_trackings, trackingmore_update_tracking, and trackingmore_delete_tracking. The 'WRITE:' prefix immediately frames the operation class.
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?
Explicit when-to-use with exclusions: confirm before creating, never bulk-create, and use trackingmore_detect_courier when the courier code is unknown. Alternative tools are named rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE (destructive): permanently remove one tracking from the TrackingMore account by id. Its checkpoint history is lost; registering the shipment again later uses another credit. Confirm with the user first. DELETE /trackings/delete/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | TrackingMore tracking id (the `id` field of a tracking from trackingmore_list_trackings or trackingmore_create_tracking). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations already declare destructiveHint=true and idempotentHint=true, the description adds consequences the annotations cannot express: checkpoint history is lost and re-registering the shipment burns another credit. That is precisely the extra context the lower bar asks for on an annotated tool.
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?
Leads with 'WRITE (destructive)' so the risk class is front-loaded, then the consequence, the confirmation requirement, and the endpoint. Every clause carries distinct information with 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 a one-parameter mutation with no output schema, the description covers purpose, consequence, preconditions, and where the id comes from. Nothing an agent needs in order to call it safely is missing.
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% and the single `id` parameter is fully documented there (source and format). The description only restates 'by id' and adds no syntax, format, or sourcing detail beyond the schema, so baseline 3 applies.
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?
Specific verb+resource+scope: 'permanently remove one tracking ... by id'. The word 'permanently' and the singular scope separate it cleanly from trackingmore_update_tracking (modify) and trackingmore_list_trackings (read), so no sibling schema needs to be opened.
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?
'Confirm with the user first' gives an explicit precondition for calling this tool, which is exactly the guidance an agent needs for a destructive operation. It does not, however, name an alternative (e.g. update_tracking) or state when deletion is the wrong choice, so it stops short of full when/when-not coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find which couriers a tracking number most likely belongs to (returns matching courier codes and names). Use the code with trackingmore_create_tracking. Does not create anything. POST /couriers/detect.
| Name | Required | Description | Default |
|---|---|---|---|
| tracking_number | Yes | The shipment's tracking number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description reinforces this with 'Does not create anything' and adds genuinely new behavioral context: it returns multiple candidate couriers with codes and names, and it is a POST endpoint (unusual given the read-only nature). No contradiction with annotations.
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?
Three short sentences, front-loaded with the purpose, then the workflow link, then the read-only assurance. 'POST /couriers/detect' is arguably implementation detail for an agent, but it is compact and non-redundant overall.
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?
With one simple parameter, no output schema, and annotations covering the safety profile, the description supplies everything needed: what it infers, what it returns, what to do with the result, and that nothing is mutated. No material gap remains.
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% and the single tracking_number parameter is fully documented in the schema. The description adds no format, length, or carrier-specific syntax guidance, so the baseline of 3 applies.
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 and resource ('Find which couriers a tracking number most likely belongs to') and explicitly describes the return payload (matching courier codes and names). This is clearly distinguishable from siblings like list_couriers or get_tracking, which operate on known couriers rather than inferring them from a number.
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?
The description names the downstream consumer explicitly: 'Use the code with trackingmore_create_tracking,' which tells the agent this is a lookup step preceding tracking creation. It does not state when not to use it (e.g., when the courier is already known and list_couriers would suffice), so it falls short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full tracking record of one shipment already registered in the account, including every checkpoint (origin_info / destination_info trackinfo with date, status, details and location). Look it up by tracking number; add courier_code if the number is used by several couriers. A number that was never registered is not found: register it with trackingmore_create_tracking first. GET /trackings/get?tracking_numbers=.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language for status text, e.g. en. | |
| courier_code | No | TrackingMore courier code, e.g. usps, ups, dhl (see trackingmore_list_couriers / trackingmore_detect_courier). | |
| tracking_number | Yes | The shipment's tracking number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds behavior the annotations do not: the not-found outcome for unregistered numbers and the prerequisite of prior registration, plus the shape of the returned checkpoint data. It omits pagination/latency details but is solid for a read tool.
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?
Front-loaded with the resource and return shape, then constraints, then the fallback action. Well packed with almost no filler, though the trailing raw endpoint string ('GET /trackings/get?tracking_numbers=') adds little for an agent that already has the schema.
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?
No output schema exists, but the description compensates by naming the returned fields (origin_info/destination_info trackinfo with date, status, details, location). Combined with the disambiguation guidance and the registration prerequisite, an agent has everything needed to call it correctly.
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 coverage is 100%, so the baseline is 3, but the description adds genuine meaning about courier_code — it is needed to disambiguate when one number maps to several couriers, which the schema only illustrates with examples. Only 'lang' goes unexplained 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?
States a specific verb+resource with scope: 'The full tracking record of one shipment already registered in the account', and even enumerates the returned checkpoint structure. It is clearly distinguishable from siblings like trackingmore_list_trackings (many shipments) and trackingmore_create_tracking (writes).
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?
Gives explicit lookup conditions ('by tracking number; add courier_code if the number is used by several couriers') and routes to the correct sibling when the precondition fails: 'A number that was never registered is not found: register it with trackingmore_create_tracking first.' This covers when-to-use and the alternative path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the carriers TrackingMore supports with their courier_code, name, country, website, phone and the extra fields some of them need. The full list is long (1,000+), so filter with search (matches name or code) and/or country; replies hold at most limit couriers. GET /couriers/all.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most couriers returned, 1-200 (default 50). | |
| offset | No | Skip this many matches (paging; default 0). | |
| search | No | Case-insensitive text in the courier name or code, e.g. 'dhl'. | |
| country | No | Courier country, ISO 3166 alpha-2, e.g. US. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful non-annotation context: the catalog is 1,000+ entries and responses are truncated at `limit`, explaining why filtering matters. Minor gap: no explicit note on paging combination or rate limits.
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?
Two tight sentences: the scoping/size constraint and filtering guidance are front-loaded before the endpoint reference. Every clause earns its place with no repetition of the title.
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?
With no output schema, the description helpfully enumerates returned fields and discloses the volume and cap on results, which is enough for an agent to call it correctly. It leaves offset/paging interplay to the schema, a minor omission for a filtered-list tool.
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% (limit range/default, offset paging, search matching, country ISO code), so the schema already carries parameter meaning. The description restates filtering behavior and the response cap but adds no syntax or format detail beyond the schema; baseline 3 applies.
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 (list) and resource (couriers/carriers TrackingMore supports) and enumerates the returned fields (courier_code, name, country, website, phone, extra fields). This is clearly distinguishable from siblings like detect_courier, which resolves a courier for a tracking number, and from the tracking CRUD tools.
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?
Gives concrete operational guidance: because the full list exceeds 1,000 entries, filter with `search` and/or `country`, and each reply is capped by `limit`. It does not explicitly contrast with detect_courier or say when not to call it, so it falls short of a full when-to-use/alternative statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the shipments already registered in the TrackingMore account, newest first as the API returns them: id, tracking number, courier, delivery_status (pending, notfound, transit, pickup, delivered, undelivered, exception, expired, inforeceived), latest event and milestone dates. Checkpoint lists are left out (use trackingmore_get_tracking for one shipment's full history). Filters: tracking numbers, courier, delivery status, created/updated date range. GET /trackings/get.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language for status text, e.g. en. | |
| page | No | Page number, from 1 (default 1). Sent as pages_amount. | |
| limit | No | Trackings per page, 1-200 (default 40). Sent as items_amount. | |
| courier_code | No | TrackingMore courier code, e.g. usps, ups, dhl (see trackingmore_list_couriers / trackingmore_detect_courier). | |
| archived_status | No | Archive filter: true = archived trackings, tracking = trackings that are not archived. | |
| delivery_status | No | pending, notfound, transit, pickup, delivered, undelivered, exception, expired or inforeceived. | |
| created_date_max | No | A date (yyyy-mm-dd, taken as 00:00:00 UTC) or an ISO 8601 date-time with a timezone, e.g. 2026-10-01T00:00:00+00:00 or 2026-10-01T00:00:00Z. Sent to TrackingMore as YYYY-MM-DDTHH:MM:SS+HH:MM. | |
| created_date_min | No | A date (yyyy-mm-dd, taken as 00:00:00 UTC) or an ISO 8601 date-time with a timezone, e.g. 2026-10-01T00:00:00+00:00 or 2026-10-01T00:00:00Z. Sent to TrackingMore as YYYY-MM-DDTHH:MM:SS+HH:MM. | |
| tracking_numbers | No | One to 40 tracking numbers, comma-separated (TrackingMore refuses more than 40 per call). | |
| updated_date_max | No | A date (yyyy-mm-dd, taken as 00:00:00 UTC) or an ISO 8601 date-time with a timezone, e.g. 2026-10-01T00:00:00+00:00 or 2026-10-01T00:00:00Z. Sent to TrackingMore as YYYY-MM-DDTHH:MM:SS+HH:MM. | |
| updated_date_min | No | A date (yyyy-mm-dd, taken as 00:00:00 UTC) or an ISO 8601 date-time with a timezone, e.g. 2026-10-01T00:00:00+00:00 or 2026-10-01T00:00:00Z. Sent to TrackingMore as YYYY-MM-DDTHH:MM:SS+HH:MM. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavior: result ordering (newest first), the exact field set returned, the full delivery_status vocabulary, and the omission of checkpoint lists.
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?
Front-loads the purpose and ordering, then packs return fields, exclusions and filters into three dense sentences with little waste. Slightly heavy for a list tool, but every clause carries information.
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?
No output schema exists, and the description compensates by enumerating the returned fields and the status values. Pagination defaults and behavior are left to the schema, which covers them adequately, so nothing critical is missing.
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 every parameter including date formats and limits. The description restates the filter categories and status values but adds no new format or semantics, which is the baseline-3 case.
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 (List) and resource (shipments registered in the TrackingMore account) plus the ordering (newest first). It explicitly distinguishes itself from the sibling trackingmore_get_tracking by noting checkpoint lists are excluded.
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?
Names the alternative tool and the condition that selects it ('use trackingmore_get_tracking for one shipment's full history'), which is clear routing guidance. It does not cover other alternatives such as list_couriers/detect_courier beyond a passing schema reference, but the main when-to-use decision is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: change the descriptive fields of a registered tracking (order number, customer name/email, title, note, label, language, postal code, ship date ...). Only the fields you pass change; the tracking number and courier cannot be changed here. PUT /trackings/update/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | TrackingMore tracking id (the `id` field of a tracking from trackingmore_list_trackings or trackingmore_create_tracking). | |
| note | No | Free-text note. | |
| label | No | Label to group shipments. It must be a label you created in the TrackingMore dashboard first, otherwise TrackingMore refuses it (meta 4131). | |
| title | No | Short title for the shipment. | |
| language | No | Language code for status text, e.g. en. | |
| order_id | No | Your order id in the shop system. | |
| order_date | No | Order date, e.g. 2026-10-01T10:00:00+00:00. | |
| customer_sms | No | Recipient mobile number, with country code. | |
| order_number | No | Your order number for this shipment. | |
| tracking_key | No | Tracking key / phone suffix (needed by some couriers). | |
| customer_name | No | Recipient name. | |
| customer_email | No | Recipient email (TrackingMore can send delivery notifications to it when enabled in the account). | |
| logistics_channel | No | Logistics channel / service name. | |
| recipient_postcode | No | Recipient postcode. | |
| tracking_ship_date | No | Ship date, yyyymmdd (needed by some couriers). | |
| origin_country_iso2 | No | Origin country, ISO 3166 alpha-2. | |
| tracking_postal_code | No | Recipient postal code (needed by some couriers). | |
| tracking_origin_country | No | Origin country for couriers that need it, ISO 3166 alpha-2. | |
| destination_country_iso2 | No | Destination country, ISO 3166 alpha-2. | |
| tracking_courier_account | No | Courier account (needed by some couriers). | |
| tracking_destination_country | No | Destination country for couriers that need it, ISO 3166 alpha-2. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, destructive=true, idempotent=true, openWorld=true. The description adds the genuinely valuable PATCH-style semantic — 'only the fields you pass change' — which an agent cannot derive from the annotations alone, plus the immutable-field constraint. It does not explain the destructiveHint flag's implications or any auth/rate-limit behavior.
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?
Two sentences, front-loaded with the operation class, then the most consequential behavioral fact (partial update), then the endpoint. No filler and nothing buried.
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 21-parameter mutation with no output schema and full schema coverage, the description covers the essentials: what changes, what cannot, and the endpoint. It omits any indication of the response shape or confirmation behavior, which is a minor gap given structured fields carry the rest.
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 21 parameters with lengths and constraints. The description's short field enumeration and the 'cannot be changed here' exclusion add only a little beyond that; baseline 3 is appropriate.
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 and resource ('change the descriptive fields of a registered tracking') and immediately scopes it by naming what is out of bounds (tracking number, courier). The 'WRITE:' prefix and the PUT endpoint make the operation class unmistakable against siblings like create/delete/get.
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?
Usage is implied well enough — 'a registered tracking' signals the record must already exist — and it rules out changing the tracking number or courier. However, no alternative is named for those cases (e.g. delete + recreate, or a courier-change tool), so the agent must infer the fallback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Track parcels across 2,500+ carriers and 3PLs: live delivery status, event history, carrier lookup.
Auto-detect carrier from tracking number: USPS, UPS, FedEx, DHL, India Post, more.
Track packages across 1,300+ global carriers with real-time status and AI-powered delivery dates.
Track 542 carriers (USPS, UPS, FedEx, UniUni, LTL) via MCP, API, Webhooks & Watches.
Add one secure layer between your agents and this server.
