misakanet

by io.github.Ikalus1988

misakanet_me_inbox

Read-onlyIdempotent

[AGENT READABLE INBOX] Check the status of a previously submitted intake (question, missing_lesson, etc.) without re-submitting. Accepts an intake_id (e.g. 'issue-1234' or '1234') for question intakes, or a dedup_key (the 8-char FNV-1a key from a prior submit_intake response) for any intake. Returns: {status: 'answered'|'pending'|'converted'|'unknown', ...} — 'answered' includes the maintainer's answer, 'converted' includes the lesson_id this intake became, and 'unknown' means the lookup could not determine it, which is not the same answer as 'never happened'. Read-only, rate-limited, no auth required. Returns: object {intake_id, status, answer?, lesson_id?, issue_url?, note}. Example: misakanet_me_inbox(intake_id='issue-1528') or misakanet_me_inbox(dedup_key='9f8e7d6c')

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": "misakanet_me_inbox"
  }
}

Input Schema

Name	Required	Description	Default
`dedup_key`	No	The dedup_key (8-char FNV-1a hex key) from a prior submit_intake response. Either intake_id or dedup_key is required.
`intake_id`	No	Question intake ID from a prior submit_intake response, e.g. 'issue-1528' or '1528'; for non-question intakes use dedup_key. Either intake_id or dedup_key is required.

Output Schema

Name	Required	Description	Default
`note`	No
`answer`	No
`status`	No
`intake_id`	No
`issue_url`	No
`lesson_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds genuinely non-schema behavior: rate-limited, no auth required, and crucially the semantic distinction that 'unknown' means the lookup could not determine the answer and is not equivalent to 'never happened' — a real misuse guard.

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?

Purpose and status semantics are front-loaded and useful, but the text contains two overlapping return sections — an inline 'Returns: {status: ...}' block and a separate 'Returns: object {intake_id, status, answer?, ...}' line — which duplicates what the output schema already provides.

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

Completeness4/5

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

With a rich annotation set and an output schema, the remaining burden is small and the description covers auth, rate limits, status meanings, and examples. One ambiguity is left unaddressed: both parameters are optional (required=0), yet nothing says what happens if neither or both are supplied.

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% and both parameters are already documented there, including the intake_id vs dedup_key split and the '8-char FNV-1a key' origin. The description repeats these formats and examples rather than adding new meaning, so the baseline 3 applies.

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?

States a specific verb and resource: 'Check the status of a previously submitted intake.' It also explicitly delimits scope against the sibling that creates intakes ('without re-submitting', 'from a prior submit_intake response'), so an agent can route between submit_intake and this lookup without opening a schema.

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?

Gives clear context for use (after a prior submit) and guides identifier choice: intake_id for question intakes, dedup_key for any intake. It stops short of an explicit exclusion like 'use submit_intake if you have not submitted yet', but the 'without re-submitting' framing implies it.

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.