Loading ToolBench
Real-time supply chain risk intelligence — 34 tools, proprietary indices, predictive signals
This server exhibits critical definition quality failures across all dimensions. The two tools have minimal descriptions, no input schema validation, no output schema documentation, and no error handling guidance. The architecture itself is problematic: tools/list and tools/call are meta-tools that proxy to a remote SupplyMaven API rather than exposing domain-specific tools directly. This violates the single-responsibility principle and makes it impossible for LLMs to understand what actual operations are available without runtime discovery. Descriptions are under 20 characters for both tools, triggering hard scoring rules. No parameter validation, no error recovery paths, and no security considerations around credential handling are evident.
Call a tool on remote SupplyMaven server
Fetch list of available tools from remote SupplyMaven server
Tools have descriptions under 20 characters ('Fetch list of available tools from remote SupplyMaven server' is ~60 chars but 'Call a tool on remote SupplyMaven server' is ~42 chars). Per hard scoring rule, description scores capped at 0-20 for both tools.
tools/call has no documented input schema in the source code. The only schema visible is a minimal inline definition {"name": {"type": "string"}, "arguments": {"type": "object"}} with no validation, no constraints on the 'arguments' object, and no description of what valid argument structures look like. Per hard scoring rule, schema score must be 0.
No output schema documented for either tool. LLMs cannot plan downstream calls or extract structured data when return types are undocumented. tools/call returns a result from the remote API with no format specification visible in code.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 31 | 2026-07-28+ | v2 |
Architectural anti-pattern: tools/list and tools/call are meta-tools that proxy to a remote server. They do not expose domain-specific operations (e.g., assess_supplier_risk, get_geopolitical_alerts, predict_disruption). LLMs have no visibility into what the 34 tools mentioned in package.json actually do. This violates single-responsibility and makes tool discovery non-deterministic.
No error handling or recovery guidance. The callTool function returns a generic 'No response' or 'Error' message with no explanation of what went wrong, no classification (retryable vs fatal), and no actionable next steps for the LLM. Per pattern:recovery-guide, error responses must tell the agent what to do.
API key passed as environment variable SUPPLYMAVEN_API_KEY with no rotation guidance, expiration handling, or scope declaration. No per-tool permission checks. Credentials are injected at server startup, not per-request, limiting multi-tenant deployments and audit granularity.
tools/call lacks parameter validation. The 'arguments' parameter is typed as 'object' with no shape, no enum constraints, no required-field enforcement. LLMs will pass arbitrary objects that the remote API may reject, with no local validation feedback.
No pagination or result limiting visible in tools/list. If the remote SupplyMaven server returns 34+ tools, the entire list floods the LLM context. No limit, offset, or cursor pattern implemented.
SSE/Event-stream parsing is fragile. The code splits response text on '\n' and looks for 'data:' prefix, then parses JSON. No error handling for malformed SSE, missing data lines, or JSON parse failures. Will silently return empty arrays or generic errors.
Parameter descriptions missing entirely. The 'name' and 'arguments' parameters in tools/call have descriptions in the type definition, but they are minimal ('Tool name to call', 'Tool arguments') and do not explain valid name formats, how to discover names, or what argument shape is expected.