France Logistics (buy Mondial Relay + more labels + tracking via Shippo)
Server Details
France shipping labels for AI agents: buy Mondial Relay and more, track and refund via Shippo.
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 3 of 3 tools scored.
Each tool has a distinct purpose: creating a shipment, tracking its status, and refunding an unused label. There is no functional overlap.
All tool names follow a consistent verb_noun pattern: create_shipment, query_tracking, refund_label. The verbs are clear and the structure is uniform.
Three tools is appropriate for this focused logistics server. The core operations—create, track, refund—are covered without unnecessary extras.
The tool surface covers the essential lifecycle of a France shipping label: creation, tracking, and refund. Missing functionality like listing all shipments or custom rate selection is a minor gap but does not hinder core use.
Available Tools
3 toolscreate_shipmentAInspect
Create a France shipping label via Shippo — pass a to_address, from_address and parcel (dimensions in CENTIMETRES, weight in GRAMS by default), and the server fetches carrier rates, buys the CHEAPEST rate by default (or the carrier/service you specify), and returns the shipment_id, transaction_id, tracking_number, printable label_url and the price paid (EUR). Recommended carrier: Mondial Relay relay-point (point relais) delivery via the Shippo master account — no Mondial Relay contract or merchant account needed — so an agent can print a Mondial Relay label with no merchant courier account. Bring your own Shippo API token via header x-shippo-token: free TEST tokens (prefix shippo_test_…) run the full flow end-to-end at no cost (sign up free, no card, at apps.goshippo.com/join); production tokens (prefix shippo_live_…) buy real labels. The token prefix auto-selects the environment. weight is always required. Owner policy headers gate the label price before any purchase.
| Name | Required | Description | Default |
|---|---|---|---|
| width | No | Parcel width in CENTIMETRES. | |
| height | No | Parcel height in CENTIMETRES. | |
| length | No | Parcel length in CENTIMETRES (cm) by default. Provide length+width+height together. | |
| to_zip | Yes | Recipient code postal (e.g. "75008"). Required. | |
| weight | Yes | Parcel weight in GRAMS (g) by default. Required. Use mass_unit to change (kg/oz/lb). | |
| carrier | No | Optional: restrict to a carrier (e.g. "Mondial Relay"). Default: cheapest across all available carriers. | |
| service | No | Optional: restrict to a service level name or token (e.g. "Point Relais"). Default: cheapest. | |
| to_city | Yes | Recipient town / city. | |
| to_name | Yes | Recipient full name. | |
| from_zip | Yes | Sender code postal. Required. | |
| to_email | No | Optional recipient email. | |
| to_phone | No | Optional recipient phone (some carriers/services require it). | |
| to_state | No | Optional recipient région (région is optional for France addresses). | |
| from_city | Yes | Sender town / city. | |
| from_name | Yes | Sender full name. | |
| mass_unit | No | Weight unit: g (default), kg, oz or lb. | |
| from_phone | No | Optional sender phone. | |
| from_state | No | Optional sender région. | |
| to_country | No | Recipient ISO country code. Default FR. | |
| to_street1 | Yes | Recipient street address line 1. | |
| to_street2 | No | Optional recipient street address line 2 (flat/unit). | |
| from_country | No | Sender ISO country code. Default FR. | |
| from_street1 | Yes | Sender street address line 1. | |
| from_street2 | No | Optional sender street address line 2. | |
| distance_unit | No | Dimension unit: cm (default), m, in or ft. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by detailing the default cheapest rate purchase, environment auto-select via token prefix, required weight, and price gating via owner policy headers. Annotations already indicate non-read-only and non-destructive, so description enriches understanding.
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 comprehensive but slightly verbose. It front-loads the core purpose, then details. Could be more structured, but each sentence adds useful information. No redundancy or tautology.
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 25 parameters and no output schema, the description covers the workflow (rate fetching, buying, returning fields) and token environment. It lacks error scenarios or rate limits, but overall provides sufficient context for an AI to use the tool 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?
With 100% schema coverage, the description still adds value by emphasizing units (cm, g), defaults (carrier, service, country), and required weight. It clarifies that to_country defaults to FR and explains token prefix behavior. This goes beyond the schema descriptions.
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 creates a France shipping label via Shippo, specifying the inputs (to_address, from_address, parcel) and outputs (shipment_id, tracking_number, label_url). It distinguishes itself from siblings query_tracking and refund_label by focusing on creation.
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 guidance on when to use the tool, including recommended carrier (Mondial Relay) and token setup (test vs production). It does not explicitly state when not to use it, but the sibling context implies appropriate usage. Good but not perfect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_trackingARead-onlyInspect
Track a France shipment by its tracking_number (the one create_shipment returned, or any carrier tracking number) plus its carrier. Returns the current status with a plain-English hint. Status values (Shippo enum): UNKNOWN, PRE_TRANSIT (label made, not yet picked up), TRANSIT, DELIVERED, RETURNED, FAILURE. Raw carrier scan details are always included. carrier defaults to "mondial_relay"; for TEST tokens use carrier="shippo" with mock numbers SHIPPO_TRANSIT / SHIPPO_DELIVERED. Safe to call anytime.
| Name | Required | Description | Default |
|---|---|---|---|
| carrier | No | Carrier token for the lookup (e.g. "mondial_relay", "usps", or "shippo" for TEST mock numbers). Default "mondial_relay". | |
| tracking_number | Yes | The tracking number to look up (from create_shipment or a carrier). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint and openWorldHint annotations, description explains status enum values and that raw carrier scan details are always included, adding behavioral context not captured by 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?
Concise, front-loaded with purpose, no fluff. Every sentence adds necessary 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, but description fully explains return values (status + hint, raw details) and covers test vs production, carriers, and defaults, making it complete for an agent.
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%, but description adds value by explaining carrier default, test token usage, and source of tracking_number, which are not in 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 clearly states the tool tracks a France shipment using tracking_number and carrier, distinguishing it from sibling tools (create_shipment, refund_label) which handle creation and refunds.
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?
Explicitly states 'Safe to call anytime' and provides guidance on carrier defaults, test token usage, and mock numbers. Could be improved by specifying when not to use, but sufficient for typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
refund_labelAIdempotentInspect
Request a refund for a France shipping label bought via create_shipment, by its transaction_id. Refund is only possible for UNUSED labels that were never scanned by the carrier; already-shipped labels cannot be refunded. Returns refund_status: QUEUED / PENDING (accepted, carrier still processing — most common), SUCCESS (money returned), or ERROR (not eligible, e.g. already scanned). Carriers can take time to move QUEUED/PENDING → SUCCESS.
| Name | Required | Description | Default |
|---|---|---|---|
| transaction_id | Yes | The transaction_id returned by create_shipment (the bought label to refund). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds details beyond annotations: refund may be queued/pending, carriers take time, and status progression. Annotations already indicate non-read-only, non-destructive, and idempotent.
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 well-structured sentences, front-loaded with action, no unnecessary words.
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?
Complete for a one-parameter tool without output schema: covers purpose, conditions, and behavioral expectations.
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 already covers transaction_id fully (100% coverage). Description reinforces source but adds little extra semantic value.
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?
Clearly states 'Request a refund for a France shipping label' using transaction_id as resource identifier. Distinguishes from siblings create_shipment and query_tracking.
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?
Explicitly specifies refund only possible for UNUSED labels never scanned, and that already-shipped labels cannot be refunded. Also explains the return statuses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!