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 | [] |
Conselho Federal de Medicina: Cadastro
Schema Changelog
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
- First observed
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation 'idempotentHint: true' is present, and the description does not contradict it. The description adds behavioral context by explaining that the tool is for reporting and that the conversation array is needed for reproduction. No annotations contradict the description.
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 two sentences, concise and front-loaded with the core purpose. Every word is useful, and it avoids 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?
Given that the tool is fairly simple with 3 parameters and no output schema, the description is mostly complete. It covers the main use case and the key parameter (conversation). It might benefit from mentioning that 'context' is optional, but overall it's adequate.
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%, but the description mentions the 'conversation' parameter explicitly, implying its purpose. However, it doesn't explain 'context' or 'message' beyond the schema, and the 'message' parameter is essentially self-explanatory. The description adds some value but not comprehensive parameter guidance.
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: report a bug, missing feature, or send feedback, and includes instruction to include conversation array for reproduction. This is specific and distinguishes it from sibling tools like marketplace or toolkit_info, which serve different purposes.
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 provides clear guidance on when to use the tool (to report a bug or provide feedback) and instructs to include the conversation array for reproduction. It implicitly excludes use for other purposes, and while it doesn't explicitly mention alternatives, the context is clear enough given the sibling list.
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.9/5.0
Disambiguation4/5
The tools are mostly distinct: authenticate, connect, and toolkit_info handle platform/connection state; marketplace covers discovery/invocation; cfm_cadastro_consultar is the only domain-specific data tool. One potential ambiguity: `connect` and `toolkit_info` both report connection status, but `connect` focuses on URLs and missing credentials while `toolkit_info` focuses on installed MCP state, so it's clear enough.
Naming Consistency3/5
Naming is mixed: some tools use clear verbs (`authenticate`, `connect`, `report_bug`, `show_version`, `toolkit_info`), but three use domain-specific or inconsistent forms (`cfm_cadastro_consultar` mixes abbreviation and verb, and `toolkit_info`/`show_version` use noun phrases vs verbs). There's no consistent verb_noun pattern across the set, though the names are readable and mostly self-explanatory.
Tool Count5/5
With 7 tools, the count is well-scoped for a platform-oriented server that includes connection management, a catalog/invocation hub, feedback, version info, and one domain-specific query tool. Each tool has a distinct function and the count feels intentional, not bloated.
Completeness3/5
For the apparent purpose — providing access to the CFM cadastro query plus platform plumbing — the surface covers authentication, connection status, the domain query, and a toolkit overview. However, there's no CRUD/lifecycle for the domain query (e.g., no way to list past queries, manage credits, or handle errors) beyond the single consultar tool, and the platform tools (marketplace) handle most management. The gaps are workable but noticeable.