Loading ToolBench

Reading the current corpus…

shiprocket-mcp MCP server · D · ToolBench

shiprocket-mcp

Model Context Protocol server for integrating Shiprocket logistics platform, enabling order tracking, delivery estimation, and order management through MCP tools with OAuth 2.0 authentication.

<=2025-11-25STREAMABLE_HTTP3 tools

53/100

Definition Quality61

Protocol Readiness66

Supportability31

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Dynamic Client Registration

Deprecated protocol patterns detected

Summary

The Shiprocket MCP server defines 3 tools with basic structure, but quality is uneven across dimensions. All tools have descriptions and schema definitions, but descriptions are generic and lack LLM optimization. Parameter schemas are present with type declarations and enums where appropriate, but descriptions for parameters are minimal. Output schemas are documented in descriptions but not formally specified. Error handling exists but lacks recovery guidance for common failure modes. Tool naming is reasonable (action_noun pattern), but composition and parameter constraints could be stronger.

Tools (3)

estimated_deliveryread onlyauthsource verified62/100

Get the Estimated Date of Delivery (EDD) for a given destination. Args: delivery_pincode: String representing pincode of order delivery destination Returns: Dictionary containing following info: estimated_delivery_date: Date-time formatted string representing expected date & time of delivery delivery_pincode: String representing pincode of order delivery destination

order_listread onlyauthsource verified58/100

Get list of orders Args: status: Optional ENUM('NEW', 'READY_TO_SHIP', 'IN_TRANSIT', 'DELIVERED') representing status filter for orders Return: List of dictionary containing following info:

order_trackread onlyauthsource verified64/100

Get order tracking related information. Args: awb_number: String representing AWB number assigned to the order Returns: Dictionary containing following info: order_status: String representing order status awb_number: String representing AWB number of order last_activity: String representing last marked activity of order last_scan_location: String representing last marked location of order last_scan_time: Timestamp formatted string representing last order scan timestamp tracking_url: String representing URL of order tracking page

Issues (6)

CRITICALtool-description ↗

order_list description is truncated and incomplete ('Return: List of dictionary containing following info:' cuts off mid-sentence). Agents cannot infer the fields or structure.

order_list

HIGHpaginated-result ↗

No pagination (limit, offset, page_size) parameters on list_orders. Agents cannot safely retrieve large result sets; responses risk blowing context window.

order_list

HIGHconstrained-input ↗

Parameter descriptions lack format/constraint details. E.g., 'delivery_pincode' accepts any string; no validation that it is a valid Indian postal code or 6-digit format. 'awb_number' has no length or pattern constraint.

estimated_deliveryorder_track

MEDIUMresponse-shaper ↗

Output schemas are documented in description text only, not in formal response type definitions. LLMs must parse unstructured text to infer response fields.

estimated_deliveryorder_track

Recommendations

Complete the order_list description immediately: specify exactly which fields are returned (e.g., order_id, customer_name, status, created_date, estimated_delivery). Cap result limit at 20-50 and document in description.
Add pagination parameters to order_list: accept 'limit' (1-100, default 20) and 'offset' (default 0) or 'cursor'. Return total_count in response so agents know if more results exist.
Enhance parameter descriptions with format constraints: 'delivery_pincode: 6-digit Indian postal code (e.g. 110001 - 999999)', 'awb_number: 12-character alphanumeric shipment tracking number assigned by courier'.
Define formal response schemas for each tool (e.g., TypeScript interface or JSON Schema). Currently output is documented ad-hoc in description text; formalize it so response shape is unambiguous.
Improve error handling: categorize errors as retryable (rate limit, timeout) vs user-fixable (invalid pincode format, non-existent AWB) vs fatal. Return structured error response: { isError: true, code: 'INVALID_PINCODE', message: '110001 is valid; got 11. Expected 6-digit code', nextSteps: 'Verify pincode and retry' }.
Add idempotentHint to tool annotations: estimated_delivery and order_track appear idempotent (repeated calls with same input return identical output, no side effects). Declare this explicitly.
Consider whether estimated_delivery should accept a date/timeframe parameter to show delivery estimates for different shipment dates, or if order_list should support filtering by date range. Current design is minimal but may be incomplete for typical agent workflows.

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Dynamic Client Registration (deprecated) - use Client ID Metadata Documents (CIMD)

Score history

Overall score trend

↑ 34 points across a rubric change (v1 → v2)

53/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-22	D	53	<=2025-11-25	v2
2026-03-09	F	19	-	v1