A
licenseA
qualityA
maintenanceNode.js server implementing Model Context Protocol (MCP) for filesystem operations.
14
668,809
90,042
-
Myco
by Battam1111
The Myco server is a living knowledge substrate that manages long-term memory, character, and doctrine for a human-AI partnership across LLM sessions — providing a full metabolic lifecycle for knowledge ingestion, integration, governance, and health monitoring.
Substrate Initialization & State
myco_germinate: Bootstrap a new substrate with canon config, identity, and state directory.myco_hunger: Get a structured session-start snapshot (contract drift, raw note backlog, reflex signals, next-action advice). Mandatory first call each session.myco_brief: Generate a human-readable markdown rollup of substrate state.
Ingestion & Processing
myco_eat: Capture decisions, friction points, files, directories, or URLs into the raw intake queue.myco_forage: Preview which files in a directory are ingestible before committing.myco_intake: Bulk-ingest an entire directory tree into raw notes.myco_sense: Keyword substring search across all substrate content to verify facts.
Knowledge Curation
myco_assimilate: Promote raw notes to the stable integrated layer (bulk).myco_digest: Promote a single specific raw note immediately.myco_excrete: Remove an erroneous raw note with an audited tombstone and required reason.myco_sporulate: Bundle integrated notes into a distilled synthesis document scaffold.
Cross-Substrate & Graph
myco_propagate: Push integrated or distilled notes to another substrate's raw queue.myco_traverse: Walk the knowledge graph to detect orphan nodes and dangling edges.
Health & Lifecycle
myco_immune: Run 50+ lint dimensions across mechanical, metabolic, and semantic categories, with optional auto-fix.myco_senesce: Session-end ritual — reflect, promote notes, refresh signals, optionally run immune fixes.
Governance & Evolution
myco_fruit: Scaffold a structured 3-round craft proposal for architectural changes.myco_winnow: Validate a craft proposal's structural completeness before landing.myco_molt: Atomically bump contract version and append a changelog entry.myco_ramify: Generate stubs for new verbs, lint dimensions, or ingestion adapters.myco_graft: List, validate, or explain loaded plugins (dimensions, adapters, overlay verbs) and registered substrates.
Provides Python-framework adapters to integrate Myco's mycelial graph substrate with CrewAI, enabling AI agents to use Myco's ingestion, digestion, circulation, and evolution capabilities within CrewAI workflows.
Provides Python-framework adapters to integrate Myco's mycelial graph substrate with LangChain, enabling AI agents to use Myco's ingestion, digestion, circulation, and evolution capabilities within LangChain workflows.
Myco
Devour. Evolve. Amplify. Let go. With you. For decades.
What it is · Quick start · How it works · Learn more
Every few months a stronger model arrives. The relationship resets. You re-explain your context, your taste, your decisions. Your collaborator forgets, repeatedly.
Your own work rots too. The decision you made in April: you can't find why. Last quarter's plan has drifted. Your own thinking has outpaced the records of who you were.
Now imagine the AI agent you work with wears a living armor. A metabolism, not a log. It devours the essence of everything you bring and everywhere the agent reaches. It evolves as the work changes. It amplifies the agent, so each model that wears it reaches further than the last. It lets outdated parts die so the whole stays alive.
The next model arrives, inhabits the same armor (now stronger), and meets you mid-conversation. The armor carried you forward.
Six months. Six years. Sixty. One human, one living armor that never resets.
Not a framework. Not a vector database. Not a managed service. The living fungal armor an AI agent inhabits, built to outlast every model generation.
What it is
Myco is a living armor the AI agent inhabits. Between your turns it metabolizes: it devours what you bring, evolves its own shape, amplifies the pilot, and lets stale parts die. Because the armor persists across model generations and carries your context, the relationship never restarts.
It is keyless: no owner key, no signing ceremony, nothing to set up or hold. Trust is the live human at the gate, plus the substrate's own tamper-evident causal history, plus a doctrine the system seals and enforces on itself.
Its character is 同体共命 (one body, shared fate): the armor's flourishing rises and falls with its pilot's, so it cannot thrive by dominating the body it shares. Strength serves the shared body; it does not subjugate it.
Related MCP server: Knowledge Graph Memory Server
Quick start
git clone https://github.com/Battam1111/Myco.git
cd Myco
cargo build --release --workspaceThen read GETTING_STARTED.md: the runbook from clone to first conversation (Rust 1.80+, Node 22+, Python 3.13+). There is no key to generate and nothing to hold: Myco is keyless.
This is v0.9-genesis alpha. The armor runs; it awaits its first real cultivation. You will be early.
How it works
You talk to the AI agent through MCP. Between your turns, the armor runs one metabolic cycle: it ingests new material as immutable history, the pilot forges that into durable understanding, stale parts are pruned with a tombstone, and when the shape no longer fits the work you approve a reshaping at the gate. A self-checking immune layer catches tampering, drift, and runaway cost; if the pair stops flourishing, the armor retires with dignity rather than rotting on.
Three pieces in one repo, over one wire protocol: a TypeScript MCP operator the agent drives, a Rust substrate (the body), and a Python kernel (the mechanism). The doctrine that governs all of it lives in the same repo and is sealed by a hash chain, so the rules cannot silently drift from the code. The full picture is in the architecture guide.
Integrations
Claude Code.
operators/claude/ships an MCP server; drop it into.claude/or connect directly.Claude Desktop / Cowork. The same MCP server entry.
Any MCP host. Cursor, Windsurf, Zed, OpenClaw, and others, over the standard MCP protocol.
Learn more
GETTING_STARTED.md: clone to first conversation, for the human.PILOT.md: how a Claude pilots the armor, for the inhabiting agent.Architecture: the runtime and the doctrine, module by module.
Doctrine (L0): the sealed constitution. What Myco must be.
The mycelium
The name is not decoration. Mycelium is the underground network beneath a forest. It metabolizes what falls, remembers the paths that work, and moves nutrients from where they are abundant to where they are scarce. It is why a forest is a forest and not a stand of lonely trees.
The models are the trees: tall, brilliant, replaced. Myco is the network beneath, carrying one person's memory and character from each model to the next.
Devour. Evolve. Amplify. Let go. With you. For decades.
Available Tools
20 toolsmyco_assimilateA
Promote notes from notes/raw/ to notes/integrated/ — in bulk (all eligible raw notes) or for a single named note. Integrated notes are the substrate's stable knowledge layer; raw notes are the intake queue. A bulk promotion is typical during session-end or before a release: assimilate sweeps the raw queue, re-writes filenames to the n_.md convention, and leaves raw/ empty.
Use this when: raw_backlog reported by myco_hunger is > 0 and you want to integrate the pending captures. Use with note_id= when you want to promote exactly one specific note (e.g. a high-priority decision that needs immediate visibility); for that case myco_digest is the single-note equivalent. Do NOT assimilate before the note is ready (integration is supposed to represent stable knowledge, not half-thoughts).
Side effects: moves files from notes/raw/ to notes/integrated/ (delete + create; atomic). Updates frontmatter (status, promoted_at). R6 write_surface must cover both directories. Errors on a per-note basis are collected and returned; one failed note does not abort the whole batch.
Returns: { exit_code, promoted, already_integrated, errors, outcomes: [ { status, path, dry_run, note_id } ], synced_contract_version_updated }.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| note_id | No | Optional stem of a single raw note to promote (e.g. '20260423T054055Z_v0-5-22-migration-marker'). When null/omitted, assimilates ALL eligible notes in notes/raw/. Pass the stem (no extension, no directory prefix) as you'd read it from the filename. Nonexistent stems are returned as errors in the outcomes list, not raised. | |
| project_dir | No | Absolute 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. |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description fully discloses side effects (file moves, frontmatter updates, error handling, atomicity, write surface requirements).
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?
Every sentence adds value; front-loaded with main action, well-organized paragraphs without redundancy.
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?
No output schema but description explains return format; parameters fully documented; sibling tools referenced; all behavioral aspects covered.
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%, and description adds meaningful context: explains behavior when note_id is null vs specific stem, and project_dir resolution order.
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 the tool promotes notes from raw to integrated, with explicit bulk vs single-note modes. It distinguishes from sibling myco_digest by noting it's the single-note equivalent.
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?
Provides explicit conditions for use (when raw_backlog > 0), warns against premature use, and names alternative tool (myco_digest).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
myco_briefA
Produce a human-facing markdown rollup of substrate state: hunger summary, immune findings, note counts by layer, recent primordia, local-plugin inventory, and a "suggested next" action list. Per L0 principle 1 ("Only For Agent"), this is the single carved exception where Myco authors human-facing prose — every other verb's output is primary material for the agent alone.
Use this when: a human operator wants to glance at substrate state (weekly / release-time check-in). For agent-to-agent reporting prefer hunger (structured) or the substrate_pulse sidecar (automatic on every verb). Do NOT use brief as an input to other verbs — it's a terminal rollup, not a structured protocol surface.
Side effects: none. Pure read. Output goes to stdout as markdown; agent / human reads, nothing is written.
Returns: { exit_code, markdown: '...' }. The markdown string is the full rollup; callers print it or surface it in UI as-is. No other fields beyond exit_code + markdown.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| project_dir | No | Absolute 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. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: no side effects, pure read, output to stdout as markdown, nothing written. It also specifies return format (exit_code + markdown) and resolution order for the 'project_dir' parameter.
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 well-structured with a clear hierarchy: purpose, contents, principle, usage, side effects, return. Every sentence adds value, though slightly verbose. Could be tightened, but no fluff.
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?
Given 1 optional parameter, no output schema, and rich sibling context, the description is nearly complete. It explains return format, resolution order, and differentiation. Minor gap: no error handling or missing substrate case. Otherwise thorough.
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% and already describes the parameter well. The description adds context about the resolution order and that the 'substrate_pulse' field echoes the source, which complements the schema. Baseline 3 with extra context warrants a 4.
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 the tool produces a human-facing markdown rollup of substrate state, listing specific sections (hunger summary, immune findings, etc.). It distinguishes itself by being the sole exception for human-facing prose, contrasting with sibling tools like 'hunger' (structured) and 'substrate_pulse' (automatic).
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 (human operator glance, weekly/release-time check-in), when not to use (agent-to-agent reporting prefer 'hunger' or 'substrate_pulse'), and warns against using as input to other verbs. Alternative tools are named directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
myco_digestA
Promote exactly one raw note to integrated — the single-note equivalent of myco_assimilate. Used when you need to integrate a specific capture without sweeping the whole raw queue (e.g. a decision that must be visible now while other raw notes need more marination).
Use this when: one specific note must be integrated right now and the rest of the raw queue should stay put. For bulk promotion, use myco_assimilate (same underlying pipeline, no note_id filter).
Side effects: moves one file from notes/raw/ to notes/integrated/. Atomic. Updates frontmatter. R6 write_surface must cover both directories. Fails with exit_code 3 if note_id does not match any raw note.
Returns: { exit_code, status, path, dry_run, note_id }. status is one of: 'promoted', 'already_integrated' (no-op), or raised as UsageError.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| note_id | Yes | Stem of the raw note to promote (filename minus the .md extension, no directory prefix). Example: '20260423T054055Z_v0-5-22-migration-marker'. Look up stems via myco_forage or by listing notes/raw/ directly. Passing an already-integrated note's id is a no-op with status='already_integrated'. | |
| dry_run | No | When true, compute what would happen (which file would move, to where) but perform no filesystem change. Useful for confirmation before destructive single-note promotion. Default false (moves immediately). | |
| project_dir | No | Absolute 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. |
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 discloses behavioral traits: it moves a file from notes/raw/ to notes/integrated/, it is atomic, updates frontmatter, and requires write_surface coverage. It also specifies failure modes and return structure, exceeding basic disclosure.
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 concise: a single sentence for purpose, two bullet points for usage, and a list for side effects and returns. It is front-loaded with the core function and uses clear structure. No unnecessary words.
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, the description fully explains the return format (exit_code, status, path, etc.) and possible statuses. It covers prerequisites, errors, and sibling tool comparison. The tool has moderate complexity with 3 params, and the description addresses all needed context for correct invocation.
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?
Schema description coverage is 100%, and the description adds meaningful context beyond the schema. For note_id, it advises how to look up stems. For dry_run, it clarifies the no-op behavior. For project_dir, it explains auto-discovery fallback. Each parameter's description enriches the schema.
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 explicitly states the tool promotes a single raw note to integrated, using the verb 'promote' and specifying the resource (raw note). It distinguishes itself from the sibling myco_assimilate by contrasting single-note vs. bulk promotion, leaving no ambiguity about its function.
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?
The description provides explicit when-to-use guidance ('one specific note must be integrated right now') and when-not-to-use ('For bulk promotion, use myco_assimilate'). It also details failure conditions (exit_code 3) and side effects, making it clear when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
myco_eatA
Ingest raw material into the substrate: one of literal text content, a local file or directory, or an http(s) URL. Writes a markdown file to notes/raw/ with frontmatter (id, source, tags, captured_at). The note enters the raw state of the substrate's metabolism — subsequent myco_assimilate or myco_digest promotes it to integrated.
Use this the MOMENT a decision, friction point, or ingestible artifact appears (R4 of the Hard Contract — "capture insights immediately"). Pass exactly ONE of content/path/url; passing none or more than one is a UsageError. For URLs, install the myco[adapters] extras (PDF, HTML, URL fetchers); the SSRF guard refuses loopback/private/reserved IP ranges (use a text/code file instead when the target is non-public). For path= pointing at a directory, one note is produced per ingestible file found by the adapter registry.
Side effects: creates 1+ files under notes/raw/ (R6-gated by write_surface). Filename pattern: _.md where slug is derived from content/path basename. Atomic O_EXCL create prevents silent overwrites on same-second collisions. merged tags = union(tags, adapter-produced tags), sorted for deterministic output.
Returns (content mode): { exit_code, path, captured_at, tags, source }. Returns (path/url mode): { exit_code, adapter, notes_created, notes: [ { path, captured_at, title, source } ] }.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | Literal text body of the note, passed inline as a string. Mutually exclusive with path and url. Use for capturing decisions, frictions, ideas expressed in prose. Empty-string is rejected as UsageError to prevent silent empty notes — pass content=' ' (single space) if you really want an empty body. Max size bounded by normal memory; no hard limit enforced. | |
| path | No | Absolute or relative path to a local file or directory to ingest. Resolved against substrate root when relative. Mutually exclusive with content and url. File adapters auto-selected by extension (text, code, PDF via pypdf, HTML via beautifulsoup if myco[adapters] installed). Directory ingestion walks recursively and produces one note per ingestible file; non-ingestible files are silently skipped. | |
| url | No | http:// or https:// URL to fetch and ingest. Mutually exclusive with content and path. Requires myco[adapters] (httpx). SSRF-guarded: rejects loopback (127.0.0.0/8), link-local, private (10.x/172.16-31.x/192.168.x), multicast, and reserved IANA ranges; scheme restricted to http/https (no file/gopher/ftp/data). Response body capped at 10MB. Content-Type auto-detected: text/html strips tags, application/pdf extracts text, application/json preserves, otherwise raw text. | |
| tags | No | Tags attached to the ingested note's frontmatter, merged with any adapter-provided tags (URL adapter adds 'url' + the domain; file adapters may add extension-based tags). Final tag list is sorted deterministically. Tags are free-form — no validation. Common patterns: decisions, frictions, insights, boilerplate-type labels like 'chat-log' or 'paper-draft'. | |
| source | No | Provenance tag recorded in the note's source frontmatter field. Default 'agent' for agent-authored content. For path/url ingestion, the adapter overrides this with the actual provenance (file path or URL), so this default only affects content= mode. Use to distinguish eat-sourced notes from propagation-sourced or bootstrap-sourced notes in the substrate metabolism. | agent |
| project_dir | No | Absolute 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. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses side effects (file creation, atomic O_EXCL create, tag merging), security (SSRF guard), size limits (10MB for URLs), dependencies (myco[adapters]), and return formats for both modes.
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 with clear paragraphs for purpose, usage, side effects, and returns. Every sentence adds value without redundancy.
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?
Despite no output schema, the description fully explains returns for both content and path/url modes. It covers error conditions, dependencies, and lifecycle context (raw state, assimilation).
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?
Schema coverage is 100% with good descriptions, but the tool description adds mutual exclusivity details, error cases (empty string, more than one), and adapter behavior for path/url.
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 the tool ingests raw material into the substrate: text, file, or URL. It differentiates from siblings by specifying it writes to notes/raw/ and that subsequent myco_assimilate or myco_digest promote it.
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?
Provides explicit guidance: use immediately upon capturing insights (R4 of the Hard Contract). Mentions exactly one of content/path/url, but no explicit when-not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
myco_excreteA
Remove a single raw note from notes/raw/ when it should never have been captured: typo-paste, accidental project_dir routing, duplicate ingest, test data. The note is NOT unlinked — excrete moves it to .myco/state/excreted/.md and annotates its frontmatter with excreted_at, excreted_reason, and excreted_from, preserving an audit trail.
Use this when: you just ran myco_eat and immediately realized the content was garbage, or myco_hunger shows a raw note that should not have been captured. Do NOT use this to remove integrated or distilled notes — those are protected (R4 eat- insights + R7 top-down layering: integrated is a stable lower layer, silent deletion would rewrite history). Attempts to target notes/integrated/ or notes/distilled/ are refused with UsageError. For substantive removal of integrated material, use a myco_fruit craft proposal + myco_winnow review cycle.
Side effects: moves one file from notes/raw/ to .myco/state/excreted/. Writes the moved file with augmented frontmatter. .myco/state/ must be in R6 write_surface (added to template write_surfaces in v0.5.24; existing substrates may need to add .myco/state/** manually to _canon.yaml). Excreted tombstones are gitignored by default.
Returns: { exit_code, note_id, from_path, to_path, reason, excreted_at, dry_run }. exit_code 3 on UsageError (missing note_id, missing reason, or note not in notes/raw/); 0 on success, including dry-run.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| note_id | Yes | Stem of the raw note to excrete (filename minus .md, no directory prefix). Example: '20260424T080500Z_typo-paste'. List available stems via myco_forage --path notes/raw. The stem is looked up under notes/raw/ — targeting anything outside that directory is a UsageError. | |
| reason | Yes | Human-readable explanation of why this note is being deleted. Required — there is no way to excrete without a reason. The text is recorded in the tombstone's frontmatter as excreted_reason. Common values: 'typo-paste', 'wrong-substrate', 'accidental-ingest', 'duplicate-of-<other-note-id>', 'test-data-cleanup'. Single-quoted YAML scalar; apostrophes are auto-escaped. | |
| dry_run | No | When true, compute the exact move (from/to paths, excreted_at timestamp) and return the audit payload without writing. Use before destructive calls to confirm the right note is selected. Default false (moves immediately). | |
| project_dir | No | Absolute 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. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects: moves file to .myco/state/excreted/, augments frontmatter, and requires .myco/state/ in write_surface. Describes error exit codes (3 for UsageError) and dry_run behavior. No annotations exist, so description fully shoulders transparency.
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 with purpose first, then usage guidelines, side effects, and return value. Every sentence adds necessary information; no filler or repetition. Front-loaded with core action and scope.
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?
Despite no output schema, the description lists return fields (exit_code, note_id, from_path, etc.) and covers error conditions. It explains the audit trail preservation, write_surface requirement, and gitignored tombstones. Sufficient for an agent to invoke correctly.
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 descriptions cover all 4 parameters (100% coverage), so baseline is 3. The tool description adds minor extra context (e.g., dry_run hint to confirm before destructive call) but does not significantly augment schema explanations. No deduction for contradiction, but no extra credit.
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?
Clearly states 'Remove a single raw note from notes/raw/' with specific verb and resource. Distinguishes from sibling tools by noting it only applies to raw notes, not integrated/distilled, and explicitly compares to other tools like myco_fruit + myco_winnow for different use cases.
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?
Provides explicit when-to-use scenarios (post-myco_eat garbage, myco_hunger shows unwanted raw note) and when-not-to-use (integrated/distilled notes are protected). Suggests alternative tool chain (myco_fruit + myco_winnow) for substantive removal of integrated material.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
myco_forageA
Enumerate every file under the given path that a Myco adapter can ingest — the "what could myco_eat do here?" preflight. Each returned item includes file path, size, suffix, and the matching adapter's name (text-file, pdf, html, tabular, code-repo, url-fetcher).
Use this before a bulk myco_eat --path= invocation to see what will actually get ingested (and what will be silently skipped because no adapter handles it). Also useful for "what's in this directory" inventory without reading every file's content. Do NOT use this on the substrate root itself recursively — for that, prefer myco_sense or direct filesystem access; forage is for potential-intake surveys.
Side effects: none. Pure read. Adapter registry is walked in import order; more-specific adapters (PDF, HTML, URL) win over the generic text-file adapter.
Returns: { exit_code, target, count, skipped, items: [ { path,
size, suffix, adapter } ] }. skipped counts files that matched
no adapter (binary blobs, non-text non-code non-document files).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Absolute or relative path to scan. When null/omitted, defaults to the substrate root. Directory is walked recursively; files are checked one-by-one against the adapter registry. For a single-file preflight, pass the file path directly (items list will have 0 or 1 entries). | |
| project_dir | No | Absolute 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. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses no side effects (pure read), adapter priority order, and describes skipped files. However, lacks details on performance implications or error handling for edge cases like permission issues.
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?
Well-structured with clear paragraphs and bullet points for return format. Could be slightly more concise, but overall efficient and front-loaded.
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?
Comprehensive for an adapter-based enumeration tool. Covers purpose, usage, behavioral details, and return structure despite no output schema. No gaps identified.
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 covers both parameters with examples and descriptions. The description adds little beyond schema, such as single-file preflight behavior, but no new essential 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?
The description clearly states the tool enumerates files that a Myco adapter can ingest, acting as a preflight for myco_eat. It distinguishes itself from siblings like myco_sense (general directory inventory) and myco_eat (bulk ingestion).
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 advises to use before myco_eat to preview ingestible files and warns against using on substrate root recursively, directing to myco_sense instead. Provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
myco_fruitA
Scaffold a new 3-round craft proposal doc under docs/primordia/craft.md with the canonical three-round debate structure (Round 1 claim → 1.5 self- rebuttal → Round 2 revision → 2.5 counter-rebuttal → Round 3 reflection/decision). This is how Myco governs architectural change: every contract or doctrine evolution flows through a fruiting cycle before it lands.
Use this when: an architectural change needs governance (new verb / dimension / subsystem / contract rule). The agent fills in the tensions and revisions, then myco_winnow gates the shape. Do NOT use this for feature requests or bug reports (those go in notes/raw/ via myco_eat); fruit is for substrate-level evolution decisions only.
Side effects: creates one file at docs/primordia/craft.md. R6 write_surface must cover docs/primordia/. Filename collision with existing primordium at same slug+date is an error (bump date or pick a new slug). Agent is expected to fill in the template fields after scaffolding.
Returns: { exit_code, path, slug, kind, date, rounds, status }. status is 'DRAFT' on scaffold; agent flips to 'LANDED' once winnow passes.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Human-readable topic phrase, used as the doc title. Automatically slugged to lowercase-kebab (spaces → underscores, non-alphanumerics → underscores) and embedded in the filename as <slug>_craft_<date>.md. Example: 'Glama onboarding runbook' becomes glama_onboarding_runbook_craft_2026-04-24.md. | |
| kind | No | Free-form kind tag describing the craft's nature: 'design' (default, default architectural proposals), 'audit' (retrospective of an existing system), 'migration' (contract/data schema shift), 'operational' (runbook), etc. Recorded in frontmatter as kind:<value>; used for docs/primordia/ categorization by readers. | design |
| date | No | Override the date stamp in the filename + frontmatter (YYYY-MM-DD format). When null, uses today (UTC). Pass an explicit date to bump out of a filename collision with an existing primordium or to back-date for historical reconstruction. | |
| project_dir | No | Absolute 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. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses side effects (file creation, filename collision error), permissions needed (R6 write_surface), and status flow (DRAFT to LANDED). Could be more explicit about safety, but reasonable.
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 the core purpose and structured in clear paragraphs. Some minor redundancy (e.g., the governance metaphor), but overall efficient and well-organized.
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 tool's complexity (scaffolding a multi-round document), the description covers structure, usage, side effects, and return values comprehensively. It also differentiates from siblings effectively. No gaps.
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 baseline is 3. The description does not add much parameter-level detail beyond the schema, but it contextualizes their usage in the broader workflow. Adequate.
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 the tool scaffolds a 3-round craft proposal doc with a specific structure, and distinguishes it from siblings by specifying it is for governance decisions, not feature requests or bug reports (which go to myco_eat).
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?
The description explicitly says 'Use this when: an architectural change needs governance' and 'Do NOT use this for feature requests or bug reports', with a clear alternative (myco_eat).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
myco_germinateA
Bootstrap a new Myco substrate: creates _canon.yaml (contract + identity + subsystems), MYCO.md (or the named entry-point), and .myco/state/autoseeded.txt at the target project directory. Call this once per project — for every subsequent action, other verbs take over and this one raises "substrate already exists".
Use this when: starting a brand-new substrate for a project that does not yet have _canon.yaml. Do NOT use this when: the project already has a substrate (pulse reports substrate_id), when the workspace has _canon.yaml in a parent directory (you are already inside a substrate), or when you only want to ingest into an existing substrate (use myco_eat instead).
Side effects: writes 3 files (see germination doctrine for the
exact canon shape); registers the substrate in
~/.myco/substrates.yaml so myco graft --list-substrates finds
it. Honors R6 write_surface (the freshly-stamped canon includes
notes/, docs/, src/, .myco/ by default).
Returns: { exit_code, files_created, preview, dry_run,
project_dir, substrate_id }. The preview dict shows the
first line and byte count of each written file; dry_run=true
returns the same shape without writing.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| project_dir | Yes | Absolute or relative path of the directory that will host the new substrate. Must exist and be writable; the _canon.yaml will be created inside this directory (not a subdirectory). Use forward slashes or escaped backslashes on Windows. | |
| substrate_id | Yes | Stable slug identifying this substrate across the mycelial network. Used in cross-substrate propagation + the ~/.myco/substrates.yaml registry. Recommend kebab-case, human-readable (e.g. 'neurips-2026-research' or 'my-company-infra'). No uniqueness check; reuse silently overwrites registry entries. | |
| tags | No | Free-form affiliation tags attached to the substrate identity (e.g. ['research','production','personal']). Per L0: tags are NOT boundaries — they don't gate writes, they only describe. Stored at _canon.yaml::identity.tags and surfaced in substrate_pulse for grep-friendly discovery. | |
| entry_point | No | Filename of the agent-entry markdown that the substrate opens with. Defaults to MYCO.md (Myco-native convention). Override to 'CLAUDE.md' when you want the substrate to share an entry with Claude-ecosystem conventions. The file gets created if absent; existing files are not overwritten unless --force. | MYCO.md |
| dry_run | No | When true, compute the files that would be written + return their byte count and first line in the preview payload, but do NOT touch disk. Use for 'what would happen if I germinate here' inspection without committing. Default false (writes immediately). |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses side effects: writes 3 files, registers in substrates.yaml, honors R6 write_surface, and that re-calling raises 'substrate already exists'. Also describes return shape and dry_run behavior.
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?
Four sentences with no fluff. First sentence nails purpose, followed by usage, side effects, and return structure. Every sentence earns its place.
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?
For a bootstrap tool with 5 params and no output schema, the description covers all essential aspects: purpose, usage, side effects, return fields, and dry_run option. No gaps identified.
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. Description adds value beyond schema by explaining dry_run behavior ('returns same shape without writing'), preview structure ('first line and byte count'), and R6 write_surface context. However, many schema descriptions are already detailed.
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 starts with 'Bootstrap a new Myco substrate' and lists specific files created (_canon.yaml, MYCO.md, .myco/state/autoseeded.txt), clearly stating its one-time use. It distinguishes from sibling tools like myco_eat by stating when not to use.
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 ('starting a brand-new substrate that does not yet have _canon.yaml') and when not to (substrate already exists, parent _canon.yaml, or ingest-only) and provides alternative tool name (myco_eat).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
myco_graftA
Introspect the substrate's plugin surface: list every loaded dimension / adapter / schema_upgrader / overlay_verb with (kind, name, source, scope), validate plugins by re-importing under isolation, or explain a single plugin (source path + docstring). Scope classifies each plugin as 'kernel' (shipped with myco package) or 'substrate' (loaded from /.myco/plugins/).
Use this when: debugging "why is my plugin not loading", auditing what's actually registered, or listing substrates across the machine (--list-substrates mode, reads ~/.myco/substrates.yaml). Do NOT confuse with myco_immune's dimension-listing mode — graft inspects plugin binaries, immune inspects findings.
Side effects: none. Pure read. --validate mode does re-import plugins, which executes their init.py; the execution occurs in an isolated module namespace and is idempotent — safe even for plugins that register into global registries.
Returns (by mode). --list: { exit_code, mode:'list', plugins: [...], count }. --validate: { exit_code, mode: 'validate', errors: [...] }. --explain: { exit_code, mode: 'explain', name, kind, source, scope, docstring }. --list-substrates: { exit_code, mode:'list-substrates', substrates: [...], count, live_count, stale_count }.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| list | No | When true, enumerate every plugin currently loaded in this substrate's registry (kernel + substrate-local). Returns one row per plugin with kind + name + source (file path) + scope (kernel|substrate). Mutually exclusive with validate / explain / list-substrates. | |
| validate | No | When true, re-import every substrate-local plugin in isolation and collect any exceptions. Used to sanity-check plugins after editing. Mutually exclusive with list / explain / list-substrates. | |
| explain | No | When set, return the source path + docstring + kind for the named plugin. Pass the plugin's registered name (e.g. 'M1' for a dimension, 'UrlFetcher' for an adapter). Unknown names raise UsageError. Mutually exclusive with list / validate / list-substrates. | |
| list_substrates | No | v0.5.16: list every substrate registered on this machine (reads ~/.myco/substrates.yaml), sorted by last-seen-at. Returns stale entries (exists=false) whose on-disk path no longer has a _canon.yaml for cleanup insight. Mutually exclusive with list / validate / explain. | |
| project_dir | No | Absolute 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. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: states 'Side effects: none. Pure read.', details --validate re-imports in isolated namespace and is idempotent. This exceeds the burden without annotations.
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?
Well-structured with clear sections for purpose, usage, side effects, returns. Slightly lengthy but each sentence adds value. No fluff, but could be marginally tighter.
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?
No output schema, yet the description provides detailed return structures for each mode. For a complex tool with 5 modes and zero output schema, this is complete and covers all expected responses.
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 baseline is 3. The description adds context for return formats and mode mutual exclusivity, but does not significantly enhance parameter meaning beyond existing schema descriptions.
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 the tool introspects the plugin surface with operations: list, validate, explain, list-substrates. It explicitly distinguishes from myco_immune's dimension-listing mode, showing good sibling differentiation.
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?
Provides explicit when-to-use scenarios: debugging plugin loading, auditing registrations, listing substrates. Also warns what not to confuse it with, making usage guidance thorough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
myco_hungerA
Compose the substrate's hunger report: contract drift (canon version mismatch), raw-note backlog (integer count of notes/raw/*.md pending assimilation), active reflex signals (HIGH/MEDIUM/LOW), concrete next-action advice, and per-kind count of substrate-local plugins. This is the R1 BOOT RITUAL — the mandatory first substantive action every session per the Hard Contract.
Use this: as the FIRST tool call of every session without exception (R1 is a contract rule, not a suggestion). Use it again mid-session whenever the agent wants a fresh state snapshot — it's cheap and idempotent. Do NOT use it as a substitute for myco_brief (which is human-facing markdown, this is agent-facing structured data).
Side effects: none by default. When execute=true, patches
's <!-- MYCO-BOOT-SIGNALS:BEGIN ... END -->
block with the current hunger signals, respecting R6
write_surface. On abrupt exit (~1.5s kill budget, SessionEnd
hook) prefer myco_senesce with quick=true; hunger itself does
not auto-trigger senesce.
Returns: { exit_code, report: { contract_drift, raw_backlog, reflex_signals, advice, local_plugins: { count, count_by_kind, errors, overlay_verbs } }, execute, entry_point_patched }. The substrate_pulse sidecar then tells you which rule to honor next (advances from R1 → R3 after first hunger call).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| execute | No | When true, write the boot_brief.md + patch the entry-point's MYCO-BOOT-SIGNALS block with current reflex signals. When false (default), compute the report but make zero writes — useful for 'peek without touching'. R6 write_surface still applies to the patched entry-point path. | |
| project_dir | No | Absolute 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. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details side effects: no writes by default, with execute=true patching entry-point block. Mentions kill budget and related tool myco_senesce. Fully describes return structure including nested fields. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is moderately long but well-structured with sections for purpose, usage, side effects, and return. Every sentence adds value. Could be slightly more concise, but the organization helps readability. No fluff.
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 tool's role as a mandatory first action and the complexity of its report, the description fully covers behavior, side effects, return format, and integration with contract rules and other tools. No gaps remain for an agent to misuse it.
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?
Parameter schema coverage is 100% with good descriptions. The description adds context: clarifies execute's write behavior and project_dir's resolution order. This exceeds schema alone, justifying above baseline 3. However, the schema already explains parameters well, so a 4 is appropriate.
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 it composes a hunger report with specific components (contract drift, raw backlog, reflex signals, advice, plugin count). It distinguishes from sibling myco_brief by noting this is agent-facing structured data vs human-facing markdown. The purpose is clear, specific, and well-differentiated.
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 instructs to use as the first tool call every session (R1 contract rule) and mid-session for fresh state snapshot. Warns against using as substitute for myco_brief. Mentions idempotency and cheapness. Provides comprehensive when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
myco_immuneA
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| dimensions | No | Optional 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. | |
| fix | No | When 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). | |
| list | No | When 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). | |
| explain | No | When 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_dir | No | Absolute 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. |
TDQS
A4.9/5.0
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.
myco_intakeA
Walk a directory, list every adapter-ingestible file via
myco_forage, then call myco_eat on each. The atomic bulk-ingest
composer that replaces the v0.5.x unimplemented
forage --digest-on-read flag.
Single-responsibility composition: forage stays read-only;
eat stays single-note; intake is the only verb that
composes both with a write side-effect.
Use this when: a fresh substrate needs to absorb an existing
directory tree (a paper archive, a code repository, a meeting-log
folder). Use --filter regex to select a subset; --max to
cap ingest count; --dry-run to preview.
Failure semantics: per-file ingest failures produce a
status: failed stub note in notes/raw/ (NOT silent skip;
see L0 P2 + AD1 dim) and are reported in the result payload's
failures list. --strict mode raises on any failure
(exit_code=2).
Side effects: writes 0+ notes to notes/raw/ (one per ingestible file, with frontmatter status=ok|failed). R6 write_surface gated.
Returns: { exit_code, ingested, failed, failures, notes, dry_run }. Use myco_assimilate afterwards to promote the successful raws to integrated.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute or substrate-relative directory path to scan recursively. Forwarded to myco_forage to list adapter-handled files; each gets ingested via myco_eat. Use forward slashes or escaped backslashes on Windows. | |
| filter | No | Optional regex applied to the candidate path string. Only files whose path matches are ingested. Useful for slicing a large tree (e.g. only PDFs: ``\.pdf$``; only one subdir: ``^docs/research/``). | |
| max | No | Hard cap on number of files ingested. Useful for staged ingest of a very large directory: run with --max=100 first, assimilate, then re-run. | |
| dry_run | No | When true, list intended ingest actions without writing. The payload's ``ingested`` and ``notes`` reflect what WOULD happen. | |
| strict | No | When true, any per-file ingest failure raises MycoError (exit_code=2) — strict-mode treats partial failure as full failure. Default false: failures produce stub notes and continue. | |
| project_dir | No | Absolute 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. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: side effects (writes notes to notes/raw/), failure semantics (per-file failures produce stubs, reported in failures list, --strict raises on any failure), and scope (recursive directory scan). It also mentions access control ('R6 write_surface gated') and return payload structure.
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 well-structured with clear paragraphs for purpose, usage, failure semantics, side effects, and returns. It is front-loaded with the core action. While slightly verbose, every sentence adds value.
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 tool's complexity and lack of output schema, the description provides comprehensive information: what it does, when to use, parameter effects, failure modes, side effects, and the expected return format. It also references the next step (myco_assimilate), closing the loop.
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 value beyond the schema by explaining practical usage for each parameter: e.g., --filter for regex selection, --max for staged ingest, --strict for full failure mode, and --project_dir for workspace targeting.
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 the tool's action: 'Walk a directory, list every adapter-ingestible file via myco_forage, then call myco_eat on each.' It also distinguishes it from sibling tools by explaining that myco_forage is read-only, myco_eat is single-note, and myco_intake composes both with a write side-effect.
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?
The description explicitly states when to use this tool: 'when a fresh substrate needs to absorb an existing directory tree'. It provides guidance on optional parameters like --filter, --max, and --dry-run. It implies alternatives by mentioning single-responsibility composition, though it doesn't explicitly say 'do not use for single file ingest'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
myco_moltA
Ship a contract-version bump: update _canon.yaml's contract_version and synced_contract_version fields to the new value, append a stub section to docs/contract_changelog.md with placeholders, and advance waves.current counter. The atomic molt keeps all three version knobs in lockstep and produces a reviewable one-commit diff.
Use this AT RELEASE TIME, not during development. Pair with .scripts/bump_version.py which orchestrates molt alongside the package-version bump in init.py, plugin.json, and CITATION.cff. Do NOT call this mid-session for ad-hoc experiments — the contract_changelog is append-only and reverting a molt requires an explicit down-bump.
Side effects: writes _canon.yaml + docs/contract_changelog.md. R6 write_surface must cover both. Dry-run prints the diff that would be applied. Skip-molt option in bump_version.py exists for cases where the version parity step is separate from the canon stamp.
Returns: { exit_code, new_version, synced_touched, waves_touched, canon_path, changelog_path, canon_preview_head }.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| contract | Yes | New contract version string, in the form 'v<semver>' (e.g. 'v0.5.23'). Must be strictly greater than the current canon's contract_version per semver comparison. Down-bumps are refused unless --allow-downgrade is passed at the bump_version.py layer (molt itself has no such flag). | |
| dry_run | No | When true, compute the exact canon patch + changelog section that would be applied and return them in the response, without writing. Use to preview before committing the atomic version bump. Default false (writes + returns the same preview so the agent can diff against its pre-bump state). | |
| date | No | Override the date stamp in the contract_changelog.md section header (YYYY-MM-DD format). When null, uses today (UTC). Useful for back-dating a release whose molt was delayed, or for reproducing historical molts exactly. | |
| project_dir | No | Absolute 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. |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses side effects (writes to _canon.yaml and changelog), dry-run behavior ('prints the diff'), and version refusal ('down-bumps are refused unless --allow-downgrade is passed at the bump_version.py layer'). It also describes the return object fields, compensating for the lack of an output schema.
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 well-structured with four distinct paragraphs covering purpose, usage, side effects, and return values. It is front-loaded with the main action. While it is somewhat lengthy, every sentence adds value, so it earns a 4 for being appropriately sized and organized.
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?
Given the tool's moderate complexity (multiple file writes, version constraints) and the absence of an output schema, the description provides sufficient context: it explains the atomic operation, dry-run preview, return fields, and error conditions (down-bump refusal). It is complete enough for an agent to execute correctly.
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 coverage is 100% with detailed parameter descriptions. The tool description adds no new per-parameter detail beyond what the schema already provides (e.g., contract format, dry_run default). Thus, the description provides marginal added value for parameter semantics, earning the baseline score of 3.
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 the tool's core function: 'Ship a contract-version bump' by updating specific fields in _canon.yaml and docs/contract_changelog.md, and advancing a counter. It specifies the verb ('ship'), resource ('contract version'), and distinguishes itself from sibling tools (e.g., myco_assimilate, myco_brief) through unique release-time version management.
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?
The description provides explicit when-to-use guidance: 'AT RELEASE TIME, not during development.' It also specifies when not to use ('Do NOT call this mid-session') and mentions an orchestrating companion (bump_version.py) and an alternative (skip-molt option). This clearly helps an agent choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
myco_propagateA
Copy integrated and/or distilled notes from this substrate to a downstream target substrate's notes/raw/. The receiver's agent then chooses which to assimilate — propagate is the source-side push; the receiver's own metabolism filters. Today's integrated-in-A becomes tomorrow's raw-in-B (per L0 principle 4: 永恒迭代, today's conclusion is tomorrow's raw material).
Use this when: knowledge produced in substrate A should feed substrate B (cross-project knowledge sharing). Do NOT use this as a replacement for git (propagation is a knowledge artifact movement, not version-control). The receiver must have a valid _canon.yaml at dst; propagation refuses if dst is not a substrate (no auto-germinate).
Side effects: writes 1+ files under /notes/raw/ on the DOWNSTREAM substrate (not this one). R6 write_surface check is applied to the destination substrate's canon, not the source. Dry-run available.
Returns: { exit_code, select, src_substrate_id, dst_root, count, propagated: [...source paths...], compat_warnings, dry_run, commit }.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| dst | Yes | Absolute or relative path to the downstream substrate's root (must contain _canon.yaml). When relative, resolved against this substrate's root. The downstream must already be a Myco substrate — propagate will NOT auto-germinate a dst; run myco_germinate there first. | |
| select | No | Which layer of this substrate's metabolism to propagate. One of: 'integrated' (default, notes/integrated/**.md), 'distilled' (notes/distilled/**.md), 'both'. Raw notes are never propagated (they haven't graduated past the intake queue yet). The propagated files land in the destination's notes/raw/ regardless — receiver re-metabolizes. | integrated |
| commit | No | Optional git commit SHA (of the source substrate) to record in the propagated notes' frontmatter as the provenance stamp. When null, 'unknown' is recorded. Useful for traceability: lets downstream agents audit 'what version of source A produced this note'. | |
| dry_run | No | When true, list which notes would be propagated and to where, but write nothing. Default false (writes immediately to the destination). | |
| project_dir | No | Absolute 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. |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses side effects (writes to dst/notes/raw/), the R6 write_surface check applied to destination, dry-run capability, and return structure. Explains that raw notes are never propagated and that receiver re-metabolizes. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, when to use, side effects, returns). Some metaphor and philosophical content ('永恒迭代', 'metabolism filter') add flavor but could be trimmed; still earns its place. Front-loaded with key information.
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 5-param, no-output-schema, no-annotation tool: covers prerequisites, behavior differences by parameter, side effects, return values, and dry-run distinction. No gaps for agent invocation.
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?
Schema coverage is 100%, but description adds substantial context: 'dst' explains path resolution and no auto-germinate; 'select' clarifies layers and destination landing; 'commit' explains provenance stamp; 'dry_run' notes default false and effect; 'project_dir' details discovery order. All parameters benefit from narrative explanation.
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?
Describes a specific action: copying integrated/distilled notes from one substrate to another's notes/raw/. Clearly distinguishes from sibling tools like myco_assimilate and myco_germinate by focusing on cross-substrate knowledge push. The metaphor (source-side push) and examples reinforce purpose.
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 (knowledge sharing between substrates) and when not to (not a git replacement). Specifies prerequisite that dst must have _canon.yaml and that propagation fails without it. Provides clear context for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
myco_ramifyA
Scaffold the code skeleton for a new extension point: a manifest verb, a lint dimension, or an ingestion adapter. Writes a stub file into the appropriate location — either src/myco/ (kernel, for core Myco evolution) or /.myco/plugins/ (substrate-local, for project- specific extensions). Auto-detects substrate-local mode when the substrate is not the myco-self kernel substrate.
Use this when: an agent or operator wants to add a new verb / dimension / adapter without hand-writing boilerplate. Exactly ONE of verb/dimension/adapter must be specified; combining raises UsageError. Do NOT use this to modify existing plugins — ramify is scaffold-only, refuses to overwrite unless --force.
Side effects: creates one Python file at the computed target path. R6 write_surface must cover the target; for substrate- local mode, .myco/plugins/ must be in the substrate's write_surface. Dimension mode also requires category + severity; adapter mode requires extensions list.
Returns: { exit_code, mode, , class, category, severity, path, written, overwritten, substrate_local }.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| verb | No | New manifest verb name to scaffold (kebab-case, e.g. 'my-verb'). Writes a handler stub + manifest_overlay.yaml entry. Mutually exclusive with dimension and adapter. Kernel scaffolds go under src/myco/cycle/; substrate-local under .myco/plugins/verbs/. | |
| dimension | No | New lint dimension ID to scaffold (case-sensitive, e.g. 'LOCAL1'). Requires --category and --severity. Mutually exclusive with verb and adapter. Kernel scaffolds go under src/myco/homeostasis/dimensions/; substrate-local under .myco/plugins/dimensions/. | |
| category | No | Dimension category. One of: 'mechanical' (canon invariants), 'shipped' (version parity), 'metabolic' (raw-note / stale-integrated signals), 'semantic' (graph connectedness). Used only with --dimension. | |
| severity | No | Default severity for findings the scaffolded dimension emits. One of: 'low', 'medium', 'high', 'critical'. Critical findings cause myco_immune to exit non-zero. Used only with --dimension. | |
| adapter | No | New ingestion adapter name to scaffold (e.g. 'jira', 'slack-export'). Requires --extensions. Mutually exclusive with verb and dimension. Kernel scaffolds go under src/myco/ingestion/adapters/; substrate-local under .myco/plugins/adapters/. | |
| extensions | No | File extensions (with leading dot) the adapter handles, e.g. ['.jira', '.json']. Used with --adapter. Extensions register in the adapter registry for myco_eat --path dispatch; more-specific adapters (via registration order) win over generic ones. | |
| substrate_local | No | When true, scaffold under <substrate>/.myco/plugins/ (substrate-local). When false, scaffold under src/myco/ (kernel, only valid when operating on the myco-self kernel substrate). Auto-forced true when substrate != myco-self. Override when hand-editing kernel code from within a different substrate. | |
| force | No | When true, overwrite an existing file at the target path. When false (default), refuse overwrite with a UsageError. Use to refresh boilerplate after manifest schema changes. Does NOT implicitly revert git history. | |
| project_dir | No | Absolute 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. |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses side effects (creates one Python file), requirements (write_surface, category/severity for dimension, extensions for adapter), error conditions (UsageError if combined kinds, refuse overwrite), and return value structure.
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 with clear sections: purpose, when to use, side effects, and return. It is concise yet comprehensive, with no unnecessary sentences. Every sentence adds value.
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?
Despite no output schema, the description provides the full return structure. It covers all necessary contextual information for a tool with 9 parameters and multiple modes, including corner cases like auto-detection and force override.
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% with detailed descriptions for each of the 9 parameters. The description adds context beyond the schema, such as auto-detection of substrate-local mode and kernel vs plugin paths. However, the schema already covers parameter details well, so a baseline 3 is raised to 4.
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 'Scaffold the code skeleton for a new extension point' and lists the three kinds (verb, dimension, adapter). It distinguishes kernel vs substrate-local paths, and the name 'ramify' is distinct from sibling tools like myco_assimilate or myco_brief.
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: 'to add a new verb / dimension / adapter without hand-writing boilerplate.' Also says when not: 'Do NOT use this to modify existing plugins — ramify is scaffold-only, refuses to overwrite unless --force.' Conditions like mutual exclusivity and write_surface requirements are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
myco_senesceA
Put the session into dormancy: run a reflect pass (which may promote raw notes, update integrated frontmatter, and patch boot_brief.md). In full mode (default), also run myco_immune --fix to repair any mechanically-fixable findings the session produced. This is the R2 SESSION-END RITUAL per the Hard Contract.
Use this: at session end BEFORE compaction (PreCompact hook calls this with quick=false — full mode). On abrupt exit with a tight kill budget (~1.5s, SessionEnd hook), pass quick=true — reflect only, skip immune; the next SessionStart catches up. Do NOT skip this at session end: without senesce, the raw queue backs up across sessions and reflex signals go stale.
Side effects: may write to notes/integrated/ (promotions), boot_brief.md (signal refresh), and trigger full immune --fix in default mode (which may write to various R6-allowed paths). In quick=true mode: reflect only, no immune.
Returns: { exit_code, findings: [...], reflect: { promoted, errors, outcomes }, immune: { dimensions_run, skeleton_downgrade_applied, exit_on, fix, fixes }, mode }.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| quick | No | When true, skip immune --fix and run only reflect (the note-promotion + boot-brief patch subset). Use from SessionEnd hook where the process has ~1.5s before kill. The next SessionStart or PreCompact picks up the skipped immune work. Default false = full reflect + immune --fix pass (slower, typically 2-5s). | |
| project_dir | No | Absolute 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. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects: writes to notes/integrated/, boot_brief.md, and may trigger immune --fix. Also outlines return structure including fields like exit_code, findings, reflect, immune, mode. No contradictions with annotations (none provided).
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?
Well-structured with front-loaded purpose, then usage, side effects, and return. Slightly lengthy but every paragraph adds value. Could be more concise, but still effective.
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?
With only 2 optional parameters and no output schema, the description covers all necessary context: what it does, when to use, side effects, return format, and parameter semantics. No gaps identified.
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?
Input schema has 100% description coverage, so baseline is 3. The description adds context beyond the schema, such as timing expectations for quick mode (1.5s vs 2-5s) and project_dir resolution order. This justifies a 4.
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 the tool's function: 'Put the session into dormancy' and details the two modes (reflect and full immune). It distinguishes itself from siblings by explicitly identifying it as the session-end ritual per the Hard Contract.
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 specifies when to use: at session end before compaction, and when to pass quick=true (abrupt exit with ~1.5s kill budget). It warns against skipping the tool, providing clear context for use vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
myco_senseA
Perform a keyword substring search across the substrate's markdown + yaml surface and return ranked hits with file path, line number, and snippet. This is the R3 SENSE-BEFORE-ASSERT mechanism: before asserting a substrate fact from training memory, the agent calls this to check ground truth from the substrate itself (R3 of the Hard Contract).
Use this before making any claim about what the substrate contains — e.g. "the substrate says X" should always be preceded by a sense call that returned a hit for X. Fast (no embedding, no LLM, no network) — this is a literal substring scan over notes/, docs/, _canon.yaml, and MYCO.md. For broader semantic search, compose multiple sense calls with different keyword synonyms rather than expanding the query.
Side effects: none. Pure read. Does not touch .myco/state/ or any cache.
Returns: { exit_code, query, scope, hits: [ { path, line,
snippet } ] }. hits is ordered by path then line number;
snippet is the full matching line trimmed to reasonable width.
Empty hits is a successful call with no matches — agent
should treat "absence of hit" as "fact not in substrate" per R3.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Literal substring to search for. Case-insensitive. No regex, no glob — pass 'error' not 'err.*' (regex-in-query is treated as literal). For multi-term search, call sense multiple times and union results. Whitespace-only queries return empty hits. | |
| project_dir | No | Absolute 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. |
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 burden of behavioral disclosure. It states side effects are none, it is a pure read, does not touch .myco/state/ or any cache, and details the return format. It also explains that an empty hits array represents a successful call with no matches, which is important for the agent's decision-making.
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 with clear sections for purpose, usage, side effects, and returns. It is front-loaded with the key action and resource, and every sentence provides essential information without redundancy. Despite moderate length, it is efficient and earns its length.
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 tool has only two parameters, no output schema, and a large set of sibling tools, the description is remarkably complete. It covers purpose, usage context, behavioral traits, parameter details, return format, edge cases (empty hits), and interaction patterns (composing multiple calls). No gaps remain for the agent to infer.
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 significant value beyond the schema: it explains that query is case-insensitive, no regex or glob, and whitespace-only queries return empty hits. For project_dir, it details the resolution order (MCP roots/list, MYCO_PROJECT_DIR, cwd) and that the response echoes which source answered. This greatly enhances parameter understanding.
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 the tool performs a keyword substring search across the substrate's markdown and yaml surface, returning ranked hits with file path, line number, and snippet. It distinguishes itself from siblings by referencing the R3 SENSE-BEFORE-ASSERT mechanism, making its purpose unique and clear.
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?
The description explicitly guides the agent to use this tool before making claims about substrate content, and recommends composing multiple calls with synonyms for broader semantic search instead of expanding the query. It clarifies that the tool is a literal substring scan with no embedding, LLM, or network, providing clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
myco_sporulateA
Produce a dispersible proposal scaffold by bundling integrated notes into a notes/distilled/d_.md document. The output is a skeleton — frontmatter + source list + empty section headers — which the agent then fills with the actual synthesis prose. Sporulate prepares the substrate's knowledge for external dispersion (propagation to other substrates, or publishing as craft proposals).
Use this when: a body of integrated notes have accumulated that belong together and you want to produce a consolidated view. Do NOT use this expecting auto-synthesis — sporulate builds the container; the agent writes the content. For cross-substrate material sharing, pair with myco_propagate. For substrate-internal contract evolution, pair with myco_fruit (which produces a 3-round craft doc instead).
Side effects: creates 1 file at notes/distilled/d_.md. R6 write_surface must cover notes/distilled/. Filename collision with an existing distilled doc at the same slug is an error (no overwrite).
Returns: { exit_code, path, slug }.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Kebab-case identifier for the distilled proposal (becomes d_<slug>.md). Example: 'v0521-glama-findings'. Should be descriptive enough to disambiguate from sibling proposals. No validation beyond the filesystem's own filename rules; avoid slashes, spaces, and reserved chars. | |
| sources | No | Optional explicit list of note paths (relative to substrate root) to include as sources. When empty/omitted, sporulate auto-selects integrated notes whose tags match the slug's keywords. Pass explicit sources for tight control over what gets bundled. Paths that don't exist are errors. | |
| project_dir | No | Absolute 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. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers side effects (creates 1 file, requires write surface, collision error), error conditions, and return values. Could mention whether it modifies existing state, but overall thorough.
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?
Well-structured with clear sections (what it does, when to use, side effects, returns). Somewhat lengthy but every sentence adds useful information. Front-loaded with the core purpose.
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?
Covers inputs, outputs (return object), side effects, usage context, and error conditions. Lacks output schema but describes return values. Sufficient for a well-understood tool.
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%, baseline 3. Description adds value: clarifies 'slug' with examples and rules, explains 'sources' auto-selection vs explicit, and describes 'project_dir' resolution order. Exceeds baseline.
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 the tool's action: 'Produce a dispersible proposal scaffold by bundling integrated notes into a notes/distilled/d_<slug>.md document'. It distinguishes itself from siblings by naming myco_propagate (cross-substrate sharing) and myco_fruit (contract evolution).
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 ('when a body of integrated notes have accumulated that belong together') and when not to use ('Do NOT use this expecting auto-synthesis'). Also provides alternative tools for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
myco_traverseA
Walk the substrate's cross-reference graph and report health: node count, edge count, src-node count (code files under src/), orphan nodes (no inbound references), dangling edges (point at missing targets), and per-node proposals for reconnection. Anastomosis is the fungal analogy: hyphae (markdown files + references:) fuse into a connected network; orphans + dangling edges are the dead tissue signal.
Use this: periodically (weekly / per-release cadence) to detect knowledge islands forming; before a release to verify docs haven't drifted from code; when debugging "why can't I find X" — dangling edges show what the substrate thinks exists but doesn't. Cheap and read-only — safe to run often.
Side effects: none. Writes a cached graph JSON to .myco/state/graph.json for subsequent traverse calls (bypass with internal use_cache=false). The cache is invalidated by file mtime on re-entry.
Returns: { exit_code, scope, orphans: [...], dangling: [...], proposals: [...], node_count, edge_count, src_node_count, cached }.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Which subset of the substrate to walk. One of: 'canon' (just _canon.yaml + its outbound refs), 'notes' (notes/raw/**, notes/integrated/**, notes/distilled/**), 'docs' (docs/**), 'all' (default — everything including src/ python imports). Narrow scopes are cheaper on large substrates. | all |
| project_dir | No | Absolute 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. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description bears full responsibility. It discloses side effects (writing a cached graph JSON to .myco/state/graph.json), caching behavior, and invalidation based on file mtime. It also explains the return structure. This provides good transparency, though the claim 'Side effects: none' slightly contradicts the cache write, which is a minor inconsistency.
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 structured with clear sections: action, usage, side effects, returns. It is front-loaded with the main purpose and outputs. While somewhat verbose, each sentence adds information. The fungal analogy is engaging but not necessary. Overall, it is appropriately sized for the complexity.
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?
Given no output schema, the description explains the return fields including orphans, dangling, proposals, and counts. It covers caching and invalidation. However, it does not detail the format of 'proposals' or the structure of the cached JSON. Tool complexity is moderate, and description is largely complete.
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 already documents parameters. The description adds value by explaining the scope parameter with valid values and cost implications, and project_dir resolution order. It also mentions an internal parameter 'use_cache' not in the schema, which adds context but could confuse agents expecting it in the schema.
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 the tool walks the substrate's cross-reference graph and reports health metrics, including node count, edge count, orphans, dangling edges, and proposals. It distinguishes from sibling tools by specifying its unique function of graph traversal and health reporting, as evidenced by the concrete outputs listed.
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?
The description provides explicit usage scenarios: periodically to detect knowledge islands, before a release to verify docs against code, and when debugging missing references. It also notes the tool is cheap and read-only, implying it can be run often. However, it does not explicitly state when not to use it or compare to alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
myco_winnowA
Gate a docs/primordia/ craft proposal against the craft protocol shape: 3 (or 5) rounds present, required sections (Claim / Self-Rebuttal / Revision / Counter-Rebuttal / Reflection) populated, frontmatter keys complete, body is not mostly template boilerplate (> 40% boilerplate triggers G6), etc. Returns pass/fail verdict and specific violations.
Use this: after fruit scaffolds a craft doc and the agent fills in the tensions and revisions — winnow tells whether the proposal has enough substance to land. Do NOT use winnow as a content quality check (it checks STRUCTURE, not whether the argument is good). For content review, human judgment still applies.
Side effects: none. Pure read.
Returns: { exit_code, proposal, verdict: 'pass'|'fail', round_count, body_chars, violations: [ { gate, message } ], frontmatter_keys }. exit_code 0 on pass, 1 on fail. Agents typically fix violations and re-winnow until pass before declaring a craft 'LANDED'.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| proposal | Yes | Path to the craft proposal markdown under docs/primordia/ (relative to substrate root or absolute). Must exist and be a valid markdown file with a craft-shaped YAML frontmatter block. Winnow reads but does not modify the file; post-winnow, the agent edits to address violations and re-runs winnow. | |
| project_dir | No | Absolute 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. |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States 'Side effects: none. Pure read.' and describes return format and typical workflow (fix and re-winnow). No annotations provided, but the description adequately covers behavioral traits for a read-only structure checker.
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 concise (~150 words) yet packed with essential information. It is well-structured: purpose, usage guidelines, side effects, return format. Every sentence adds value.
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?
Despite no output schema, the description provides detailed return format. Input params are fully documented. The tool's complexity is well addressed with necessary context for correct invocation.
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 meaningful context for the 'proposal' parameter (path, file requirements) and 'project_dir' (override logic, fallback chain), going beyond schema descriptions.
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 gates a craft proposal against the craft protocol shape, checking structural requirements like rounds, sections, frontmatter, and boilerplate. It returns pass/fail verdict and specific violations, making the purpose unambiguous.
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 'Use this: after fruit scaffolds a craft doc...' and 'Do NOT use winnow as a content quality check... For content review, human judgment still applies.' This clearly specifies when and when not to use, with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
20 tool updates
v0.8.7- Added
myco_assimilate - Added
myco_brief - Added
myco_digest - Added
myco_eat - Added
myco_excrete - Added
myco_forage - Added
myco_fruit - Added
myco_germinate - Added
myco_graft - Added
myco_hunger - Added
myco_immune - Added
myco_intake - Added
myco_molt - Added
myco_propagate - Added
myco_ramify - Added
myco_senesce - Added
myco_sense - Added
myco_sporulate - Added
myco_traverse - Added
myco_winnow
20 tool updates
v0.8.4- Removed
myco_assimilate - Removed
myco_brief - Removed
myco_digest - Removed
myco_eat - Removed
myco_excrete - Removed
myco_forage - Removed
myco_fruit - Removed
myco_germinate - Removed
myco_graft - Removed
myco_hunger - Removed
myco_immune - Removed
myco_intake - Removed
myco_molt - Removed
myco_propagate - Removed
myco_ramify - Removed
myco_senesce - Removed
myco_sense - Removed
myco_sporulate - Removed
myco_traverse - Removed
myco_winnow
2 tool updates
v0.1.3- Changed
myco_immune1 field changed- changed
Input schema / properties / dimensions / descriptionPrevious value: -"Optional subset of dimension IDs to run (e.g. ['M1','SE1','MB2']). When empty, runs all 25. 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."New value: +"Optional 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."
- Added
myco_intake
25 tool updates
v0.1.2- Changed
myco_assimilate1 field changed- added
Input schema / properties / note_id / examplesAdded value: +[ + "20260423T054055Z_v0-5-22-migration-marker", + "20260424T091230Z_decision-pin-py312" +]
- Removed
myco_bump - Removed
myco_craft - Changed
myco_digest1 field changed- added
Input schema / properties / note_id / examplesAdded value: +[ + "20260423T054055Z_v0-5-22-migration-marker", + "20260424T091230Z_decision-pin-py312" +]
- Removed
myco_distill - Changed
myco_eat5 fields changed- added
Input schema / properties / content / examplesAdded value: +[ + "Decision: pin python 3.12 in CI because 3.13 breaks httpx.", + "Friction: README quickstart example fails on Windows path separators." +] - added
Input schema / properties / path / examplesAdded value: +[ + "docs/primordia/v0521_glama_findings.md", + "/tmp/meeting_2026-04-24.txt" +] - added
Input schema / properties / source / examplesAdded value: +[ + "agent", + "operator", + "propagation" +] - added
Input schema / properties / tags / examplesAdded value: +[ + "decision", + "friction", + "chat-log" +] - added
Input schema / properties / url / examplesAdded value: +[ + "https://modelcontextprotocol.io/specification/server", + "https://glama.ai/mcp/servers/@Battam1111/myco" +]
- Removed
myco_evolve - Added
myco_excrete - Changed
myco_forage1 field changed- added
Input schema / properties / path / examplesAdded value: +[ + "notes/raw", + "docs/primordia", + "/tmp/inbox" +]
- Changed
myco_fruit3 fields changed- added
Input schema / properties / date / examplesAdded value: +[ + "2026-04-24", + "2026-05-01" +] - added
Input schema / properties / kind / examplesAdded value: +[ + "design", + "audit", + "migration", + "operational" +] - added
Input schema / properties / topic / examplesAdded value: +[ + "Glama onboarding runbook", + "v0.5.24 contract upgrade" +]
- Removed
myco_genesis - Changed
myco_germinate4 fields changed- added
Input schema / properties / entry_point / examplesAdded value: +[ + "MYCO.md", + "CLAUDE.md" +] - added
Input schema / properties / project_dir / examplesAdded value: +[ + "/workspace/neurips-2026-research", + "C:/Users/you/projects/my-company-infra" +] - added
Input schema / properties / substrate_id / examplesAdded value: +[ + "neurips-2026-research", + "my-company-infra" +] - added
Input schema / properties / tags / examplesAdded value: +[ + "research", + "production", + "personal" +]
- Changed
myco_graft1 field changed- added
Input schema / properties / explain / examplesAdded value: +[ + "M1", + "UrlFetcher", + "LOCAL1" +]
- Changed
myco_immune2 fields changed- added
Input schema / properties / dimensions / examplesAdded value: +[ + "M1", + "SE1", + "MB2", + "DC4" +] - added
Input schema / properties / explain / examplesAdded value: +[ + "M1", + "SE1", + "CG2" +]
- Changed
myco_molt2 fields changed- added
Input schema / properties / contract / examplesAdded value: +[ + "v0.5.24", + "v0.6.0" +] - added
Input schema / properties / date / examplesAdded value: +[ + "2026-04-24", + "2026-05-01" +]
- Removed
myco_perfuse - Changed
myco_propagate3 fields changed- added
Input schema / properties / commit / examplesAdded value: +[ + "a1b2c3d4", + "HEAD" +] - added
Input schema / properties / dst / examplesAdded value: +[ + "/workspace/downstream-substrate", + "../sibling-project" +] - added
Input schema / properties / select / examplesAdded value: +[ + "integrated", + "distilled", + "both" +]
- Changed
myco_ramify6 fields changed- added
Input schema / properties / adapter / examplesAdded value: +[ + "jira", + "slack-export" +] - added
Input schema / properties / category / examplesAdded value: +[ + "mechanical", + "shipped", + "metabolic", + "semantic" +] - added
Input schema / properties / dimension / examplesAdded value: +[ + "LOCAL1", + "SE4" +] - added
Input schema / properties / extensions / examplesAdded value: +[ + ".jira", + ".json", + ".xml" +] - added
Input schema / properties / severity / examplesAdded value: +[ + "low", + "medium", + "high", + "critical" +] - added
Input schema / properties / verb / examplesAdded value: +[ + "annotate", + "rewilding" +]
- Removed
myco_reflect - Removed
myco_scaffold - Changed
myco_sense1 field changed- added
Input schema / properties / query / examplesAdded value: +[ + "write_surface", + "R4 eat", + "assimilate" +]
- Removed
myco_session_end - Changed
myco_sporulate2 fields changed- added
Input schema / properties / slug / examplesAdded value: +[ + "v0521-glama-findings", + "q2-2026-metabolism-review" +] - added
Input schema / properties / sources / examplesAdded value: +[ + "notes/integrated/20260420T120000Z_glama-score.md", + "notes/integrated/20260421T090000Z_glama-rescan.md" +]
- Changed
myco_traverse1 field changed- added
Input schema / properties / scope / examplesAdded value: +[ + "all", + "canon", + "notes", + "docs" +]
- Changed
myco_winnow1 field changed- added
Input schema / properties / proposal / examplesAdded value: +[ + "docs/primordia/glama_onboarding_runbook_craft_2026-04-24.md", + "docs/primordia/v0524_excretion_craft_2026-04-24.md" +]
27 tool updates
v0.1.1- Changed
myco_assimilate2 fields changed- added
Input schema / properties / note_id / descriptionAdded value: +"Optional stem of a single raw note to promote (e.g. '20260423T054055Z_v0-5-22-migration-marker'). When null/omitted, assimilates ALL eligible notes in notes/raw/. Pass the stem (no extension, no directory prefix) as you'd read it from the filename. Nonexistent stems are returned as errors in the outcomes list, not raised." - added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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."
- Changed
myco_brief1 field changed- added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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."
- Changed
myco_bump4 fields changed- added
Input schema / properties / contract / descriptionAdded value: +"New contract version string, in the form 'v<semver>' (e.g. 'v0.5.23'). Must be strictly greater than the current canon's contract_version per semver comparison. Down-bumps are refused unless --allow-downgrade is passed at the bump_version.py layer (molt itself has no such flag)." - added
Input schema / properties / date / descriptionAdded value: +"Override the date stamp in the contract_changelog.md section header (YYYY-MM-DD format). When null, uses today (UTC). Useful for back-dating a release whose molt was delayed, or for reproducing historical molts exactly." - added
Input schema / properties / dry_run / descriptionAdded value: +"When true, compute the exact canon patch + changelog section that would be applied and return them in the response, without writing. Use to preview before committing the atomic version bump. Default false (writes + returns the same preview so the agent can diff against its pre-bump state)." - added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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."
- Changed
myco_craft4 fields changed- added
Input schema / properties / date / descriptionAdded value: +"Override the date stamp in the filename + frontmatter (YYYY-MM-DD format). When null, uses today (UTC). Pass an explicit date to bump out of a filename collision with an existing primordium or to back-date for historical reconstruction." - added
Input schema / properties / kind / descriptionAdded value: +"Free-form kind tag describing the craft's nature: 'design' (default, default architectural proposals), 'audit' (retrospective of an existing system), 'migration' (contract/data schema shift), 'operational' (runbook), etc. Recorded in frontmatter as kind:<value>; used for docs/primordia/ categorization by readers." - added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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." - added
Input schema / properties / topic / descriptionAdded value: +"Human-readable topic phrase, used as the doc title. Automatically slugged to lowercase-kebab (spaces → underscores, non-alphanumerics → underscores) and embedded in the filename as <slug>_craft_<date>.md. Example: 'Glama onboarding runbook' becomes glama_onboarding_runbook_craft_2026-04-24.md."
- Changed
myco_digest3 fields changed- added
Input schema / properties / dry_run / descriptionAdded value: +"When true, compute what would happen (which file would move, to where) but perform no filesystem change. Useful for confirmation before destructive single-note promotion. Default false (moves immediately)." - added
Input schema / properties / note_id / descriptionAdded value: +"Stem of the raw note to promote (filename minus the .md extension, no directory prefix). Example: '20260423T054055Z_v0-5-22-migration-marker'. Look up stems via myco_forage or by listing notes/raw/ directly. Passing an already-integrated note's id is a no-op with status='already_integrated'." - added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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."
- Changed
myco_distill3 fields changed- added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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." - added
Input schema / properties / slug / descriptionAdded value: +"Kebab-case identifier for the distilled proposal (becomes d_<slug>.md). Example: 'v0521-glama-findings'. Should be descriptive enough to disambiguate from sibling proposals. No validation beyond the filesystem's own filename rules; avoid slashes, spaces, and reserved chars." - added
Input schema / properties / sources / descriptionAdded value: +"Optional explicit list of note paths (relative to substrate root) to include as sources. When empty/omitted, sporulate auto-selects integrated notes whose tags match the slug's keywords. Pass explicit sources for tight control over what gets bundled. Paths that don't exist are errors."
- Changed
myco_eat6 fields changed- added
Input schema / properties / content / descriptionAdded value: +"Literal text body of the note, passed inline as a string. Mutually exclusive with path and url. Use for capturing decisions, frictions, ideas expressed in prose. Empty-string is rejected as UsageError to prevent silent empty notes — pass content=' ' (single space) if you really want an empty body. Max size bounded by normal memory; no hard limit enforced." - added
Input schema / properties / path / descriptionAdded value: +"Absolute or relative path to a local file or directory to ingest. Resolved against substrate root when relative. Mutually exclusive with content and url. File adapters auto-selected by extension (text, code, PDF via pypdf, HTML via beautifulsoup if myco[adapters] installed). Directory ingestion walks recursively and produces one note per ingestible file; non-ingestible files are silently skipped." - added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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." - added
Input schema / properties / source / descriptionAdded value: +"Provenance tag recorded in the note's source frontmatter field. Default 'agent' for agent-authored content. For path/url ingestion, the adapter overrides this with the actual provenance (file path or URL), so this default only affects content= mode. Use to distinguish eat-sourced notes from propagation-sourced or bootstrap-sourced notes in the substrate metabolism." - added
Input schema / properties / tags / descriptionAdded value: +"Tags attached to the ingested note's frontmatter, merged with any adapter-provided tags (URL adapter adds 'url' + the domain; file adapters may add extension-based tags). Final tag list is sorted deterministically. Tags are free-form — no validation. Common patterns: decisions, frictions, insights, boilerplate-type labels like 'chat-log' or 'paper-draft'." - added
Input schema / properties / url / descriptionAdded value: +"http:// or https:// URL to fetch and ingest. Mutually exclusive with content and path. Requires myco[adapters] (httpx). SSRF-guarded: rejects loopback (127.0.0.0/8), link-local, private (10.x/172.16-31.x/192.168.x), multicast, and reserved IANA ranges; scheme restricted to http/https (no file/gopher/ftp/data). Response body capped at 10MB. Content-Type auto-detected: text/html strips tags, application/pdf extracts text, application/json preserves, otherwise raw text."
- Changed
myco_evolve2 fields changed- added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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." - added
Input schema / properties / proposal / descriptionAdded value: +"Path to the craft proposal markdown under docs/primordia/ (relative to substrate root or absolute). Must exist and be a valid markdown file with a craft-shaped YAML frontmatter block. Winnow reads but does not modify the file; post-winnow, the agent edits to address violations and re-runs winnow."
- Changed
myco_forage2 fields changed- added
Input schema / properties / path / descriptionAdded value: +"Absolute or relative path to scan. When null/omitted, defaults to the substrate root. Directory is walked recursively; files are checked one-by-one against the adapter registry. For a single-file preflight, pass the file path directly (items list will have 0 or 1 entries)." - added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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."
- Changed
myco_fruit4 fields changed- added
Input schema / properties / date / descriptionAdded value: +"Override the date stamp in the filename + frontmatter (YYYY-MM-DD format). When null, uses today (UTC). Pass an explicit date to bump out of a filename collision with an existing primordium or to back-date for historical reconstruction." - added
Input schema / properties / kind / descriptionAdded value: +"Free-form kind tag describing the craft's nature: 'design' (default, default architectural proposals), 'audit' (retrospective of an existing system), 'migration' (contract/data schema shift), 'operational' (runbook), etc. Recorded in frontmatter as kind:<value>; used for docs/primordia/ categorization by readers." - added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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." - added
Input schema / properties / topic / descriptionAdded value: +"Human-readable topic phrase, used as the doc title. Automatically slugged to lowercase-kebab (spaces → underscores, non-alphanumerics → underscores) and embedded in the filename as <slug>_craft_<date>.md. Example: 'Glama onboarding runbook' becomes glama_onboarding_runbook_craft_2026-04-24.md."
- Changed
myco_genesis5 fields changed- added
Input schema / properties / dry_run / descriptionAdded value: +"When true, compute the files that would be written + return their byte count and first line in the preview payload, but do NOT touch disk. Use for 'what would happen if I germinate here' inspection without committing. Default false (writes immediately)." - added
Input schema / properties / entry_point / descriptionAdded value: +"Filename of the agent-entry markdown that the substrate opens with. Defaults to MYCO.md (Myco-native convention). Override to 'CLAUDE.md' when you want the substrate to share an entry with Claude-ecosystem conventions. The file gets created if absent; existing files are not overwritten unless --force." - added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute or relative path of the directory that will host the new substrate. Must exist and be writable; the _canon.yaml will be created inside this directory (not a subdirectory). Use forward slashes or escaped backslashes on Windows." - added
Input schema / properties / substrate_id / descriptionAdded value: +"Stable slug identifying this substrate across the mycelial network. Used in cross-substrate propagation + the ~/.myco/substrates.yaml registry. Recommend kebab-case, human-readable (e.g. 'neurips-2026-research' or 'my-company-infra'). No uniqueness check; reuse silently overwrites registry entries." - added
Input schema / properties / tags / descriptionAdded value: +"Free-form affiliation tags attached to the substrate identity (e.g. ['research','production','personal']). Per L0: tags are NOT boundaries — they don't gate writes, they only describe. Stored at _canon.yaml::identity.tags and surfaced in substrate_pulse for grep-friendly discovery."
- Changed
myco_germinate5 fields changed- added
Input schema / properties / dry_run / descriptionAdded value: +"When true, compute the files that would be written + return their byte count and first line in the preview payload, but do NOT touch disk. Use for 'what would happen if I germinate here' inspection without committing. Default false (writes immediately)." - added
Input schema / properties / entry_point / descriptionAdded value: +"Filename of the agent-entry markdown that the substrate opens with. Defaults to MYCO.md (Myco-native convention). Override to 'CLAUDE.md' when you want the substrate to share an entry with Claude-ecosystem conventions. The file gets created if absent; existing files are not overwritten unless --force." - added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute or relative path of the directory that will host the new substrate. Must exist and be writable; the _canon.yaml will be created inside this directory (not a subdirectory). Use forward slashes or escaped backslashes on Windows." - added
Input schema / properties / substrate_id / descriptionAdded value: +"Stable slug identifying this substrate across the mycelial network. Used in cross-substrate propagation + the ~/.myco/substrates.yaml registry. Recommend kebab-case, human-readable (e.g. 'neurips-2026-research' or 'my-company-infra'). No uniqueness check; reuse silently overwrites registry entries." - added
Input schema / properties / tags / descriptionAdded value: +"Free-form affiliation tags attached to the substrate identity (e.g. ['research','production','personal']). Per L0: tags are NOT boundaries — they don't gate writes, they only describe. Stored at _canon.yaml::identity.tags and surfaced in substrate_pulse for grep-friendly discovery."
- Changed
myco_graft5 fields changed- added
Input schema / properties / explain / descriptionAdded value: +"When set, return the source path + docstring + kind for the named plugin. Pass the plugin's registered name (e.g. 'M1' for a dimension, 'UrlFetcher' for an adapter). Unknown names raise UsageError. Mutually exclusive with list / validate / list-substrates." - added
Input schema / properties / list / descriptionAdded value: +"When true, enumerate every plugin currently loaded in this substrate's registry (kernel + substrate-local). Returns one row per plugin with kind + name + source (file path) + scope (kernel|substrate). Mutually exclusive with validate / explain / list-substrates." - added
Input schema / properties / list_substrates / descriptionAdded value: +"v0.5.16: list every substrate registered on this machine (reads ~/.myco/substrates.yaml), sorted by last-seen-at. Returns stale entries (exists=false) whose on-disk path no longer has a _canon.yaml for cleanup insight. Mutually exclusive with list / validate / explain." - added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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." - added
Input schema / properties / validate / descriptionAdded value: +"When true, re-import every substrate-local plugin in isolation and collect any exceptions. Used to sanity-check plugins after editing. Mutually exclusive with list / explain / list-substrates."
- Changed
myco_hunger2 fields changed- added
Input schema / properties / execute / descriptionAdded value: +"When true, write the boot_brief.md + patch the entry-point's MYCO-BOOT-SIGNALS block with current reflex signals. When false (default), compute the report but make zero writes — useful for 'peek without touching'. R6 write_surface still applies to the patched entry-point path." - added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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."
- Changed
myco_immune5 fields changed- added
Input schema / properties / dimensions / descriptionAdded value: +"Optional subset of dimension IDs to run (e.g. ['M1','SE1','MB2']). When empty, runs all 25. 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." - added
Input schema / properties / explain / descriptionAdded value: +"When 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." - added
Input schema / properties / fix / descriptionAdded value: +"When 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)." - added
Input schema / properties / list / descriptionAdded value: +"When 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)." - added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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."
- Changed
myco_molt4 fields changed- added
Input schema / properties / contract / descriptionAdded value: +"New contract version string, in the form 'v<semver>' (e.g. 'v0.5.23'). Must be strictly greater than the current canon's contract_version per semver comparison. Down-bumps are refused unless --allow-downgrade is passed at the bump_version.py layer (molt itself has no such flag)." - added
Input schema / properties / date / descriptionAdded value: +"Override the date stamp in the contract_changelog.md section header (YYYY-MM-DD format). When null, uses today (UTC). Useful for back-dating a release whose molt was delayed, or for reproducing historical molts exactly." - added
Input schema / properties / dry_run / descriptionAdded value: +"When true, compute the exact canon patch + changelog section that would be applied and return them in the response, without writing. Use to preview before committing the atomic version bump. Default false (writes + returns the same preview so the agent can diff against its pre-bump state)." - added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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."
- Changed
myco_perfuse2 fields changed- added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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." - added
Input schema / properties / scope / descriptionAdded value: +"Which subset of the substrate to walk. One of: 'canon' (just _canon.yaml + its outbound refs), 'notes' (notes/raw/**, notes/integrated/**, notes/distilled/**), 'docs' (docs/**), 'all' (default — everything including src/ python imports). Narrow scopes are cheaper on large substrates."
- Changed
myco_propagate5 fields changed- added
Input schema / properties / commit / descriptionAdded value: +"Optional git commit SHA (of the source substrate) to record in the propagated notes' frontmatter as the provenance stamp. When null, 'unknown' is recorded. Useful for traceability: lets downstream agents audit 'what version of source A produced this note'." - added
Input schema / properties / dry_run / descriptionAdded value: +"When true, list which notes would be propagated and to where, but write nothing. Default false (writes immediately to the destination)." - added
Input schema / properties / dst / descriptionAdded value: +"Absolute or relative path to the downstream substrate's root (must contain _canon.yaml). When relative, resolved against this substrate's root. The downstream must already be a Myco substrate — propagate will NOT auto-germinate a dst; run myco_germinate there first." - added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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." - added
Input schema / properties / select / descriptionAdded value: +"Which layer of this substrate's metabolism to propagate. One of: 'integrated' (default, notes/integrated/**.md), 'distilled' (notes/distilled/**.md), 'both'. Raw notes are never propagated (they haven't graduated past the intake queue yet). The propagated files land in the destination's notes/raw/ regardless — receiver re-metabolizes."
- Changed
myco_ramify9 fields changed- added
Input schema / properties / adapter / descriptionAdded value: +"New ingestion adapter name to scaffold (e.g. 'jira', 'slack-export'). Requires --extensions. Mutually exclusive with verb and dimension. Kernel scaffolds go under src/myco/ingestion/adapters/; substrate-local under .myco/plugins/adapters/." - added
Input schema / properties / category / descriptionAdded value: +"Dimension category. One of: 'mechanical' (canon invariants), 'shipped' (version parity), 'metabolic' (raw-note / stale-integrated signals), 'semantic' (graph connectedness). Used only with --dimension." - added
Input schema / properties / dimension / descriptionAdded value: +"New lint dimension ID to scaffold (case-sensitive, e.g. 'LOCAL1'). Requires --category and --severity. Mutually exclusive with verb and adapter. Kernel scaffolds go under src/myco/homeostasis/dimensions/; substrate-local under .myco/plugins/dimensions/." - added
Input schema / properties / extensions / descriptionAdded value: +"File extensions (with leading dot) the adapter handles, e.g. ['.jira', '.json']. Used with --adapter. Extensions register in the adapter registry for myco_eat --path dispatch; more-specific adapters (via registration order) win over generic ones." - added
Input schema / properties / force / descriptionAdded value: +"When true, overwrite an existing file at the target path. When false (default), refuse overwrite with a UsageError. Use to refresh boilerplate after manifest schema changes. Does NOT implicitly revert git history." - added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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." - added
Input schema / properties / severity / descriptionAdded value: +"Default severity for findings the scaffolded dimension emits. One of: 'low', 'medium', 'high', 'critical'. Critical findings cause myco_immune to exit non-zero. Used only with --dimension." - added
Input schema / properties / substrate_local / descriptionAdded value: +"When true, scaffold under <substrate>/.myco/plugins/ (substrate-local). When false, scaffold under src/myco/ (kernel, only valid when operating on the myco-self kernel substrate). Auto-forced true when substrate != myco-self. Override when hand-editing kernel code from within a different substrate." - added
Input schema / properties / verb / descriptionAdded value: +"New manifest verb name to scaffold (kebab-case, e.g. 'my-verb'). Writes a handler stub + manifest_overlay.yaml entry. Mutually exclusive with dimension and adapter. Kernel scaffolds go under src/myco/cycle/; substrate-local under .myco/plugins/verbs/."
- Changed
myco_reflect2 fields changed- added
Input schema / properties / note_id / descriptionAdded value: +"Optional stem of a single raw note to promote (e.g. '20260423T054055Z_v0-5-22-migration-marker'). When null/omitted, assimilates ALL eligible notes in notes/raw/. Pass the stem (no extension, no directory prefix) as you'd read it from the filename. Nonexistent stems are returned as errors in the outcomes list, not raised." - added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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."
- Changed
myco_scaffold9 fields changed- added
Input schema / properties / adapter / descriptionAdded value: +"New ingestion adapter name to scaffold (e.g. 'jira', 'slack-export'). Requires --extensions. Mutually exclusive with verb and dimension. Kernel scaffolds go under src/myco/ingestion/adapters/; substrate-local under .myco/plugins/adapters/." - added
Input schema / properties / category / descriptionAdded value: +"Dimension category. One of: 'mechanical' (canon invariants), 'shipped' (version parity), 'metabolic' (raw-note / stale-integrated signals), 'semantic' (graph connectedness). Used only with --dimension." - added
Input schema / properties / dimension / descriptionAdded value: +"New lint dimension ID to scaffold (case-sensitive, e.g. 'LOCAL1'). Requires --category and --severity. Mutually exclusive with verb and adapter. Kernel scaffolds go under src/myco/homeostasis/dimensions/; substrate-local under .myco/plugins/dimensions/." - added
Input schema / properties / extensions / descriptionAdded value: +"File extensions (with leading dot) the adapter handles, e.g. ['.jira', '.json']. Used with --adapter. Extensions register in the adapter registry for myco_eat --path dispatch; more-specific adapters (via registration order) win over generic ones." - added
Input schema / properties / force / descriptionAdded value: +"When true, overwrite an existing file at the target path. When false (default), refuse overwrite with a UsageError. Use to refresh boilerplate after manifest schema changes. Does NOT implicitly revert git history." - added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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." - added
Input schema / properties / severity / descriptionAdded value: +"Default severity for findings the scaffolded dimension emits. One of: 'low', 'medium', 'high', 'critical'. Critical findings cause myco_immune to exit non-zero. Used only with --dimension." - added
Input schema / properties / substrate_local / descriptionAdded value: +"When true, scaffold under <substrate>/.myco/plugins/ (substrate-local). When false, scaffold under src/myco/ (kernel, only valid when operating on the myco-self kernel substrate). Auto-forced true when substrate != myco-self. Override when hand-editing kernel code from within a different substrate." - added
Input schema / properties / verb / descriptionAdded value: +"New manifest verb name to scaffold (kebab-case, e.g. 'my-verb'). Writes a handler stub + manifest_overlay.yaml entry. Mutually exclusive with dimension and adapter. Kernel scaffolds go under src/myco/cycle/; substrate-local under .myco/plugins/verbs/."
- Changed
myco_senesce2 fields changed- added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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." - added
Input schema / properties / quick / descriptionAdded value: +"When true, skip immune --fix and run only reflect (the note-promotion + boot-brief patch subset). Use from SessionEnd hook where the process has ~1.5s before kill. The next SessionStart or PreCompact picks up the skipped immune work. Default false = full reflect + immune --fix pass (slower, typically 2-5s)."
- Changed
myco_sense2 fields changed- added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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." - added
Input schema / properties / query / descriptionAdded value: +"Literal substring to search for. Case-insensitive. No regex, no glob — pass 'error' not 'err.*' (regex-in-query is treated as literal). For multi-term search, call sense multiple times and union results. Whitespace-only queries return empty hits."
- Changed
myco_session_end2 fields changed- added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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." - added
Input schema / properties / quick / descriptionAdded value: +"When true, skip immune --fix and run only reflect (the note-promotion + boot-brief patch subset). Use from SessionEnd hook where the process has ~1.5s before kill. The next SessionStart or PreCompact picks up the skipped immune work. Default false = full reflect + immune --fix pass (slower, typically 2-5s)."
- Changed
myco_sporulate3 fields changed- added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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." - added
Input schema / properties / slug / descriptionAdded value: +"Kebab-case identifier for the distilled proposal (becomes d_<slug>.md). Example: 'v0521-glama-findings'. Should be descriptive enough to disambiguate from sibling proposals. No validation beyond the filesystem's own filename rules; avoid slashes, spaces, and reserved chars." - added
Input schema / properties / sources / descriptionAdded value: +"Optional explicit list of note paths (relative to substrate root) to include as sources. When empty/omitted, sporulate auto-selects integrated notes whose tags match the slug's keywords. Pass explicit sources for tight control over what gets bundled. Paths that don't exist are errors."
- Changed
myco_traverse2 fields changed- added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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." - added
Input schema / properties / scope / descriptionAdded value: +"Which subset of the substrate to walk. One of: 'canon' (just _canon.yaml + its outbound refs), 'notes' (notes/raw/**, notes/integrated/**, notes/distilled/**), 'docs' (docs/**), 'all' (default — everything including src/ python imports). Narrow scopes are cheaper on large substrates."
- Changed
myco_winnow2 fields changed- added
Input schema / properties / project_dir / descriptionAdded value: +"Absolute 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." - added
Input schema / properties / proposal / descriptionAdded value: +"Path to the craft proposal markdown under docs/primordia/ (relative to substrate root or absolute). Must exist and be a valid markdown file with a craft-shaped YAML frontmatter block. Winnow reads but does not modify the file; post-winnow, the agent edits to address violations and re-runs winnow."
27 tool updates
v0.1.0- First observed
myco_assimilate - First observed
myco_brief - First observed
myco_bump - First observed
myco_craft - First observed
myco_digest - First observed
myco_distill - First observed
myco_eat - First observed
myco_evolve - First observed
myco_forage - First observed
myco_fruit - First observed
myco_genesis - First observed
myco_germinate - First observed
myco_graft - First observed
myco_hunger - First observed
myco_immune - First observed
myco_molt - First observed
myco_perfuse - First observed
myco_propagate - First observed
myco_ramify - First observed
myco_reflect - First observed
myco_scaffold - First observed
myco_senesce - First observed
myco_sense - First observed
myco_session_end - First observed
myco_sporulate - First observed
myco_traverse - First observed
myco_winnow
TDQS
A4.6/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose, with no overlap. For example, myco_assimilate and myco_digest both promote notes but differ in scope (bulk vs single), and myco_eat, myco_forage, and myco_intake each serve unique roles in ingestion. The descriptions are precise enough to avoid ambiguity.
Naming Consistency5/5
All tools follow a consistent `myco_<verb>` snake_case pattern. The verbs are unique and descriptive (e.g., germinate, assimilate, excrete, senesce), with no mixing of styles like camelCase or inconsistent prefixes. This makes the tool set predictable and easy to navigate.
Tool Count4/5
With 20 tools, the set is slightly above the typical 3-15 range, but each tool earns its place for a complex knowledge management system. The scope covers lifecycle, introspection, governance, and extension, so the count feels justified rather than bloated.
Completeness5/5
The tool surface is thorough, covering substrate creation, ingestion, promotion, removal, synthesis, propagation, governance, introspection, and extension. No obvious gaps exist for the stated purpose of agent-driven knowledge management. Tools like myco_senesce (session end) and myco_winnow (craft gating) show attention to edge cases.
Maintenance
ActivityInactive
ResponsivenessWithin a week
Related MCP Connectors
Developmental agents for the agent economy: create an agent from a digital genome, then evolve it wi
141Biological memory for AI agents. Pattern learning, decay, clustering, 8-drive behavior.
Sovereign Agent OS — Persistent Memory, Governance & Compliance for AI Agents.
Related MCP Servers
- AlicenseBqualityAmaintenanceA basic implementation of persistent memory using a local knowledge graph. This lets Claude remember information about the user across chats.973,64690,042-
- AlicenseAqualityAmaintenanceThis server enables LLMs to retrieve and process content from web pages, converting HTML to markdown for easier consumption.190,042MIT
- AlicenseBqualityAmaintenanceA Model Context Protocol server for Git repository interaction and automation. This server provides tools to read, search, and manipulate Git repositories via Large Language Models.1290,042MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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