A
licenseNot graded
qualityD
maintenanceA multi-agent MCP server that turns LLMs into an autonomous incident-response copilot, enabling rapid investigation, correlation, and remediation of production incidents.
MIT
Mycelium
by dihannahdi
Allows sending triage reports directly to Slack channels using the --output slack flag.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Myceliumtriage freshness SLA missed on ORDER_DETAILS"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Mycelium
An on-call agent for data incidents, built on a bio-inspired context protocol.
An agent should not read the catalogue. It should forage in it.
Built for Build with DataHub: The Agent Hackathon. Apache-2.0. Runs offline against a real DataHub datapack — no server required to try it.
pip install mycelium-datahub
mycelium triage "freshness SLA missed on ORDER_DETAILS"P1 CUSTOMERS fails the default quality failing assertions Test(s) and is 50.1x past its
SLA — 35 assets downstream, 1 watched
page now — a governed consumer is serving wrong or missing data
Suspects (4 found)
2 hop CUSTOMERS (origin)
· test: failing DataHub Test(s) on the data: default quality failing assertions
· freshness: last written 1203.0h ago against a Daily SLA (50.12x the window)
Who no owner is recorded on the asset; this is the escalation path the catalogue implies
· escalate via data product Customer Analytics: bryan.prosser@datahub.com
Next 1. Check the job that writes CUSTOMERS: it has not produced data in 1203h.
2. Notify consumers — 35 assets downstream, starting with datahub_order_entries.
Not determined
· the evidence comes from DataHub Tests rather than assertions, so which rows are
affected is not recorded
severity, blast radius, ownership and timeline computed from DataHub; narrative by
deepseek. 57 DataHub calls, 734 context tokens, 1 model call, 15,005 ms.Or open the page: docker run -p 7860:7860 ghcr.io/dihannahdi/mycelium.
The severity, the affected assets, the owners and the timeline are computed from DataHub. A model only writes the prose. That order is the whole design: an engineer at 03:00 can check every number against the catalogue and read the rule that produced the P-level — and with no API key at all the report loses its narrative and keeps every fact. A triage tool that goes down because a third-party inference API is rate-limiting you is not an operations tool.
The problem
Most of what a catalogue gets asked is a lookup — who owns this, is it fresh, what are the columns. An agent with a generic tool loop spends thousands of tokens on each one, because the loop has no way to tell a lookup from an investigation. In our measurements, a documented-practice DataHub MCP tool loop puts 8,154 tokens in front of the model to answer "who owns ORDER_HISTORY?" — a median of 8,696 across the nine lookup questions in the benchmark. Mycelium answers them with none.
The harder questions have the opposite failure. Ask "why is the Order Entry Dashboard showing stale order totals?" and the agent can load everything it might need — schemas, lineage, owners, queries, assertions — most of it about tables with no bearing on the problem. Or it can load too little, answer from the first three tables it found, and be confident and wrong.
Both failures share a root: the agent is handed context instead of acquiring it. And every session starts from zero — the fiftieth investigation of the same pipeline costs exactly what the first one did, though any human on the team would have learned the path by now.
Mycelium is a protocol layer between an agent and DataHub that changes the acquisition model. Four mechanisms, each borrowed from a system that already solved a version of this problem.
Related MCP server: semley
The job it does
The protocol exists to serve a task, and the task is incident triage: an alert arrives and an on-call engineer needs six things inside a minute.
Computed from | Why it is not left to a model | |
What broke | the cascade origin of the failure, not its nearest symptom | A→B→C all stale: the actionable asset is A. Restarting C fixes nothing. |
How badly | evidence strength × SLA breach factor × watched consumers | A severity nobody can audit is a vibe with a letter in front of it. The rule is printed in the report. |
Who is affected | downstream data-flow edges, consumer types only | Owners and tags are edges too. Counting them inflated one blast radius from 26 to 41 — and that number decides whether somebody is paged. |
Why | assertions, DataHub Tests, incidents, SLA arithmetic | "96 hours stale" is a catastrophe hourly and a non-event monthly. The breach factor is the number that means something. |
Who to wake | owners, then domain, then data product, then platform | "No owner recorded" is a useless triage output, and unowned assets are the common case. |
What to do next | each action tied to one piece of evidence |
Plus a seventh that separates a tool from a demo: what could not be determined. A report that never says "I don't know" is not being careful, it is being quiet.
Three surfaces, one report: mycelium triage (with --output json|markdown|slack and severity
exit codes for a webhook), the mycelium_triage MCP tool, and POST /api/triage.
Worth knowing about the shipped catalogue: DataHub's published showcase-ecommerce pack contains
no failing assertions at all. Every strong finding rests on failing DataHub Tests, which the
engine reads as first-class evidence and splits by category — a failing __default_quality_* Test
is an incident, a failing __default_governance_documentation is real and is not why the
dashboard is stale. Conflating them once put "failing tests include governance ownership and cost
change percentile" into a paragraph explaining a freshness breach.
The four mechanisms
1. Hyphal foraging
A fungal mycelium has no map and no planner. It pushes hyphae outward; where one finds nutrients the network thickens that channel, and branches that found nothing wither. Tero et al. (Science, 2010) showed this literally — Physarum polycephalum on a map of Tokyo, oat flakes at the stations, reproducing the real rail topology overnight.
Applied to a catalogue: instead of reading the schema, the agent releases cheap spores along lineage edges. Each edge carries a pheromone weight. Trails that reach an asset the agent ends up citing get pheromone deposited, weighted towards the discovery end. Everything evaporates a little each cycle, so the network never fossilises around last quarter's incidents.
The frontier score for a candidate reached over edge e at depth d:
score = w_τ · norm(τ(e)) learned: has this path paid off before?
+ w_s · similarity(goal,n) lexical: does this node look relevant?
+ w_p · n.prior() intrinsic: is it busy, broken, recently changed?
+ w_a · affinity(n) history: has it ended up in answers?
− w_h · d cost: distance is not freen.prior() treats a low quality score as attractive. A heavily-queried table with a
failing assertion is exactly where a debugging agent should look. The signals come straight
from DataHub: usageFeatures, assertionsSummary, and the dataQualityScore structured
property.
Weights live in SQLite and persist across sessions — you can open the file and sort by tau
to read off which paths your team's investigations have carved.
2. Semantic zoom
Human working memory holds about seven chunks (Miller, 1956). We read a book by holding chapters and gists, and zoom in only when a detail is needed. Three resolutions per node, with measured costs:
Level | Contents | Cost |
Forest | It exists: URN, type, platform, domain | ~50 tokens |
Tree | Name, purpose, owners, tags, neighbour counts, health verdict. No columns. | ~100 tokens |
Leaf | Full schema, sample SQL, documentation excerpt, complete health signal | ~450–1,200 tokens |
The agent does not pick its own resolution. A planner allocates the expensive seats — at most four nodes at Leaf — and simulates the cost against the token budget before anything is fetched. Truncation is always announced: a table rendered with 40 of 200 columns says so, because silently dropping columns is how an agent comes to believe a column does not exist.
3. Synaptic pruning
A maturing brain actively destroys rarely-used synapses. The pruning is not damage; it is what makes the rest fast.
Miller's seven is cited here and it is worth being precise about what actually binds: in practice the resident set settles at three, not seven, because the three-step recency rule claims a chunk before the slot limit ever does. The seven-slot ceiling is real but rarely the constraint — so the famous number is the framing, and the recency rule is the mechanism.
Every resident chunk carries an activation that decays each step and refreshes on reference. Then: anything untouched for 3 steps is evicted regardless of activation; anything below the demote threshold loses a zoom level (Leaf → Tree → Forest), shedding most of its cost without disappearing; anything below the evict threshold leaves, lowest-activation first.
Eviction writes to long-term storage first. recall(urn) brings it back at full fidelity with
fresh activation — remembering is itself an act of attention. Nothing is destroyed; it is
only set down.
Measured over a 40-step loop admitting a 600-token chunk every step:
resident tokens 600 → 1,200 → 1,800 → 1,800 … 1,800 (budget 6,000)
resident chunks settles at 3
admitted 40
accounted for 40 of 40 ← 3 resident + 37 in long-term store, all at original sizeFlat, and nothing lost. The binding constraint turns out to be the three-step recency rule, not the seven-slot capacity.
4. Dual-process routing
Pull your hand off a hot pan and the spinal cord handled it. Work out why the pan was hot and the cortex is involved. Kahneman's System 1 and System 2.
A router classifies with zero model calls — a pattern table (English and Indonesian) plus entity resolution against DataHub search. Lookups get a template and a handful of DataHub calls — one to eight in the benchmark, and never a token of context. Investigations get the foraging loop.
The load-bearing part is knowing when it doesn't know. Two genuinely different assets sharing a name is an ambiguity, so the reflex refuses and says why. But a dbt model and the warehouse table it builds are siblings in DataHub's own model — one asset, two platforms — so those collapse instead of escalating. Getting that distinction right is what took the reflex from answering 1 of 5 lookups on the real catalogue to answering 5 of 5.
Measurements
Three strategies, same questions, same catalogue, same token estimator. Every arm makes real
DataHub calls through one counted client and gets the same system prompt. Reproduce with
python -m bench.run; full table in bench/results/.
Strategy | Median context | Mean context | DataHub calls | Evidence surfaced |
naive dump | 2,990 | 3,381 | 33.0 | 13/13 |
DataHub MCP tool loop, documented practice | 8,701 | 9,330 | 27.2 | 13/13 |
Mycelium | 479 | 1,063 | 27.2 | 13/13 |
Evidence surfaced asks whether the expected asset appeared in the assembled context — model-free, so the comparison does not depend on prose quality or on which model ran. All three surface the evidence on all thirteen scored questions. This is a comparison of cost at equal recall, not of one strategy finding things the others missed.
Where the saving actually comes from
Split by question type, and the picture is more specific than the headline:
naive dump | MCP loop | Mycelium | |
Lookups (9 questions) | 2,662 median | 8,696 median | 7 of 9 cost nothing at all |
Diagnostics (7 questions) | 3,128 median | 8,702 median | 3,073 median |
So: on diagnostic questions Mycelium is level with a plain search-and-render dump (1.0×) and 2.8× cheaper than the MCP tool loop. The overall 6.4× comes almost entirely from routing — recognising that most catalogue questions are lookups and answering them with no model call and no context at all.
That is a narrower claim than "foraging beats search", and it is the one this catalogue supports. On 197 entities, search usually lands on the culprit directly, so walking the lineage graph buys accuracy that search already had.
DataHub API calls are a wash: 27.2 for both Mycelium and the MCP loop. Tokens are 18.2× cheaper by median and 8.8× by mean; round trips are not cheaper at all. A protocol that advertises frugality should say which axis it is frugal on — and which average it is quoting.
Does the advantage widen with the catalogue? Yes — measured
This was a hypothesis in an earlier draft of this README. python -m bench.scale now tests it.
The showcase-ecommerce topology is replicated into N tenants over one shared set of org-wide
entities (people, tags, glossary — one company, many teams). A broken table is planted in exactly
one tenant. Dataset names collide across tenants on purpose, because every team really does have
an order_details; dashboards carry the team name, because BI assets are named that way. So the
culprit is reachable by lineage and not by name, and the question names one tenant's dashboard.
Entities | naive dump | MCP loop | Mycelium |
197 | 2,016 ✓ | 8,896 ✓ | 1,741 ✓ |
656 | 1,391 ✗ | 13,260 ✓ | 2,840 ✓ |
2,492 | 1,391 ✗ | 14,851 ✓ | 2,840 ✓ |
9,836 | 1,391 ✗ | 14,851 ✓ | 2,840 ✓ |
19,628 | 1,391 ✗ | 14,851 ✓ | 2,840 ✓ |
✓ / ✗ is whether the broken table reached the context at all. Three different shapes:
The dump stops finding the answer. Not because it was given a stingy top-8 — the culprit simply sinks in the ranking as its identically-named twins multiply: rank 6 → 12 → 36 → 132 → 260. Dumping down to rank 260 at leaf resolution costs 42,342 tokens, against Mycelium's 2,840. That is 14.8× at equal recall, and it is the fair comparison, because the 1,391 in the table above is the cost of not finding it.
The MCP loop keeps recall and pays for it in width, 8,896 → 14,851, then flattens once the lineage neighbourhood it reads is fully explored. 5.2× Mycelium at the same recall.
Mycelium is flat at 2,840 from 656 entities upward, because its cost is bounded by the context budget rather than by what the catalogue happens to return.
So the honest summary of both experiments: at 197 entities the foraging is level with search and the win comes from routing; by 20,000 entities search-and-dump has stopped working and foraging is the cheapest strategy that still answers. That said, this is replicated topology, not a second real catalogue — it holds lineage depth and branching constant and grows only the number of competing names. It isolates the variable the hypothesis was about and cannot stand in for a genuinely different organisation's mess.
It also found a real bug. The walk's diminishing-returns rule had a patience of two weak waves, with a comment explaining that a diagnostic path "often crosses a thin BI layer before reaching the warehouse table that actually broke". That layer is two hops deep — chart, then embedded BI view — so a patience of two stopped the walk one hop short of the answer, every time. The main benchmark never noticed, because its dashboard questions are answered at the dashboard, which is five months stale and genuinely its own cause. Patience is now three, and the main benchmark's numbers did not move at all.
What repetition is worth
python -m bench.run --warm 4 reinforces each question four times before measuring:
cold | warm | |
mean context, whole set | 1,063 | 989 |
the question where recognition engages first | 1,952 | 783 |
its DataHub calls | 69 | 48 |
visits during the walk | 36 | 13 |
Recognition fires when a remembered asset is a seed of the new walk and is still unhealthy. Both halves are required: affinity alone would make the network answer every question with whatever it answered last, and the health check is what sends it back to work once an asset is fixed. It engages on two of the seven diagnostics (−60% and −38% context) and two get dearer by 580 and 597 tokens, because a warmed frontier reorders which neighbours are worth expanding and sometimes that means expanding more of them. Where the conditions do not hold, repetition costs exactly what the first run did — which is why the aggregate improvement is 7% and the best per-question one is 60%.
Corrections made to this table
Worth stating, because the numbers moved a long way and always downward:
An earlier draft claimed 21× on diagnostics. That came from diagnostic questions being short-circuited into a cheap lookup path they did not belong in.
Then 8.3×, against an MCP baseline that rendered every lineage node at full leaf detail — which DataHub's own skill guidance explicitly tells agents not to do. Rewriting that arm to follow the documented practice (batched tree-level enrichment, leaf only on the seeds) took it from 22,195 to 8,718 median tokens, and the ratio to 2.8×.
Five of the questions were co-developed with the router, so the reflex rate they produced (5 of 5) was tuning on the test set. Four held-out questions — different subject area, one with no asset name in it, one naming an asset that does not exist — bring it to 7 of 9 that cost no context. Strictly, 6 of 9 reach the reflex; the seventh is the nonexistent asset, which escalates and then costs nothing anyway because the router's failure to resolve it is the answer. Both framings are in the table; this one is the honest way to say it.
Reproduce any of it with python -m bench.run (or python -m bench.scale for the scaling table);
artefacts land in bench/results/ — bench-cold.md,
bench-warm.md, scale.md. Both run in
CI, so a change that quietly breaks a measurement fails the build rather than the README.
What is asserted, not just described
Claim | Test |
Foraging finds the culprit | From the dashboard, the broken table ranks top-3 |
It does not wander | No irrelevant-domain node ranks top-5 |
Foraging is cheap | No Leaf-level fetch occurs during a walk |
It learns | Second run reaches the culprit with no more visits; trail weights measurably rise |
Learning persists | Reinforce, close the database, reopen it — the preference survives |
It forgets | Repeated evaporation without reinforcement returns weights to the floor |
Context stays flat | 40-step loop never exceeds budget and shows no upward trend |
Nothing is lost | Every chunk admitted is recallable at its original size |
Reflexes are free | System 1 answers with zero model calls |
It knows when it doesn't know | Ambiguous and unresolvable entities escalate |
Ordering is deterministic | Two identical runs produce identical rankings |
Citations survive extraction | A URN written in prose round-trips, closing parenthesis intact |
The best finding reaches memory | The rank-1 result is resident, not evicted by rank-30 ones |
Repetition engages recognition | The second run of a question shortens the walk, on a graph where depth binds |
Memory is not tunnel vision | Recognition refuses once the remembered asset is healthy again |
A missing asset costs nothing | An unresolvable name is reported, not investigated |
Every documented MCP tool exists | The names the skill tells an agent to call are registered |
The page can fetch its own assets |
|
The trace replays and terminates | A finished run streams its history and closes, rather than hanging the page |
The CLI runs |
|
A model can ask for more |
|
Attention, not a timer | Across a five-turn loop the asset the reasoning keeps naming stays resident while others are pruned by the three-step rule, and the context handed over shrinks |
The catalogue ships | The snapshot exists as package data and no default path lands in |
The scaling generator is honest | Replication preserves every edge, no tenant points at another, and the planted incident is the only thing of its severity |
pytest -q → 520 tests, one skipped (the live smoke test, which needs a running DataHub).
CI runs the suite, both benchmarks, and the CLI on 3.11 and 3.12; a second workflow builds the
container image, starts it, and asks it a question before pushing.
The last three exist because each was a bug that every mechanism test passed through. Citations
were being trimmed with rstrip(".,;:)"), which eats the closing parenthesis that ends every
DataHub dataset URN — so nothing ever matched, nothing was ever reinforced, and the learning
claim was quietly false. Findings were admitted to a seven-slot memory without bound, so the
last seven survived rather than the best seven. The learning test itself asserted only
second <= first * 1.2 — a non-regression check wearing the name of an improvement check, which
passed while repetition made no difference at all. And pyproject.toml declared a mycelium
console script pointing at a module that did not exist, so pip install produced an executable
that crashed on every invocation.
Each was invisible in isolation, and obvious the moment the whole thing ran against a real catalogue — or the moment someone typed the tool's own name.
Giving the learning back
Weights in a local SQLite file are a private optimisation. The point of a context platform
is that knowledge accrues where the team can see it, so Mycelium writes its hot paths back
into DataHub as a knowledge-base document and marks the assets involved with a
mycelium.pathWeight structured property.
The document is written for a human: which paths repeated investigations actually traversed and cited, with the caveats stated — a weight reflects traffic, not correctness, and low-quality assets attract the walk on purpose.
Off by default. Writing into someone's catalogue is not a side effect of asking a question:
it takes MYCELIUM_WRITEBACK_ENABLED=true and the live backend.
Running it
Triage an incident
mycelium triage "freshness SLA missed on ORDER_DETAILS"
mycelium triage "the exec dashboard shows last week's numbers" --output slack
mycelium triage "assertion failed" --subject 'urn:li:dataset:(...)' --output json --exit-code--subject skips name resolution, which is what a real alerting integration does — the monitor
already knows which asset fired. --exit-code returns 10/11/12 for P1/P2/P3 so a webhook script can
branch on severity without parsing prose. --writeback puts the report into DataHub as a document
and tags the assets involved, which is what makes the next incident on that asset say "this is
the third time, here is what the last two said".
Reasoning backends
Nothing is required. With no key, the narrative is composed by a deterministic reporter that restates the evidence and says so on screen; every fact in the report is unchanged. With a key, a model writes the prose over the same computed facts.
export DEEPSEEK_API_KEY=... # or ANTHROPIC_API_KEY
mycelium triage "..." --llm deepseekClaude wins when both resolve. Forcing a backend that has no credential raises rather than degrading quietly — an operator who believes a model reasoned over their incident when nothing did is worse off than one who got an error.
The page
docker run -p 7860:7860 ghcr.io/dihannahdi/mycelium
# or
uv venv && uv pip install -e ".[dev]" && python -m mycelium.web.appWatch the lineage graph light up along a narrow path while the token meter stays flat. Click run it again to see the second investigation take the reinforced trail.
The image is public and carries the catalogue inside it, so that first command needs no clone,
no API key and no DataHub. curl localhost:7860/api/health should report "entities": 197 —
if it ever reports 0, the catalogue did not ship and every answer will be "no asset matching".
To host the same image as a public demo, see
deploy/huggingface/DEPLOY.md.
As an MCP server, in your agent
claude mcp add mycelium -- uvx --from mycelium-datahub mycelium-mcpAdd -e MYCELIUM_BACKEND=live -e DATAHUB_GMS_URL=... -e DATAHUB_GMS_TOKEN=... to point it at
your own DataHub. Nine tools: triage first when something is broken, then ask, forage,
zoom, step, recall, reinforce, stats and writeback.
As a DataHub Skill
skills/mycelium-forage/SKILL.md follows the
datahub-skills format and teaches an agent
the discipline: route before you think, forage before you read, zoom only the top three, let
things go, reinforce what paid off. It extends /datahub-search, /datahub-lineage, and
/datahub-quality rather than replacing them — underneath, it is calling the same DataHub
tools, just far fewer of them.
Two backends, one contract
Backend | Source | Purpose |
| The real | Runs offline. Judges and CI need no server. |
| A running DataHub via GMS GraphQL | Production path, and where write-back works. |
Both implement the same DataHubClient protocol and are exercised by the same contract tests.
The snapshot is real DataHub metadata — 197 entities, 546 edges, with the generated
documentation, usage statistics and quality properties the mechanisms depend on — not a
hand-written mock.
Timestamps are anchored to the present the way datahub datapack load does, so an offline run
does not make the whole catalogue look half a year stale. Be aware of what that means: the
freshest asset in the pack always reads as written just now, because the shift is derived from
it. Relative staleness across the catalogue is faithful; the absolute figures are anchored, not
observed.
Reasoning is optional
System 1 never calls a model. System 2 uses Claude when a credential resolves, and otherwise a deterministic reporter that composes findings from the evidence the protocol gathered. It is labelled as such everywhere it appears — it restates, it does not reason. It exists so the mechanism can be inspected end to end without an API key, and so the benchmark can compare context cost without model variance confounding it.
Honest limitations
The foraging is not what wins. On diagnostic questions it is level with a plain search-and-render dump at this catalogue size. The measured advantage comes from routing — from most questions not needing an investigation at all. The lineage walk earns its place by producing a bounded answer with a citable trail, not by being cheaper than search.
Mechanism 3 has never run against a live model. The loop iterates only when the model asks for something (
NEED: ZOOM/NEED: RECALL), and the deterministic backend never asks — so with no API key every run finishes in one step and decay never ticks. The loop, the three-step prune rule, the attention bookkeeping, the step ceiling and both failure paths are now driven by a scripted model in the test suite, which is honest about what it proves: the mechanism is correct, and it is unmeasured on a real incident with a real model deciding what to keep.The suspect is chosen by a second ranking. The forager ranks by relevance;
_pick_suspectthen re-ranks the shortlist by severity of evidence. Two evaluations rather than two rankings: the first is a cheap guess made before paying for a health call, the second the same judgement once the call is paid for. They now pivot on one shared threshold (staleness_suspect_hours) and the polarity of the clock follows the question — silence is suspicious for "why is this stale", recency for "what changed upstream". Before that they contradicted each other outright: the walk rewarded the freshest tables on a staleness question and penalised the four-day-old culprit. Fixing it moved the mean context from 1,126 to 1,090 with the same evidence recall, which is a small win on a small catalogue and the right shape of change regardless.Round trips are not reduced. 27.2 DataHub calls against the MCP loop's 27.2. Only tokens are cheaper.
One catalogue, one subject area. Every measured number here comes from the 197-entity
showcase-ecommercedatapack. Thelivebackend was exercised against a real DataHub v1.6.0 holding 1,245 entities — enough to prove the GraphQL path, not enough to claim the mechanism scales. Nothing above that size has been tried.The
livebackend's GraphQL field names were checked against DataHub's own schema for datasets, dashboards, charts, containers, domains, tags, users and groups; fordataJob,dataFlow,dataProductandglossaryTerma few annotation fields follow the schema's consistent pattern rather than having been individually re-read. A wrong guess there degrades one entity type's detail, not the run.The
showcase-ecommercepack ships noqueryentities, soqueries_forreturns empty against it. The parsing path exists and is covered by a synthetic test, but is unverified against real DataHub query output.Census.domains[].entity_countis free for the snapshot backend and would cost a query per domain live, so the live backend reports zero.Answer quality is only measured with
--llm. The default benchmark mode measures context cost and evidence recall, which is what this project claims to improve.
Documentation
docs/ARCHITECTURE.md— design of record, and why each constant is what it isdocs/DEMO_SCRIPT.md— the shot plan for the videosrc/mycelium/config.py— every tuning knob, with its rationale
References
Tero, A. et al. (2010). Rules for Biologically Inspired Adaptive Network Design. Science 327(5964), 439–442.
Dorigo, M. (1992). Optimization, Learning and Natural Algorithms. PhD thesis, Politecnico di Milano.
Miller, G. A. (1956). The Magical Number Seven, Plus or Minus Two. Psychological Review 63(2), 81–97.
Kahneman, D. (2011). Thinking, Fast and Slow.
Huttenlocher, P. R. (1979). Synaptic density in human frontal cortex. Brain Research 163(2), 195–205.
Licence
Apache-2.0. See LICENSE.
Available Tools
9 toolsmycelium_askA
Route a question and answer it if it does not need deliberation.
Start here for every question. Lookups ("who owns X", "is X fresh", "what columns does X
have") come back answered, with zero model calls and no context spent. Anything genuinely
open-ended comes back marked for investigation, at which point use mycelium_forage.
If the router escalated because the entity was ambiguous, the reasons say so -- resolve that with the user before investigating, rather than investigating the wrong asset thoroughly.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The user's question, in their own words. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A5/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 that lookups return answers with zero model calls and no context spent, and open-ended questions are marked for investigation. Also covers escalation due to ambiguity.
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?
Three paragraphs, each sentence adds value. Front-loaded with purpose, no fluff, well-structured for quick comprehension.
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 low complexity (1 param, no nested objects, output schema exists), description fully explains behavior, routing logic, and when to use alternatives. No gaps.
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?
Single parameter 'question' with schema coverage 100%. Description adds meaning by explaining how the question is processed (lookup vs. investigation), which is beyond the schema's description of 'The user's question, in their own words.'
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 purpose: "Route a question and answer it if it does not need deliberation." It specifies that it handles lookups directly and escalates open-ended questions, distinguishing it from sibling mycelium_forage.
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 "Start here for every question." Provides examples of when to use (lookups) and when not (open-ended questions requiring mycelium_forage). Also advises resolving ambiguity before investigating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mycelium_forageA
Walk the lineage graph on a budget and return a ranked shortlist of what to look at.
This is not a lineage dump. Every candidate is fetched at forest resolution only -- the walk is deciding where to read, not reading. Results come back best-first, each with the trail that reached it.
Treat the ranking as a hypothesis. Investigate the top three; note the rest without reading them. An empty result is a real finding: it means the cause is outside the hop budget or the direction was wrong, not that there is no cause.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | What you are trying to find out. State the symptom, not a table. | |
| seeds | No | Optional starting URNs. Inferred from the goal if omitted. | |
| max_hops | No | Lineage depth. Defaults to 5. | |
| direction | No | 'upstream' for causes, 'downstream' for blast radius, 'both'. | upstream |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it fetches at forest resolution only, returns best-first results with trails, and treats ranking as a hypothesis. It also explains the meaning of empty results. No contradictions or hidden behaviors.
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 and well-structured, with the core function stated upfront. Every sentence adds value, and the tone is direct. It does not waste words, and the length is appropriate 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 presence of an output schema and full schema coverage, the description is complete. It explains the nature of the output (ranked shortlist with trail), the resolution level, and how to interpret results. No gaps are evident for this tool's complexity.
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%, so description carries limited additional value per parameter. The schema already documents each parameter's purpose. The description adds context on how they work together but does not provide new per-parameter semantics 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 the tool walks the lineage graph on a budget and returns a ranked shortlist of what to look at, distinguishing it from a lineage dump. The verb 'walk' and resource 'lineage graph' are specific, and it contrasts with sibling tools by emphasizing efficiency and hypothesis generation.
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 clear usage context: it is for finding causes or blast radius with a budget. It gives guidance on interpreting results (treat ranking as hypothesis, investigate top three) and explains empty results. However, it does not explicitly state when not to use or list alternatives, though context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mycelium_recallA
Bring something back that was pruned. Nothing was ever destroyed, only set down.
Cheaper than re-foraging or re-zooming, so prefer this over hoarding context "in case" -- hoarding is what degrades your own reasoning.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| urn | Yes | The entity to bring back into working memory. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.9/5.0
Behavior3/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 clarifies that nothing is destroyed ('only set down'), which is a key behavioral trait. However, it doesn't disclose potential costs, idempotency, or failure modes, leaving some gaps for a tool that recalls data.
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 extremely concise: two sentences and a short note. The first sentence immediately states the purpose, and the second adds behavioral context. Every sentence serves a purpose without redundancy.
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?
For a simple tool with one parameter and an output schema, the description covers the key aspects: purpose, usage guidance, and a behavioral trait. It doesn't explain return values, but the output schema presumably handles that. The description is complete enough for an agent to use effectively.
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?
The input schema already covers the 'urn' parameter with a basic description. The tool description adds context ('bring back into working memory'), enriching the schema's meaning and helping the agent understand the parameter's role in the recall process.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool brings back pruned items ('Bring something back that was pruned'), which is a clear verb+resource. It distinguishes from siblings by noting it's cheaper than re-foraging or re-zooming, though the metaphor 'pruned' may be slightly ambiguous for newcomers.
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 advises using this tool over hoarding context and contrasts it with re-foraging or re-zooming, providing explicit usage guidance. It doesn't list exclusions, but the context is clear enough for an AI agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mycelium_reinforceA
Lay pheromone on the trails that reached these entities.
This is the step that makes the next investigation cheaper. Be honest about the list: reinforcing something you merely looked at teaches the network a wrong path, and it will keep sending agents there for weeks. An empty reinforcement is better than a padded one.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| urns | Yes | Only the URNs your conclusion genuinely rests on. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.7/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 makes next investigation cheaper, warns that dishonesty teaches wrong paths and sends agents for weeks, and states empty is better than padded. This is thorough and transparent about consequences.
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?
Three sentences, each earning its place: first states the action, second explains significance, third provides a critical rule. No wasted words, front-loaded with the core action, and uses plain language effectively.
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?
While the description covers purpose, usage, and parameter semantics well, it omits what the tool returns or any side effects beyond cost. However, an output schema exists (though not shown) which likely explains return values, so the burden is partially shifted. For a tool with one parameter, this is adequate but could mention expected outcome.
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 a single required parameter 'urns' described as 'Only the URNs your conclusion genuinely rests on.' The description adds significant meaning: 'the trails that reached these entities' and the ethical context of honesty, reinforcing the schema's guidance and explaining the parameter's purpose and consequence.
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 uses specific verbs and resources: 'Lay pheromone on the trails that reached these entities.' It clearly defines the tool's purpose as reinforcing paths to make future investigations cheaper, distinguishing it from sibling tools like mycelium_ask or mycelium_forage which involve querying or searching.
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 clear guidance: this tool is for reinforcing trails after a conclusion to reduce future investigation cost. It warns against reinforcing based on mere looks and recommends empty over dishonest input. While it doesn't explicitly name alternatives, the context of siblings and the action of 'reinforcing' imply when to use this versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mycelium_statsB
What the network has learned, and what is currently in mind.
Useful mid-investigation to see how much of the budget is left, and after one to see which paths the catalogue's traffic has carved.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose safety traits like idempotency or side effects. It implies a read-only operation (stats), but does not confirm that changes are not made, nor does it mention permissions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes metaphorical language that may obscure meaning. It could be more direct and concise without losing substance. Score 3 for being adequate but not optimized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and an output schema present, the description provides enough context about what the tool shows (learned info, budget, paths), but the explanation is somewhat cryptic. It meets minimum viability but leaves room for interpretation.
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?
The tool has no parameters, and the schema description coverage is 100%. Per guidelines, baseline is 4. The description does not need to add parameter information as there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description indicates it shows learned information and current state, and provides usage contexts (mid-investigation, after investigation), but lacks a specific verb and resource, making it somewhat vague. It distinguishes from siblings by suggesting a stats/status role, but not clearly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It describes when to use (mid-investigation for budget, after for paths) but does not explicitly state when not to use or mention alternative tools. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mycelium_stepA
Advance the reasoning loop one step: decay activation, demote, prune.
Call this between phases of a long investigation. Anything you have not referenced for
three steps leaves working memory -- and is retrievable with mycelium_recall, at full
fidelity. Letting things go is what keeps a long investigation coherent.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that items not referenced for three steps leave working memory and are retrievable with mycelium_recall. Does not mention side effects or safety, but the described behavior is benign and sufficient.
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?
Three sentences, front-loaded with the core action. Every sentence adds value—states what it does, when to use, and behavioral implications. No wasted words.
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?
No annotations or parameters, but has output schema (no need to explain return values). Description explains effect, usage timing, and links to sibling. Adequately complete for a step 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?
No parameters exist, so schema coverage is trivially 100%. Rule states baseline 4 for 0 parameters. Description adds no parameter info, but none is needed.
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 advances the reasoning loop one step with specific actions: decay activation, demote, prune. It distinguishes itself from siblings like mycelium_recall by explaining that forgotten items can be retrieved.
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?
Explicitly says 'Call this between phases of a long investigation,' providing clear when-to-use guidance. Mentions mycelium_recall as an alternative for retrieval, but does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mycelium_triageA
Triage a data incident end to end: cause, severity, blast radius, owner, next actions.
Use this instead of mycelium_ask whenever something is broken. ask answers a question;
this does the on-call job, and returns a report rather than a paragraph.
What comes back is computed from DataHub, not inferred: the severity (P1-P4) with the inputs
that produced it and the rule that combined them, the assets downstream and how many of them a
person actually watches, the cause with its lineage path and evidence, the owner or the
escalation path when there is no owner, a timeline, ranked next actions, and -- importantly --
a gaps list of what could not be determined.
Three things worth knowing before you act on it:
You may not overrule the severity. It is arithmetic over the catalogue and the rule is in the response. If you disagree, say which input you think is wrong.
statusmatters as much asseverity.resolved_itselfmeans the alert already cleared;ambiguousmeans several unrelated assets match and you should ask the user which fired, not guess;no_cause_foundmeans the metadata genuinely does not explain the symptom, which is a finding and tells you to look outside the catalogue.Read
gapsbefore summarising. Reporting a cause while omitting that the suspect has no SLA recorded is how a confident wrong answer gets made.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| alert | Yes | The alert, in the monitor's words or the user's. e.g. 'freshness SLA missed on ORDER_DETAILS' or 'the exec dashboard is showing last week's numbers'. | |
| subject | No | URN of the asset that fired, if known. Skip the name resolution and its ambiguity by passing this whenever the monitor tells you which asset it was. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.8/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: severity is arithmetic and not overridable, the response includes a 'gaps' list, computation is from DataHub and not inferred, and it returns a structured report not a paragraph. It also warns about potential pitfalls like reporting a cause without mentioning missing SLA.
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 sections and bold key points. It is front-loaded with the main purpose. Although it is fairly long, every sentence provides valuable information. Could be slightly more concise, but structure earns a 4.
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 existence of an output schema (context indicates it exists), the description does not need to detail return values. However, it still mentions important aspects like gaps, severity inputs, and status meanings. For a tool with two parameters and complex behavior, the description covers all essential context comprehensively.
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 description coverage is 100%, so baseline is 3. The description adds context about the 'subject' parameter: passing it avoids name resolution and ambiguity, which adds value beyond the schema. It also reinforces the purpose of 'alert' parameter implicitly. A slight boost is warranted.
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's purpose: to triage a data incident end to end, listing specific outputs (cause, severity, blast radius, owner, next actions). It distinguishes from sibling tool mycelium_ask by advising to use this tool when something is broken, providing clear 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?
The description gives clear guidance on when to use this tool vs mycelium_ask. It also explains important behavioral notes: severity cannot be overridden, status values have specific meanings (resolved_itself, ambiguous, no_cause_found), and to read gaps before summarising. These guidelines help the agent decide and act correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mycelium_writebackA
Write the learned hot paths back into DataHub as a knowledge-base document.
Turns a private optimisation into shared context: the catalogue that fed the agent gets
better because the agent used it. Requires MYCELIUM_WRITEBACK_ENABLED=true and the live
backend -- writing to someone's catalogue is not something to do by surprise.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| domain_hint | No | Optional label for the document title, e.g. the domain investigated. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the write behavior, the requirement for a feature flag, and the potential impact of writing to someone's catalogue, providing adequate 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?
Two sentences with no wasted words; critical information is 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?
Given the tool's simplicity (one optional parameter, output schema present), the description fully covers purpose, usage, and behavioral context.
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?
The schema covers 100% of the single parameter, and the description adds context that domain_hint is optional and used for the document title, such as the domain investigated.
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 verb 'Write' and the resource 'learned hot paths back into DataHub as a knowledge-base document', distinguishing it from siblings like mycelium_ask or mycelium_forage.
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 provides when to use (turning private optimization into shared context) and when not to use (requires feature flag and live backend; warns against surprising writes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mycelium_zoomA
Materialise one entity at a chosen level of detail, and admit it to working memory.
Default to tree. Go to leaf only when you need column names, real query patterns, or
assertion detail -- that is, when you are about to write SQL or name a specific field.
At most four entities sit at leaf resolution at once. If you need a fifth, the least-used one is demoted to make room; that is the mechanism working, not a failure. If the response says columns were truncated, quote the stated count rather than concluding a column is absent.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| urn | Yes | The entity to look at more closely. | |
| level | No | 'forest' (it exists), 'tree' (identity + relations), 'leaf' (full). | tree |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 shoulders the burden. It discloses the demotion policy for leaf entities and warns about column truncation, advising to quote the count rather than assume absence.
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, front-loaded with the core purpose, followed by usage guidelines and behavioral notes. Every sentence earns its place 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?
Covering purpose, usage, behavior, and parameters, and given the presence of an output schema, the description is complete and self-sufficient for correct tool selection and 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?
The description enriches the schema by explaining the three levels ('forest', 'tree', 'leaf') with practical usage contexts, and notes the default. This goes beyond the schema's brief 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 materializes an entity at a chosen level of detail and admits it to working memory. It distinguishes this from other mycelium tools (e.g., mycelium_ask, mycelium_forage) by focusing on zooming into a single entity.
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?
Explicit guidance is provided: default to 'tree', use 'leaf' only when column names or query patterns are needed (e.g., before writing SQL). It also notes the constraint of at most four leaf entities, explaining the demotion mechanism.
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.
9 tool updates
v0.1.0- First observed
mycelium_ask - First observed
mycelium_forage - First observed
mycelium_recall - First observed
mycelium_reinforce - First observed
mycelium_stats - First observed
mycelium_step - First observed
mycelium_triage - First observed
mycelium_writeback - First observed
mycelium_zoom
TDQS
A4.2/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: ask routes questions, forage explores lineage, triage handles incidents, zoom materializes details, step manages memory, recall retrieves pruned data, reinforce lays pheromones, stats shows network state, and writeback persists learned paths. No two tools overlap in function.
Naming Consistency5/5
All tools follow a consistent 'mycelium_<verb>' pattern in snake_case (e.g., mycelium_forage, mycelium_recall). The verbs are all single-word actions, maintaining a uniform and predictable naming convention throughout the set.
Tool Count5/5
With 9 tools, the server is well-scoped for its domain of data investigation and incident triage. Each tool serves a specific and necessary role, from question routing to memory management and learning, without redundancy or excess.
Completeness5/5
The tool surface covers the full lifecycle of data investigation: initial query (ask), lineage exploration (forage), incident triage (triage), detailed inspection (zoom), memory management (step, recall), reinforcement learning (reinforce, stats), and knowledge persistence (writeback). No obvious gaps exist for the stated purpose.
Maintenance
ActivitySlowing
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Data + AI observability — monitor and troubleshoot production-grade agents and the context they use.
AI agent run monitoring with incident replay and SLA receipts.
- causelyOAuthapp.causely
Causal reasoning for reliability: root cause, blast radius, and service health for agents.
- SuperlogOAuthsh.superlog
Open-source agent that observes and fixes your application. Query logs, traces, metrics, incidents.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables autonomous SRE incident investigation by allowing users to describe incidents in natural language. The agent follows a governed state machine to gather read-only evidence and produce grounded conclusions.MIT
- AlicenseAqualityBmaintenanceMCP server that enables agents to manage DataHub incidents, recall past incident memory, guard columns against regression, and write postmortems into the data graph.7Apache 2.0
- AlicenseNot gradedqualityBmaintenanceA data-incident triage agent for DataHub that traverses downstream lineage, ranks affected assets by criticality, resolves owners, and records incidents back into the catalog.Apache 2.0
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/dihannahdi/mycelium'
If you have feedback or need assistance with the MCP directory API, please join our Discord server