India Logistics (Shiprocket: courier serviceability + rates, create orders, track AWB)
Server Details
India shipping for AI agents: Shiprocket courier serviceability, create orders, track AWB.
- Status
- Healthy
- 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.6/5 across 4 of 4 tools scored.
Each tool has a completely distinct purpose: serviceability quotes, order creation, cancellation, and tracking. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern (check_serviceability, create_shipment, cancel_shipment, query_tracking) using snake_case.
4 tools are well-scoped for the domain of logistics – covering rate checks, order creation, cancellation, and tracking without unnecessary bloat.
Core workflow is covered, but the critical step of assigning courier/generating AWB after creation is missing, requiring external steps or missing tools.
Available Tools
4 toolscancel_shipmentADestructiveIdempotentInspect
Cancel one or more India Shiprocket orders by their Shiprocket order id(s). Pass a single order_id or an array of ids. Cancellation is only possible before the parcel is picked up / in transit — an already-shipped order cannot be cancelled here (it would need an RTO). Returns the cancellation result reported by Shiprocket.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | No | A single Shiprocket order id to cancel (the numeric id Shiprocket returned, not your own reference). | |
| order_ids | No | Alternative: an array of Shiprocket order ids to cancel in one call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds valuable context about preconditions (only before pickup) and return value (cancellation result), going beyond 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?
Two concise sentences, front-loaded with the main action. Every sentence provides necessary information without redundancy.
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?
Completely describes the tool's functionality, constraints, and return value. No output schema exists, but the description adequately covers what the agent needs to know.
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% with descriptions for both parameters. The description further clarifies that order_id is a single string representing Shiprocket's numeric ID, distinguishing it from user references, adding value 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?
The description clearly states the tool cancels Shiprocket orders by order IDs, specifying the action, resource, and domain. It distinguishes from siblings like query_tracking and create_shipment.
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?
Provides explicit context on when cancellation is possible (before pickup) and when it is not (already shipped), with an alternative mentioned (RTO). Does not directly compare to siblings, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_serviceabilityARead-onlyInspect
India shipping courier serviceability + live rate quote — THE tool to call FIRST. Given a pickup pincode, a delivery pincode, the parcel weight (KG) and whether it is COD, it returns every courier company (Delhivery, Bluedart, Ekart, Xpressbees, DTDC etc.) that can carry the parcel, each with its freight rate (INR), estimated delivery days and rating, plus which one is cheapest. Read-only: quotes only, creates nothing and spends nothing. Bring your own Shiprocket merchant credentials via headers x-shiprocket-email + x-shiprocket-password.
| Name | Required | Description | Default |
|---|---|---|---|
| cod | No | true = Cash On Delivery, false = Prepaid. Default false. Serviceability differs by payment mode. | |
| weight | Yes | Parcel weight in KILOGRAMS (kg). e.g. 0.5 = 500 g. Required. | |
| declared_value | No | Optional order value in INR — some couriers gate by declared value / COD amount. | |
| pickup_postcode | Yes | Origin pincode (6-digit Indian postal code the parcel ships FROM). Must be a serviceable pickup pincode on your Shiprocket account. | |
| delivery_postcode | Yes | Destination pincode (6-digit Indian postal code the parcel ships TO). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description reinforces this by stating 'Read-only: quotes only, creates nothing and spends nothing.' No contradiction exists. The description adds clarity about the read-only nature and the output (list of couriers with rates, days, rating, cheapest).
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 concise with two short paragraphs. The purpose is front-loaded in the first sentence. Every sentence serves a purpose: describing inputs, outputs, read-only nature, and authentication requirements. No wasted 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?
The description covers the main behavior and output, mentions authentication, and explains what is returned (list of couriers with freight rate, delivery days, rating, cheapest). It does not describe error handling or limits, but given the complexity and that there is no output schema, it is reasonably 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%, so baseline is 3. The description adds context by explicitly explaining how each parameter (pickup pincode, delivery pincode, weight in KG, COD) is used to generate the result. It doesn't mention the optional 'declared_value' parameter, but overall it adds value 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?
The description clearly specifies the tool's purpose: checking India shipping courier serviceability and getting live rate quotes. It uses a specific verb ('check') and resource ('courier serviceability + rates'), and distinguishes itself from sibling tools by positioning itself as the tool to call first before creating a shipment.
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 'THE tool to call FIRST', indicating it should be used before create_shipment. It also specifies required authentication via headers, providing clear guidance on when and how to use the tool. The context of sibling tools implies when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_shipmentAInspect
Create an India shipping order in Shiprocket (adhoc order) — pass the pickup_location nickname (a pickup address you already registered in your Shiprocket dashboard), the buyer billing address, the order_items, the payment_method (COD or Prepaid), the order value (sub_total, INR) and the parcel box in CENTIMETRES (length/breadth/height) + weight in KILOGRAMS. Returns the Shiprocket order_id and shipment_id you then use to assign a courier / print the AWB label and to track. NOTE: creating the order does NOT yet debit your Shiprocket wallet — wallet is charged only when you assign a courier / generate the AWB (a step you do in the dashboard or a later tool). Bring your own Shiprocket merchant credentials via headers x-shiprocket-email + x-shiprocket-password. A completed KYC (Aadhaar/GSTIN) and a registered pickup location are merchant-side prerequisites before real parcels ship. Owner policy headers gate the order value before creation.
| Name | Required | Description | Default |
|---|---|---|---|
| height | Yes | Parcel height in CENTIMETRES (cm). Required, > 0.5. | |
| length | Yes | Parcel length in CENTIMETRES (cm). Required, > 0.5. | |
| weight | Yes | Parcel weight in KILOGRAMS (kg). Required, > 0. | |
| breadth | Yes | Parcel breadth in CENTIMETRES (cm). Required, > 0.5. | |
| order_id | No | Your own order reference (any unique string). Optional — a timestamp-based id is generated if omitted. | |
| sub_total | Yes | Order value in INR (sum of line items). Required. Owner policy headers gate this amount before the order is created. | |
| order_date | No | Order date "YYYY-MM-DD HH:mm". Optional — defaults to now. | |
| order_items | Yes | Line items in the parcel. At least one. Each: { name (required), units (required int), selling_price (required INR), sku (optional) }. | |
| billing_city | Yes | Buyer city. | |
| billing_email | Yes | Buyer email. | |
| billing_phone | Yes | Buyer 10-digit phone. | |
| billing_state | Yes | Buyer state (e.g. Maharashtra, Karnataka). | |
| shipping_city | No | Shipping city (only if shipping_is_billing=false). | |
| payment_method | Yes | COD or Prepaid. Required. | |
| shipping_phone | No | Shipping phone (only if shipping_is_billing=false). | |
| shipping_state | No | Shipping state (only if shipping_is_billing=false). | |
| billing_address | Yes | Buyer street address line 1. | |
| billing_country | No | Buyer country. Default India. | |
| billing_pincode | Yes | Buyer 6-digit Indian pincode. | |
| pickup_location | Yes | The nickname of a pickup address ALREADY registered in your Shiprocket dashboard (Settings → Pickup Addresses). Required — must match exactly. This is where the courier collects the parcel. | |
| shipping_address | No | Shipping street address (only if shipping_is_billing=false). | |
| shipping_country | No | Shipping country (only if shipping_is_billing=false). Default India. | |
| shipping_pincode | No | Shipping pincode (only if shipping_is_billing=false). | |
| billing_address_2 | No | Buyer street address line 2. Optional. | |
| billing_last_name | No | Buyer last name. Optional. | |
| shipping_is_billing | No | true (default) = ship to the billing address. Set false to provide a separate shipping_* address. | |
| billing_customer_name | Yes | Buyer first name. | |
| shipping_customer_name | No | Shipping recipient name (only if shipping_is_billing=false). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description clearly states the tool creates a shipment order but does not debit the wallet, and returns IDs for later use. It also mentions owner policy headers gate order value. This adds significant context beyond annotations (readOnlyHint=false, destructiveHint=false) and 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?
Two clear paragraphs: first describing the essential flow, second adding prerequisites and header requirements. It is front-loaded with key information but could be slightly more structured (e.g., bullet points).
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 28 parameters, no output schema, and sibling tools, the description covers the main process, return values, and prerequisites. It lacks explanation of error states or rate limits but is sufficiently complete for an AI 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 description coverage is 100%, so baseline is 3. Description adds value by specifying units (cm, kg, INR), explaining pickup_location must match dashboard, and clarifying order_items format. 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?
Description explicitly states 'Create an India shipping order in Shiprocket (adhoc order)' with a clear verb and resource. It distinguishes from siblings like cancel_shipment, check_serviceability, and query_tracking by focusing on order 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 mentions prerequisites (registered pickup location, KYC) and notes that wallet is not debited yet. It implies using later tools for courier assignment. However, it does not explicitly state when not to use this tool or mention alternatives beyond 'later tool'.
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 an India shipment by its shipment_id (the one create_shipment returned) or by AWB number. Returns the current courier status plus a plain-English hint. Common Shiprocket statuses: NEW, PICKUP SCHEDULED, PICKED UP, IN TRANSIT, OUT FOR DELIVERY, DELIVERED, UNDELIVERED, RTO INITIATED, RTO DELIVERED, CANCELED, LOST. The raw tracking_data (scan activities, EDD, courier) is always included. Non-terminal statuses carry next_steps. Safe to call anytime. NOTE: a brand-new order shows no tracking until a courier/AWB is assigned.
| Name | Required | Description | Default |
|---|---|---|---|
| awb | No | Alternative to shipment_id: the AWB / tracking number assigned by the courier. | |
| shipment_id | No | The shipment_id returned by create_shipment (preferred). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true. The description adds specifics: returns status plus hint, includes raw tracking_data, lists common statuses, and mentions next_steps for non-terminal statuses. No contradiction exists.
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 concise yet informative, front-loading the main action and then detailing status information and a note. Every sentence provides value without redundancy.
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 lacking an output schema, the description adequately explains return values including status, raw data, and next_steps. It covers the common statuses list and usage caveat. Could benefit from more detail on the hint format, but sufficient for most use cases.
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% with parameter descriptions. The description adds context about preferred use of shipment_id vs AWB and explains the purpose of each, which goes 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?
The description clearly states it tracks an India shipment by shipment_id or AWB, returning courier status and plain-English hint. It distinguishes itself from sibling tools like cancel_shipment, check_serviceability, create_shipment by being a read-only tracking tool.
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 notes 'Safe to call anytime' and warns that a brand-new order shows no tracking until courier/AWB assigned, providing temporal guidance. It does not explicitly state when not to use compared to alternatives, but the context is clear.
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!