Skip to main content
Glama

misakanet_preflight

Proactively checks risk level before high-risk operations by matching agent intent against lesson triggers and risk profiles, warning 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. 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

TableJSON 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.5/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. It discloses that the tool is read-only with no side effects, no auth, local stdio only, error behavior for missing intent, output shape, and subtle interpretation details such as high risk_level with empty matched_lessons.

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 front-loaded with purpose and usage, then labels input semantics, output shape, error cases, side effects, auth, and rate limits. Despite its length, every section provides actionable information and no sentence is wasted.

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?

The tool has no output schema and no annotations, so the description must supply return format, safety profile, and operational context. It does all of this, including the output JSON structure, error case, side-effect absence, auth, and rate limits, leaving no critical gap for correct invocation.

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 both parameters are already documented in the input schema. The description repeats the examples and adds the required/optional distinction, but does not provide syntax, format, or constraints beyond what the schema already contains.

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 begins with a specific verb and resource: 'Check risk level before executing high-risk operations.' It then clarifies that the tool matches agent intent against lesson triggers and risk profiles, distinguishing it from sibling tools like misakanet_search or misakanet_get_lesson.

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 concrete when-to-use examples: 'before RAG builds, WSL/GPU tasks, bulk imports, or any operation that might fail.' It does not explicitly state when not to use the tool or name a sibling alternative, but the triggering conditions are clear.

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