Skip to main content
Glama

BTGPactual 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

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added
  2. Removed
  3. Added
  4. Removed
  5. Added
  6. Removed
  7. Added
  8. Removed
  9. Added
  10. Removed
  11. Added
  12. Removed
  13. Added
  14. Removed
  15. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Adds context beyond annotations by describing return data (global indicator, degraded components, incidents, your_banks_affected). Annotations already declare readOnly and idempotent, so description enriches without 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?

Concise (~100 words), front-loaded with purpose, every sentence serves a purpose. Structured logically: what, when, what returns.

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?

Given zero parameters and no output schema, description covers all needed context: purpose, usage scenario, and return value details. Annotations cover safety profile.

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?

No parameters exist, so description adds no param-specific info. Per guidelines, 0 params yields baseline 4. No additional param meaning 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?

Clearly states the verb 'checks' and resource 'LIVE operational status of the Open Finance provider'. Explicitly differentiates from sibling tool openfinance_get_item_status by emphasizing provider vs connection health.

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?

Provides explicit when-to-use scenario: when data looks incomplete/stale despite a connection showing UPDATED. Contrasts with the sibling tool and explains diagnostic value.

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

All BTGPactual 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

A3.9/5.0
Disambiguation4/5

The openfinance_* family is well-decomposed by resource (accounts, transactions, bills, investments, loans, connections) and by action (list, get, update, sync, disconnect), and the highly detailed descriptions make each tool's boundaries clear. A few pairs can be confused at a glance (list_accounts vs. get_account_balance, list_transactions vs. list_transactions_by_item, connect vs. toolkit_info), but the semantics are ultimately distinguishable.

Naming Consistency3/5

The openfinance_* group follows a strong and consistent verb_noun pattern (list_transactions, get_item_status, force_sync). However, the platform-level tools are a mixed bag—authenticate, connect, marketplace, toolkit_info, show_version, report_bug—so there is no single predictable naming scheme across the whole server.

Tool Count3/5

At 25 tools, the server is at the heavy/borderline boundary, though most of the surface area is genuinely needed for Open Finance reads and connection lifecycle management. Some functions overlap (list_accounts returns balances that get_account_balance also exposes), making the set feel slightly bloated and closer to a two-in-one platform (Open Finance + marketplace).

Completeness4/5

The server covers the full Open Finance discovery and connectivity lifecycle: search, reconnect, force sync, provider health, accounts, transactions, credit cards, investments, loans, and category correction. Gaps like initiating a new connection or executing financial movements are handled through connect URLs rather than direct tools, so the unavoidable dead-end is likely workable and the core read/aggregate domain is well covered.

Resources