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 | [] |
ECRVSP Documentos: Escolha da Placa
Schema Changelog
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
- First observed
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds the useful instruction to include the conversation array for reproduction, but does not disclose any post-submit behavior (e.g., issue creation) or other side effects beyond what annotations imply.
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 short sentences, front-loaded with the core purpose and followed by an actionable reproduction tip. Every sentence earns its place and there is no filler or 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?
For a simple 3-parameter tool with no output schema and no enums, the description covers the main action and the reproduction detail. The only notable gaps are the lack of explicit guidance on the required 'message' parameter and the expected response, but the tool's simplicity keeps the overall completeness high.
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 free-text description must compensate. It clarifies that 'conversation' should contain recent messages for reproduction, but leaves 'message' and 'context' semantics implicit, forcing the agent to infer their meaning from the tool's purpose.
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' with the resources 'bug, missing feature, or feedback', clearly distinguishing it from sibling tools like authenticate and marketplace. It also adds a practical instruction about including the conversation array, reinforcing the tool's unique role.
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?
Provides clear context: use when reporting bugs, missing features, or feedback. It does not explicitly state when not to use or name alternatives, but given no sibling tool serves a similar purpose, the guidance is sufficient.
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.1/5.0
Disambiguation2/5
The set mixes platform utilities (authenticate, connect, show_version), a bug reporter, and one domain-specific Brazilian vehicle-docs query tool (ecrvsp_docs_escolher_placa_consultar). The `marketplace` tool is the worst offender: its description claims it can search, describe, invoke, install, subscribe, and handle prompts—an entire parallel application that an agent would have no reason to distinguish from the main server. authenticate/connect also blur around connection state vs. action.
Naming Consistency2/5
Conventions are mixed: single-word bare verbs (`connect`, `authenticate`), snake_case `verb_noun` (`report_bug`, `show_version`), a noun phrase (`toolkit_info`), and a long Portuguese snake_case string (`ecrvsp_docs_escolher_placa_consultar`). The inconsistent Portuguese/English mix and inconsistent verb-first vs. noun-first patterns make the surface unpredictable.
Tool Count3/5
At 7 tools, the count is right in the sweet spot, and most are generic platform utilities that plausibly need to exist. However, six of the seven are generic infrastructure, leaving only one tool to represent the actual product domain, while `marketplace` crams dozens of capabilities into a single mis-sized tool. The count looks fine numerically but is lopsided in practice.
Completeness2/5
The domain (ECRVSP plate selection/consultation) has exactly one operation: `consultar` (query). There is no way to save a plate, view historical lookups, retrieve a document/receipt, handle multiple document types, or resolve a failed lookup—so any multi-step workflow hits a dead end immediately. The `marketplace`'s wrapper capabilities don't fill these gaps, and the actual product surface feels like just one CRUD read among many missing operations.