Skip to main content
Glama

pagarme_customers_list_addresses

Read-onlyIdempotent

Clientes e endereços no Pagar.me V5. Ações:

  • list: lista clientes (page, size; data: name, email, document, code).

  • get: cliente por customer_id.

  • list_addresses: endereços do cliente (requer customer_id).

  • get_address: endereço (requer customer_id + address_id).

[Flattened action: list_addresses]

Bulk support: accepts customer_ids, address_ids for batched execution.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo
pageNo
sizeNo
accountNo
address_idNo
address_idsNo
customer_idNo
customer_idsNo

Schema Changelog

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

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so description's main addition is the requirement for customer_id and batch execution. Describes no side effects beyond what annotations cover.

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

Conciseness2/5

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

Description includes a list of unrelated actions (list, get, etc.) before focusing on list_addresses. This is verbose and not front-loaded for the specific tool.

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

Completeness2/5

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

With 8 parameters and no output schema, the description fails to explain most parameters (page, size, data, account, address_id). Only customer_id and bulk arrays are covered, leaving significant gaps.

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 coverage is 0%. Description only explains customer_id, customer_ids, and address_ids in context. Leaves page, size, data, account, address_id unexplained.

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 explicitly states 'list_addresses: endereços do cliente (requer customer_id)' and distinguishes from sibling tools like pagarme_customers_get_address (single address) and pagarme_customers_list (list customers). The flattened action clarifies the exact operation.

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

Usage Guidelines4/5

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

Clearly mentions that customer_id is required ('requer customer_id') and notes bulk support with customer_ids and address_ids. However, it does not explicitly state when not to use or compare directly to alternatives like get_address.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.