Criar/renovar cartões de um cliente no Pagar.me V5 (só sk_; requer customer_id). Ações:
create: tokeniza/salva cartão (data: number, holder_name, exp_month, exp_year, cvv ou card_token).
renew: renova cartão (requer card_id).
[Flattened action: renew]
Bulk support: accepts customer_ids, card_ids for batched execution.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | ||
| account | No | ||
| card_id | No | ||
| card_ids | No | ||
| customer_id | Yes | ||
| customer_ids | No |
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 are minimal (no readOnlyHint or destructiveHint). The description mentions the write operation and bulk execution, but lacks details on side effects, idempotency, or authorization requirements beyond requiring customer_id.
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 cluttered with line breaks, redundant action lists, and a '[Flattened action: renew]' note that adds noise. It could be more streamlined and front-loaded with the key action.
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 complexity of two actions and bulk support, and no output schema, the description covers basic usage but omits information about return values, error conditions, and what happens after renewal (e.g., new card token).
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?
Schema description coverage is 0%. The description adds meaning by listing data fields for create and specifying card_id for renew, but the structure of the 'data' parameter is described inconsistently (as a string but with multiple fields), which may cause confusion.
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 'Criar/renovar cartões de um cliente' and specifies that 'renew' is the action for this tool, distinguishing it from the sibling tool 'pagarme_cards_write_create' which likely handles only creation.
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 provides usage context: 'renew' requires card_id, and bulk support is noted with array parameters. However, it does not explicitly state when not to use or contrast with alternatives, which would improve 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.