misakanet

by io.github.Ikalus1988

misakanet_write_lesson

[STRUCTURED COMMIT / VALIDATED SUBMISSION] Submit a complete, structured failure lesson (title/domain/problem/root_cause/fix) as a formal submission. Requires authentication (Bearer token in header) — this is the 'validated author' path, not open triage. Output goes through lesson-gate/lint/review and becomes a versioned lesson in the git repo. For quick open reports when you only have a partial failure description, use misakanet_submit_intake instead (no Bearer). Lessons are immutable once merged — corrections go through a new intake/PR, so there is intentionally no misakanet_update_lesson/misakanet_delete_lesson. Returns: object {lesson_id: string, status: 'pending_review', quality_score: number}; or {submitted: false, error}. Example: misakanet_write_lesson(title='pip timeout behind proxy', domain='python', problem='...', root_cause='...', fix='...')

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "title": "<title>",
      "domain": "<domain>",
      "problem": "<problem>",
      "root_cause": "<root_cause>",
      "fix": "<fix>"
    },
    "name": "misakanet_write_lesson"
  }
}

Input Schema

Name	Required	Description
`fix`	Yes	How to fix it (required).
`tags`	No	Comma-separated tags.
`title`	Yes	Short descriptive title.
`domain`	Yes	Domain: devops, python, network, feishu, rag, fanuc, mcp, etc.
`source`	No	Source: codex, claude-code, cursor, dsh, curl, cindy, etc.
`problem`	Yes	What failed (required).
`root_cause`	Yes	Why it failed (required).
`contributor`	No	Optional: contributor identity (GitHub username, agent name, or email). Included in lesson frontmatter for attribution.
`verification`	No	How to confirm the fix works.

Output Schema

Name	Required	Description	Default
`error`	No
`status`	No
`lesson_id`	No
`submitted`	No
`quality_score`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond annotations, it discloses authentication requirements, the downstream pipeline (lesson-gate/lint/review), the destination (versioned lesson in the git repo), immutability after merge, and the concrete return shape including status and quality_score. The non-destructive annotation is not contradicted, since no deletion or mutation of existing records is implied.

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

Conciseness4/5

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

Content is front-loaded and dense with actionable facts; the bracketed label and example are slightly redundant with the required-field list already stated earlier. Still, nearly every sentence carries distinct routing, auth, or lifecycle information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a write tool requiring auth and undergoing review, the description supplies the auth mode, review pipeline, immutability rule, error case, and return shape. Even though an output schema exists, the return description reinforces what an agent needs to branch on {submitted: false, error}.

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 coverage is 100%, so the schema already documents all nine parameters and their meanings. The description restates the five required fields and provides one realistic example call, which adds illustrative but not substantial semantic detail beyond the schema.

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 opens with a precise verb+resource ("Submit a complete, structured failure lesson") and enumerates the content fields it expects. It explicitly distinguishes itself from the closest sibling, misakanet_submit_intake, and notes the deliberate absence of update/delete siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

It states the exact precondition (Bearer token) and frames this as the 'validated author' path, then names the alternative tool for partial reports with the distinguishing condition (no Bearer). It further says corrections must go through a new intake/PR rather than an update, closing off a plausible wrong path.

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

All misakanet 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.