Supports tracking parcels shipped with DHL, allowing users to check delivery status and shipment progress.
Enables tracking of FedEx packages, providing delivery status updates and shipment information.
Allows tracking of UPS parcels, providing delivery status, timestamps, and location updates.
Supports tracking of USPS mail and packages, showing delivery progress and status information.
Click on "Install 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., "@Parcel Tracking MCP Server track package 9400111899561234567890"
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 (MCP) server for tracking parcel deliveries using the 17track.net API.
Track parcel deliveries from various carriers
Automatic carrier detection
Support for manual carrier specification
Built with TypeScript and MCP SDK
Related MCP server: Parcel App MCP Server
Node.js (v16 or higher)
npm or yarn
17track.net API token
Install the package via npm:
npm install -g parcel-tracking-mcp-serverOr install locally:
npm install parcel-tracking-mcp-serverCreate a config.json file in your working directory with your 17track.net API token:
{
"apiToken": "your-17track-api-token-here"
}Note: The server looks for config.json in the current working directory where you run the command.
Visit 17track.net
Sign up for an account
Navigate to the API section
Generate your API token
Add it to your config.json file
If installed globally:
parcel-tracking-mcp-serverIf installed locally:
npx parcel-tracking-mcp-serverOr if you're using it as a dependency in your project:
node node_modules/parcel-tracking-mcp-server/dist/index.jsTo use this server with MCP clients (like Claude Desktop), add it to your MCP configuration:
{
"mcpServers": {
"parcel-tracking": {
"command": "npx",
"args": ["parcel-tracking-mcp-server"]
}
}
}Or if installed globally:
{
"mcpServers": {
"parcel-tracking": {
"command": "parcel-tracking-mcp-server"
}
}
}tracking-deliveryTrack a parcel delivery by providing a tracking number.
Parameters:
number (required): The tracking number of the parcel
carrier (optional): The carrier of the parcel (defaults to 'auto' for automatic detection)
Example:
// Track with automatic carrier detection
await trackingDelivery({
number: "1234567890"
});
// Track with specific carrier
await trackingDelivery({
number: "1234567890",
carrier: "ups"
});The server supports automatic carrier detection, but you can also specify carriers manually. Common carriers include:
UPS
FedEx
DHL
USPS
China Post
And many more (check 17track.net documentation for full list)
The server returns tracking information in JSON format, including:
Tracking status
Delivery progress
Timestamps
Location updates
Carrier information
The server includes comprehensive error handling:
API connection errors
Invalid tracking numbers
Missing configuration
Network timeouts
├── index.ts # Main server implementation
├── config.json # Configuration file (create this)
├── package.json # Dependencies and scripts
└── README.md # This file@modelcontextprotocol/sdk - MCP SDK for building servers
zod - Schema validation
node-fetch - HTTP requests (if needed for older Node.js versions)
MIT License
Fork the repository
Create a feature branch
Make your changes
Submit a pull request
For issues related to:
MCP protocol: Check the MCP documentation
17track.net API: Visit 17track.net API docs
This implementation: Create an issue in the repository
Initial release
Basic parcel tracking functionality
Support for automatic and manual carrier detection
Error handling and logging
Search carriers by name keyword (supports fuzzy typos)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Keyword to search carrier names, case-insensitive (typos allowed) | |
| limit | No | Max number of results to return (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions 'supports fuzzy typos', it doesn't describe what 'fuzzy' means operationally, whether there are rate limits, authentication requirements, error conditions, or what the response format looks like. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.
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?
The description is extremely concise at just one sentence with zero wasted words. It's front-loaded with the core purpose and efficiently adds the key behavioral detail about fuzzy matching in parentheses.
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?
Given the lack of annotations and output schema, the description should do more to compensate. While the purpose is clear, it doesn't describe the return format, error conditions, or operational constraints. For a search tool that presumably returns results, the absence of output information is a significant gap.
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 fully documents both parameters. The description adds minimal value by mentioning 'keyword' and 'fuzzy typos', but doesn't provide additional syntax, format details, or examples beyond what the schema descriptions already state about case-insensitivity and typos.
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 clearly states the tool's purpose as 'Search carriers by name keyword' with the specific functionality of 'supports fuzzy typos'. It uses a specific verb ('Search') and resource ('carriers'), but doesn't explicitly differentiate from the sibling tool 'tracking-delivery' which appears to have a different function.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool 'tracking-delivery' or any other search methods, nor does it provide context about when this fuzzy search is preferred over exact matching or other filtering approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Track a parcel delivery via 17TRACK
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | The tracking number of the parcel | |
| carrier | No | Carrier ID (number). If omitted, 17TRACK will auto-detect, but accuracy may be lower. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool's function but does not disclose behavioral traits such as authentication requirements, rate limits, error handling, or what the output might look like (e.g., tracking status details). This leaves significant gaps for an agent to understand how to invoke it effectively.
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?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and every part earns its place, making it highly concise and well-structured.
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?
Given the tool's complexity (tracking with potential carrier detection) and lack of annotations and output schema, the description is incomplete. It does not cover behavioral aspects, output format, or error cases, which are crucial for an agent to use the tool correctly in real-world scenarios.
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 both parameters thoroughly. The description does not add any meaning beyond what the schema provides (e.g., it doesn't explain parameter interactions or provide examples). Baseline 3 is appropriate as 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?
The description clearly states the specific action ('track') and resource ('parcel delivery') with the service provider ('via 17TRACK'), making the purpose explicit. It distinguishes from the sibling tool 'search-carrier' by focusing on tracking rather than carrier lookup.
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 implies usage context (tracking parcels with 17TRACK) but does not explicitly state when to use this tool versus alternatives like the sibling 'search-carrier'. It provides clear functional intent but lacks explicit comparison or exclusion guidance.
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. Dates show when Glama detected each change.
search-carriertracking-deliveryThe two tools have clearly distinct purposes: one searches for carriers by name, while the other tracks parcel deliveries. There is no overlap in functionality, making it easy for an agent to select the correct tool based on the task.
Both tools follow a consistent verb_noun pattern (search-carrier and tracking-delivery), using hyphens for separation. The naming is predictable and readable throughout the set.
With only 2 tools, the server feels thin for a parcel tracking domain. A typical tracking system would include more operations, such as creating shipments, updating statuses, or handling multiple carriers, making this count insufficient for comprehensive coverage.
The toolset is severely incomplete for parcel tracking. It lacks essential CRUD operations like creating or updating shipments, retrieving carrier details beyond search, and managing delivery events. This will likely cause agent failures in common tracking workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Auto-detect carrier from tracking number: USPS, UPS, FedEx, DHL, India Post, more.
Track parcels across 2,500+ carriers and 3PLs: live delivery status, event history, carrier lookup.
Track packages across 1,300+ global carriers with real-time status and AI-powered delivery dates.
Track shipments and search shipping products (DPD, InPost, DHL, FedEx, UPS, GLS) via GlobKurier API.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/iamfiro/parcel-tracking-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
