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 | [] |
DETRAN PR: Multas (Extrato)
Schema Changelog
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
- First observed
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false, which align with a non-mutating report action. The description adds that the conversation array should be included for reproduction, which is useful. However, it doesn't mention any side effects like storing feedback or rate limits, but annotations already cover safety profile.
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, front-loaded with purpose and a key hint. No fluff.
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?
With no output schema and partial parameter coverage, the description is adequate but missing details on 'context' usage and any response or follow-up behavior. Given the simplicity and annotations, it's minimally viable but not fully complete.
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 not the 'context' parameter. The description clarifies 'message' is the main content and 'conversation' is for reproduction, but 'context' is undocumented in both schema (only default) and description, missing semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports bugs, missing features, or feedback, with a specific resource (the conversation array). It distinguishes itself from siblings like authenticate, connect, and marketplace by focusing on feedback/reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage for reporting issues and feedback, but doesn't explicitly state when to use versus alternatives or any exclusion criteria. The sibling tools are different enough that purpose alone suffices, but no explicit guidance on context.
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-level tools (authenticate, connect, marketplace, report_bug, show_version, toolkit_info) with a single data tool (detran_pr_multas_extrato_consultar). There is a clear distinction between platform management and the domain tool, but the platform tools overlap slightly (e.g., authenticate vs connect vs toolkit_info all relate to login/status), causing some ambiguity about when to use each.
Naming Consistency2/5
Tool names are inconsistent: some are single verbs (authenticate, connect, report_bug, show_version), some are compound nouns (toolkit_info, marketplace), and the domain tool uses a verbose snake_case pattern with a prefix (detran_pr_multas_extrato_consultar). This mix makes it hard to predict naming conventions.
Tool Count2/5
The server includes 7 tools, but most are generic platform utilities (authenticate, connect, marketplace, report_bug, show_version, toolkit_info) that are not specific to the DETRAN domain. Only one tool provides the actual data service, making the set feel bloated with unrelated functionality and thin on domain-specific value.
Completeness2/5
For the stated domain of DETRAN PR fines (Multas), only one tool exists for consultation. There are no tools for listing multiple vehicles, checking fine details, appealing, or paying fines. The platform tools are not domain-relevant, leaving a significant gap in the expected operational coverage.