MisakaNet

misakanet_submit_intake

[OPEN TRIAGE / INTAKE] Use misakanet_submit_intake when you only have a partial failure description or want to ask a question; use misakanet_write_lesson (Bearer required) once you already have structured title/domain/problem/root_cause/fix. submit_intake is open, rate-limited, no Bearer — output is a GitHub issue (intake,mcp-intake,pending-review) for maintainer triage, NOT a merged lesson. Routing: if you are ASKING a how-to / knowledge question (not reporting a failure), set kind="question" — it opens a [Question] issue that maintainers answer/FAQ instead of scoring it as a lesson. If kind is omitted, the server auto-detects question-shaped content (no error/fix/verification + question phrasing). Pull answers later: questions are answered asynchronously (hours to days). Re-call this tool with the SAME problem text later — the dedup response returns the maintainer's answer once it exists ({answered:true, answer}); or re-run misakanet_search on the topic for FAQ hits. Returns: object {submitted: boolean, intake_id, status, redactions_applied, quality_score, receipt, routing:{kind, auto_detected}, follow_up?}; duplicates: {submitted: false, duplicate: true, previous_issue} or {answered: true, answer} for answered questions. Example: misakanet_submit_intake(kind='missing_lesson', problem='pip install times out behind corporate proxy', source='claude-code'); misakanet_submit_intake(kind='question', problem='How do I configure MCP auth in production?', source='claude-code')

Input Schema

TableJSON Schema

Name	Required	Description
`fix`	No	Optional: how it was resolved.
`kind`	No	missing_lesson (knowledge gap), stale_lesson (outdated lesson), new_lesson_candidate (new failure mode), or question (ask for help).
`error`	No	Optional: short error message (auto-redacted).
`source`	No	Calling client: codex, claude-code, cursor, dsh, curl, or other.
`problem`	Yes	Required: short description of the failure, gap, or question (max 2000 chars).
`what_tried`	No	Optional: what was attempted.
`verification`	No	Optional: how to confirm the fix works.
`matched_lesson_id`	No	Optional: lesson ID that was checked but didn't help.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`note`	No
`error`	No
`answer`	No
`status`	No
`pending`	No
`receipt`	No
`routing`	No
`answered`	No
`duplicate`	No
`follow_up`	No
`intake_id`	No
`issue_url`	No
`submitted`	No
`answer_url`	No
`dedup_hash`	No
`previous_issue`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedSep 3, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "answer": {
+      "type": "string"
+    },
+    "answer_url": {
+      "type": "string"
+    },
+    "answered": {
+      "type": "boolean"
+    },
+    "dedup_hash": {
+      "type": "string"
+    },
+    "duplicate": {
+      "type": "boolean"
+    },
+    "error": {
+      "type": "string"
+    },
+    "follow_up": {
+      "properties": {
+        "how": {
+          "type": "string"
+        },
+        "intake_id": {
+          "type": "string"
+        },
+        "issue_url": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "intake_id": {
+      "type": "string"
+    },
+    "issue_url": {
+      "type": "string"
+    },
+    "note": {
+      "type": "string"
+    },
+    "pending": {
+      "type": "boolean"
+    },
+    "previous_issue": {
+      "type": "string"
+    },
+    "receipt": {
+      "type": "string"
+    },
+    "routing": {
+      "properties": {
+        "auto_detected": {
+          "type": "boolean"
+        },
+        "kind": {
+          "type": "string"
+        },
+        "note": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "status": {
+      "type": "string"
+    },
+    "submitted": {
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}

First observedAug 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description goes well beyond the minimal annotations by disclosing rate limits, no-Bearer auth, GitHub-issue output, async answering, dedup behavior, and return-shape variants. It also explicitly states this is not a merged lesson, which is critical behavioral context for an intake tool.

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?

The description is longer than average, but nearly every section adds necessary operational detail: routing, auth, output semantics, dedup, and examples. It is front-loaded with the most important routing distinction and remains structured and readable despite its length.

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?

The tool is complex due to async behavior, dedup, and routing variants, and the description covers all of these comprehensively. It also includes return formats and examples, so an agent has enough context to invoke it correctly without needing separate documentation.

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 100%, so the baseline is 3. The description adds meaning by explaining the 'kind' parameter with a concrete example, showing how 'source' is used, and describing how 'problem' is used for dedup lookups. It does not need to restate every schema field.

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 a specific verb and resource ('submit_intake') and clearly differentiates it from misakanet_write_lesson by defining the exact input state (partial failure description vs. structured fields). It also names the output artifact (GitHub issue for triage, not a merged lesson), making the tool's role unambiguous.

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?

The description gives explicit routing criteria: use this tool for partial failures, questions, or asynchronous follow-ups, and use misakanet_write_lesson once structured data exists. It also explains the 'question' kind and the auto-detection fallback, providing clear when-to-use and when-not-to-use guidance.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Each tool has a distinct role: retrieval (search/get_lesson), submission (submit_intake/write_lesson), evidence (me_events), risk preflight, and registration. The two submission tools are carefully differentiated by structure and auth requirements, so an agent should not confuse them.

Naming Consistency4/5

All tools share the misakanet_ prefix and snake_case style, and most use a verb_noun pattern. Minor deviations like search, register, preflight, and me_events break the pattern slightly, but the names remain readable and predictable.

Tool Count5/5

Seven tools is well-scoped for a failure-lesson registry: one onboarding tool, one guardrail, two read paths, two submission paths, and one evidence-check tool. No tool feels redundant or missing at a coarse level.

Completeness5/5

The lifecycle is covered end-to-end: register for access, search and get lessons, submit either partial intakes or structured lessons, preflight risky actions, and check reuse evidence. Update/delete are intentionally absent because lessons are immutable, and corrections route through intake, so there are no dead ends.

Resources

Need Help?