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 | [] |
Magnific
Schema Changelog
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
- First observed
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide the safety profile: non-read-only, non-destructive, and idempotent. The description adds that the conversation array is used for reproduction, which is useful context, but it does not explain side effects, response behavior, or any prerequisites.
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 with the main purpose front-loaded and the reproduction guidance in the second sentence. Every sentence earns its place without redundant restating of schema details.
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?
This is a simple tool and annotations cover the core safety semantics, but with no output schema and 0% schema description coverage, the description should explain the required message parameter. It is adequate for basic invocation but incomplete around message and context semantics.
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 clarifies the conversation array's purpose but leaves the required message parameter and the optional context parameter semantically underdescribed, which is a notable gap.
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 states 'Report a bug, missing feature, or send feedback' with a specific verb and target resource. This clearly distinguishes it from the many magnific_* media/design siblings and from the more specific magnific_project_report.
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 clearly defines when to use the tool: for bug reports, missing features, or feedback. It also gives a practical instruction to include the conversation array for reproduction, though it does not mention exclusions or 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
B3.1/5.0
Disambiguation4/5
The vast majority of tools have clear, distinct purposes with category prefixes (images, creations, audio, etc.) that aid selection. However, the inclusion of platform-level tools like 'marketplace', 'connect', and 'authenticate' introduces potential ambiguity, especially since 'marketplace' bundles many sub-actions into one tool, and 'connect' vs 'authenticate' both relate to session/auth status.
Naming Consistency3/5
Most tools follow a consistent 'magnific_<category>_<action>' pattern (e.g., magnific_images_generate, magnific_audio_voices_list). However, several tools (authenticate, connect, marketplace, report_bug, show_version, toolkit_info) omit the prefix entirely, breaking the otherwise predictable naming convention. This mixed pattern reduces overall consistency.
Tool Count1/5
With 67 tools, the surface is extremely large and far beyond a well-scoped set (typically 3-15). Even for a multi-domain media platform, this is overwhelming, risking agent confusion and performance issues. The calibration indicates anything above 50 is an extreme mismatch, which this clearly is.
Completeness4/5
The tool set covers a broad range of domains—images, video, audio, 3D, flows, spaces, stock, folders, and library assets—with operations covering create, read, list, search, and generation workflows. However, there are noticeable gaps such as no explicit deletion for individual creations (only folder deletion) and no direct update for certain resources, which slightly limits lifecycle completeness.