Loading ToolBench
Production-grade shipping utility that parses package details, computes volumetric weight, runs postal code format audits, and constructs EasyPost/FedEx standard API payloads.
The server defines 2 tools with partial schema documentation and varying quality. Both tools have descriptions, but parameter descriptions are sparse and some critical information is missing. Tool naming follows verb_noun conventions adequately. No input validation guidance, error recovery instructions, or output schema documentation visible. The implementation appears to be standalone Python (not MCP-integrated), and the source does not show MCP server registration, handler setup, or protocol compliance.
Estimates shipping parameters and outputs a clean payload draft for shipping carriers.
Validates basic postal code formats for US and general international rules.
Output schema not documented. generate_label_draft returns a Dict with keys 'volumetric_weight_lbs', 'postage_rate_est', and 'carrier_payload', but no schema is provided to the LLM. LLMs cannot plan downstream operations or extract fields without a documented return schema.
Parameter descriptions incomplete or missing. 'sender' and 'recipient' objects are described at the object level, but individual nested fields (street, city, postal_code, country) lack usage context. No mention of format requirements, constraints, or when each field is mandatory. 'parcel' similarly lacks detail on valid ranges for dimensions and weight.
No error guidance or recovery instructions. The code raises ValueError for invalid postal codes (e.g., 'Invalid sender postal code format.'), but the tool definition does not document what errors can occur, when to retry, or what the LLM should do next (e.g., 'Call validate_postal_code first').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2026-07-28+ | v2 |
validate_postal_code returns a boolean (True/False) with no structured error explanation. An LLM given 'False' does not know why validation failed or how to fix it. Return should include the reason: {"valid": false, "reason": "Must be 5 digits for US postal codes"}.
No constraint documentation for numeric parameters. 'length_in', 'width_in', 'height_in', 'weight_oz' are numbers, but their valid ranges (min/max) are not documented. LLMs may pass nonsensical values like negative dimensions or weights >10000 oz without guidance.
No format or enum constraints on country code parameter. Descriptions say 'Country code' but do not specify ISO 3166-1 alpha-2 (US, CA) vs alpha-3 (USA, CAN) vs full name. The implementation assumes alpha-2 ('US') but does not enforce it.
MCP server registration and protocol implementation not visible in provided source. No evidence of MCP server initialization, tool handler registration via MCP SDK, or protocol message handling. This appears to be a standalone Python class, not an MCP server ready for agent integration.