Skip to main content
Glama

myco_propagate

Propagate integrated or distilled notes from a Myco substrate to a downstream substrate's raw notes. Enables cross-project knowledge sharing; receiver filters and assimilates.

Instructions

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 }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dstYesAbsolute 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.
selectNoWhich 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
commitNoOptional 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_runNoWhen true, list which notes would be propagated and to where, but write nothing. Default false (writes immediately to the destination).
project_dirNoAbsolute path of the workspace / project whose Myco substrate this call targets. Overrides auto-discovery. When omitted, Myco resolves via MCP roots/list, then MYCO_PROJECT_DIR, then cwd — the substrate_pulse field in every response echoes which source answered.
Behavior5/5

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

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.

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