Revokes the Open Finance consent for a specific bank and deletes the connection data. The bank's data will no longer be available. Returns an add_connection_url to re-connect if needed.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive (destructiveHint=true, readOnlyHint=false). The description adds valuable behavioral details: 'The bank's data will no longer be available' and 'Returns an add_connection_url to re-connect if needed'. This goes beyond the annotations by explaining consequences and recovery, giving the agent a clearer picture of the operation's impact.
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?
The description is only two sentences, front-loaded with the primary action. It explains both what the tool does and a key recovery mechanism (the returned add_connection_url). Every sentence earns its place, with no redundant or vague phrasing.
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?
The tool is simple (1 parameter, no output schema), but the description covers the effect and return value. However, the critical parameter 'item' is unexplained, and there is no mention of prerequisites (e.g., existing connection) or edge cases (e.g., already disconnected). While the behavioral context is good, the missing parameter details prevent this from being fully complete.
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 input schema has one required parameter 'item' (string) with no description coverage. The description mentions 'a specific bank' but never explains what 'item' should be (e.g., bank ID, connection ID, item ID). With 0% schema coverage and no parameter explanation in the description, the agent cannot confidently determine the correct value to pass. This is a significant gap.
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 uses the specific verb 'Revokes' and clearly states the resource: 'Open Finance consent for a specific bank' and 'deletes the connection data'. This distinguishes it from all sibling tools, which are focused on reading or updating data. There is no ambiguity about what this tool does.
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?
The description provides clear context: this tool is used when you need to revoke consent and delete a bank connection. However, it does not explicitly mention alternatives or when not to use it. The context is sufficient for most cases, but lacks explicit exclusions or cross-references to sibling tools.
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 tool targets a specific resource/action (balance, transactions, bills, loans, investments, connections, categories, provider status), with clear boundaries. Minor overlap exists between openfinance_list_transactions and openfinance_list_transactions_by_item, and among the multiple account-related tools, but the descriptions are detailed enough to disambiguate.
Almost all tools follow an openfinance_<verb>_<noun> snake_case pattern (list_accounts, get_credit_card_bill, update_transaction_category). Minor deviations include openfinance_provider_status (noun_noun) and openfinance_list_transactions_by_item (extra preposition), but the overall convention is predictable and consistent.
19 tools is on the heavier side but fits the broad scope of an Open Finance banking integration covering connections, accounts, transactions, credit cards, loans, investments, and provider health. Each tool appears justified; the count does not feel bloated.
The surface covers the full lifecycle: connection discovery/search/list/sync/disconnect/status, account and transaction retrieval, credit card bill summaries and detail, loans, investments, transaction categorization, and provider diagnostics. No critical dead ends are apparent for the stated banking data domain.