mzizi-mcp

Report an issue

mzizi_report_issue

Report a problem with a component or the registry. It goes to your own issue desk — a Durable Object holding your reports — which reproduces it via fundi, drafts an issue body including what the reproduction actually returned, and logs it to fundi. fundi files the GitHub issue with its proposed fix in it and tracks that issue afterwards, so action 'get' shows where yours got to: filed, picked up, closed. Use 'list' to see your earlier reports and 'retry' to re-attempt one that drafted but could not be logged. Your history is included in each new issue, because a repeated complaint from one reporter is often one bug. Needs sign-in: the desk belongs to your Mzizi console user.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "mzizi_report_issue"
  }
}

Input Schema

Name	Required	Description	Default
`kind`	No	Report kind. Required for action 'file'.
`limit`	No
`skill`	No	fundi skill to run for the reproduction. fundi never infers a skill from text, so omit this to let the report kind choose one.
`action`	No	What to do. Defaults to filing a new report.	file
`message`	No	What happened. Required for action 'file'.
`reportId`	No	Report id. Required for actions 'get' and 'retry'.
`severity`	No
`component`	No	Component the report concerns.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 1, 2026
- changedInput schema / $schema
```
Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
```
- addedInput schema / properties / component / maxLength
```
Added value: +200
```
- addedInput schema / properties / message / maxLength
```
Added value: +20000
```
- addedInput schema / properties / reportId / maxLength
```
Added value: +200
```
- addedInput schema / properties / skill / maxLength
```
Added value: +100
```
First observedSep 30, 2026

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: it discloses real side effects (a GitHub issue is filed with a proposed fix and tracked afterwards), that the report is stored in a per-user Durable Object desk, that prior history is embedded in each new issue, and that sign-in is required. Annotations only say openWorld/non-idempotent/non-destructive, so this adds genuine context. Minor deduction for the tangled fundi/desk phrasing, which makes the exact write sequence hard to follow.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose, which is good, but the middle is a dense run-on chain of jargon ('a Durable Object holding your reports — which reproduces it via fundi, drafts an issue body... and logs it to fundi. fundi files...'). Sentences repeat the fundi hand-off and could be tightened without losing information.

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 8 parameters, no output schema, and no annotation coverage of returns, the description does well on lifecycle and auth but omits what a filed report returns (id? status?), what `severity` and `limit` do, and how the tool behaves when the reproduction fails. Adequate, but not complete for a multi-action tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, so the baseline is ~3; the description earns above that by explaining cross-parameter behavior the schema cannot — that `skill` is never inferred from text and is chosen by `kind` when omitted, and what each `action` value returns. It leaves `limit` and `severity` entirely unexplained, which is the remaining gap.

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?

Opens with a specific verb+resource: 'Report a problem with a component or the registry', then explains the pipeline (reproduce via fundi, draft body, log, file GitHub issue, track). The scope is clear, but it never distinguishes itself from the sibling `docs_submit_feedback`, which sounds like the obvious alternative for 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It maps the in-tool alternatives explicitly: 'get' shows where the report got to (filed, picked up, closed), 'list' shows earlier reports, 'retry' re-attempts one that drafted but could not be logged. That is clear when-to-use guidance, though it gives no when-NOT-to-use or sibling routing (e.g. vs `docs_submit_feedback`).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All mzizi-mcp tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?