Skip to main content
Glama

misakanet_preflight

Check risk before high-risk operations by matching intent against failure lessons and risk profiles, returning warnings and guards before RAG builds, WSL/GPU tasks, or bulk imports.

Instructions

Check risk level before executing high-risk operations. Matches agent intent against lesson triggers and risk profiles to provide proactive warnings before you start. Use before RAG builds, WSL/GPU tasks, bulk imports, or any operation that might fail. Input semantics: intent (required) describes what you plan to do in concrete terms (e.g. 'build RAG pipeline with ChromaDB'); context (optional) describes the environment (e.g. 'WSL, GPU 8GB'). Output schema: JSON with {risk_level (low|medium|high), intent, matched_lessons: [{id, title, domain, relevance}], guards: [string]}. Matched lessons are pulled from the local corpus using keyword overlap — a high risk_level with empty matched_lessons means the profile matched (e.g. 'GPU' triggers the WSL profile) but no specific lesson was close enough. That reading holds only while index_status is "ok"; it is "unreadable" when data/lessons.json could not be read or parsed, and then matched_lessons is empty because no lesson was checked rather than because none matched, with index_error saying why. Guards are concrete 'do X before Y' suggestions drawn from matched profiles and lessons. Error cases: missing intent returns {error}. Side effects: none — this is a read-only check. Auth: none. Rate limits: local stdio process only.

Input Schema

NameRequiredDescriptionDefault
intentYesTask intent description (e.g. 'build RAG index from PDFs')
contextNoEnvironment context (e.g. 'WSL, GPU 8GB')

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.17.1

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries full burden and does so thoroughly: it discloses side effects ('none — read-only check'), auth requirements ('none'), rate limits ('local stdio process only'), the exact JSON return structure including the subtle risk_level/matched_lessons interaction, and the failure mode where an unreadable index produces empty matched_lessons for a different reason. This is exceptional behavioral disclosure.

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 front-loaded with purpose and usage, then flows into input semantics, output schema, error cases, and operational traits. It is dense but well-organized. It is somewhat long, but every section earns its place given the tool's complexity. Minor deduction for slight redundancy in re-explaining the empty matched_lessons scenario twice.

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?

Complete for a 2-parameter read-only tool with no annotations and no output schema. The description covers purpose, usage, parameters, return structure including edge cases, error handling, side effects, auth, and rate limits. Nothing material is missing for an agent to invoke and interpret results correctly.

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 schema documents both parameters. However, the description adds concrete examples ('build RAG pipeline with ChromaDB', 'WSL, GPU 8GB') and clarifies the semantic distinction between intent (what you plan to do) and context (the environment), which goes beyond the schema's brief descriptions. Baseline 3 is exceeded because the description actively enriches parameter meaning.

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 risk level before executing high-risk operations') and immediately distinguishes the tool from the sibling set: none of misakanet_search, misakanet_get_lesson, or misakanet_memory_context is a preflight risk check. The scope and purpose are unmistakable.

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?

Explicitly says when to use it ('before RAG builds, WSL/GPU tasks, bulk imports, or any operation that might fail') and clarifies the timing ('before you start'). This is direct when-to-use guidance with no ambiguity about the alternative (i.e., simply proceeding without a preflight check).

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