Japan Logistics (Ship&co: Yamato / Sagawa / Japan Post labels + tracking)
Server Details
Japan shipping labels for AI agents: buy Yamato, Sagawa, Japan Post labels and track via Ship&co.
- 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.7/5 across 4 of 4 tools scored.
Each tool handles a distinct operation: create shipment, get rates, track, void. No overlap in purpose.
All tool names use a consistent verb_noun snake_case pattern (create_shipment, get_rates, query_tracking, void_label).
Four tools cover the essential workflow of a shipping label service: rate estimation, label creation, tracking, and voiding. No extraneous tools.
The tool surface covers the full lifecycle: pre-creation rates, creation, tracking, and voiding. No obvious gaps for the stated purpose.
Available Tools
4 toolscreate_shipmentAInspect
Create a Japan shipping label via Ship&co in ONE call — pass a carrier (yamato / sagawa / japanpost / seino / dhl / ups / fedex), a from_address (sender) and to_address (recipient) with a 7-digit Japanese postal code (郵便番号), prefecture (都道府県) and city (市区町村), the parcel (weight in GRAMS, dimensions in CENTIMETRES) and the products. Ship&co creates the shipment AND issues the label in one step, returning shipment_id, carrier, tracking_number(s) and a printable label PDF (label_url). Ship&co reaches Japan domestic couriers Yamato (ヤマト運輸) / Sagawa (佐川急便) / Japan Post (日本郵便) / Seino (西濃運輸) plus international DHL / UPS / FedEx. TEST MODE IS THE DEFAULT (test:true → free non-billable virtual label; Yamato / Sagawa need no carrier account for test mode) — set test:false to buy a REAL billable label. Bring your own Ship&co API token via header x-shipandco-token (self-serve in the Ship&co Dashboard: API menu -> Create New Token). Owner policy headers gate the declared goods value (JPY) before creation.
| Name | Required | Description | Default |
|---|---|---|---|
| test | No | TRUE (default) = free non-billable virtual TEST label (Yamato / Sagawa / UPS / DHL need no extra carrier account). FALSE = buy a REAL billable label. Defaults to true to prevent accidental live shipments. | |
| width | No | Parcel width in CENTIMETRES (cm). Optional. | |
| height | No | Parcel height in CENTIMETRES (cm). Optional. | |
| length | No | Parcel length/depth in CENTIMETRES (cm). Optional — provide length+width+height together if the carrier needs dimensions. | |
| to_zip | Yes | Recipient 7-digit Japanese postal code 郵便番号 (e.g. "150-0001" or "1500001"). Required. | |
| weight | Yes | Parcel weight in GRAMS (g). e.g. 1000 = 1 kg. Required. | |
| carrier | Yes | Carrier token (required): "yamato", "sagawa", "japanpost", "seino", "dhl", "ups" or "fedex". For a free TEST label with no carrier account use "yamato" or "sagawa". | |
| service | No | Optional carrier service token, e.g. "yamato_taqbin" / "yamato_collect" (Yamato), "japanpost_ems" (Japan Post), "dhl_express_worldwide" (DHL). Get valid values from get_rates. If the carrier requires a service and it is omitted, Ship&co returns a native error. | |
| to_city | Yes | Recipient city / ward / town 市区町村 (e.g. "Shibuya-ku"). Required. | |
| to_name | Yes | Recipient full name (氏名). Required. | |
| from_zip | Yes | Sender 7-digit Japanese postal code 郵便番号 (e.g. "150-0001" or "1500001"). Required. | |
| products | Yes | Parcel contents (at least one). Each: { name (required), price (required, JPY per unit), quantity (required int), origin_country? (ISO, for international) }. The declared goods value (sum of price x quantity, JPY) is what the owner policy gate checks. | |
| to_email | No | Recipient email. Optional (some carriers/services require it). | |
| to_phone | No | Recipient phone number. Optional but recommended (many Japanese carriers require it). | |
| from_city | Yes | Sender city / ward / town 市区町村 (e.g. "Shibuya-ku"). Required. | |
| from_name | Yes | Sender full name (氏名). Required. | |
| ship_date | No | Optional ship date "YYYY-MM-DD". Defaults to the carrier default if omitted. | |
| from_email | No | Sender email. Optional (some carriers/services require it). | |
| from_phone | No | Sender phone number. Optional but recommended (many Japanese carriers require it). | |
| to_company | No | Recipient company name. Optional. | |
| to_country | No | Recipient ISO country code. Default "JP". | |
| to_address1 | Yes | Recipient street address line 1 番地 (chome-banchi-go). Required. | |
| to_address2 | No | Recipient street address line 2 (building / room). Optional. | |
| to_province | Yes | Recipient prefecture 都道府県 (e.g. "Tokyo" / "東京都"). Required. | |
| from_company | No | Sender company name. Optional. | |
| from_country | No | Sender ISO country code. Default "JP". | |
| from_address1 | Yes | Sender street address line 1 番地 (chome-banchi-go). Required. | |
| from_address2 | No | Sender street address line 2 (building / room). Optional. | |
| from_province | Yes | Sender prefecture 都道府県 (e.g. "Tokyo" / "東京都"). Required. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses that the tool both creates the shipment and issues the label, including test mode default, API token requirement, and owner policy gates. Annotations indicate readOnlyHint=false and destructiveHint=false, and the description aligns perfectly with no contradictions.
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 front-loaded with the main purpose. While slightly long, every sentence contributes meaningful information with no redundancy. Minor trimming could improve, but structure is clear.
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 complexity (29 parameters, no output schema), the description covers return values (shipment_id, tracking, label_url) and critical operational details like test mode and API token. It could mention common error scenarios, but the provided information is sufficient for an agent 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?
Although schema coverage is 100%, the description adds valuable context beyond basic descriptions, such as unit requirements (grams, cm), test mode behavior for specific carriers, and the declared value gate. This reduces ambiguity for agents.
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 Japan shipping label via Ship&co in one call, listing supported carriers and key required fields. It distinguishes itself from sibling tools by focusing on label creation, while siblings handle rates, tracking, or voiding.
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 explains when to use the tool (creating a shipment) and provides context on test mode and carrier selection. It implicitly differentiates from siblings by mentioning get_rates for service tokens, but could explicitly state alternatives for other tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ratesARead-onlyInspect
Estimate Japan shipping rates BEFORE creating a label (read-only — quotes only, creates nothing and spends nothing). Given a from_address (sender), a to_address (recipient) and the parcel (weight in GRAMS, dimensions in CENTIMETRES) plus the products, it asks Ship&co for the available carrier services and their prices (JPY), and flags the cheapest. Ship&co reaches Japan domestic couriers Yamato (ヤマト運輸) / Sagawa (佐川急便) / Japan Post (日本郵便) / Seino (西濃運輸) plus international DHL / UPS / FedEx. Use the returned carrier + service in create_shipment. NOTE: /rates returns quotes for the carriers registered in your Ship&co account; if none are registered you can still create TEST labels directly with create_shipment (carrier=yamato or sagawa, setup.test defaults true — no carrier account needed for test mode). Bring your own Ship&co API token via header x-shipandco-token.
| Name | Required | Description | Default |
|---|---|---|---|
| width | No | Parcel width in CENTIMETRES (cm). Optional. | |
| height | No | Parcel height in CENTIMETRES (cm). Optional. | |
| length | No | Parcel length/depth in CENTIMETRES (cm). Optional — provide length+width+height together if the carrier needs dimensions. | |
| to_zip | Yes | Recipient 7-digit Japanese postal code 郵便番号 (e.g. "150-0001" or "1500001"). Required. | |
| weight | Yes | Parcel weight in GRAMS (g). e.g. 1000 = 1 kg. Required. | |
| to_city | Yes | Recipient city / ward / town 市区町村 (e.g. "Shibuya-ku"). Required. | |
| to_name | Yes | Recipient full name (氏名). Required. | |
| from_zip | Yes | Sender 7-digit Japanese postal code 郵便番号 (e.g. "150-0001" or "1500001"). Required. | |
| products | Yes | Parcel contents (at least one). Each: { name (required), price (required, JPY per unit), quantity (required int), origin_country? (ISO, for international) }. The declared goods value (sum of price x quantity, JPY) is what the owner policy gate checks. | |
| to_email | No | Recipient email. Optional (some carriers/services require it). | |
| to_phone | No | Recipient phone number. Optional but recommended (many Japanese carriers require it). | |
| from_city | Yes | Sender city / ward / town 市区町村 (e.g. "Shibuya-ku"). Required. | |
| from_name | Yes | Sender full name (氏名). Required. | |
| from_email | No | Sender email. Optional (some carriers/services require it). | |
| from_phone | No | Sender phone number. Optional but recommended (many Japanese carriers require it). | |
| to_company | No | Recipient company name. Optional. | |
| to_country | No | Recipient ISO country code. Default "JP". | |
| to_address1 | Yes | Recipient street address line 1 番地 (chome-banchi-go). Required. | |
| to_address2 | No | Recipient street address line 2 (building / room). Optional. | |
| to_province | Yes | Recipient prefecture 都道府県 (e.g. "Tokyo" / "東京都"). Required. | |
| from_company | No | Sender company name. Optional. | |
| from_country | No | Sender ISO country code. Default "JP". | |
| from_address1 | Yes | Sender street address line 1 番地 (chome-banchi-go). Required. | |
| from_address2 | No | Sender street address line 2 (building / room). Optional. | |
| from_province | Yes | Sender prefecture 都道府県 (e.g. "Tokyo" / "東京都"). Required. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description reinforces this with 'creates nothing and spends nothing' and explains that it only queries for quotes. It adds context about carrier services (Yamato, Sagawa, etc.) and the test mode fallback. No contradictions.
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 multi-sentence but well-organized: purpose, carrier list, usage tip, test mode note. It front-loads the key information and avoids unnecessary fluff. Slightly verbose but not excessive; a 4 is appropriate.
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 has 25 parameters, no output schema, and moderate complexity, the description covers essential behavior: quote mechanism, carrier list, test mode alternative. It does not detail the response format (beyond 'flags the cheapest'), which could be helpful. However, for a read-only estimation tool, the provided context is sufficient for an agent to select and invoke 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 description coverage is 100%, so the baseline is 3. The description adds value by clarifying units (weight in GRAMS, dimensions in CENTIMETRES) and the structure of the 'products' array (name, price, quantity, optional origin_country). It also explains the purpose of the price (declared value). This extra context justifies a 4.
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 purpose: 'Estimate Japan shipping rates BEFORE creating a label (read-only — quotes only, creates nothing and spends nothing).' It uses a specific verb ('estimate') and resource ('shipping rates'), and distinguishes itself from the sibling tool 'create_shipment' by emphasizing it provides quotes only.
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 explicitly says to use this tool for rate estimation before label creation: 'Use the returned carrier + service in create_shipment.' It also notes an alternative scenario: if no carriers are registered, test labels can be created directly with create_shipment using test mode. This provides clear when-to-use and when-not-to-use guidance.
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 Japan shipment by its carrier + tracking_number (the tracking number create_shipment returned, or any carrier tracking number). Returns the current status with a plain-English hint. Status values (Ship&co enum): collected, transit, out_for_delivery, delivered, exception, returned. The raw current_status details, location and full scan history are always included. Non-terminal statuses carry next_steps. Safe to call anytime.
| Name | Required | Description | Default |
|---|---|---|---|
| carrier | Yes | Carrier token for the lookup: "yamato", "sagawa", "japanpost", "seino", "dhl", "ups", "fedex". Required. | |
| tracking_number | Yes | The tracking number to look up (from create_shipment, or a carrier tracking number). Required. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), description details output: current status, plain-English hint, raw details, location, scan history, and next_steps for non-terminal statuses. No contradiction.
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?
Four sentences, all essential. Front-loaded with core function, no redundant information, efficient structure.
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?
Despite no output schema, description fully covers return values including status enum, plain-English hint, details, scan history, and next_steps. Adequate for tool's simplicity.
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 has 100% coverage with parameter descriptions. Description adds context (e.g., tracking number may come from create_shipment or any carrier tracking number, carrier examples) that enriches understanding beyond 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?
Description clearly states it tracks a Japan shipment by carrier and tracking number, specifying the output includes status, details, and scan history. It distinguishes from sibling tools (create_shipment, get_rates, void_label) by its specific verb and resource.
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?
Description indicates when to use (after create_shipment or with any carrier tracking number) and that it's safe to call anytime, but lacks explicit discussion of when not to use or direct comparison with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
void_labelADestructiveIdempotentInspect
Void / cancel a Japan shipment (and its label) created by create_shipment, by its shipment_id. Use this to cancel a label you created by mistake before the parcel is handed to the carrier. TEST labels can always be voided; a REAL label can only be voided while it has not yet been shipped/scanned — an already-collected parcel cannot be voided here. Returns the void result reported by Ship&co.
| Name | Required | Description | Default |
|---|---|---|---|
| shipment_id | Yes | The Ship&co shipment id to void (the shipment_id create_shipment returned). Required. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations: describes destructive nature (void/cancel), special condition for already-collected parcels, and that it returns the void result. Annotations include destructiveHint true and idempotentHint true, which are consistent.
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 at 4 sentences, front-loaded with verb and target, no redundant 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?
Succinctly covers purpose, parameter, usage conditions, and return value (though no output schema). No gaps given the simplicity of the 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 already provides 100% coverage with description for shipment_id. Tool description adds context that the id comes from create_shipment, which is helpful for selection.
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 the tool voids/cancels a Japan shipment and its label, identified by shipment_id. Distinct from siblings (create_shipment, get_rates, query_tracking) as it's the only tool for voiding.
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 says when to use: to cancel a label created by mistake before handed to carrier. Explains conditions for REAL vs TEST labels. Does not mention alternatives but none exist among siblings.
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!