report_bug
Report a bug, missing feature, or send feedback. Include the conversation array with recent messages for reproduction.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | ||
| message | Yes | ||
| conversation | No | [] |
Report a bug, missing feature, or send feedback. Include the conversation array with recent messages for reproduction.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | ||
| message | Yes | ||
| conversation | No | [] |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a behavioral note that the conversation array is used 'for reproduction,' which goes beyond the annotations. Since annotations already declare readOnlyHint=false and destructiveHint=false, the description only adds a small extra detail. It doesn't mention side effects like external communication or rate limits, but given the annotations, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and includes a necessary usage hint. Every word earns its place, with no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool being relatively simple with three plain string parameters, no output schema, and no enums, the description is still sparse. It omits guidance on what happens after reporting, required fields beyond 'message', and how to structure the conversation array. The provided instruction is good but not sufficient for unambiguous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 'conversation array' which hints at the 'conversation' parameter, but it doesn't explain 'message' or 'context' at all. The parameter types are all strings, and the default values are not explained. This is insufficient for a 3-parameter tool with no other parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Report a bug, missing feature, or send feedback.' This uses specific verbs and resources and is clear about its function. However, it does not differentiate from sibling tools, though the instant purpose is obvious enough for a near-top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction to 'Include the conversation array with recent messages for reproduction' provides some usage context, but there is no guidance on when to use this tool versus alternatives or any exclusions. It lacks the explicit 'when/when-not' structure needed for a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
anp_postos_consultar, report_bug, and show_version have clearly distinct roles, but marketplace is a broad multi-purpose tool that overlaps with connect, toolkit_info, and authenticate for status, auth, and catalog concerns. An agent could reasonably misfile a request between marketplace, connect, and toolkit_info.
The names mix bare verbs (authenticate, connect), nouns (marketplace), snake_case verb_noun (report_bug, show_version), noun_noun (toolkit_info), and a Portuguese object-verb name (anp_postos_consultar). There is no consistent naming convention across the set.
Seven tools is a reasonable size and does not feel bloated. However, six of the seven are generic platform utilities that could belong to any server, leaving only one tool actually tied to the 'ANP: Postos' domain.
Platform concerns like authentication, connection status, marketplace discovery, feedback, versioning, and toolkit state are well covered. The ANP/Postos domain itself is represented by a single opaque consult tool with no visible list, filter, detail, or search operations, which is a notable gap for a domain-specific server.