Loading ToolBench
FedEx Developer Portal MCP Server — exposes FedEx APIs as MCP tools for AI agents
The FedEx MCP server demonstrates solid tool design with well-structured schemas, clear naming conventions, and comprehensive parameter documentation. All 5 tools are explicitly registered with verb_noun naming (track_package, get_rates, validate_address, create_shipment, check_services). However, several high-impact gaps prevent a higher score: (1) Tool descriptions lack explicit guidance on when to use each tool vs. similar ones (e.g., get_rates vs. check_services distinction is unclear). (2) Error handling is not visible in the provided code samples, no evidence of recovery guidance or error classification. (3) The create_shipment tool shows good confirmation pattern documentation but lacks visible error messages for invalid inputs. (4) Output schemas are not documented in the tool definitions themselves, only input schemas are visible. (5) Tool descriptions, while present, average ~150 chars but lack concrete examples of what users should expect back. The server includes helpful resources (service catalog, packaging reference) and prompts (shipping wizard) that elevate the UX, but core tool-level output documentation is missing.
Check which FedEx services are available between an origin and destination. Returns available service types, packaging options, and transit times.
Create a FedEx shipment and generate a shipping label. IMPORTANT: This tool requires human confirmation before executing — it will first present a shipment summary and wait for approval. Set confirmed=true only after the user has explicitly approved the shipment details.
Get FedEx rate quotes for a shipment. Returns all available services sorted by price, with transit times and delivery dates.
Track a FedEx package by tracking number. Returns current status, location, estimated delivery date, and scan history.
Validate a shipping address with FedEx. Checks if the address is valid, corrects minor errors, and identifies residential vs commercial addresses.
Missing output schema documentation for all tools. Input schemas are well-defined, but what each tool returns is not documented in the tool definitions themselves. This forces LLMs to infer structure from trial-and-error or context clues.
Error handling and recovery guidance not visible in tool implementations. No evidence of try-catch blocks, error categorization, or actionable error messages that tell LLMs whether to retry, ask the user, or abandon the operation.
Tool descriptions do not explain WHEN to use a tool vs. similar alternatives. For example, get_rates and check_services both provide service options, but it's unclear which to call in which scenario. Description should state: 'Use get_rates for pricing quotes across services. Use check_services for service availability and transit times without pricing.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Secrets in environment variables (FEDEX_CLIENT_ID, FEDEX_CLIENT_SECRET) are correctly NOT exposed as tool parameters. However, the code does not show explicit validation that these are present at startup, missing credentials will surface only at runtime when a tool is invoked.
Pagination and result limits not visible for tools that may return large datasets (e.g., track_package with includeHistory=true could return hundreds of scan events). No limit parameter, no pagination metadata in responses.