The RootCause MCP server enables AI agents to conduct medical reasoning and structured root cause analysis (RCA). It provides:
Session Management — Start, retrieve, list, filter, and archive RCA sessions with case types such as death, complication, near miss, safety, and staffing.
Evidence Handling — Add, retrieve, and verify structured evidence with provenance and source metadata.
Differential Diagnosis — Propose, update, rank, and exclude hypotheses using Bayesian updates and likelihood ratios, and link evidence to hypotheses.
Cognitive Transparency — Record explicit reasoning, alternatives considered, uncertainty factors, and confidence rationales as auditable thinking steps.
Fishbone (Ishikawa) Analysis — Initialize 6M diagrams (Personnel, Equipment, Material, Process, Environment, Monitoring), add causes with sub-causes, evidence, and HFACS codes, inspect diagrams, and export in Mermaid, JSON, or Markdown.
5-Why / Why Tree Analysis — Iteratively drill down with Why questions up to 5 levels, branch from any node, mark root causes with confidence, and export trees in Mermaid, JSON, or Markdown.
Causal Relationship Mapping — Add directed or bidirectional causal links between Why nodes and classify them as contributes_to, feedback, escalates, or mitigates.
Causation Verification — Run counterfactual tests for temporality, necessity, mechanism, and sufficiency, with standard or comprehensive verification modes.
HFACS-MES Classification — Get AI-ranked HFACS-MES code suggestions, confirm classifications, browse the framework hierarchy, list learned rules, reload rules from YAML, and map 6M Fishbone categories to HFACS codes.
Reporting — Generate auditable CONTRACT reports in JSON or FHIR-compatible DiagnosticReport formats with content hashes for integrity.
Teaching Case Generation — Convert Why Trees into teaching cases with learning objectives, common pitfalls, discussion prompts, and reverse-causality questions, targeted to learner levels and exported in Markdown or JSON.
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., "@rootcause-mcp Perform root cause analysis on a fall incident using fishbone diagram"
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.
Medical reasoning, differential diagnosis, and clinical RCA harness for any MCP-compatible AI agent.
English | 繁體中文
RootCause MCP enables general-purpose agents such as Claude Code, Codex, Cline, OpenCode, OpenClaw, and Z.ai agents to perform a specialized workflow:
Inventory and extract de-identified clinical documents through the host agent.
Register source-grounded evidence with exact raw snippets, preserve source-faithful time, and append authorized source/de-identification/independence reviews.
Build the maximum reasonable mechanism-based differential for the phenotype and time course, explicitly select the working lead, then relate source-linked evidence using direct likelihood ratios only when a separate verified literature record establishes the quantitative calibration.
Treat unknowns as reasoning inputs and record each candidate's rationale, support/refutation/neutral evidence, discriminator, qualitative certainty, and bias.
Connect diagnostic reasoning to Fishbone and 5-Why, obtain an authorized HFACS-MES disposition for every cause, and run a conservative causation proof-obligation audit.
Produce a typed, machine-readable report with explicit source lineage and deterministic conformance results.
The agent performs the reasoning. The MCP server does not inspect hidden model states or raw private chain-of-thought. It provides schemas, workflow constraints, persistence, calculations, and audit records for reasoning the agent explicitly chooses to externalize.
For clinician-facing output, the built-in Markdown renderer supports Traditional Chinese explanatory prose while preserving canonical diagnosis, test, drug, device, and procedure names in English. Exact source quotations, units, IDs, codes, JSON/FHIR values, and custom-template language are never machine-translated.
This project is not a medical device and must not autonomously diagnose or treat patients. Clinical use requires qualified human review, local governance, privacy controls, and independent verification of source documents.
Related MCP server: SafetyOps MCP Server
The deterministic final-report boundary is implemented: nested report sections are
typed, every report carries machine-readable conformance_checks[], and unsafe
finalization is blocked for source, DDx, root-lineage, causation-disposition,
reviewer, or integrity failures. Final snapshots carry a reviewer, timezone-aware
time, recomputable SHA-256 hash, and recursively reject mutation.
DDx breadth is now explicit rather than inferred from a count: the Agent selects a
syndrome-appropriate framework, reviews every canonical cell, and persists a PRIMARY
breadth audit. REVIEWED_INSUFFICIENT_DATA retains unknowns and typed discriminators;
NOT_ASSESSED blocks finalization. The audit establishes documented coverage, not
clinical correctness.
Final conformance also carries the complete append-only source-review ledger and recomputes its final inventory projection, independence lineage, explicit leading-diagnosis selection, source-calibrated LR links, source-faithful temporal semantics, per-cause HFACS review, guidance/readiness facts, gap counts, and Why/root/causation lineage. Date, range, relative, and unknown time may remain in a valid final artifact but cannot be silently sorted or used to establish temporality.
Release 2.0.0a3 (2026-08-19) is still an engineering alpha, not a clinically
validated Agent MVP. The
public six-case corpus and runner are engineering references. A formal result
requires at least 3 real Agent runtimes × 6 cases × 2 repeats, repository-external
private case bundles, separately protected private holdout gold, filesystem
isolation, trusted runtime/server MCP traces, and two blinded qualified clinical
reviewers per job with adjudication of disagreement. That evaluation is currently
AGENT_EVAL_NOT_ESTABLISHED. See
MVP conformance and evaluation.
A general Agent can read every document and write a report in one long prompt. That approach works, but repeatedly spends context on tool schemas, prior facts, formatting, probability arithmetic, graph construction, completeness checks, and report prose. RootCause MCP moves those repeatable operations into deterministic code while leaving clinical judgment with the Agent.
Work | Agent-only workflow | RootCause MCP assistance |
Tool context | Load all schemas |
|
Tool results | Re-read duplicate text and JSON | Complete SDK 2.0 |
Quantitative evidence links | Recalculate and narrate | Compatibility arithmetic only for source-calibrated direct LR; otherwise a neutral qualitative link |
Case continuity | Re-inject earlier conversation | Persisted aggregate and restart rehydration |
Report assembly | Rewrite DDx, evidence, gaps, metrics, and graphs | Deterministic |
Quality review | Remember every checklist item | Automatic structural traceability warnings |
Tokenizer-independent regression fixtures compare tool-profile schema bytes,
duplicated text fallbacks, and deterministic report generation. Use the current CI
artifacts as the source of truth because schema changes alter those measurements.
These byte proxies are not promises about a specific model tokenizer. The Agent
still must read the source extracts, generate clinically plausible hypotheses,
choose defensible evidence relationships, and review the final artifact. A non-neutral
LR requires a distinct verified LITERATURE calibration record. No uncalibrated
prior/posterior may be presented as clinical probability or certainty; LR=1.0 means
neutral/quantitatively unknown and does not count as support or refutation.
Lightweight or fast models (such as Flash/mini variants) commonly struggle with complex clinical cases: they tend to jump to conclusions, stop after a single hypothesis (premature closure), neglect disconfirming tests, and skip cognitive reflections.
RootCause MCP acts as an active Reasoning State Machine:
Every core tool call returns a structured guidance payload evaluating the case state.
Stage Progression: Automatically tracks progress through EVIDENCE_COLLECTION → DIFFERENTIAL_EXPANSION → BAYESIAN_EVALUATION → COGNITIVE_AUDIT → READY_FOR_SYNTHESIS.
Readiness Checklist: Requires verified source content, typed candidate labels,
at least three unique diagnoses across two non-UNKNOWN mechanisms, an applicable
must-not-miss diagnosis, evidence/test disposition for every active diagnosis,
support plus contradiction or a typed rule-out plan for leading/must-not-miss
diagnoses, and explicit uncertainty/bias review. These are deterministic
finalization floors, not a clinical breadth target or cap.
Next Prompt Directives: Provides explicit next_recommended_actions with exact tool names and Socratic push_questions in each response, allowing Flash agents to loop iteratively until the case is complete.
Audit Tools: Agents or external orchestrators can call
rc_audit_differential_breadth to persist every-cell framework coverage and
rc_audit_reasoning_state to inspect remaining prerequisites before report generation.
Inspired by data integration and ETL lineage architectures (such as Airbyte's stream/source verification models), RootCause MCP establishes deterministic, cryptographic evidence grounding without relying on probabilistic LLM memory:
Verbatim Snippets & Lineage Anchors: Evidence records capture exact raw_snippet quotes, file paths, line locators, and SHA-256 digests.
Deterministic Provenance Verification: The ProvenanceVerifier domain service scans physical raw files on disk (TXT, CSV, HL7, XML) to verify substring matches and line numbers without invoking an LLM.
Tamper & Hallucination Detection: If an agent invents a quote, references an unavailable source, or presents a source whose bytes no longer match the pinned manifest, the server keeps the evidence unverified and returns audit diagnostics.
Append-only Source Review: The pinned manifest and digest never change.
Extraction, de-identification, and independent/derived lineage advance only through
rc_adjudicate_source; every final source needs an allowlisted reviewer, time,
reason, and stable adjudication ID.
Clean Architecture Boundary: RootCause MCP focuses on reasoning contracts and provenance checks; it does not parse raw PDF, DOCX, image, scan, spreadsheet, or EHR-export batches.
The host agent or an approved extractor must produce citation-ready text/cells while preserving exact content, source locations, hashes, units, negation, time precision, OCR corrections, and extraction method. Send only structured atomic findings into RootCause MCP, and do not claim MCP verification for binary or inaccessible sources.
The packaged YAML protocols and domain playbooks are versioned, non-normative retrospective DDx resources that the bundled agent harness tells agents to read. Markdown templates are deterministic rendering inputs. Runtime readiness thresholds and gap rules are still implemented in Python; editing a protocol YAML alone does not change those gates. These playbooks prompt retrospective mechanism review only; they do not provide active-care management, treatment/rescue instructions, or patient-specific dosing.
Configurable SOP & Domain Playbooks (config/protocols/, config/domains/):
anesthesia_mm_rca_protocol.yaml: 4-Tier backward causal framework (Tier 0 Terminal Rhythm → Tier 1 ACLS 5H5T → Tier 2 Tri-stream Triggers [Patient baseline vs Surgical insult vs Anesthesia pharmacology] → Tier 3 HFACS Latent System Gaps).
perioperative_shock.yaml & toxicology_sedation.yaml: Non-normative retrospective
DDx prompts for considering Dynamic LVOT Obstruction (SAM) and Propofol Infusion
Syndrome (PRIS), not active-care protocols.
Customizable Markdown Templates (config/templates/):
anesthesia_mm_rca_report_template.md: Specialized departmental M&M conference review format with deterministic slot filling.
clinical_reasoning_report_template.md: General clinical reasoning and patient safety action report.
graph TB
A[General-purpose AI Agent] -->|MCP SDK 2.0| T[8 facade or 25 / 24 / 46 discrete tools]
D[Clinical documents] --> A
subgraph Harness
T --> S[ServerState / case aggregate]
S --> O[ClinicalReasoningOrchestrator]
O --> E[Evidence + provenance + hash]
O --> H[Hypotheses + Bayesian updates]
O --> R[ReasoningChain]
O --> G[Clinical Guidance Engine]
S --> C[ThinkingChain: explicit rationale records]
end
E --> DB[(SQLite / SQLModel)]
H --> DB
R --> DB
C --> DB
S --> CR[CONTRACT report]
CR --> J[JSON]
CR --> F[FHIR-compatible DiagnosticReport]
CR --> M[Deterministic Markdown]
T --> RCA[Fishbone / 5-Why / HFACS-MES / conservative causation audit]
The dependency direction follows DDD:
Interface -> Application -> Domain <- InfrastructureThe SDK 2.0 server persists the medical reasoning aggregate in SQLite:
Structured Evidence and source metadata
Differential-diagnosis hypotheses and Bayesian update history
Explicit ThinkingStep records supplied by the agent
ReasoningStep audit records generated by the orchestrator
RCA sessions, source manifests, Fishbone diagrams, and Why Trees
Authentication, encryption-at-rest, tenant isolation, reviewer-role authorization, database migrations, and regulated deployment controls must be supplied by the deployment environment before clinical production use. See the PHI and clinical-data policy.
You can automatically detect uv, synchronize virtual environments, configure client MCP harnesses (Copilot-native .mcp.json, VS Code .vscode/mcp.json, Claude Desktop, and Cline), and run a production stdio diagnostic with a single command:
Windows PowerShell:
powershell -ExecutionPolicy Bypass -File scripts/setup.ps1Linux / macOS / WSL:
chmod +x scripts/setup.sh
./scripts/setup.shThe MCP command runs on the Agent or extension host that starts the server. If VS Code uses WSL, SSH, a Dev Container, or another remote host, install
uvand runscripts/setup.shin that remote integrated terminal. Runningsetup.ps1on local Windows does not installuvon the remote host. Run Developer: Reload Window after setup.
Universal Python CLI:
uv run --locked python scripts/install.py --profile all --target all
uv run --locked python scripts/mcp_doctor.py --config allRun the six bundled synthetic scenarios (SAM, PRIS, transfusion hyperkalemia, post-operative PE, LVAD suction, and delayed diagnosis). This script is a developer regression/demo, not a substitute for the native manifest/finalization acceptance tests or clinical validation:
uv run python scripts/run_case_trial.py --case allThe public corpus dry-run checks runner/artifact mechanics only and deliberately
returns AGENT_EVAL_NOT_ESTABLISHED:
eval_output="$(mktemp -d)"
uv run python scripts/run_agent_eval.py dry-run \
--output-root "$eval_output" \
--repeats 2Formal runs must use repository-external private cases and separately protected private gold. Start with the fail-closed preflight:
uv run python scripts/run_agent_eval.py \
--preflight \
--matrix /secure/adapter-matrix.json \
--corpus-file /secure/private-corpus/corpus.json \
--gold-dir /secure/private-holdout \
--attest-holdout-isolation \
--authorize-provider-egressSee the evaluation protocol before any formal run. Egress authorization applies only to approved de-identified synthetic inputs, never real clinical records or PHI.
# Install the locked environment
uv sync --locked --all-extras
# Run the MCP SDK 2.0 stdio server
uv run --locked rootcause-mcpCopilot CLI and Agent Host read .mcp.json at the repository root directly:
{
"mcpServers": {
"rootcauseMcp": {
"type": "local",
"command": "uv",
"args": ["run", "--locked", "rootcause-mcp"],
"cwd": ".",
"env": {
"ROOTCAUSE_TOOL_PROFILE": "all",
"ROOTCAUSE_RESPONSE_MODE": "compact"
},
"tools": ["*"]
}
}
}The VS Code editor uses .vscode/mcp.json and forwards it to the active Agent
Host:
{
"servers": {
"rootcauseMcp": {
"type": "stdio",
"command": "uv",
"args": [
"run",
"--locked",
"--directory",
"${workspaceFolder}",
"rootcause-mcp"
],
"cwd": "${workspaceFolder}",
"env": {
"ROOTCAUSE_TOOL_PROFILE": "all",
"ROOTCAUSE_RESPONSE_MODE": "compact"
}
}
}
}Both files intentionally use the same rootcauseMcp server key so Agent Host
does not create two MCP identities. Shared configuration uses the PATH-resolved
uv name only. Never commit C:\...\uv.exe, ROOTCAUSE_DATA_DIR, or
ROOTCAUSE_AUTHORIZED_REVIEWERS; provide protected runtime values in the host
environment. Put unrelated MCP servers in VS Code user or remote-user config
instead of committing personal executable and data paths to this repository.
spawn ... uv.EXE ENOENTThis means the execution host cannot find the configured executable. In a WSL, SSH, or container Remote extension host, a common cause is forwarding a local Windows absolute path. In the VS Code remote terminal, run:
uv --version
uv sync --locked --all-extras
uv run --locked python scripts/install.py --profile all --target all \
--skip-tests --skip-trial
uv run --locked python scripts/mcp_doctor.py --config allThe doctor should report PASS for both configs and their stdio handshakes.
Then run Developer: Reload Window, restart rootcauseMcp from MCP: List
Servers, and use MCP: Reset Cached Tools after a tool-catalog update. See
the official VS Code MCP configuration
reference
and GitHub Copilot CLI MCP
configuration.
Environment variables:
Variable | Purpose | Default |
| SQLite database, checkpoints, learned rules, and generated exports | OS user-data directory |
| Optional configuration override containing | Packaged |
| OS-path-separated allowlist of roots for exact plain-text provenance checks | Current working directory |
| Comma-separated operator-controlled identities allowed to manually verify, adjudicate sources/HFACS, or finalize | Empty (manual review/final approval disabled) |
| Tool catalog: |
|
|
|
|
A compatible agent can use either the discrete tool workflow or the ultra-compact 8-facade workflow:
rc_start_session(source_manifest={...})
-> rc_add_evidence(temporal={kind=..., raw_value=...})
-> rc_adjudicate_source # each manifest source; authorized append-only review
-> rc_think_aloud / rc_identify_gaps / rc_challenge_assumption
-> rc_propose_hypothesis(planned_tests=[...])
-> rc_audit_differential_breadth(audit={...})
-> rc_link_evidence_to_hypothesis(calibration_status=...,
calibration_source_ref=...)
-> rc_select_leading_hypothesis(reason=..., changed_by=...)
-> rc_get_differential_diagnosis
-> rc_get_reasoning_chain
-> rc_detect_conflicts
-> rc_create_checkpoint
-> rc_init_fishbone / rc_add_cause / rc_confirm_classification
-> rc_ask_why / rc_mark_root_cause
-> rc_verify_causation # conservative audit, not clinical causal proof
-> rc_generate_contract_report(format="markdown", detail_level="standard",
locale="zh-TW", audience="clinician", finalize=false)rc_rca(action="session_start")
-> rc_evidence(action="add")
-> rc_rca(action="session_adjudicate_source")
-> rc_thinking(action="think" / "gap" / "challenge" / "reflect")
-> rc_hypothesis(action="propose" / "audit_breadth" / "link" / "select_leading" / "rank")
-> rc_audit(action="stage_guidance" / "detect_conflicts")
-> rc_checkpoint(action="create")
-> rc_diagram(action="timeline" / "validate")
-> rc_report(action="preview")rc_propose_hypothesis (or rc_hypothesis(action="propose")) records
mechanism_category, diagnostic_role, reasoning_basis, qualitative certainty,
clinical rationale, alternatives, candidate-specific unknowns, and typed planned
tests. Build the maximum reasonable distinct mechanisms; three diagnoses are a
finalization floor, not the reasoning target or cap. These are explicit agent-authored
records, not a dump of hidden model reasoning.
With the built-in renderer, locale="zh-TW" and audience="clinician" produce
Traditional Chinese discussion with English canonical medical names and an expanded
candidate-level evidence/unknown/test view. Custom templates retain their authored
language; JSON and FHIR data are not translated.
See Agent Integration Guide for payload examples.
RootCause MCP leverages the full spectrum of MCP SDK 2.0 primitives to deliver maximum agent ergonomics:
When using ROOTCAUSE_TOOL_PROFILE=condensed, the advertised surface is consolidated
into 8 polymorphic facade tools, reducing discovery/schema overhead. A few
administrative operations remain discrete-only; the bundled harness lists the exact
mapping and hands the same session to an appropriate profile instead of silently
skipping them:
rc_evidence: Add, get, or verify physical provenance.
rc_hypothesis: Propose candidates, audit framework breadth, link evidence, explicitly select the lead, inspect, or exclude.
rc_thinking: Record clinical rationale, reflect on cognitive bias, identify gaps, or challenge assumptions.
rc_audit: Query multi-loop guidance, audit reasoning completeness, or detect contradictions/omissions.
rc_report: Generate deterministic contract reports or export audit artifacts.
rc_diagram: Render chronological event timelines, audit Mermaid syntax, or export graphs.
rc_checkpoint: Create, list, or restore integrity-checked case state snapshots.
rc_rca: Route session/source review plus traditional Fishbone (6M), 5-Why, and HFACS-MES workflows.
Inspect domain knowledge and case states with 0 tool call overhead:
Static Protocol & Template URIs (19 resources in the 2.0.0a3 snapshot):
clinical://contracts/case-input-manifest: canonical multi-source handoff schema.
clinical://contracts/case-analysis-report: canonical standardized output schema.
clinical://protocols/anesthesia-mm-rca-protocol: 4-Tier backward causal reasoning SOP.
clinical://protocols/clinical-reasoning-sop: Core diagnostic investigation playbook.
clinical://protocols/non-death-adverse-event-protocol: Near-miss and adverse-event barrier-analysis protocol.
clinical://protocols/timeline-patterns: Source-faithful temporal-pattern definitions.
clinical://templates/anesthesia-mm-rca-report-template: Markdown report template.
clinical://templates/clinical-reasoning-report-template: General clinical reasoning report template.
clinical://templates/clinician-ddx-discussion-zh-tw: Clinician-facing Traditional Chinese DDx discussion template.
clinical://templates/near-miss-adverse-event-rca-template: Swiss Cheese & barrier failure template.
clinical://domains/*: 9 non-normative retrospective DDx playbooks:
anaphylaxis-crisis, anesthesia-perioperative-arrest,
delayed-diagnosis-systems, difficult-airway-crisis,
local-anesthetic-toxicity, lvad-mechanical-crisis, pediatric-opioid,
perioperative-shock, and toxicology-sedation.
Dynamic Case Resource Templates (4 in the 2.0.0a3 snapshot):
clinical://sessions/{session_id}/report: Current rendered case report.
clinical://sessions/{session_id}/timeline: Current chronological event timeline.
clinical://sessions/{session_id}/guidance: Live reasoning stage, checklist, and Socratic push questions.
clinical://sessions/{session_id}/conflicts: Live contradiction, paradox, and omission audit.
Launch standardized clinical investigation workflows with one click in Claude Desktop, VS Code, or Cline:
anesthesia_mm_investigation: 4-Tier Backward Anesthesia M&M investigation.
perioperative_crisis_differential: Crisis differential expansion with 5H5T triage.
near_miss_barrier_analysis: Swiss Cheese non-death adverse event barrier RCA.
delayed_diagnosis_investigation: Diagnostic trajectory and cognitive bias investigation.
clinician_ddx_discussion_zh_tw: General clinician-facing Traditional Chinese DDx
discussion with maximum reasonable mechanism breadth, explicit unknowns, source-linked
support/refutation/neutral evidence, discriminating tests, and qualitative certainty.
The server automatically supplies system-level meta-instructions during the MCP handshake, anchoring AI agents to rigorous source grounding, 4-tier backward causal reasoning, disconfirming hypothesis testing, and cognitive bias transparency.
Category | Count | Purpose |
Cognitive transparency | 5 | Explicit rationale, reflection, gaps, assumptions, thinking-chain retrieval |
Evidence & Provenance | 3 | Add, retrieve, and verify structured evidence with raw snippets and SHA-256 hash |
Differential diagnosis | 6 | Propose, audit framework breadth, link evidence, explicitly select the lead, inspect, and exclude hypotheses |
Reasoning chain & guidance | 3 | Retrieve audit action chain, export diagrams, and audit reasoning completion |
Gap Analysis & Conflict Detection | 1 | Detect diagnostic contradictions, paradoxical drug responses, and monitoring omissions |
Case Checkpointing | 3 | Create, restore, and list integrity-checked JSON case snapshots |
CONTRACT report | 1 | Generate preliminary or gated-final JSON, FHIR-compatible, or deterministic Markdown output |
HFACS-MES Taxonomy | 6 | Suggest, confirm, inspect, learn, reload, and map classifications |
Session Management | 5 | Start, append source-review adjudications, retrieve, list, and archive RCA sessions with SQLite persistence |
Fishbone (Ishikawa 6M) | 4 | Initialize, add causes, inspect, and export |
Why Tree (5-Why Analysis) | 6 | Ask why, inspect, cross-link, mark root causes, export, and teach (SQLite-persisted) |
Verification & Diagrams | 3 | Conservative causation audit, Mermaid syntax auditor, and timeline renderer |
Total (Discrete) | 46 | Exposes 46 discrete tools across |
Artifact | Machine-readable output | Diagram output |
Fishbone | JSON | Mermaid 6M Ishikawa layout with spine, causes, and sub-causes |
Why Tree | JSON | Mermaid hierarchy with root causes and cross-causal links |
Reasoning Chain | JSON | Mermaid ordered audit trail with evidence/hypothesis references |
Evidence Graph | CONTRACT JSON | Embedded Mermaid support/contradiction graph |
Event Timeline | JSON | Mermaid |
The repository and CI define these engineering gates:
uv run pytest -W error::ResourceWarning
uv run ruff check .
uv run ruff format --check .
uv run mypy src --ignore-missing-imports
uv run bandit -c pyproject.toml -r src --severity-level low --confidence-level medium
uv run vulture src tests --min-confidence 80
uv export --frozen --no-dev --no-emit-project --no-hashes --quiet --output-file requirements-audit.txt
uvx --from "pip-audit==2.9.0" pip-audit --strict --requirement requirements-audit.txt
uv build
uvx --from "twine==6.2.0" twine check dist/*Use the current CI run and release artifacts as the source of truth for test counts, coverage, security findings, and packaging results. These engineering gates validate software behavior; they do not establish Agent clinical performance or clinical validity.
src/rootcause_mcp/
├── domain/ # Entities, value objects, repository contracts, services
├── application/ # Case aggregate, orchestration, progress guidance
├── infrastructure/ # SQLModel repositories and safe export paths
├── interface/ # MCP tool schemas and handlers
└── server_v2.py # Sole MCP SDK 2.0 entry pointThe design references publicly available clinical-reasoning, RCA, FHIR, provenance, causal-inference, and Agent-evaluation work. The dated research survey states the product boundary; the per-repository reports record what can be learned, how a foundation package should be integrated and cited, and which license or data-use constraints prohibit direct reuse.
Apache License 2.0. See LICENSE.
Add a directed or bidirectional causal relationship between Why nodes. Use this to capture escalation loops, feedback cycles, or mitigation links that are not visible in a simple linear 5-Why chain.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| source_node_id | Yes | The source WhyNode ID | |
| target_node_id | Yes | The target WhyNode ID | |
| relationship | No | Type of causal relationship | feedback |
| strength | No | Relationship strength (0.0-1.0) | |
| bidirectional | No | Whether the influence also goes from target back to source | |
| note | No | Optional explanatory note for this link | |
| evidence | No | Optional evidence supporting the link |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'adds a relationship' without disclosing mutation effects, prerequisites, or error states. Does not explain behavior on duplicate links or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first defines action, second provides context. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and no output schema, the description lacks guidance on parameter selection (e.g., when to use each relationship type) and does not mention return value or validation outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds no extra meaning beyond 'directed or bidirectional' which maps to the bidirectional field. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Add' and resource 'causal relationship between Why nodes'. Distinguishes from linear 5-Why chain, providing specific use cases (escalation loops, feedback cycles, mitigation links).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (non-linear relationships). Implicitly differentiates from rc_add_cause but lacks explicit 'when not to use' or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a cause to a Fishbone category. Each cause can have sub-causes, evidence, and HFACS classification.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| category | Yes | The 6M category for this cause | |
| description | Yes | Description of the cause | |
| sub_causes | No | List of sub-causes (optional) | |
| hfacs_code | No | HFACS classification code (optional) | |
| evidence | No | Supporting evidence (optional) |
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 fails to disclose side effects (e.g., whether it modifies the session state), return behavior, error conditions, or dependencies. The description only repeats information already available in the parameter schema without adding behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the primary action. It is not verbose, and every word serves a purpose. However, it could benefit from a brief structured layout for clarity, such as separating the primary action from optional details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description is too sparse. It omits crucial context such as the need for a prior session, error handling, and the meaning of HFACS classification. A more complete description would explain typical usage and expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, granting a baseline of 3. The description adds minimal meaning beyond the schema: it mentions sub-causes, evidence, and HFACS classification, which are already defined as optional parameters. No constraints or relationships between parameters are explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the resource 'cause to a Fishbone category', distinguishing it from siblings like rc_add_causal_link or rc_init_fishbone. It also lists optional attributes (sub-causes, evidence, HFACS classification), making the tool's function precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this tool versus alternatives (e.g., rc_add_causal_link). No context about prerequisite actions (like initializing a session or fishbone) or typical workflow is provided, leaving the AI agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Archive a completed RCA session. Archived sessions are preserved but marked as inactive.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID to archive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions that archived sessions are preserved but marked inactive, but does not disclose potential side effects, reversibility, permissions required, or impacts on related data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence that front-loads the key information. Every word contributes meaning, and there is no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no output schema, the description is minimally adequate. However, it lacks details about the behavior of archiving (e.g., whether it can be undone, impact on list views, or related links).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'session_id', and the description adds no additional meaning beyond the schema. The baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool archives a completed RCA session, specifying the resource (RCA session) and action (archive). However, it does not differentiate from sibling tools, but since no other archive tool exists, this is acceptable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only implies that the session should be completed before archiving, but does not provide explicit guidance on when to use this tool vs alternatives, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask 'Why?' to drill down into root causes using 5-Why analysis. Creates or extends a WhyChain for the session. Each call goes one level deeper (up to 5 levels). This is the CORE tool for systematic root cause reasoning.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| answer | Yes | The answer to 'Why?'. This becomes the basis for the next question. Example: 'Because the nurse miscalculated the dose' | |
| parent_node_id | No | Optional: ID of parent node to branch from. If not provided, continues from the last node or creates first Why. | |
| evidence | No | Supporting evidence for this answer (optional) | |
| initial_problem | No | The initial problem statement. Required only for the FIRST Why in a chain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the full burden. It discloses the key behavioral aspect: each call goes one level deeper up to 5 levels. It does not describe the output format or what happens after the 5th level, but overall it is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: first states purpose, second explains behavior with constraints, third emphasizes importance. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should hint at the return value. It does not describe what the tool returns after each call. It covers the reasoning flow well but omits output expectations, making it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents each parameter. The description adds value by explaining the role of 'initial_problem' (required only for first Why) and the default behavior of 'parent_node_id', which clarifies usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Ask Why?'), the resource ('drill down into root causes using 5-Why analysis'), and distinguishes from siblings by labelling itself 'the CORE tool for systematic root cause reasoning.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that each call goes one level deeper (up to 5 levels) and that it creates or extends a WhyChain, giving clear context for when to use it. However, it does not explicitly mention when not to use it or compare to alternative tools like rc_add_cause or rc_get_why_tree.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transform a completed Why Tree into a teaching-ready lesson plan. Generates learning objectives, common pitfalls, discussion prompts, and reverse-causality questions for medical learners.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| learner_level | No | Target learner level | medical_student |
| format | No | Output format | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It describes outputs but does not disclose side effects (e.g., whether the tool modifies the session), required permissions, or any limitations. The behavior is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The main purpose is front-loaded, and every sentence adds value by listing outputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 100% schema coverage and no output schema, the description adequately explains the tool's function and outputs. However, it could be more specific about the output format (though format param exists) and does not state dependencies like authentication or session validity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema; the parameters are straightforward, and the description focuses on outputs rather than parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Transform' and the resource 'completed Why Tree into a teaching-ready lesson plan', and lists the generated outputs (learning objectives, pitfalls, etc.). It clearly distinguishes from sibling tools like export functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a Why Tree is completed, but does not explicitly state when to use it versus alternatives like rc_export_why_tree, nor does it provide exclusions or prerequisites beyond the tree being complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm an HFACS classification as correct. This helps the system learn from expert decisions and improve future suggestions. Confirmed classifications are stored as learned rules.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | The original cause description | |
| hfacs_code | Yes | The confirmed HFACS code (e.g., 'UA-S', 'PC-C-PMC', 'EF-RE') | |
| reason | Yes | Brief explanation of why this classification is correct | |
| session_id | No | Optional session ID for tracking | |
| confidence | No | Confidence level (0.0-1.0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that confirmed classifications are stored as learned rules, which is a key behavioral trait (side effect). This helps the agent understand the learning impact. It could mention irreversibility or permission requirements, but the disclosure is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise, front-loaded sentences with no wasted words. Every sentence adds value: action statement, learning purpose, and storage behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description does not explain the return value, but the action is simple. It covers the core purpose and key behavior. It could mention that the tool requires a prior suggestion or that the reason parameter is used for traceability, but it is sufficiently complete for a straightforward confirmation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter already has a description. The tool description adds no additional meaning beyond what the schema provides, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Confirm an HFACS classification as correct' and specifies the resource. It explains the higher-level purpose: helping the system learn and improving future suggestions, distinguishing it from sibling tools like rc_suggest_hfacs and rc_list_learned_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates that this tool should be used when a classification needs to be confirmed and stored as a learned rule. It provides context for learning but does not explicitly state when not to use it or mention alternatives. However, given sibling tools, the usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export Fishbone diagram in various formats. Supports Mermaid, JSON, and Markdown formats.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| format | No | Export format | mermaid |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description only hints at non-destructive behavior (export) but does not disclose details like whether the session must be active, potential side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences, no unnecessary details, and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description is adequate but incomplete: it does not specify the output format or behavior on errors, which would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds context by listing the supported formats, which matches the enum, but does not provide additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports a Fishbone diagram in specific formats (Mermaid, JSON, Markdown), which distinguishes it from sibling tools like rc_get_fishbone (retrieves data) and rc_export_why_tree (exports a different diagram type).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like rc_get_fishbone or rc_export_why_tree. The description lacks context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export Why Tree in various formats. Supports Mermaid (flowchart), JSON, and Markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| format | No | Export format | mermaid |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It states 'Export' but does not specify if the operation is synchronous, generates a file, returns a string, or has any side effects. The behavioral details are minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences covering the essential action and supported formats. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks critical info about the output: does the tool return a downloadable file, a string, or something else? Without an output schema, the description should clarify the nature of the export result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and clearly describes both parameters. The description simply echoes the format options, adding no new semantic depth beyond what the enum already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports a 'Why Tree' and lists the supported formats (Mermaid, JSON, Markdown). It distinguishes from sibling tools like rc_get_why_tree (retrieval) and rc_export_fishbone (different diagram type).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is clear but no explicit guidance on when to use this tool versus alternatives like rc_get_why_tree for retrieval or other export tools. Usage is implied but without conditional or exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get mapping between 6M Fishbone categories and HFACS codes. Shows how Fishbone categories (Personnel, Equipment, Material, Process, Environment, Monitoring) correspond to HFACS levels. Useful for cross-framework analysis and ensuring comprehensive coverage. Also provides Why Tree depth guidance for each category.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional: specific 6M category to retrieve mapping for. If not specified, returns all mappings. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it provides mapping and Why Tree depth guidance, but lacks details on permission requirements, rate limits, or response format. Adds value beyond schema but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with action, no wasted words. Efficiently covers purpose, details, and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema, description adequately explains the type of information returned (mapping and depth guidance). Given low complexity, it is sufficiently complete, though could elaborate on the output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description already explaining the default behavior. Description does not add new information about parameter beyond what schema provides, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves mappings between 6M Fishbone categories and HFACS codes, lists all six categories, and explains it shows correspondence. This distinguishes it from sibling tools like rc_get_fishbone or rc_get_hfacs_framework.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates use for cross-framework analysis and comprehensive coverage, giving clear context. Does not explicitly state when not to use or compare to siblings, but the purpose is sufficiently clear for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the complete Fishbone diagram for a session. Returns all categories and causes in structured format.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only indicates it returns the diagram. It does not disclose whether the operation is read-only, behavior on invalid session IDs, or any side effects. The 'get' prefix implies idempotency but is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose and output. Every word is necessary with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description is minimally adequate. It lacks details on output structure, error handling, and how it differs from similar retrieval tools among 20+ siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter (session_id) with 100% schema coverage. The description adds no additional meaning beyond the schema's 'The session ID' – no format, examples, or constraints. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the complete Fishbone diagram for a session, returning all categories and causes in a structured format. It uses specific verbs and resource naming, and implicitly distinguishes from export or other retrieval tools like rc_get_why_tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as rc_get_session or rc_get_why_tree. The description does not provide any exclusions, prerequisites, or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get HFACS-MES framework structure and category definitions. Use this to understand the classification hierarchy and criteria.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Optional: specific level to retrieve (EF, OI, US, PC, UA). If not specified, returns all levels. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description implies a read operation but does not explicitly state read-only nature, response details, or any constraints beyond parameter behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with purpose, no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one optional parameter and no output schema, the description fully covers purpose and parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds clarity by noting the default behavior when not specified ('returns all levels'), which goes beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves the HFACS-MES framework structure and category definitions, with a specific verb ('Get') and resource. It distinguishes from sibling tools that add causes or links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description suggests using it to understand classification hierarchy but does not explicitly state when to use vs alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of an RCA session by ID. Returns session status, current stage, and progress.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns session status, stage, and progress, but does not disclose whether it is read-only, idempotent, or any potential side effects. Basic behavioral context is present, but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the purpose and output. It is front-loaded with the action and resource, with no redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter, the description adequately covers what it does and what it returns. It does not address error handling or edge cases, but given the low complexity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'session_id' described as 'The session ID to retrieve'. The description adds no additional meaning, constraints, or examples beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves session details by ID and specifies the returned data (status, stage, progress). It distinguishes itself from sibling tools like rc_list_sessions (which lists sessions) and rc_start_session (which creates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives (e.g., after obtaining a session ID from rc_list_sessions). It lacks guidance on prerequisites, exclusions, or context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the complete Why Tree (5-Why analysis chain) for a session. Shows all Why questions and answers in hierarchical format.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It describes a read operation (get, shows) and implies no side effects, but does not explicitly state it is non-destructive or discuss permissions. This is acceptable for a simple retrieval but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core action and output. Every sentence adds value with no redundancy or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, no output schema, and low complexity, the description sufficiently explains what the tool returns. The sibling list adds context, but the description alone is adequate for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'session_id' is already described in the schema with full coverage. The description adds no further meaning about the parameter format or constraints beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the complete Why Tree for a session, specifying the format (5-Why analysis chain, hierarchical). This differentiates it from sibling tools like rc_get_fishbone or rc_export_why_tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like rc_get_fishbone or rc_get_hfacs_framework. The context implies it is for viewing the Why Tree but lacks exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize a Fishbone (Ishikawa) diagram for a session. Creates a 6M structure (Personnel, Equipment, Material, Process, Environment, Monitoring) with the problem statement as the fish head.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID to create fishbone for | |
| problem_statement | Yes | The problem statement (fish head) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavioral traits such as idempotency, side effects on existing fishbone for the same session, or required permissions. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that front-load the core purpose and key structural detail (6M categories). No redundant words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main action and structure created. For a parameter-light, no-output-schema tool, it is mostly complete. However, could mention what happens if a fishbone already exists for the session (overwrite vs error) and return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have descriptions (session_id and problem_statement) that explain their roles. The tool description adds context about the 6M structure but does not enhance parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Initialize' and describes creating a Fishbone diagram with a 6M structure and problem statement as fish head. Distinguishes from siblings like rc_get_fishbone (retrieval) and rc_add_cause (modification).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage (for starting a new fishbone diagram) but no explicit guidance on when to use vs siblings like rc_start_session or rc_get_fishbone. Lacks 'when not to use' or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all learned classification rules. Shows rules that have been confirmed by experts.
| Name | Required | Description | Default |
|---|---|---|---|
| hfacs_code | No | Optional: filter by specific HFACS code | |
| min_confidence | No | Minimum confidence threshold |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that only rules confirmed by experts are returned, which is a key behavioral trait. However, with no annotations, it lacks details on authorization, pagination, or complete behavior. The description adds value beyond annotations but is not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short sentences, front-loading the purpose. Every word earns its place, though a bit more structure (e.g., bullet points) could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and two simple filters, the description is adequate but could mention return format, sorting, or pagination. It provides enough context for a basic list tool but lacks completeness for complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters have descriptions in the schema). The tool description does not add any additional meaning beyond what the schema already provides, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'learned classification rules', adding that these are confirmed by experts. This clearly distinguishes it from sibling tools like rc_reload_rules or rc_suggest_hfacs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing confirmed rules but provides no explicit guidance on when to use this tool versus alternatives such as rc_get_hfacs_framework or rc_get_session. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all RCA sessions with optional filters. Returns summary of all sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by session status | |
| case_type | No | Filter by case type | |
| limit | No | Maximum number of sessions to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Returns summary of all sessions'. It does not disclose behavioral traits such as side effects, authentication needs, or rate limits. For a read-only list tool, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two front-loaded sentences. Every word is necessary and adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of a list tool with optional filters, the description adequately covers the purpose and return type. However, with no output schema, it could briefly mention that it returns a summary (not full details), which it does. Nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions in the input schema. The description only adds 'with optional filters' which adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all RCA sessions with optional filters', providing a specific verb (list) and resource (RCA sessions). It distinguishes itself from siblings like rc_get_session by implying a list versus a single session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing sessions but does not explicitly state when to use it versus alternatives or provide any exclusion criteria. No guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a WhyNode as the identified root cause. This indicates the analysis has reached a fundamental cause that requires action.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| node_id | Yes | The WhyNode ID to mark as root cause | |
| confidence | No | Confidence level (0.0-1.0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only says it 'indicates the analysis has reached a fundamental cause that requires action', but does not disclose what changes occur, e.g., if the node is locked, if effects are reversible, or if confirmation is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, no extraneous words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description is minimally adequate but lacks behavioral and usage context that would fully inform an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add any meaning beyond the schema—it doesn't explain the confidence parameter or how to choose the node_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Mark' and the resource 'WhyNode as the identified root cause', and distinguishes this from sibling tools like rc_add_cause or rc_confirm_classification by specifying the action of marking the root cause.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives, such as rc_confirm_classification or rc_add_cause. It does not specify prerequisites or situations where marking a root cause is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reload classification rules from YAML files. Use this after manually editing config files.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavior. It states the action (reload from YAML) but does not mention potential side effects (e.g., overwriting existing rules, validation errors). The description is adequate but lacks depth about what happens during reload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with no unnecessary words. It is front-loaded with the core purpose and provides usage context, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description covers the essential purpose and usage. It could mention potential outcomes (e.g., success messages, error handling) but is still reasonably complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage (since none exist). The description does not need to add parameter information. Following the baseline rule for zero parameters, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reload') and the resource ('classification rules from YAML files'), distinguishing it from sibling tools that add, confirm, or export classifications. It uses a specific verb and resource, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'after manually editing config files.' This provides clear context for usage, though it does not mention when not to use it or list alternatives. The guidance is sufficient for this simple action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a new RCA analysis session. Creates a new session with the specified case type and title. Returns session_id for subsequent operations.
| Name | Required | Description | Default |
|---|---|---|---|
| case_type | Yes | Type of case being analyzed | |
| case_title | Yes | Brief title for the case | |
| initial_description | No | Initial description of the incident |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose side effects and behaviors. It only states 'creates a new session' without mentioning auth requirements, potential conflicts, or whether the session is persisted. Minimal transparency for a creation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Could be slightly improved with structured format (e.g., listing return value separately), but overall concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains return value despite no output schema, but missing details on error cases, validation rules for case_type enum, and what happens if required fields are missing. Adequate but not complete for a tool with 3 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by mentioning return of session_id, but does not elaborate on parameter meaning beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it starts a new RCA analysis session with specified case type and title, and returns session_id. This is specific and distinguishes from sibling tools like rc_list_sessions or rc_get_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage as the initial step for RCA analysis, but no explicit guidance on when to use versus alternatives like rc_list_sessions or rc_archive_session. No exclusion criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest HFACS-MES classification codes for a cause description. Returns ranked suggestions with confidence scores. HFACS-MES has 5 levels: External Factors, Organizational Influences, Unsafe Supervision, Preconditions, Unsafe Acts.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | The cause description text to classify | |
| domain | No | Optional domain context for better suggestions (e.g., 'anesthesia', 'surgery', 'nursing') | |
| max_suggestions | No | Maximum number of suggestions to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry full burden. It states the tool returns ranked suggestions with confidence scores and lists HFACS-MES levels, but lacks details on side effects, permissions, or output specifics like the format of suggestions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loading the purpose. It efficiently conveys the key function and context, though it could incorporate usage guidelines without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description provides high-level output info (ranked suggestions with confidence scores) and lists HFACS-MES levels. However, it does not explain confidence scoring or return structure, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptions in the input schema (100% coverage). The tool description does not add extra meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool suggests HFACS-MES classification codes for a cause description and returns ranked suggestions with confidence scores. The description differentiates from sibling tools which involve adding causes, links, sessions, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like rc_confirm_classification or rc_get_hfacs_framework. The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify causal relationship between cause and effect using the Counterfactual Testing Framework. Tests: 1) Temporality - Did cause precede effect? 2) Necessity - Would effect occur without cause? 3) Mechanism - Is there a plausible causal pathway? 4) Sufficiency - Is cause alone sufficient for effect?
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| cause | Yes | The cause event | |
| effect | Yes | The effect event | |
| verification_level | No | 'standard' tests Temporality+Necessity. 'comprehensive' tests all 4 criteria. | standard |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are given, so the description carries full burden. It details the four tests but omits behavioral traits like side effects, idempotency, required permissions, or what happens on invalid input. It partially compensates with internal logic but lacks safety/state context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and uses a clear list format. Every sentence is informative. Loses a point for lacking structured formatting (e.g., line breaks for the list) but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain what the tool returns (e.g., boolean, scores). It also does not describe how session_id is used or caveats about nested objects. Lacks completeness for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description lists the four tests but does not explicitly link them to parameters. The verification_level parameter is already well-described in the schema. The description adds marginal value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Verify' and the resource 'causal relationship', and lists four specific tests. This distinguishes it from sibling tools like rc_add_causal_link or rc_confirm_classification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. Sibling tools exist but no differentiation criteria are provided. The tests imply a verification scenario, but 'when-not' and alternatives are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0rc_add_causal_linkrc_add_causerc_archive_sessionrc_ask_whyrc_build_teaching_caserc_confirm_classificationrc_export_fishbonerc_export_why_treerc_get_6m_hfacs_mappingrc_get_fishbonerc_get_hfacs_frameworkrc_get_sessionrc_get_why_treerc_init_fishbonerc_list_learned_rulesrc_list_sessionsrc_mark_root_causerc_reload_rulesrc_start_sessionrc_suggest_hfacsrc_verify_causationEach tool targets a distinct aspect of RCA (session management, Fishbone, Why Tree, HFACS, verification, teaching cases). No two tools serve the same purpose, and descriptions clearly differentiate them.
All tools follow the rc_verb_noun pattern consistently using snake_case. Verbs like start, get, list, add, ask, export, etc., are predictable and logically applied.
21 tools cover a rich domain comprehensively. While slightly above the ideal range, each tool has a clear role and no redundancy, making the count reasonable for this complex subject.
Covers creation, retrieval, and updates well, but lacks deletion or removal operations for causes, links, or classifications. This can hinder correction of mistakes, leaving notable gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Physician-reviewed medical opinions and prescriptions for AI agents.
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.
Medical RAG: semantic search for clinical guidelines, drug interactions, diagnoses & EHR data.
Medical RAG: semantic search for clinical guidelines, drug interactions, diagnoses & EHR data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/u9401066/rootcause-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server