DB Schenker

You deploy and run a dedicated MCP server that tracks DB Schenker shipments by reference number, returning structured shipment data such as sender/receiver details, package information, and tracking history. It handles API rate limits gracefully, caches data to improve responsiveness, and exposes a straightforward way to query shipments through an MCP client.

How to use

You connect to the DB Schenker Shipment Tracker MCP Server with an MCP client and configure it as a server you trust. Once connected, you can request shipment details by providing a reference number. The server will respond with a structured payload that includes shipment identifiers, transport mode, sender and receiver information, package details, and the complete tracking history.

Practical usage patterns include querying a few common reference numbers to verify setup and then using the client in your workflows to fetch real-time shipment data as needed. If the shipment reference is valid and DB Schenker has data for that reference, you receive a comprehensive shipment object along with metadata for the sender, receiver, and each tracking event.

How to install

Prerequisites You must have Node.js version 18 or higher installed on your machine. npm ships with Node.js, so you do not need a separate npm installation.

# 1) Clone the MCP server repository
git clone https://github.com/digitalxenon98/sendify-dbschenker-mcp
cd sendify-dbschenker-mcp

# 2) Verify Node.js installation
node --version  # Should be v18 or higher
npm --version

Install dependencies for the project to prepare the MCP server runtime and build tools.

npm install

Optionally build the TypeScript project for production deployment. This compiles TypeScript to JavaScript in the dist/ directory.

npm run build

Running the MCP server

Development mode runs the server directly from source using TypeScript, communicating via stdio. Production mode runs the compiled JavaScript. Use the commands that fit your workflow.

Development mode (no build required) shows the runtime using tsx for on-the-fly compilation.

npm run dev

Production mode first builds the project and then starts the compiled server.

npm run build
npm start

MCP client configuration

Configure your MCP client to point to the local or remote MCP server. The server can be referenced in your MCP client configuration so you can invoke the track shipment tool directly from your client interface.

Example client configuration (two valid approaches shown): use a local stdio server or run via a node-based runtime.

Testing the tool with common references

You can test the server using common reference numbers to verify that it returns the expected shipment data. Use reference numbers that are known to be valid for DB Schenker shipments.

Example references you can try include several 10-digit IDs that align with typical shipment references.

Notes on rate limits and reliability

DB Schenker public API enforces rate limits to ensure fair usage and system stability. The MCP server includes mechanisms to handle rate limits gracefully, including automatic retries with exponential backoff and in-memory response caching for 60 seconds.

If a request hits a rate limit, you will receive a clear error with guidance to retry later once the backoff period has elapsed. Successful responses are cached to reduce repeated API calls for the same reference within the cache window.

Configuration & run modes

The server supports two typical run modes. In development, you may run directly from source to speed up testing. In production, you build once and run the compiled output for stability and performance.

Key runtime notes: ensure your environment has the necessary Node.js version and that the server process has permission to access any required network resources for DB Schenker data.

Available tools

Automatic Retries

Failed requests due to rate limiting (HTTP 429) are automatically retried with exponential backoff, up to a defined number of attempts.

Exponential Backoff

Retry delays increase with each attempt to reduce repeated rate-limit hits and balance load.

Response Caching

Successful API responses are cached in memory for 60 seconds to minimize repeated calls for the same reference.

Graceful Error Handling

Clear, actionable error messages are provided when rate limits persist after retries.