Loading ToolBench
Model Context Protocol (MCP) server for Sure personal finance platform
Server provides 5 READ_ONLY tools with basic descriptions and input schemas. All tools follow verb_noun naming and have documented input parameters with types. However, descriptions are minimal (10-30 characters), lacking context about WHEN to use each tool and WHY it matters. Output schemas are not documented, LLMs cannot know what fields to expect or how to chain tools. No error handling guidance or recovery patterns. Tools lack parameter descriptions entirely (list_accounts and get_account have params with no descriptions beyond the schema type). This is a functional baseline but well below production quality.
Check if authentication is configured for Sure API.
Test connection to Sure API.
Retrieve a single account by ID.
List all financial accounts from Sure with optional pagination.
Get instructions for setting up authentication with Sure.
Descriptions are too brief (10-35 chars) and lack decision context. LLMs cannot determine WHEN to use check_auth_status vs setup_authentication, or WHY they should call check_connection. Descriptions should be 50-200 chars and answer: What does it do? When to call? What's returned?
Output schemas are completely undocumented. Source code does not show what fields setup_authentication, check_auth_status, check_connection, or list_accounts return. LLMs cannot plan downstream operations or extract the correct response fields. Every tool must document its return type.
Parameter descriptions are missing. list_accounts has 'page' and 'per_page' parameters with schema types but NO descriptions explaining valid ranges, defaults, or behavior. get_account has 'account_id' with no description of format (UUID? alphanumeric? system ID vs user-provided?). Per pattern:tool-description, every parameter must be described.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No error handling or recovery guidance. If check_connection fails, what should the agent do? If list_accounts returns empty, is that normal or an error? If get_account receives an invalid account_id, what error message does it return? No error classification (retryable, user-fixable, fatal) provided.
list_accounts pagination lacks total count or next_cursor. Without knowing if there are more results, agents cannot reliably fetch all accounts. Per pattern:paginated-result, paginated endpoints must return pagination metadata (total_count, has_next, next_page, or cursor).
No result-limiting guidance in descriptions. If Sure API returns thousands of accounts, will list_accounts cap at 20? 50? Unbounded results blow the context window. Description should state: 'Returns up to 50 accounts per page; use page parameter to iterate.'