Loading ToolBench
MCP server for Fintual API integration, providing tools to authenticate users, retrieve asset provider information, and fetch fund performance data for four investment funds with different risk profiles
The server has 10 tools with basic descriptions and input schemas, but significant quality gaps reduce the overall score. Tool naming is reasonable but some names are repetitive (get_very_conservative_streep, get_conservative_clooney, get_moderate_pit, get_risky_norris are variants of the same operation on different funds). Descriptions vary in quality, some are brief and lack context on when to use the tool or what it returns. Input schemas are present but parameter descriptions are minimal (e.g., 'The ID of the asset provider' lacks format/range guidance). Output schemas are not documented anywhere, tools return JSON responses but there's no schema specification for what fields to expect. Error handling is present but generic ('An unexpected error occurred') without guidance on recovery steps. The login tool exposes sensitive parameters (email/password) which should be handled via server-side injection in a production environment.
Gets the list of asset providers from the API
Gets the list of banks from the API
Gets the asset provider by ID from the API
Gets the conceptual asset by asset provider ID from the API
Obtiene el valor cuota del fondo Conservative Clooney (ID: 188)
Obtiene el valor cuota de cualquier fondo por su ID
Obtiene el valor cuota del fondo Moderate Pit (ID: 187)
No output schemas documented. Tools return JSON responses but the agent has no specification of what fields to expect, their types, or which are required. This forces LLMs to parse unstructured responses.
Credentials (email/password) exposed as tool parameters in login(). Should use server-side secret injection via environment variables or vault. Agent traces log all parameters, secrets leak into logs.
Four fund-specific tools (get_very_conservative_streep, get_conservative_clooney, get_moderate_pit, get_risky_norris) are redundant variants of the same operation. Should consolidate into get_fund_data with a fund_id parameter. Duplicate tools waste LLM reasoning cycles.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Obtiene el valor cuota del fondo Risky Norris (ID: 186)
Obtiene el valor cuota del fondo Very Conservative Streep (ID: 15077)
Authenticates a user with Fintual API and returns an access token
Parameter descriptions are minimal. 'The ID of the asset provider' lacks format guidance (is it a UUID? integer?), range (min/max), or valid values. 'Fecha hasta la cual obtener datos (formato YYYY-MM-DD)' is good, but others like 'ID del fondo' omit context.
Discovery tools (asset_providers, banks) lack descriptions explaining what data they return and when to call them. E.g., 'Gets the list of banks from the API' does not say whether this returns bank account options, payment partners, or something else.
Error handling is generic and non-actionable. 'An unexpected error occurred: {e}' or 'Error: {e}' tells the agent nothing about recovery steps. Per the rubric, errors should categorize as retryable, user-fixable, or fatal.
No pagination support on list tools. asset_providers and banks likely return unbounded lists. Tools returning lists should accept page/offset/limit and return total_count or next_cursor to avoid context window exhaustion.
Tool descriptions are too brief. 'Gets the list of asset providers from the API' (40 chars) lacks context. Should explain: what asset providers are (investment options?), when to call this tool, what the response structure is, and how it chains with other tools.