Skip to main content
Glama

pagarme_subscriptions_write_add_item

Criar/operar assinaturas no Pagar.me V5 (só sk_; não-destrutivas). Ações:

  • create: cria assinatura (data: customer_id/customer, plan_id ou items[], payment_method, card_id, …).

  • update_card: altera cartão (requer subscription_id; data).

  • update_payment_method: altera meio de pagamento (requer subscription_id; data).

  • update_billing_date: altera data de cobrança (requer subscription_id; data).

  • add_item: adiciona item (requer subscription_id; data).

  • add_usage: registra uso de item medido (requer subscription_id + item_id; data opcional).

[Flattened action: add_item]

Bulk support: accepts subscription_ids, item_ids for batched execution.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo
accountNo
item_idNo
item_idsNo
subscription_idNo
subscription_idsNo

Schema Changelog

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

  1. First observed

TDQS

C2.7/5.0
Behavior3/5

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

Annotations already indicate non-destructive and non-read-only. The description adds 'não-destrutivas' and mentions bulk support, but does not disclose idempotency, rate limits, or authorization needs beyond 'só sk_'.

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

Conciseness3/5

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

The description is longer than necessary due to listing all actions. While structured with a header and bullet points, it could be more concise by focusing solely on add_item.

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?

The tool has 6 parameters, bulk support, and no output schema. The description omits the result of adding an item (e.g., response format, side effects). It provides some context on required fields but lacks completeness for effective use.

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

Parameters3/5

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

With 0% schema coverage, the description must compensate. It states that add_item requires subscription_id and data, and mentions bulk support with subscription_ids and item_ids. However, 'data' is left undefined (likely JSON), and the schema's item_id parameter is not explained in the add_item context.

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

Purpose3/5

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

The description lists multiple actions (create, update_card, etc.) while the tool is specifically named 'add_item'. The flattened action note clarifies, but the overall purpose is vague and could mislead an agent into thinking this tool handles multiple subscription operations.

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?

No when-to-use or when-not-to-use guidance is provided. It does not differentiate from sibling tools like pagarme_subscriptions_write_create or pagarme_subscriptions_write_update_card.

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.