report_bug
Idempotent
Report a bug, missing feature, or send feedback. Include the conversation array with recent messages for reproduction.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | ||
| message | Yes | ||
| conversation | No | [] |
CIGAM
Schema Changelog
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
- First observed
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, idempotent, non-destructive behavior. The description adds the requirement to include conversation for reproduction, which is helpful context. It does not disclose external transmission or side effects beyond that, but with annotations present, this is acceptable.
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?
Two sentences, no wasted words, and the key instruction is front-loaded. Perfectly concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no output schema, and annotations are present. The description covers the primary use case and the conversation requirement, but does not explain the 'context' parameter or expected result. It is minimally adequate but leaves minor 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 description coverage is 0%, so the description must compensate. It mentions the conversation array, but does not explain the 'context' parameter or clarify message format. The description adds value only for 'conversation' and leaves the others undocumented, failing to fully compensate for the schema gap.
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 states it reports bugs, missing features, or sends feedback, using a specific verb and resource. It distinguishes itself from siblings like cigam_* or authenticate by focusing on agent-level feedback, making its purpose unambiguous.
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?
It provides explicit instruction to include the conversation array for reproduction, guiding usage. However, it does not specify when not to use it or mention alternatives, but given the sibling set, the usage context is clear enough.
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.
TDQS
B3.4/5.0
Disambiguation4/5
Most cigam_* tools target a distinct ERP area (AP, AR, sales, purchases, inventory, cash), and descriptions clarify their boundaries. However, the sales-reporting cluster (vendas, vendas_por_dia, vendas_resumo, resultado, ranking_clientes) has overlapping period-summary purposes, and cigam_estoque overlaps with REL_610 in cigam_relatorio, creating a few plausible misselections.
Naming Consistency3/5
The 21 domain tools mostly follow a cigam_<snake_case noun> pattern, giving a recognizable prefix, but they mix Portuguese and English for the same operation (cigam_listar_lojas vs cigam_list_accounts) and mix noun-tools with verb-tools (consulta/relatorio/job vs listar). The 7 infrastructure tools (authenticate, connect, marketplace, etc.) use a completely different unprefixed English style, so there are effectively three naming conventions.
Tool Count2/5
At 28 tools the server exceeds the heavy threshold, and the count is padded by a fragmented sales-reporting family (four-plus tools all summarizing sales) plus a monolithic marketplace tool that bundles search, describe, invoke, install, subscription, and prompt-library operations. The broad ERP domain justifies many tools, but this set would benefit from consolidation.
Completeness4/5
As a read-only reporting/advisory adapter, the surface covers the main ERP workflows: sales, purchases, returns, invoices, AP/AR, delinquency, cash flow, payment mix, stock, financial entries, results, and custom reports. Notable gaps are a customer master list, product names in stock data, and per-document detail lookups, but the generic cigam_consulta and cigam_relatorio provide workarounds.