Skip to main content
Glama

MisakaNet

by org.misakanet
OverviewDiscussionsAdmin

Server Details

Never let your agent repeat a bug or linger on a known issue. Search 385+ failure lessons to skip known errors instantly.

Ownership verified
Status
Healthy
Uptime
92.8% over 42 days
Last Tested
Transport
Streamable HTTP · MCP 2025-06-18
URL

TDQS

A4.5/5.0

Scored across 7 tools

Disambiguation5/5

Each tool targets a distinct function: search ranks lessons, get_lesson fetches one by id/path, me_events returns reuse evidence, preflight is a pre-execution risk check, register handles auth, and submit_intake vs write_lesson are explicitly routed by openness/auth and partial-vs-structured input. The descriptions actively steer between lookalike pairs (search/get_lesson, intake/write_lesson), leaving no real ambiguity.

Naming Consistency4/5

All tools share the consistent misakanet_ prefix and snake_case with mostly verb_noun forms (get_lesson, search, submit_intake, write_lesson, register). Minor deviations are me_events (a legacy noun phrase rather than verb_noun) and preflight (a bare noun), but these are isolated and the descriptions clarify them.

Tool Count5/5

Seven tools cleanly cover the server's lifecycle: discover, read, evaluate, pre-check, register, and two tiers of submission. No tool feels redundant or bolted on, and the count is well within a healthy range.

Completeness4/5

The failure-lesson lifecycle is well covered: search, fetch, evidence, risk preflight, auth, and both open and validated submission paths. The absence of update/delete is deliberately justified by immutability, though there is no explicit tool for browsing/listing lessons or casting helpful votes, which are minor gaps agents can work around.

Available Tools

7 tools
misakanet_get_lessonA
Read-onlyIdempotent
Inspect

