Returns the current toolkit state: installed MCPs, their connection status, the accounts connected to each one, and how many catalog tools each exposes.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 read-only, idempotent, non-destructive behavior. The description adds meaningful detail about what 'state' includes (installed MCPs, connection status, connected accounts, number of exposed catalog tools), which goes beyond the bare annotation and helps the agent predict the response structure.
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 a single, well-structured sentence that front-loads the main action and then lists the key output categories. Every phrase adds value, with no repetition of schema or annotation information and no filler.
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 tool's simplicity (no parameters, read-only, no output schema), the description fully covers what the tool returns. It enumerates all major aspects of the tool state, making it complete enough for an agent to understand the tool's behavior and likely response format without additional schema or documentation.
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 is empty (0 parameters), so there is nothing for the description to clarify about parameters. Per the rubric, a tool with no parameters receives a baseline of 4; the description adds no unnecessary parameter information, which is appropriate.
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 a specific verb ('Returns') and resource ('current toolkit state'), and enumerates the key components (installed MCPs, connection status, accounts, catalog tool counts). This distinguishes it from sibling tools, which focus on specific actions like authentication, connection, or data listing.
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 clearly conveys that this tool is for obtaining an overall state snapshot, making its primary use case obvious. It does not explicitly state when not to use it or name alternatives, but its unique purpose among the siblings (general state inspection) provides sufficient contextual guidance.
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.
Several tools have overlapping purviews—list_transactions vs list_transactions_by_item, get_credit_card_bill vs list_credit_card_bills, and connect vs list_connections vs get_item_status vs provider_status—so an agent could pick the wrong one. The very detailed descriptions disambiguate them, but the tool names alone do not.
The openfinance_ prefix provides a clear family and most members use list_/get_/update_ verbs, but there are deviations like openfinance_provider_status (no verb), openfinance_disconnect_bank, and openfinance_force_sync. Platform tools (authenticate, connect, marketplace, toolkit_info) follow a different, less uniform style.
At 25 tools, this sits at the top of the heavy range. Most Open Finance operations are justified given the breadth of banking data, but overlapping tools and the mega-marketplace tool with many sub-actions make the set feel slightly bloated.
The Open Finance surface covers list/get/update/disconnect/sync for accounts, transactions, credit card bills, loans, and investments, plus provider health, connection search, and platform-level auth, marketplace, version, and feedback. There are no obvious dead ends or missing lifecycle operations.