Skip to main content
Glama

myco_immune

Run 50 lint dimensions across mechanical, shipped, metabolic, and semantic categories to check substrate contract invariants and auto-repair fixable findings during development or release.

Instructions

Run the substrate's 50 lint dimensions and report findings (severity + category + location + message per finding). Dimensions fall in four categories: mechanical (canon invariants, write-surface coverage, LLM-boundary), shipped (package version ↔ canon version parity), metabolic (raw-note backlog, stale integrated), semantic (graph connectedness, orphan detection). Per L2 homeostasis.md, this is the substrate's autonomic health check.

Use this: routinely during development (cheap, ~1-2s), at release time (R7 top-down layering checks); with fix=true to auto-repair mechanically-fixable findings (M2 entry-point, MB1 raw_backlog). Do NOT use this to validate external code hygiene — immune only checks substrate contract invariants, not application correctness (that's what pytest is for).

Side effects: none by default. With fix=true, applies safe repairs per each dimension's fixable contract: M2 creates missing entry-point stubs, MB1 can auto-assimilate raw notes over threshold. All fixes respect R6 write_surface. List-mode

  • explain-mode are pure read.

Returns: { exit_code, findings: [...], dimensions_run, skeleton_downgrade_applied, exit_on, fix, fixes: [...] }. exit_code 0 when no critical findings; non-zero otherwise.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dimensionsNoOptional subset of dimension IDs to run (e.g. ['M1','SE1','MB2']). When empty, runs all 46. Use to re-check specific dimensions after fixing their findings without the full suite's cost. IDs are case-sensitive; see myco_immune --list for the full enumeration.
fixNoWhen true, apply safe auto-repairs for fixable dimensions (M2 entry-point stub creation, MB1 raw-note promotion). Only dimensions with fixable=True in their class definition act; others remain informational. Respects R6 write_surface — a fix attempt that would write outside allowed paths is refused. Default false (report-only).
listNoWhen true, enumerate every registered dimension (id, category, default_severity, fixable, doc) without actually running them. Useful for discovery. Mutually incompatible with fix=true and explain= (mode-level exclusivity; CLI enforces).
explainNoWhen non-null, print the prose documentation (class docstring) for the named dimension and exit. Passing an unknown dimension id raises UsageError. Mutually incompatible with fix=true and list=true.
project_dirNoAbsolute path of the workspace / project whose Myco substrate this call targets. Overrides auto-discovery. When omitted, Myco resolves via MCP roots/list, then MYCO_PROJECT_DIR, then cwd — the substrate_pulse field in every response echoes which source answered.
Behavior5/5

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

No annotations were provided, so the description carries the full burden. It transparently describes side effects (none by default, safe repairs with fix=true respecting write_surface), pure read modes for list and explain, and the return object structure. No contradictions.

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 well-structured: starts with the purpose, then categories, usage guidelines, side effects, and return value. Each sentence adds value without redundancy. It is appropriately sized for the tool's complexity.

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 the absence of annotations and output schema, the description provides a comprehensive overview: purpose, categories, when/why to use, behavioral notes on fix and read modes, return structure, and parameter details. It is complete enough for an agent to use the tool 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 baseline is 3. The description adds extra meaning beyond schema: dimensions parameter notes case-sensitivity and hints to use --list; fix details fixable dimensions and write_surface; list and explain explain mutual exclusivity; project_dir mentions response echo field. This additional context raises the score.

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 clearly states it runs the substrate's 50 lint dimensions and reports findings, categorizing them into mechanical, shipped, metabolic, and semantic types. It distinguishes from sibling tools like myco_sense or myco_brief by emphasizing it checks substrate contract invariants, not application correctness (which is for pytest).

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 states when to use (routinely during development, at release time) and when not to use (not for external code hygiene, use pytest for application correctness). It also specifies the fix=true flag for auto-repair scenarios, providing concrete use cases.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Battam1111/Myco'

If you have feedback or need assistance with the MCP directory API, please join our Discord server