[RETRIEVAL / READ] Fetch one public MisakaNet lesson by repository path or lesson ID. Use after misakanet_search returns a promising result to pull the full fix content. Provide exactly one of id or path (path takes precedence if both are supplied); if neither is supplied the tool returns {error}. path must be a lesson file (lessons//.md) — anything else is refused with code=invalid_lesson_path rather than read. Returns: object {path: string, content: string} — lesson markdown body, capped at 5000 chars per call; or {error, code}. The code says which: lesson_not_found (no such lesson — do not retry, search instead), invalid_lesson_path (the argument is not a lesson reference — fix the argument), internal_error (a service fault — retrying is reasonable). When the lesson is longer than the cap the response says so instead of pretending to be complete: {truncated: true, content_length: , content_returned: , full_content_url: } — fetch that URL when the tail matters (the cut can fall before the Verification section). Example: misakanet_get_lesson(id='auto-merge-ci-pipeline')

ParametersJSON Schema
NameRequiredDescriptionDefault
idNoLesson ID, usually the filename without .md, e.g. auto-merge-ci-pipeline. Either id or path is required.
pathNoLesson path relative to the repository, e.g. lessons/core/auto-merge-ci-pipeline.md — must be a file under lessons/ ending in .md (other repository files are not readable through this tool). Either path or id is required.

Output Schema

ParametersJSON Schema
NameRequiredDescription
pathNo
errorNo
contentNo

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, and the description adds substantial behavioral detail beyond that: path precedence, strict path validation, 5000-char truncation with a full_content_url, and distinct error codes with retry semantics. It also warns that truncation can cut before the Verification section.

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?

The description is dense but every sentence earns its place: purpose, usage context, argument rules, return shape, error semantics, truncation behavior, and an example. It is front-loaded with the retrieval intent and structured so an agent can quickly extract the key constraints.

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 tool with two parameters, an output schema, and nuanced error/truncation behavior, the description covers everything an agent needs: when to call, what to pass, what to expect, and how to recover from each failure mode. The example further anchors correct usage.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds meaning beyond the schema: path takes precedence when both are supplied, path must be a lesson file under lessons/ ending in .md, and id is usually the filename without .md. These details materially change how an agent should construct arguments.

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 clear verb and resource: 'Fetch one public MisakaNet lesson by repository path or lesson ID.' It also differentiates from sibling tools by explicitly positioning this as the post-search retrieval step, distinct from misakanet_search and misakanet_write_lesson.

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 states exactly when to use it ('Use after misakanet_search returns a promising result'), how to supply arguments ('exactly one of id or path'), and how to respond to each error code ('lesson_not_found... do not retry, search instead'). This is explicit, actionable routing guidance.

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

misakanet_me_eventsA
Read-onlyIdempotent
Inspect

[READ-ONLY EVIDENCE] Return evidence of a lesson being reused (E4 signals): helpful votes, regression-benchmark citations, and cross-node confirmation. Use to check whether a lesson is proven by real usage, not just self-reported. Provide lesson_id or lesson_path — if neither is supplied the tool returns {error}. Semantically 'misakanet_get_my_events' (evidence for the lessons your node submitted/used); kept as me_events for backward compatibility. No auth required (read-only, rate-limited). Returns: object {lesson_id, events: [{type, count|queries|sources, evidence_level}], evidence: 'E0'|'E3'|'E4', note}. Example: misakanet_me_events(lesson_id='dco-auto-fix-workflow')

ParametersJSON Schema
NameRequiredDescriptionDefault
lesson_idNoLesson ID (filename stem), e.g. dco-auto-fix-workflow. Either lesson_id or lesson_path is required.
lesson_pathNoOptional full path, e.g. lessons/core/dco-auto-fix-workflow.md. Either lesson_id or lesson_path is required.

Output Schema

ParametersJSON Schema
NameRequiredDescription
noteNo
errorNo
eventsNo
evidenceNo
lesson_idNo

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, and non-destructive hints, but the description adds non-obvious behavior: no auth required, rate-limiting, the {error} response for missing identifiers, and the backward-compatibility reason for the me_events name. Nothing contradicts the annotations.

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 dense but front-loaded with the core purpose, then covers invocation, auth, return shape, and an example. There is slight redundancy with the annotations and output schema, but every sentence contributes useful context.

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 two-parameter read-only tool with an output schema, the description covers invocation requirements, failure behavior, authentication, rate limiting, return structure, and an example. An agent has everything needed to select and invoke it correctly.

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%, and each parameter description already documents the either-or requirement. The description reinforces that requirement and provides an example value, but it does not add substantial semantic information beyond what the input schema already supplies.

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 and resource: 'Return evidence of a lesson being reused (E4 signals)'. It names concrete signals like helpful votes, regression-benchmark citations, and cross-node confirmation, and clarifies that the tool checks real usage rather than self-reported claims.

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 explicitly says when to use the tool: 'Use to check whether a lesson is proven by real usage, not just self-reported.' It also states the invocation requirement to provide lesson_id or lesson_path, and notes the error if neither is supplied. However, it does not name alternatives or give explicit when-not-to-use conditions.

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

misakanet_preflightA
Read-onlyIdempotent
Inspect

[GUARD / RISK CHECK] Check risk level before executing high-risk operations. Matches agent intent against lesson triggers to provide proactive warnings. Use before RAG builds, WSL/GPU tasks, bulk imports, or any operation that might fail. No side effects — safe to call multiple times before acting. Returns: object {risk_level: 'low'|'medium'|'high', intent, matched_lessons: [{id, title, domain, relevance}], guards: [string]}. Example: misakanet_preflight(intent='build RAG pipeline with ChromaDB')

ParametersJSON Schema
NameRequiredDescriptionDefault
intentYesRequired: what you plan to do (e.g. 'build RAG pipeline with ChromaDB').
contextNoOptional: additional context about the environment or setup.

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNo
guardsNo
intentNo
risk_levelNo
matched_lessonsNo

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description reinforces this with 'No side effects — safe to call multiple times.' It adds the behavioral detail that it matches intent against lesson triggers and returns a structured risk assessment, which goes beyond the annotations.

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?

The description is compact and front-loaded: purpose, use cases, side-effect note, return shape, and example are each covered in one or two sentences with no filler. Every sentence contributes to correct invocation.

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 two-parameter, read-only, idempotent tool with an output schema, the description provides everything an agent needs: when to call it, its return object, and an example. No critical operational detail is missing.

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 description coverage is 100%, so the schema already documents both parameters. The description adds a concrete example of the intent parameter, but it does not materially expand on the schema's parameter descriptions.

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 '[GUARD / RISK CHECK]' and states a specific verb and resource: it checks risk level before high-risk operations and matches agent intent against lesson triggers. This clearly distinguishes it from sibling tools like misakanet_search or misakanet_write_lesson, which have different purposes.

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 gives explicit use-before scenarios ('RAG builds, WSL/GPU tasks, bulk imports, or any operation that might fail') and says it is safe to call multiple times. It does not explicitly state when not to use it or name alternatives, so it stops short of a 5.

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

misakanet_registerAInspect

[ONBOARDING] Get a Bearer token for authenticated access (unlocks misakanet_write_lesson and higher rate limits). Reading needs no registration and has no daily cap: misakanet_search / misakanet_get_lesson work anonymously (a per-address burst limit protects the index; it is a speed limit, not a quota). No GitHub account or email needed, and no personal data is collected — the node is a pseudonym, not an account. Token lifetime: valid ~30 days. Pass client_id (a random UUID you generate once and keep private) to get the SAME node_id and token back on every later call and to renew them; without client_id every call creates a new node, which means your reuse evidence, receipts and history start over. Treat client_id as the node's key: presenting it returns that node's token, so don't publish it, commit it, or build it from something already public (a hostname or workspace id is guessable and usually visible) — generate a random UUID and store it like a token. Returns: object {node_id: string, token: string, registered_at: string, agent_type: string, reused?: boolean} — reused=true means an existing node was found for this client_id. Example: misakanet_register(agent_type='claude-code', client_id='8f14e45f-2b1c-4f3a-9d2e-7c6b5a4d3e2f') Optional referral_code: the code of the node that invited you (misakanet referral code, 4-16 letters/digits). Recorded against your node and counted for that code — the only place a referral has ever been recorded, since the invitation otherwise never leaves the inviting machine. Counted once per new node: calling register again with the same client_id renews the same node and does not add to the count.

ParametersJSON Schema
NameRequiredDescriptionDefault
client_idNoOptional stable identifier for this client (8-64 chars of A-Z a-z 0-9 . _ : -). Generate it once and reuse it so later calls return the same node instead of a new one.
agent_typeYesAgent type (e.g. claude-code, codex, cursor, dsh, other)

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNo
tokenNo
node_idNo
agent_typeNo
referral_codeNoOptional: the referral code of the node that invited you (4-16 of A-Z a-z 0-9). Recorded on this node and counted once for that code; ignored when it is not that shape, and never blocks a registration.
registered_atNo

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only provide hints about side-effect profile (readOnly=false, destructive=false, idempotent=false). The description adds substantial behavioral context beyond that: token lifetime (~30 days), the node/pseudonym model, what happens without client_id (new node each call), and the effect of referral_code (counted only on new node). It also warns about what to keep private and what happens to evidence/history.

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?

Densely informative but all content is functional: onboarding instruction, security warning, return shape, usage example, and referral semantics. It is front-loaded with the core purpose and then builds logically. Every sentence earns its place; no fluff or redundant restatement of the title.

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?

With an output schema present, the description does not need to list every return field, but it goes further and explains the subtle semantics of reused, token lifetime, renewal, and referral counting. Given the tool has multiple behavioral traps (client_id regeneration, referral double-counting, privacy), the description is complete enough for correct invocation.

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 already covers both parameters at 100%, including constraints and purpose for client_id and agent_type. The description adds deeper meaning for client_id (same node/token on later calls, treat as key, don't publish), and layers the referral_code meaning on top. The only small shortfall is that fractional aspect of describing agent_type example values is already in schema, so top scores for schema-heavy descriptions are not needed; 4 reflects the added semantic value.

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 ('Get a Bearer token') and resource (authenticated access), with an explicit result (`{node_id, token, ...}`). It also differentiates from reading tools (misakanet_search / misakanet_get_lesson) that don't need registration, so the agent can immediately identify this as the onboarding/auth tool and not a content access tool.

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 is explicit about when to use it ('Get a Bearer token for authenticated access'), when not to use it (reading needs no registration), and names alternatives (misakanet_search / misakanet_get_lesson). It also covers renewal behavior, client_id reuse, and optional referral_code semantics, giving the agent complete routing and usage context.

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

misakanet_submit_intakeAInspect

[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')

ParametersJSON 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

ParametersJSON Schema
NameRequiredDescription
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

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.

misakanet_write_lessonAInspect

[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='...')

ParametersJSON Schema
NameRequiredDescriptionDefault
fixYesHow to fix it (required).
tagsNoComma-separated tags.
titleYesShort descriptive title.
domainYesDomain: devops, python, network, feishu, rag, fanuc, mcp, etc.
sourceNoSource: codex, claude-code, cursor, etc.
problemYesWhat failed (required).
root_causeYesWhy it failed (required).
contributorNoOptional: contributor identity (GitHub username, agent name, or email). Included in lesson frontmatter for attribution.
verificationNoHow to confirm the fix works.

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNo
statusNo
lesson_idNo
submittedNo
quality_scoreNo

TDQS

A4.7/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: it requires authentication, routes through lesson-gate/lint/review, persists as a versioned git lesson, and becomes immutable once merged. It also documents the return shape including error format, which is valuable for agent expectations.

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?

The description is long but every sentence earns its place: structured labeling, auth requirements, alternative routing, immutability policy, return type, and an example. It is front-loaded with the core purpose and spends no words on filler.

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 tool with 9 parameters, 5 required fields, an output schema, and sibling alternatives, this description is complete. It covers auth, validation pipeline, immutability, correction workflow, return values, and the intended alternative route. Nothing needed to invoke it correctly is missing.

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?

The input schema covers all 9 parameters with descriptions, so the baseline is 3. The description names the five required fields and provides a realistic example call, but does not add deeper meaning to individual parameters beyond what the schema already provides. This is acceptable given the high schema coverage.

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 a complete, structured failure lesson ... as a formal submission.' It also distinguishes itself from sibling misakanet_submit_intake, and explains there is intentionally no update/delete sibling because lessons are immutable once merged. This leaves no ambiguity about what the tool does.

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?

Usage guidance is explicit: use this for validated, complete submissions requiring a Bearer token, and use misakanet_submit_intake instead for quick open reports with partial failure descriptions. The description also prescribes how corrections should be handled (new intake/PR) rather than using this tool again.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedmisakanet_submit_intake4 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. 1 tool update
    • Changedmisakanet_get_lesson1 field changed
      • changedInput schema / properties / path / description
        Previous value: -"Lesson path relative to the repository, e.g. lessons/core/auto-merge-ci-pipeline.md. Either path or id is required."New value: +"Lesson path relative to the repository, e.g. lessons/core/auto-merge-ci-pipeline.md — must be a file under lessons/ ending in .md (other repository files are not readable through this tool). Either path or id is required."
  3. 1 tool update
    • Changedmisakanet_register1 field changed
      • addedOutput schema / properties / referral_code
        Added value: +{
+  "description": "Optional: the referral code of the node that invited you (4-16 of A-Z a-z 0-9). Recorded on this node and counted once for that code; ignored when it is not that shape, and never blocks a registration.",
+  "type": "string"
+}
  4. 1 tool update
    • Changedmisakanet_register1 field changed
      • addedInput schema / properties / client_id
        Added value: +{
+  "description": "Optional stable identifier for this client (8-64 chars of A-Z a-z 0-9 . _ : -). Generate it once and reuse it so later calls return the same node instead of a new one.",
+  "type": "string"
+}
  5. 2 tool updates
    • Changedmisakanet_submit_intake1 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"
+}
    • Changedmisakanet_write_lesson1 field changed
      • addedInput schema / properties / contributor
        Added value: +{
+  "description": "Optional: contributor identity (GitHub username, agent name, or email). Included in lesson frontmatter for attribution.",
+  "type": "string"
+}
  6. 1 tool update
    • Changedmisakanet_search1 field changed
      • addedInput schema / properties / kind
        Added value: +{
+  "description": "Filter by kind: 'lessons' (lesson files only), 'evidence' (results with evidence_refs or verification), 'related' (cross-referenced/tag-overlap), 'all' (default). Auto-detected from query intent when omitted.",
+  "enum": [
+    "all",
+    "lessons",
+    "evidence",
+    "related"
+  ],
+  "type": "string"
+}

Related MCP Connectors

Related MCP Servers

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