あらゆるMCP互換AIエージェントのための、医学的推論・鑑別診断・臨床RCAハーネス。
英語 | 繁體中文
RootCause MCP は、Claude Code、Codex、Cline、OpenCode、OpenClaw、Z.ai エージェントなどの汎用エージェントが、専門的なワークフローを実行できるようにします。
ホストエージェントを通じて、匿名化された臨床文書をインベントリ化・抽出します。
正確な生のスニペットを含むソースに基づくエビデンスを登録し、ソースに忠実な時間を保持し、承認されたソース/匿名化/独立性のレビューを追加します。
表現型と時間経過に対して、最大限合理的なメカニズムベースの鑑別診断を構築し、作業仮説を明示的に選択し、ソースにリンクされたエビデンスを、別の検証済み文献記録が定量的な較正を確立している場合にのみ、直接尤度比を使用して関連付けます。
未知のものを推論入力として扱い、各候補の根拠、支持/反駁/中立のエビデンス、判別子、定性的確実性、バイアスを記録します。
診断推論をフィッシュボーン図と5-Whyに接続し、すべての原因に対して承認されたHFACS-MES処分を取得し、保守的な因果関係の証明義務監査を実行します。
明示的なソース系統と決定的な適合結果を持つ、型付きの機械可読レポートを生成します。
エージェントが推論を実行します。MCPサーバーは、隠れたモデル状態や生のプライベートな思考連鎖を検査しません。エージェントが明示的に外部化することを選択した推論に対して、スキーマ、ワークフロー制約、永続化、計算、監査記録を提供します。
臨床医向けの出力では、組み込みのMarkdownレンダラーが繁体字中国語の説明文をサポートしながら、診断名、検査名、薬剤名、デバイス名、手技名は英語で保持します。正確なソース引用、単位、ID、コード、JSON/FHIR値、カスタムテンプレート言語は、機械翻訳されません。
このプロジェクトは医療機器ではなく、自律的に患者を診断または治療してはなりません。臨床使用には、資格のある人間によるレビュー、ローカルガバナンス、プライバシー管理、およびソース文書の独立した検証が必要です。
Related MCP server: SafetyOps MCP Server
決定的な最終レポート境界が実装されています。ネストされたレポートセクションは型付けされ、すべてのレポートには機械可読な conformance_checks[] が含まれ、ソース、DDx、ルート系統、因果関係処分、レビューア、または整合性の失敗に対して安全でない最終化がブロックされます。最終スナップショットには、レビューア、タイムゾーン対応の時刻、再計算可能なSHA-256ハッシュが含まれ、再帰的に変更を拒否します。
DDxの広さは、数から推測されるのではなく、明示的になりました。エージェントは症候群に適したフレームワークを選択し、すべての標準セルをレビューし、PRIMARYの広さ監査を永続化します。REVIEWED_INSUFFICIENT_DATA は未知のものと型付き判別子を保持します。NOT_ASSESSED は最終化をブロックします。監査は文書化されたカバレッジを確立しますが、臨床的正しさは確立しません。
最終適合には、完全な追加専用ソースレビュー台帳も含まれ、最終インベントリ予測、独立性系統、明示的な主要診断選択、ソース較正済みLRリンク、ソース忠実な時間的意味論、原因別HFACSレビュー、ガイダンス/準備状況ファクト、ギャップ数、Why/ルート/因果関係系統を再計算します。日付、範囲、相対、未知の時間は、有効な最終成果物に残ることができますが、黙ってソートしたり、時間性を確立するために使用したりすることはできません。
リリース 2.0.0a3 (2026-08-19) は依然としてエンジニアリングアルファであり、臨床的に検証されたエージェントMVPではありません。公開されている6症例コーパスとランナーはエンジニアリングリファレンスです。正式な結果には、少なくとも3つの実エージェントランタイム×6症例×2回の繰り返し、リポジトリ外部のプライベートケースバンドル、個別に保護されたプライベートホールドアウトゴールド、ファイルシステム分離、信頼できるランタイム/サーバーMCPトレース、およびジョブごとに2人の盲検化された資格のある臨床レビューアと不一致の裁定が必要です。その評価は現在 AGENT_EVAL_NOT_ESTABLISHED です。MVP適合と評価 を参照してください。
汎用エージェントは、すべての文書を読み、1つの長いプロンプトでレポートを書くことができます。そのアプローチは機能しますが、ツールスキーマ、以前の事実、フォーマット、確率計算、グラフ構築、完全性チェック、レポート散文にコンテキストを繰り返し費やします。RootCause MCP は、これらの反復可能な操作を決定的なコードに移し、臨床的判断はエージェントに残します。
作業 | エージェントのみのワークフロー | RootCause MCP の支援 |
ツールコンテキスト | すべてのスキーマをロード |
|
ツール結果 | 重複したテキストとJSONを再読取 | 完全なSDK 2.0 |
定量的エビデンスリンク | 再計算して説明 | ソース較正済み直接LRのみの互換性計算。それ以外は中立的な定性的リンク |
ケースの連続性 | 以前の会話を再注入 | 永続化された集計と再起動時の再水和 |
レポート組み立て | DDx、エビデンス、ギャップ、メトリクス、グラフを書き直す | 決定的な |
品質レビュー | すべてのチェックリスト項目を覚える | 自動構造トレーサビリティ警告 |
トークナイザーに依存しない回帰フィクスチャは、ツールプロファイルスキーマのバイト数、重複テキストフォールバック、決定的レポート生成を比較します。スキーマの変更はこれらの測定値を変更するため、現在のCIアーティファクトを真実のソースとして使用してください。これらのバイトプロキシは、特定のモデルトークナイザーに関する約束ではありません。エージェントは依然として、ソース抽出物を読み、臨床的に妥当な仮説を生成し、防御可能なエビデンス関係を選択し、最終アーティファクトをレビューする必要があります。非中立的なLRには、個別の検証済み LITERATURE 較正記録が必要です。較正されていない事前/事後確率を臨床確率または確実性として提示することはできません。LR=1.0 は中立/定量的に未知を意味し、支持または反駁としてカウントされません。
軽量または高速なモデル（Flash/miniバリアントなど）は、複雑な臨床症例でしばしば苦労します。結論に飛びつき、単一の仮説で停止し（早期閉鎖）、反証テストを無視し、認知的反省をスキップする傾向があります。
RootCause MCP は、アクティブな推論状態機械として機能します。
すべてのコアツール呼び出しは、ケース状態を評価する構造化された guidance ペイロードを返します。
ステージ進行: EVIDENCE_COLLECTION → DIFFERENTIAL_EXPANSION → BAYESIAN_EVALUATION → COGNITIVE_AUDIT → READY_FOR_SYNTHESIS の進行を自動的に追跡します。
準備状況チェックリスト: 検証済みソースコンテンツ、型付き候補ラベル、2つの非 UNKNOWN メカニズムにわたる少なくとも3つの一意の診断、適用可能な見逃してはならない診断、すべてのアクティブな診断のエビデンス/検査処分、主要/見逃してはならない診断の支持と矛盾または型付き除外計画、明示的な不確実性/バイアスレビューが必要です。これらは決定的な最終化フロアであり、臨床的広さのターゲットまたは上限ではありません。
次のプロンプトディレクティブ: 各応答で正確なツール名とソクラテス的 push_questions を含む明示的な next_recommended_actions を提供し、Flashエージェントがケースが完了するまで反復的にループできるようにします。
監査ツール: エージェントまたは外部オーケストレーターは、rc_audit_differential_breadth を呼び出して全セルフレームワークカバレッジを永続化し、rc_audit_reasoning_state を呼び出してレポート生成前に残りの前提条件を検査できます。
データ統合およびETL系統アーキテクチャ（Airbyteのストリーム/ソース検証モデルなど）に触発され、RootCause MCP は、確率的なLLMメモリに依存せずに、決定的で暗号化されたエビデンスグラウンディングを確立します。
逐語スニペットと系統アンカー: エビデンスレコードは、正確な raw_snippet 引用、ファイルパス、行ロケーター、SHA-256ダイジェストをキャプチャします。
決定的な出所検証: ProvenanceVerifier ドメインサービスは、ディスク上の物理的な生ファイル（TXT、CSV、HL7、XML）をスキャンして、LLMを呼び出さずに部分文字列一致と行番号を検証します。
改ざんと幻覚検出: エージェントが引用を発明したり、利用できないソースを参照したり、バイトが固定マニフェストと一致しなくなったソースを提示したりした場合、サーバーはエビデンスを未検証のままにし、監査診断を返します。
追加専用ソースレビュー: 固定マニフェストとダイジェストは決して変更されません。抽出、匿名化、独立/派生系統は、rc_adjudicate_source を介してのみ進行します。すべての最終ソースには、許可リストに登録されたレビューア、時刻、理由、安定した裁定IDが必要です。
クリーンアーキテクチャ境界: RootCause MCP は推論契約と出所チェックに焦点を当てています。生のPDF、DOCX、画像、スキャン、スプレッドシート、EHRエクスポートバッチを解析しません。
ホストエージェントまたは承認された抽出器は、正確なコンテンツ、ソース位置、ハッシュ、単位、否定、時間精度、OCR修正、抽出方法を保持しながら、引用可能なテキスト/セルを生成する必要があります。構造化された原子的所見のみをRootCause MCPに送信し、バイナリまたはアクセスできないソースに対してMCP検証を主張しないでください。
パッケージ化されたYAMLプロトコルとドメインプレイブックは、バージョン管理された非規範的な遡及的DDxリソースであり、バンドルされたエージェントハーネスはエージェントに読むように指示します。Markdownテンプレートは決定的なレンダリング入力です。ランタイム準備状況しきい値とギャップルールは依然としてPythonで実装されています。プロトコルYAMLを編集するだけでは、これらのゲートは変更されません。これらのプレイブックは遡及的メカニズムレビューのみを促します。アクティブケア管理、治療/蘇生手順、患者固有の投与量は提供しません。
設定可能なSOPとドメインプレイブック（config/protocols/、config/domains/）:
anesthesia_mm_rca_protocol.yaml: 4層後方因果フレームワーク（Tier 0 終末リズム → Tier 1 ACLS 5H5T → Tier 2 3ストリームトリガー [患者ベースライン vs 外科的侮辱 vs 麻酔薬理学] → Tier 3 HFACS潜在システムギャップ）。
perioperative_shock.yaml および toxicology_sedation.yaml: 動的左室流出路閉塞（SAM）およびプロポフォール注入症候群（PRIS）を考慮するための非規範的な遡及的DDxプロンプト。アクティブケアプロトコルではありません。
カスタマイズ可能なMarkdownテンプレート（config/templates/）:
anesthesia_mm_rca_report_template.md: 決定的なスロットフィリングを備えた専門部門M&Mカンファレンスレビューフォーマット。
clinical_reasoning_report_template.md: 一般的な臨床推論および患者安全アクションレポート。
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]
依存関係の方向性はDDDに従います:
Interface -> Application -> Domain <- InfrastructureSDK 2.0サーバーは、医療推論アグリゲートをSQLiteに永続化します:
構造化エビデンスとソースメタデータ
鑑別診断仮説とベイズ更新履歴
エージェントが提供する明示的なThinkingStepレコード
オーケストレーターが生成するReasoningStep監査レコード
RCAセッション、ソースマニフェスト、フィッシュボーン図、Whyツリー
認証、保存データの暗号化、テナント分離、レビュアー役割の認可、 データベースマイグレーション、規制対象デプロイメントの制御は、臨床本番利用の前に デプロイメント環境によって提供される必要があります。PHIおよび臨床データポリシーを参照してください。
uvの自動検出、仮想環境の同期、クライアントMCPハーネスの設定（Copilotネイティブ.mcp.json、VS Code .vscode/mcp.json、Claude Desktop、Cline）、および本番stdio診断の実行を単一のコマンドで自動的に行えます:
Windows PowerShell:
powershell -ExecutionPolicy Bypass -File scripts/setup.ps1Linux / macOS / WSL:
chmod +x scripts/setup.sh
./scripts/setup.shMCPコマンドは、サーバーを起動するAgentまたは拡張機能ホスト上で実行されます。VS CodeがWSL、SSH、Dev Container、または別のリモートホストを使用する場合は、そのリモート統合ターミナルで
uvをインストールし、scripts/setup.shを実行してください。ローカルのWindowsでsetup.ps1を実行しても、リモートホストにはuvはインストールされません。セットアップ後はDeveloper: Reload Windowを実行してください。
ユニバーサルPython CLI:
uv run --locked python scripts/install.py --profile all --target all
uv run --locked python scripts/mcp_doctor.py --config all6つのバンドル済み合成シナリオ（SAM、PRIS、輸血による高カリウム血症、 術後PE、LVADサクション、診断遅延）を実行します。このスクリプトは開発者向けの 回帰テスト/デモであり、ネイティブのマニフェスト/ファイナライゼーション受け入れテストや 臨床検証の代替ではありません:
uv run python scripts/run_case_trial.py --case all公開コーパスのドライランはランナー/アーティファクトのメカニズムのみをチェックし、
意図的にAGENT_EVAL_NOT_ESTABLISHEDを返します:
eval_output="$(mktemp -d)"
uv run python scripts/run_agent_eval.py dry-run \
--output-root "$eval_output" \
--repeats 2正式な実行には、リポジトリ外部のプライベートケースと、別途保護されたプライベートゴールドを使用する必要があります。フェイルクローズの事前チェックから開始してください:
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-egress正式な実行の前に評価プロトコルを参照してください。エグレス認可は承認済みの匿名化合成入力にのみ適用され、実際の臨床記録やPHIには決して適用されません。
# Install the locked environment
uv sync --locked --all-extras
# Run the MCP SDK 2.0 stdio server
uv run --locked rootcause-mcpCopilot CLIとAgent Hostは、リポジトリルートの.mcp.jsonを直接読み取ります:
{
"mcpServers": {
"rootcauseMcp": {
"type": "local",
"command": "uv",
"args": ["run", "--locked", "rootcause-mcp"],
"cwd": ".",
"env": {
"ROOTCAUSE_TOOL_PROFILE": "all",
"ROOTCAUSE_RESPONSE_MODE": "compact"
},
"tools": ["*"]
}
}
}VS Codeエディターは.vscode/mcp.jsonを使用し、それをアクティブな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"
}
}
}
}両方のファイルは意図的に同じrootcauseMcpサーバーキーを使用するため、Agent Hostは2つのMCPアイデンティティを作成しません。共有設定はPATH解決されたuv名のみを使用します。C:\...\uv.exe、ROOTCAUSE_DATA_DIR、またはROOTCAUSE_AUTHORIZED_REVIEWERSをコミットしないでください。保護されたランタイム値はホスト環境で提供してください。無関係なMCPサーバーは、個人の実行可能ファイルやデータパスをこのリポジトリにコミットする代わりに、VS Codeのユーザーまたはリモートユーザー設定に配置してください。
spawn ... uv.EXE ENOENTこれは、実行ホストが設定された実行可能ファイルを見つけられないことを意味します。WSL、SSH、またはコンテナのRemote拡張機能ホストでは、一般的な原因はローカルのWindows絶対パスを転送していることです。VS Codeのリモートターミナルで以下を実行してください:
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 allドクターは両方の設定とそのstdioハンドシェイクについてPASSを報告する必要があります。その後、Developer: Reload Windowを実行し、MCP: List ServersからrootcauseMcpを再起動し、ツールカタログの更新後はMCP: Reset Cached Toolsを使用してください。公式のVS Code MCP設定リファレンスとGitHub Copilot CLI MCP設定を参照してください。
環境変数:
変数 | 目的 | デフォルト |
| SQLiteデータベース、チェックポイント、学習済みルール、生成されたエクスポート | OSユーザーデータディレクトリ |
|
| パッケージ化された |
| 正確なプレーンテキスト出所チェックのためのOSパス区切り許可ルート | 現在の作業ディレクトリ |
| 手動検証、ソース/HFACSの裁定、またはファイナライズを許可されるカンマ区切りのオペレーター管理アイデンティティ | 空（手動レビュー/最終承認は無効） |
| ツールカタログ: |
|
|
|
|
互換性のあるエージェントは、個別ツールワークフローまたは超コンパクトな8ファサードワークフローのいずれかを使用できます:
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（またはrc_hypothesis(action="propose")）は、
mechanism_category、diagnostic_role、reasoning_basis、定性的certainty、
臨床的根拠、代替案、候補固有の未知事項、型付き計画テストを記録します。
最大限の合理的な異なるメカニズムを構築してください。3つの診断は
ファイナライゼーションの下限であり、推論の目標や上限ではありません。これらは明示的なエージェント作成レコードであり、
隠れたモデル推論のダンプではありません。
組み込みレンダラーでは、locale="zh-TW"とaudience="clinician"により、
英語の標準医学名と拡張された候補レベルのエビデンス/未知事項/テストビューを備えた繁体字中国語の議論が生成されます。カスタムテンプレートは作成時の言語を保持します。JSONおよびFHIRデータは翻訳されません。
ペイロード例についてはエージェント統合ガイドを参照してください。
RootCause MCPはMCP SDK 2.0プリミティブの全スペクトルを活用して、最大のエージェント操作性を実現します:
ROOTCAUSE_TOOL_PROFILE=condensedを使用する場合、公開されるサーフェスは
8つのポリモーフィックなファサードツールに統合され、ディスカバリー/スキーマのオーバーヘッドが削減されます。いくつかの管理操作は個別専用のままです。バンドルされたハーネスは正確なマッピングをリストし、サイレントにスキップする代わりに適切なプロファイルに同じセッションを渡します:
rc_evidence: 物理的な出所の追加、取得、または検証。
rc_hypothesis: 候補の提案、フレームワークの網羅性の監査、エビデンスのリンク、リードの明示的選択、検査、または除外。
rc_thinking: 臨床的根拠の記録、認知バイアスへの反映、ギャップの特定、または前提への挑戦。
rc_audit: マルチループガイダンスのクエリ、推論の完全性の監査、または矛盾/省略の検出。
rc_report: 決定論的契約レポートの生成または監査アーティファクトのエクスポート。
rc_diagram: 時系列イベントタイムラインのレンダリング、Mermaid構文の監査、またはグラフのエクスポート。
rc_checkpoint: 整合性チェック済みケース状態スナップショットの作成、リスト、または復元。
rc_rca: セッション/ソースレビューのルーティングに加え、従来のフィッシュボーン（6M）、5-Why、HFACS-MESワークフロー。
0ツールコールのオーバーヘッドでドメイン知識とケース状態を検査:
静的プロトコル & テンプレートURI（2.0.0a3スナップショットの19リソース）:
clinical://contracts/case-input-manifest: 標準的なマルチソースハンドオフスキーマ。
clinical://contracts/case-analysis-report: 標準的な出力スキーマ。
clinical://protocols/anesthesia-mm-rca-protocol: 4層後方因果推論SOP。
clinical://protocols/clinical-reasoning-sop: 中核的な診断調査プレイブック。
clinical://protocols/non-death-adverse-event-protocol: ニアミスおよび有害事象バリア分析プロトコル。
clinical://protocols/timeline-patterns: ソース忠実な時間パターン定義。
clinical://templates/anesthesia-mm-rca-report-template: Markdownレポートテンプレート。
clinical://templates/clinical-reasoning-report-template: 一般的な臨床推論レポートテンプレート。
clinical://templates/clinician-ddx-discussion-zh-tw: 臨床医向け繁体字中国語DDx議論テンプレート。
clinical://templates/near-miss-adverse-event-rca-template: スイスチーズ & バリア失敗テンプレート。
clinical://domains/*: 9つの非規範的なレトロスペクティブDDxプレイブック:
anaphylaxis-crisis、anesthesia-perioperative-arrest、
delayed-diagnosis-systems、difficult-airway-crisis、
local-anesthetic-toxicity、lvad-mechanical-crisis、pediatric-opioid、
perioperative-shock、toxicology-sedation。
動的ケースリソーステンプレート（2.0.0a3スナップショットの4つ）:
clinical://sessions/{session_id}/report: 現在のレンダリング済みケースレポート。
clinical://sessions/{session_id}/timeline: 現在の時系列イベントタイムライン。
clinical://sessions/{session_id}/guidance: ライブ推論ステージ、チェックリスト、ソクラテス式プッシュ質問。
clinical://sessions/{session_id}/conflicts: ライブの矛盾、パラドックス、省略監査。
Claude Desktop、VS Code、またはClineでワンクリックで標準化された臨床調査ワークフローを起動:
anesthesia_mm_investigation: 4層後方麻酔M&M調査。
perioperative_crisis_differential: 5H5Tトリアージによる危機的鑑別診断の拡張。
near_miss_barrier_analysis: スイスチーズ非死亡有害事象バリアRCA。
delayed_diagnosis_investigation: 診断軌跡と認知バイアス調査。
clinician_ddx_discussion_zh_tw: 臨床医向けの一般的な繁体字中国語DDx
議論。最大限の合理的なメカニズムの網羅性、明示的な未知事項、ソースリンク付きの
支持/反駁/中立エビデンス、識別テスト、定性的確実性を備えています。
サーバーはMCPハンドシェイク中にシステムレベルのメタ指示を自動的に提供し、AIエージェントを厳密なソース接地、4層後方因果推論、反証仮説テスト、認知バイアスの透明性に固定します。
カテゴリ | 件数 | 目的 |
認知的透明性 | 5 | 明示的な根拠、振り返り、ギャップ、前提条件、思考チェーンの取得 |
エビデンスと来歴 | 3 | 生スニペットとSHA-256ハッシュによる構造化エビデンスの追加、取得、検証 |
鑑別診断 | 6 | 仮説の提案、フレームワークの網羅性の監査、エビデンスのリンク、主仮説の明示的選択、検査、除外 |
推論チェーンとガイダンス | 3 | 監査アクションチェーンの取得、図表のエクスポート、推論完了の監査 |
ギャップ分析と矛盾検出 | 1 | 診断の矛盾、逆説的な薬物反応、モニタリング漏れの検出 |
ケースチェックポイント | 3 | 整合性チェック済みJSONケーススナップショットの作成、復元、一覧表示 |
CONTRACTレポート | 1 | 予備版またはゲート付き最終版のJSON、FHIR互換、または決定論的Markdown出力の生成 |
HFACS-MES分類法 | 6 | 分類の提案、確認、検査、学習、再読み込み、マッピング |
セッション管理 | 5 | SQLite永続化によるRCAセッションの開始、ソースレビュー判定の追加、取得、一覧表示、アーカイブ |
フィッシュボーン（石川6M） | 4 | 初期化、原因の追加、検査、エクスポート |
ホワイツリー（5-Why分析） | 6 | なぜの問いかけ、検査、相互リンク、根本原因のマーク、エクスポート、教育（SQLite永続化） |
検証と図表 | 3 | 保守的な因果関係監査、Mermaid構文監査、タイムライン描画 |
合計（個別） | 46 |
|
成果物 | 機械可読出力 | 図表出力 |
フィッシュボーン | JSON | 背骨、原因、副原因を含むMermaid 6M石川レイアウト |
ホワイツリー | JSON | 根本原因と相互因果リンクを含むMermaid階層 |
推論チェーン | JSON | エビデンス/仮説参照を含むMermaid順序付き監査トレイル |
エビデンスグラフ | CONTRACT JSON | 埋め込みMermaid支持/矛盾グラフ |
イベントタイムライン | JSON | 臨床フェーズとタイムスタンプを含むMermaid |
リポジトリとCIは以下のエンジニアリングゲートを定義しています：
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/*テスト数、カバレッジ、セキュリティ検出結果、パッケージング結果の真実の情報源として、現在のCI実行とリリース成果物を使用してください。これらのエンジニアリングゲートはソフトウェアの動作を検証するものであり、Agentの臨床性能や臨床的妥当性を確立するものではありません。
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 point本設計は、公開されている臨床推論、RCA、FHIR、来歴（provenance）、因果推論、Agent評価に関する研究を参照しています。日付付きの調査レポートは製品の境界を示し、リポジトリ別レポートは、何を学べるか、基盤パッケージをどのように統合・引用すべきか、またどのライセンスまたはデータ利用制約が直接的な再利用を禁止しているかを記録しています。
Apache License 2.0。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