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 |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds that the data is deleted and a re-connection URL is returned, but does not detail other behavioral aspects like authorization needs or rate limits.
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 sentences, no extraneous text. Each sentence contributes: action, effect, and return value.
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?
With no output schema and a vague parameter, the description should clarify the parameter meaning and full return payload. The mention of add_connection_url helps but is insufficient.
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 single parameter 'item' is not explained. Schema coverage is 0% and the description does not clarify what 'item' represents (e.g., bank ID, connection ID). This hinders correct invocation.
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 action: revokes consent and deletes connection data for a specific bank. It distinguishes from sibling tools like openfinance_list_connections (read-only) by emphasizing destructive behavior.
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?
It explains the consequence (data no longer available) and provides a re-connection path via returned URL. However, it does not explicitly state when to use this vs. other tools or prerequisites.
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.
The openfinance_* tools are mostly distinct resource/action pairs, but several boundaries blur: openfinance_list_transactions vs openfinance_list_transactions_by_item vs openfinance_get_credit_card_bill(include_transactions) all return transaction data, and openfinance_get_item_status / openfinance_provider_status / openfinance_list_connections all concern connection health. The monolithic marketplace tool also bundles search/describe/invoke/install/prompt-library operations, adding further ambiguity.
The 19 openfinance_* tools follow a clean snake_case verb_noun pattern (list_accounts, get_item_status, update_transaction_category), but the six platform tools break it with bare verbs (authenticate, connect) and noun-style names (marketplace, toolkit_info). The split is namespace-based and still readable, so it is only a minor inconsistency.
25 tools is on the heavy side, but the server spans two domains: an Open Finance banking surface (accounts, bills, loans, investments, connections) and a marketplace/platform layer (auth, search, prompts, bug reporting). Many openfinance tools are necessary for that breadth, though the count is high enough to feel bloated.
The Open Finance surface is nearly complete: connections can be searched, listed, disconnected, force-synced, and health-checked; accounts, transactions, bills, loans, and investments all have read/detail paths; transaction categories can be updated. Minor gaps exist, such as no granular marketplace tools outside the monolithic marketplace tool and no single-transaction detail endpoint, but core workflows do not dead-end.