Skip to main content
Glama

Conta Simples

by io.github.mcp-dir

contasimples_summary

Read-onlyIdempotent

Resumo agregado do período (bancário + cartão) — uma chamada em vez de paginar centenas de transações. Retorna totais (entradas/saídas, PIX/TED, cartão compras/IOF/estorno), top categorias e top estabelecimentos, cash_flow e flags _meta (truncated se passar do limite de páginas). Período máximo 62 dias (API). Por padrão só transações bancárias processadas (status=2); include_canceled=true busca todas e exclui canceladas (status=1) dos totais, contando-as em banking.canceled_excluded. Opcional: accounts — agrega N empresas em paralelo, resposta vem em accounts[] (uma entrada por conta) + errors[] se alguma falhar. Opcional: keywords — restrinja o agregado às transações cuja descrição/contraparte/categoria/tipo contenham qualquer uma das palavras (_meta.keyword_filter mostra matched vs scanned).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
top_nNo
accountsNo
end_dateYes
keywordsNo
start_dateYes
movement_typeNo
include_canceledNo

Schema Changelog

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

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Description provides extensive behavioral context beyond annotations, including return structure (totals, top categories, cash flow, meta flags), truncation handling, period limit, include_canceled behavior, parallel aggregation for multiple accounts, and keyword filtering. Annotations already indicate read-only and idempotent, so no contradiction.

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 concise, well-structured, and front-loaded. It begins with the main purpose, lists return values, then constraints and optional parameters. Every sentence adds value without redundancy.

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

Completeness4/5

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

The description is largely complete given the schema's lack of descriptions and no output schema. It explains return structure, constraints, and optional parameters. Minor gaps: movement_type and top_n are not mentioned, and error handling beyond accounts could be elaborated.

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?

With 0% schema description coverage, the description compensates by explaining the roles of start_date, end_date, include_canceled, accounts, and keywords. However, movement_type and top_n are not described, leaving minor gaps.

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?

Description clearly states the tool returns an aggregated summary of banking and card transactions for a period, distinguishing it from paginating through detailed transactions. It specifies what it returns: totals, top categories, top establishments, cash flow, and meta flags.

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 explains that the tool is a one-call alternative to paginating hundreds of transactions, implying usage for aggregate queries. It also notes the maximum period of 62 days and explains the include_canceled behavior. However, it does not explicitly list when not to use this tool or name specific sibling alternatives.

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

All Conta Simples toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0
Disambiguation4/5

Almost all tools have clear purposes, especially with the contasimples_ prefix. Some overlap between statement and summary, but descriptions differentiate well. The general tools (marketplace, report_bug, etc.) are completely different from the financial ones, which reduces potential confusion.

Naming Consistency3/5

The domain tools follow a consistent verb_noun pattern (e.g., contasimples_card_write_block). However, the inclusion of general tools like authenticate, connect, marketplace breaks the pattern. This inconsistency lowers the score.

Tool Count4/5

With 24 tools covering authentication, financial operations, and platform utilities, the number is reasonable for a moderately complex MCP server. It doesn't feel excessive or too thin.

Completeness3/5

The toolset covers key financial operations (balance, bills, cards, statements, summary) and some mutations (block/unblock, create invite, delete user). However, missing CRUD for several entities (e.g., no update user, no create card, no delete invite) leaves gaps. The presence of platform utilities adds breadth but not depth.

Resources