Skip to main content
Glama

Próxima cobrança de assinaturas

subscription_renewals
Read-only

Data exata da próxima cobrança de cada recorrência de despesa ativa (RecurringTransaction), recalculada na hora (não usa o nextDueDate salvo, que fica desatualizado após a primeira ocorrência). entity traz o nome da marca reconhecida (ex: 'Canva', 'Netflix') quando a descrição bate com o catálogo de merchants conhecidos, senão repete a descrição. Use query pra perguntas específicas tipo 'quando renova minha assinatura do Canva' — filtra por nome do merchant ou trecho da descrição, case-insensitive. Sem query, lista tudo.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "subscription_renewals"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryNoFiltra por nome do merchant (ex: 'canva') ou trecho da descrição da recorrência. Omita pra listar todas.

Output Schema

NameRequiredDescriptionDefault
dataYes
textNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses meaningful behavior: the next charge date is recalculated at call time and ignores the possibly stale nextDueDate field. It also explains the `entity` field's fallback behavior, which is not inferable from annotations or schema.

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?

The description is compact and front-loaded, with each sentence serving a distinct purpose: core computation behavior, `entity` semantics, and query usage. There is no filler or redundant restatement of the tool name.

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?

The description covers the data source, recalculation behavior, entity derivation, query filtering, and the no-query default. With an output schema present and read-only annotations, the agent has all necessary information to select and invoke this tool correctly.

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?

The schema already documents the `query` parameter with 100% coverage, so the baseline is 3. The description adds value by specifying case-insensitive matching and giving a concrete subscription renewal example, which clarifies expected behavior beyond the schema.

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 clearly identifies the resource (active RecurringTransaction entries) and the specific output (exact next charge date recalculated on the fly). It also distinguishes itself from broader subscription or recurring-transaction tools by emphasizing per-recurrence dates and the fact that the stored nextDueDate is intentionally not used.

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?

The description gives clear context for when to use the optional `query` parameter, including a concrete question example, the matching behavior, and that omitting the query lists everything. It does not explicitly compare against sibling alternatives such as subscriptions_overview, but it provides enough usage context to guide an agent.

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.