Loading ToolBench
The BAMM MCP server has 7 tools with basic parameter schemas and descriptions, but exhibits significant quality gaps. Tool names follow a reasonable verb_noun pattern (ADD_COLLATERAL, BORROW, GET_POSITIONS, etc.), but descriptions are generic and lack LLM-optimized context. Most critically: (1) All 7 tools lack documented output schemas, the tool definitions show input schemas only, with no specification of what fields/structure will be returned; (2) Optional parameters with unspecified resolution logic create ambiguity (e.g., ADD_COLLATERAL accepts both 'collateralToken' address AND 'collateralTokenSymbol', but no guidance on which takes precedence or how mismatches are handled); (3) Error handling is absent from all tool descriptions, no guidance on failure modes, retries, or recovery steps; (4) Parameter descriptions are minimalist (e.g., 'The BAMM pool address' with no format, length, or validation hints); (5) No indication of idempotency, permission requirements, or destructive consequences for write operations. The server uses FastMCP (good for schema validation), but the schema definitions themselves are sparse.
Add collateral tokens to a BAMM position
Borrow tokens from a BAMM pool by providing collateral
Retrieve all active BAMM positions for the connected wallet
Lend Fraxswap LP tokens to a BAMM pool
Get statistics for all available BAMM pools
Remove collateral tokens from a BAMM position
Repay borrowed tokens to a BAMM pool
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or extract data when they don't know what fields/structure will be returned. All 7 tools are affected.
Tool descriptions are generic and lack LLM-optimized context. 'Add collateral tokens to a BAMM position' (42 chars) does not explain when to use this tool, what prerequisites exist, or how it differs from similar operations. Baseline for A+ tools is 50-200 chars with WHEN/WHY context.
Parameter descriptions lack format/constraint details. 'The BAMM pool address' provides no indication of format (is it an Ethereum address? checksummed? lowercase?), length, or validation rules. Similarly, 'The amount to add in normal decimal form (e.g., "10" for 10 tokens)' includes an example value that LLMs may reuse literally rather than adapt to context.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2026-07-28+ | v2 |
Multiple write operations (ADD_COLLATERAL, BORROW, LEND, REMOVE_COLLATERAL, REPAY) lack error guidance and destructive operation warnings. No indication of: (1) failure modes (insufficient collateral, slippage, insufficient balance); (2) whether operations are retryable or destructive; (3) recovery guidance if a call fails. LLMs cannot plan recovery without this information.
Ambiguous optional parameter handling in ADD_COLLATERAL, BORROW, REMOVE_COLLATERAL, REPAY. These tools accept BOTH a token address ('collateralToken' / 'borrowToken') AND a symbol ('collateralTokenSymbol' / 'borrowTokenSymbol'), but the tool description does not specify: (1) which takes precedence if both are provided; (2) whether one is required if the other is missing; (3) how resolution works (symbol lookup, address validation). This forces LLMs to guess and risks type confusion.
No indication of idempotency, confirmation, or dry-run support for destructive write operations. Agents may retry on transient failures, if REMOVE_COLLATERAL or REPAY are not idempotent, repeated calls risk unintended state changes. No pattern guidance.
GET_POSITIONS and POOL_STATS have empty input schemas ({}) but no description of pagination, result limits, or filtering. If these return large lists, they risk context explosion. No indication of whether results are capped, paginated, or unbounded.