Skip to main content
Glama

Toro MCP

by io.github.mcp-dir

openfinance_provider_status

Read-onlyIdempotent

Checks the LIVE operational status of the Open Finance provider (its public status page) — this is the PROVIDER's health, separate from your own connection's openfinance_get_item_status. Use it whenever data looks incomplete or stale even though a connection shows UPDATED (accounts/transactions/balances missing, a bank not returning everything): it reveals an upstream outage or a known incident on a specific bank/connector, so you can tell a provider-side problem apart from a connection that just needs reconnecting. Returns the global indicator (none/minor/major/critical), degraded components, open incidents, and — when you have banks connected — flags the incidents that affect YOUR connected banks in your_banks_affected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds context about the live public status page and the specific outputs (global indicator, incidents, your_banks_affected), which is useful beyond annotations. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence earns its place: it states the action, distinguishes from a sibling, explains when to use it, and lists output fields. The description is dense but not bloated, and it is front-loaded with the primary purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully explains what is returned (global indicator, degraded components, incidents, your_banks_affected) and provides enough context for an agent to understand the operational meaning. It is complete for a simple read-only tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the description correctly implies a no-input read operation. The schema provides 100% coverage trivially, and the description adds no parameter info because none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'Checks the LIVE operational status of the Open Finance provider' and explicitly differentiates it from the sibling tool `openfinance_get_item_status`, making the resource and scope unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use guidance ('Use it whenever data looks incomplete or stale even though a connection shows UPDATED') and names the alternative (openfinance_get_item_status), helping the agent choose correctly between provider-side and connection-side diagnostics.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Toro MCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation4/5

Each Open Finance resource has a clearly named list/get pair, and connection status vs provider status vs force sync are distinct. The main ambiguity is between list_accounts (which already carries balances) and get_account_balance, and between list_transactions and list_transactions_by_item, which requires reading the descriptions carefully.

Naming Consistency4/5

The openfinance_* tools follow a consistent verb_noun pattern (list_*, get_*, update_*, force_sync, search_*). Exceptions like marketplace, toolkit_info, and openfinance_provider_status break the pattern slightly, but the two logical groups are predictable internally.

Tool Count3/5

At 25 tools this is on the heavy end of the scale. Most tools have a real purpose, but several list/get pairs and the multi-purpose marketplace mega-tool could be consolidated without losing functionality, making the overall surface feel larger than strictly necessary.

Completeness4/5

The Open Finance surface is impressively broad: connections, accounts, balances, transactions, credit-card bills, loans, investments, categorization, sync, provider health, and connector search are all covered. Minor gaps like a single-transaction getter or a consolidated statement export force agents to assemble data with extra calls, but no critical workflow is blocked.

Resources