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 | [] |
SCR Banco Central (Detalhado)
Schema Changelog
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
- First observed
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context by telling the agent to include the conversation array for reproduction, which helps set expectations for how the tool should be invoked beyond what annotations disclose.
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 a single sentence that front-loads the purpose and then provides a critical instruction. Every word earns its place, and there is no redundancy or irrelevant detail.
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?
For a simple bug reporting tool, the description covers the main purpose and reproduction guidance, but it lacks clarity on the required 'message' parameter and the response/outcome behavior. Since there is no output schema, more context on return values or side effects would be helpful, though not critical for a straightforward reporting action.
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 only explains the 'conversation' parameter ('Include the conversation array with recent messages for reproduction'), but does not clarify what 'message' (required) or 'context' mean. This leaves the most important parameter under-specified.
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 the tool's purpose with a specific verb 'Report' and resources 'bug, missing feature, or send feedback.' This is distinct from sibling tools like authenticate or show_version, which have unrelated functions, so there is no ambiguity.
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 tells the agent when to use this tool ('Report a bug, missing feature, or send feedback') and provides a key usage instruction ('Include the conversation array with recent messages for reproduction'). It does not explicitly state when not to use alternatives, but the guidance is clear enough for typical scenarios.
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.8/5.0
Disambiguation2/5
Multiple tools have unclear boundaries: `connect` and `toolkit_info` both report connection status, and `marketplace` duplicates `report_bug` and includes list/status capabilities that overlap with both. The monolithic `marketplace` tool makes it hard for an agent to decide whether to call it directly or use the more specific tools.
Naming Consistency2/5
Tool names follow no consistent pattern: simple verbs (`authenticate`, `connect`), verb_noun (`report_bug`, `show_version`), a bare noun (`marketplace`), a long snake_case domain name (`scr_bacen_detalhado_consultar`), and a noun phrase (`toolkit_info`). The mixed conventions and variable lengths make the set feel ad hoc.
Tool Count4/5
Seven tools is within the typical well-scoped range and not overwhelming. However, only one tool maps to the server's stated SCR domain; the rest are generic platform utilities. While each earns a place, the count feels slightly disproportionate for a server whose name suggests a focused SCR service.
Completeness4/5
The core SCR detail consultation is fully covered by the single domain tool, and platform-level tools handle authentication, connection status, bug reporting, versioning, and toolkit state. Minor gaps exist (e.g., no dedicated tool to list available reference months), but there are no dead ends for the primary workflows.