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 | [] |
CAF Agricultura Familiar PJ
Schema Changelog
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
- First observed
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds that conversation history should be included for reproduction, which is useful context, but it does not describe what happens after submitting, response format, or any side effects.
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, front-loaded sentences. The first states the purpose, and the second gives the key usage instruction. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and 0% schema description coverage, the description should explain more. It leaves the 'message' and 'context' parameters undefined, and the 'conversation' format is misleading. Essential user guidance for parameter usage is missing.
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 only explains 'conversation' (for reproduction) and incorrectly calls it an 'array' when the schema defines it as a string. The required 'message' parameter and the 'context' parameter are not explained at all.
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's purpose with a specific verb ('Report') and resource (bugs, missing features, feedback). It is distinct from sibling tools like 'authenticate' or 'marketplace', though it does not explicitly name alternatives.
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?
It gives clear use cases: reporting bugs, missing features, or feedback. It also provides practical guidance to include the conversation for reproduction, though it does not mention when not to use the tool or suggest alternatives.
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.7/5.0
Disambiguation4/5
Most tools have distinct purposes: authenticate handles login, connect shows connection status, marketplace handles discovery and invocation, report_bug sends feedback, show_version displays versions, toolkit_info shows installed MCPs. The single domain tool caf_agricultura_pj_consultar is clearly separate. Minor overlap exists between connect and toolkit_info (both touch connection status), but descriptions clarify their roles.
Naming Consistency2/5
Naming is inconsistent: some tools are bare verbs (authenticate, connect, marketplace), some are snake_case verb_noun (report_bug, show_version, toolkit_info), and one is a long Portuguese domain-specific name (caf_agricultura_pj_consultar). There is no unified pattern or verb style across the set.
Tool Count4/5
Seven tools is a reasonable number for a general platform toolkit. However, the server name suggests a CAF-specific domain, yet only one tool is actually CAF-related; the rest are generic platform utilities. The count itself is fine, but the scope is slightly mismatched with the server's title.
Completeness4/5
The platform tooling is fairly complete: authentication, connection status, marketplace search/run, bug reporting, version info, and toolkit state cover common needs. The CAF domain has a single query tool, which may be sufficient for a simple lookup, but lacks any additional operations like batch queries or listing categories. Minor gaps, but no critical dead ends.