Lists loan contracts per bank connection (GET /loans). Pass items as an array of connection selectors (item_id uuid, connector_id, or connector_name) — one entry per connection to fetch; multiple connections are queried sequentially with rate-limit spacing. OMIT items to list loans across ALL linked banks. Returns { results, errors } per connection.
| Name | Required | Description | Default |
|---|---|---|---|
| items | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations declare readOnlyHint=true and idempotentHint=true, the description adds valuable details about sequential querying, error handling per connection, and the return format (`{ results, errors }`), enriching the behavioral model beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no wasted words. The first sentence states purpose and endpoint, the second explains the parameter, and the third covers the omission case. Information is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single optional parameter, no output schema, and simple role (listing loans), the description covers all necessary details: usage patterns, query behavior, and return structure. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully compensates for the 0% schema description coverage by explaining the `items` parameter's type (array of connection selectors: item_id uuid, connector_id, or connector_name) and its purpose—one entry per connection. This is thorough and actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'lists' and resource 'loan contracts per bank connection', specifies the HTTP endpoint, and differentiates from sibling tools like get_loan_detail which focuses on a single loan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use the `items` parameter (for specific connections) versus omitting it (for all banks), and describes sequential querying with rate-limit spacing. This provides clear guidance on usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each openfinance_* tool targets a distinct resource (account, transaction, bill, loan, investment) with a clear action (get/list/update/force_sync). The administrative tools (connect, authenticate, report_bug) are clearly separate. No two tools appear to perform the same function.
The openfinance_* tools follow a consistent verb_noun pattern (e.g., get_account_balance, list_transactions, update_transaction_category). Minor deviations like openfinance_provider_status (lacks a verb) and openfinance_force_sync (verb phrase) slightly break the pattern, but the overall convention is predictable.
25 tools is on the higher end but appropriate for a comprehensive Open Finance server covering accounts, transactions, bills, loans, investments, connections, and administration. Each tool has a distinct purpose and none feel redundant.
The tool surface is complete for the domain: it covers connection management (connect/disconnect/force sync/status), account and transaction queries, credit card bills, loans, investments, and transaction categorization, plus admin utilities. No obvious gaps that would block typical workflows.