Skip to main content
Glama

myco_germinate

Generate a new Myco substrate for a project without _canon.yaml: writes required files and registers the substrate. Only for first-time project setup.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_dirYesAbsolute 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_idYesStable 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.
tagsNoFree-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_pointNoFilename 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_runNoWhen 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).
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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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

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

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