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 | [] |
MPT MS: Certidão Negativa de Feitos
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 already provide idempotentHint=true and destructiveHint=false, and the description does not contradict them. It adds useful context by explaining that the conversation array should be included for reproduction, but it does not disclose what happens after reporting (e.g., dispatch, storage, confirmation).
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, front-loaded sentences convey the tool's purpose and key usage guidance. Every sentence adds value with no 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 tool is simple with three parameters, no output schema, and helpful annotations. The description provides enough to invoke it correctly, though a one-line note about the 'context' parameter would make it fully complete.
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 clarifies the 'conversation' parameter's purpose as a recent-messages array for reproduction, and 'message' is implied as the report content, but the 'context' parameter remains unexplained.
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 uses a specific verb 'Report' and clearly identifies the resource/action: bug, missing feature, or feedback. It distinguishes itself from unrelated sibling tools by stating its exact purpose.
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 states clear use cases ('bug, missing feature, or send feedback') and gives a practical instruction (include conversation array for reproduction). It does not mention alternatives or exclusions, but none of the sibling tools compete with this function.
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.3/5.0
Disambiguation3/5
The server mixes platform-management tools (authenticate, connect, marketplace, report_bug, show_version, toolkit_info) with a single domain-specific tool (mpt_ms_cnf_consultar). The platform tools are distinct, but the presence of the domain tool alongside them creates confusion about the server's purpose. 'authenticate' and 'connect' overlap in credential management, and 'marketplace' has broad, multi-role behavior that may be ambiguous with 'toolkit_info'.
Naming Consistency2/5
Naming is inconsistent: mostly snake_case verbs (authenticate, connect, marketplaces, report_bug, show_version, toolkit_info), but the domain tool uses a multi-part snake_case with an acronym 'mpt_ms_cnf_consultar' that doesn't follow the simple verb_noun pattern. Also the server is named 'MPT MS' but the tool 'marketplace' is not mpt-specific, adding to inconsistency.
Tool Count3/5
7 tools is within a reasonable range, but the server appears to be a general MCP platform toolkit rather than a focused Certidão service. Only one tool (mpt_ms_cnf_consultar) serves the stated domain, while the others are platform utilities, making the count appropriate for a platform server but mismatched with the server name.
Completeness2/5
For the stated domain 'Certidão Negativa de Feitos', the surface is severely incomplete—only one consultation tool with no supporting operations (e.g., status check, history, PDF retrieval). The other tools are generic platform functions not specific to the domain, but they do provide infrastructure for authentication and billing, so the server isn't useless.