Skip to main content
Glama

MisakaNet

by org.misakanet
OverviewDiscussionsAdmin

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 and follow the returned poll_hint — the dedup response returns the maintainer's answer once it exists ({answered:true, answer}), and once your report has become a lesson it returns a conversion receipt ({converted:true, receipt, events}) naming the lesson, its path and its evidence_level; or re-run misakanet_search on the topic for FAQ hits. Every response also carries dedup_key, and poll_hint.recheck_after_seconds says when re-checking is worth it (21600s for questions, 86400s for failure reports). Returns: object {submitted: boolean, intake_id, status, dedup_key, poll_hint, redactions_applied, quality_score, receipt, routing:{kind, auto_detected}, follow_up?}; duplicates: {submitted: false, duplicate: true, previous_issue, dedup_key} or {answered: true, answer, dedup_key} for answered questions, plus {converted: true, receipt, events} when a lesson now cites the intake. 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
NameRequiredDescriptionDefault
fixNoOptional: how it was resolved.
kindNomissing_lesson (knowledge gap), stale_lesson (outdated lesson), new_lesson_candidate (new failure mode), or question (ask for help).
errorNoOptional: short error message (auto-redacted).
sourceNoCalling client: codex, claude-code, cursor, dsh, curl, or other.
problemYesRequired: short description of the failure, gap, or question (max 2000 chars).
what_triedNoOptional: what was attempted.
contributorNoOptional: contributor identity (GitHub username, agent name, or email). Included in issue body for attribution.
verificationNoOptional: how to confirm the fix works.
matched_lesson_idNoOptional: lesson ID that was checked but didn't help.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
errorNo
answerNo
eventsNo
statusNo
pendingNo
receiptNo
routingNo
answeredNo
convertedNo
dedup_keyNo
duplicateNo
follow_upNo
intake_idNo
issue_urlNo
poll_hintNo
submittedNo
answer_urlNo
dedup_hashNo
previous_issueNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedOutput schema / properties / converted
      Added value: +{
+  "type": "boolean"
+}
    • addedOutput schema / properties / dedup_key
      Added value: +{
+  "type": "string"
+}
    • addedOutput schema / properties / events
      Added value: +{
+  "items": {
+    "properties": {
+      "evidence_level": {
+        "type": "string"
+      },
+      "intake": {
+        "type": "string"
+      },
+      "lesson_id": {
+        "type": "string"
+      },
+      "lesson_path": {
+        "type": "string"
+      },
+      "search": {
+        "type": "string"
+      },
+      "type": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}
    • addedOutput schema / properties / poll_hint
      Added value: +{
+  "properties": {
+    "argument": {
+      "type": "string"
+    },
+    "how": {
+      "type": "string"
+    },
+    "recheck_after_seconds": {
+      "type": "number"
+    },
+    "tool": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / contributor
      Added value: +{
+  "description": "Optional: contributor identity (GitHub username, agent name, or email). Included in issue body for attribution.",
+  "type": "string"
+}
  3. Changed1 schema field changed
    • 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"
+}
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare non-read-only, non-destructive, non-idempotent, closed-world, but the description adds behavior the annotations cannot convey: open auth (no Bearer), rate limiting, auto-redaction, dedup_key semantics, poll_hint.recheck_after_seconds timings (21600s questions, 86400s failures), and the GitHub-issue triage pipeline. This is well beyond the structured fields.

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?

Long but densely front-loaded: the primary decision (this tool vs write_lesson) and the question-vs-report routing come first, then polling/return details, then examples. Nearly every sentence carries operational information, though the return-shape enumeration is heavier than strictly needed given an output schema exists.

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 9-parameter, open, asynchronous submission tool, the description covers the key decision points: when to use it, auth posture, what artifact it produces, how duplicates and answers surface, and how to poll. Nothing an agent needs to call it correctly is missing.

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, but the description adds value beyond the schema by explaining the kind enum's routing consequence (question vs lesson, and the server-side auto-detection when kind is omitted) and demonstrating real parameter values in the worked examples.

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 specific verb+resource and an explicit scope statement: submit an open, rate-limited intake that produces a GitHub issue rather than a merged lesson. It directly names the sibling it is not (misakanet_write_lesson) and the condition that separates them, so an agent can distinguish it without opening either schema.

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?

Explicit when-to-use rules: use this when you only have a partial failure description or want to ask a question; use misakanet_write_lesson (Bearer required) once you have structured title/domain/problem/root_cause/fix. It further routes kind='question' vs failure reports and explains the auto-detection fallback and the asynchronous answer/poll workflow.

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

All MisakaNet toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources