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 | [] |
Receita Federal PJ
Schema Changelog
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
- First observed
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is idempotent and non-destructive, but the description adds no behavioral details beyond mentioning to include the conversation array for reproduction. It does not contradict annotations, but does not provide additional context such as expected outcome or side effects, which with annotations present is acceptable but not rich.
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 concise sentences with no redundant information. The description is front-loaded with the purpose and followed by a practical instruction, making it highly scannable.
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 tool is simple with no output schema and few parameters. The description covers the purpose, provides a key usage hint (conversation for reproduction), and is sufficient for an AI agent to select and invoke the tool. Minor gap: no mention of what constitutes a valid 'message' or any expected response, but these are not critical for a bug report tool.
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?
Schema description coverage is 0%, so the description must compensate. It explains the purpose of the conversation parameter ('with recent messages for reproduction') but leaves message and context implicit. Since message is the required parameter and its meaning is fairly intuitive, this is minimally adequate.
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 uses a specific verb 'Report' and clearly states the resource: 'a bug, missing feature, or send feedback'. This clearly distinguishes it from sibling tools like authenticate, connect, and show_version, which serve entirely different purposes.
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 explicitly states when to use the tool: to report a bug, missing feature, or send feedback. It does not explicitly mention not using it for other scenarios, but given the sibling context, the usage context is clear and unambiguous.
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
A3.9/5.0
Disambiguation4/5
Most tools serve distinct platform functions (auth, status, version, bug reporting) and the sole domain tool is clearly separated. However, connect and toolkit_info both expose connection status, and marketplace is a broad catch-all, creating minor overlap.
Naming Consistency2/5
Naming is inconsistent: verbs (authenticate, connect, report_bug, show_version), nouns (marketplace, toolkit_info), and a Portuguese object-verb order (receita_pj_consultar) are mixed without a clear pattern. While style is all lowercase with underscores, the convention is not predictable.
Tool Count3/5
At 7 tools the count is within a reasonable range, but six of the seven are platform meta-tools unrelated to the Receita Federal domain suggested by the server name. This dilutes the tool set's purpose and makes it feel cluttered.
Completeness4/5
The core CNPJ consultation is covered with optional shareholder data, which is appropriate for a public-data lookup. There are no obvious lifecycle gaps since the operation is read-only, though search or batch capabilities are missing directly but could be discovered via the marketplace tool.