Loading ToolBench
MCP server for the agent_fabric x402 marketplace that exposes API proxies and workflows as tools, with payment-based access control
The agent_fabric MCP server exposes two dynamically-generated tools with significant quality gaps. Both tools rely on dynamic schema generation from proxy/workflow configurations stored in a database, making static validation difficult. Tool naming lacks action verbs. Descriptions are present but generic. Input schemas are dynamically constructed at runtime from configuration objects, which limits visibility and raises concerns about schema consistency. Error handling appears minimal. The server's architecture prioritizes flexibility for user-configured workflows over the agentic tool patterns that enable reliable LLM tool selection and chaining.
Creates MCP tools from API proxy configurations that forward requests to backend APIs with x402 payment headers
Creates MCP tools from workflow definitions that execute multi-step sequences with on-chain transaction support
Tool names lack action verbs (verb_noun pattern). 'dynamic proxy tool' and 'dynamic workflow tool' are descriptors, not actions. LLMs cannot infer intent from names alone. Should be 'execute_proxy_request' or 'call_proxy', 'execute_workflow' or similar.
Input schemas are dynamically generated from database configurations (variablesSchema, inputSchema fields). The actual parameter names, types, and constraints are not visible in the source code, they are constructed at runtime from user-provided proxy/workflow definitions. This means: (1) we cannot statically verify schema quality; (2) parameters lack consistent descriptions; (3) LLMs cannot reliably infer parameter meaning without seeing the actual schema.
Parameter descriptions are inferred from user-provided metadata (e.g., 'Dynamic schema built from proxy's variablesSchema'). This is generic and non-actionable for LLMs. No parameter-level guidance: what values are valid? What format? What do they control? The pattern 'supports string, number, boolean, array, and object types' describes type support, not parameter semantics.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | <=2025-11-25 | v2 |
Output schema is not documented. Callers do not know what fields to expect, what structure is returned, or how to chain calls downstream. The ToolResult interface (content array with text) is defined in code but never exposed to the LLM in the tool definition.
No error recovery guidance. The proxy-tool.ts handler returns generic error messages ('Proxy not found', 'Error: ...') without actionable next steps. LLMs cannot distinguish retryable errors from fatal ones. No suggestion of alternative tools or corrective actions.
Tool descriptions do not declare side effects or reversibility. 'dynamic proxy tool' creates requests to backend APIs (WRITE risk). 'dynamic workflow tool' executes multi-step sequences with on-chain transactions (IRREVERSIBLE risk). LLMs must know these are destructive before invocation. No mention of confirmation steps or dry-run modes.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in tool definitions. These hints are crucial for agents to reason about safety, idempotency, and chaining.
Dynamic schema generation from unvalidated user input. The buildInputSchema() function in proxy-tool.ts processes variable definitions from the database without strict validation. If a workflow configuration contains a malformed variablesSchema, the generated Zod schema may be invalid. No graceful degradation or error reporting if schema construction fails.