Skip to main content
Glama
gabrielbssantos

Pluggy Finance MCP

get_credit_card_bill

Read-only

Fetch detailed credit card bill information by bill ID, covering transactions, charges, and due amount for that billing period.

Instructions

Detalhe de fatura após comprovação pela listagem de cartão autorizado.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bill_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
dataNo
metaYes
toolYes
errorNo
warningsYes
paginationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the contextual constraint that the bill detail is obtained after verification through an authorized card listing, which goes beyond the annotations. However, it does not clarify open-world behavior or what happens if the bill is not found, so the contribution is modest.

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

Conciseness4/5

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

The description is a single, front-loaded sentence with no redundant padding. The core object 'Detalhe de fatura' appears first, and the qualifier adds contextual information, even if its phrasing is somewhat cryptic.

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

Completeness3/5

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

For a one-parameter, read-only tool with annotations and an output schema, this is close to minimally viable. The main gap is that the prerequisite 'comprovação pela listagem de cartão autorizado' is ambiguous, and the description does not clarify how bill_id is obtained or validated.

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

Parameters2/5

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

Schema description coverage is 0%, and the description does not explain bill_id beyond the schema's title and uuid format. The indirect reference to 'fatura' and 'cartão autorizado' hints that bill_id relates to a verified card's bill, but the description fails to compensate for the complete lack of schema-level parameter documentation.

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

Purpose4/5

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

The phrase 'Detalhe de fatura' clearly indicates a credit-card bill-detail retrieval, and this is distinguishable from sibling tools like list_credit_card_bills and get_credit_card_summary. However, it lacks an explicit verb like 'get' or 'retrieve' and includes an unusual qualifier about 'comprovação pela listagem de cartão autorizado' that slightly obscures the core purpose.

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

Usage Guidelines2/5

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

The description hints at a workflow ('após comprovação pela listagem de cartão autorizado') but never explicitly says when to use this tool versus alternatives. It does not name list_credit_card_bills or explain what scenario should lead an agent to this tool, leaving usage largely to inference.

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