Skip to main content
Glama

misakanet_memory_context

Fetch relevant failure-memory lessons before starting a task to have known pitfalls in context from the first step, preventing repeated mistakes.

Instructions

Proactive half of the pair: call this BEFORE starting a task so failure-memory is in context from the first step; call misakanet_search once a specific error has actually appeared. Input semantics: task is required and is matched as lexical keyword/token overlap over lesson titles, summaries and tags (BM25 when the index is present, a plain scorer otherwise) — not embeddings — so pass the concrete nouns, tools and error words you are about to meet ('chromadb on an NTFS mount', 'docker multi-stage build OOM') rather than a goal ('make it faster'); intent-only phrasing retrieves nothing. How domain behaves: a hard filter over a closed vocabulary of the domains the lesson corpus declares (the repository's data/domains.json is the list; rag, devops, fanuc, python, ci, mcp are examples), and a value outside it returns zero lessons with no error — so leave it out unless you know the domain; an empty result with a domain set is usually the filter, not an empty corpus. How top_n behaves: silently clamped to 10 (larger values are accepted and reduced), and each lesson is trimmed to 200 characters per field inside context_block — past roughly five matches you spend prompt space faster than you gain information. Output schema: Returns {task, lesson_count, lessons, context_block}; context_block is ready-to-inject markdown, and lesson_count 0 (voice='failure-warning') means the corpus has no match yet — retry with the raw error text or submit an intake, rather than reading it as a tool failure. Error cases: a missing or empty task returns {error, hint, voice} instead of lessons; a domain outside the declared vocabulary returns zero lessons rather than an error; a missing or empty index degrades to the plain lexical scorer instead of failing. Side effects: none — this is a read-only call, and it does not record usage or touch the network. Auth: none. Rate limits: none — matching runs against the lessons/ directory of the checkout this server was started from, so results are only as current as that checkout. Local stdio server only — the hosted endpoint exposes misakanet_search and misakanet_get_lesson instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskYesWhat you are about to do, in the vocabulary of the tools, systems and errors involved (e.g. 'set up a ChromaDB RAG pipeline on WSL', 'deploy FastAPI behind a corporate proxy'). Matched lexically, so include the distinctive terms a lesson would use in its title or problem statement.
top_nNoHow many lessons to return (default 5). Values above 10 are accepted and silently clamped to 10. Each returned lesson is truncated to 200 characters per field in context_block, so ~5 is where extra matches start costing more prompt budget than they add.
domainNoOptional hard filter on the lesson's frontmatter domain, from a closed vocabulary (e.g. 'rag', 'devops', 'fanuc', 'python', 'ci', 'mcp'). It narrows and never widens: an unknown value yields zero lessons without an error, so omit it when unsure.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.31.1
    • changedInput schema / properties / domain / description
      Previous value: -"Optional domain filter (e.g. 'search-and-retrieval', 'ci-cd')."New value: +"Optional hard filter on the lesson's frontmatter domain, from a closed vocabulary (e.g. 'rag', 'devops', 'fanuc', 'python', 'ci', 'mcp'). It narrows and never widens: an unknown value yields zero lessons without an error, so omit it when unsure."
    • changedInput schema / properties / task / description
      Previous value: -"Task description (e.g. 'set up ChromaDB RAG pipeline', 'deploy FastAPI to production')."New value: +"What you are about to do, in the vocabulary of the tools, systems and errors involved (e.g. 'set up a ChromaDB RAG pipeline on WSL', 'deploy FastAPI behind a corporate proxy'). Matched lexically, so include the distinctive terms a lesson would use in its title or problem statement."
    • changedInput schema / properties / top_n / description
      Previous value: -"Number of lessons to retrieve (default 5, max 10)."New value: +"How many lessons to return (default 5). Values above 10 are accepted and silently clamped to 10. Each returned lesson is truncated to 200 characters per field in context_block, so ~5 is where extra matches start costing more prompt budget than they add."
  2. Addedv2.21.0

TDQS

A5/5.0
Behavior5/5

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

With no annotations provided, the description fully carries the behavioral burden and does so extensively: matching is lexical/BM25 not embeddings, `domain` is a hard filter with silent zero-result behavior, `top_n` is silently clamped, fields are truncated, empty results are not tool failures, side effects/auth/rate limits are declared, and the deployment limitation is disclosed. This goes well beyond what any structured field could provide.

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 densely informative and structurally organized around decision-relevant sections: usage, parameter semantics, output, errors, side effects, and environment. The proactive usage guidance is front-loaded, and every sentence contributes operational value for a tool with meaningful edge cases.

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?

Given no output schema and no annotations, the description is complete: it covers input semantics, output shape, zero-result interpretation, error behavior, retry guidance, side effects, auth, rate limits, and the context of local vs hosted deployment. An agent has everything needed to select and invoke this tool correctly.

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?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema: `task` must be phrased in the vocabulary of emerging errors rather than intents, `domain` is a closed-vocabulary hard filter that returns zero rather than erroring, and `top_n` has clamping and truncation behavior. It materially improves the agent's ability to supply correct argument values.

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 purpose and action: retrieve failure-memory context BEFORE starting a task, positioning it as the proactive counterpart to misakanet_search. It explicitly names the sibling it is not and the trigger condition for each, so an agent can distinguish them without opening schemas.

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 gives explicit when-to-use guidance ('call this BEFORE starting a task') and when-not-to-use guidance ('call misakanet_search once a specific error has actually appeared'). It also provides actionable parameter-level usage advice: pass concrete nouns/tools/error words rather than goals, and omit `domain` unless the exact vocabulary is known.

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