Mycelium

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.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.
Average 4.4/5 across 9 of 9 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 20 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mycelium MCP server](https://glama.ai/mcp/servers/dihannahdi/mycelium/badges/card.svg)](https://glama.ai/mcp/servers/dihannahdi/mycelium)

Score Badge

Copy to your README.md:

[![mycelium MCP server](https://glama.ai/mcp/servers/dihannahdi/mycelium/badges/score.svg)](https://glama.ai/mcp/servers/dihannahdi/mycelium)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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