Deep Agentic Core MCP

deep-agentic-core-mcp

deep-agentic-core-mcp は、DeepAgentLabs エコシステム共通の MCP サーバーレイヤーです。次の要素を組み合わせた単一の MCP インターフェースを提供するように設計されています。

• agenticlens 形式のワークフローの調査、プロファイリング、分析
• agentic-chaos 形式のレジリエンステストとフォールトインジェクションのワークフロー
• agentic-sidecar 形式の監督準備状況とモジュールサーフェスの検出
• 認証済みのローカル Control Tower 0.7.0 の調査と、フリートの状態への読み取り専用アクセス

このサーバーはAI Operations Workflow Specificationの上位に位置し、リファレンス実装で使用されている共有運用モデルに対して、統一された MCP ネイティブな制御サーフェスを提供します。

目指しているのは、製品ごとに個別の MCP サーバーを用意するのではなく、1 つの MCP サーバー、1 つのパッケージ、1 つのレジストリ ID に集約することです。

接続して使用する

ホスト型サービスへの登録、MCP クライアントの接続、ワークフロー分析、評価レポート、ローカルでのカオス／Sidecar 機能については、ユーザーおよび開発者向けガイドを参照してください。Python ワークフローのサンプルを実行すると、エクスポートしたワークフローをホスト型サービスに送信できます。このガイドでは、現在利用可能な統合機能について説明し、実装済みのツールと今後のランタイム機能を区別しています。

アイデア

このプロジェクトは、LLM ホストと既存の Python ライブラリの間に位置するコントロールプレーンです。

• agenticlens は、中核となるプロファイリングおよび分析エンジンとして機能します
• agentic-chaos は、中核となるカオスおよびレジリエンスエンジンとして機能します
• agentic-sidecar は、中核となる意思決定の監督およびガバナンスエンジンとして機能します
• agenticops-control-tower 0.7.0 は、オペレーター向けのコントロールプレーンを提供します
• AI Operations Workflow Specification は、共有データコントラクトとして機能します
• deep-agentic-core-mcp は、ホストから呼び出せる MCP ネイティブなインターフェースになります

これにより、MCP クライアントは一度接続するだけで、1 つのサーバーを通じて可観測性、カオス、Sidecar の検出機能、および将来的には Control Tower に準拠した運用サーフェスにアクセスできます。

このサーバーが最終的に提供する機能

予定されている機能領域：

• エージェント型ワークフローをプロファイリングし、構造化されたテレメトリーの概要を返す
• ワークフローの成果物を分析し、最適化の推奨事項を提示する
• 対象のワークフローに対して、制御されたカオス実験を実行する
• インストール済みの Sidecar の意思決定／ランタイム機能とモジュールの一覧を公開する。パッケージの準備状況と、実行中のタスクへの接続は別のものです
• 同じパッケージが提供され次第、Control Tower のインベントリーとオペレーター向け制御サーフェスを将来的に公開する
• 通常実行とカオス実行を比較する
• ワークフローのスキーマ、実行メタデータ、保存済みレポートなどの共有リソースを公開する

設計原則

• MCP ID の統一：単一のサーバーを MCP Registry に公開します
• Python を優先：PyPI 経由でパッケージ化して公開します
• 薄いオーケストレーションレイヤー：ロジックを再実装せず、agenticlens、agentic-chaos、agentic-sidecar を再利用します
• ローカル優先：開発ワークフローで stdio MCP サーバーとして快適に動作します。chaos.run_experiment は実際のコードを実行するため（SECURITY.mdを参照）、このサーバーは信頼できるローカル／stdio 環境での使用を想定しています。認証済み HTTP デプロイではコード実行が無効になります
• トランスポートは 2 種類、ツールサーフェスは 1 つ：オプションの Streamable HTTP トランスポート（以下を参照）は stdio のツール／リソース／プロンプトを再利用し、リモートでのスクリプト実行は対象外です

Agentic Chaos v0.5 互換性（MCP 0.3.2）

サーバーと一緒に agentic-chaos>=0.5.0 をインストールすると、chaos.list_faults を通じてストリーミング、認証、コンテキスト長の障害を検出できます。既存のローカル stdio chaos.run_experiment ツールは、 examples/chaos_stream_target.py を faults=["stream_cut"] で実行し、ネイティブの劣化イベントを返します。同じリポジトリ内の実際の統合テストで、カタログと実験パスを確認します。Chaos は引き続きオプションであり、必須の兄弟依存関係は追加されません。ホスト型 HTTP では Chaos の実行が拒否されます。

この例はリポジトリ内のファイルであり、wheel にインストールされるアセットではありません。 v0.3.2 のソースを mcp-server ディレクトリにクローンし、サーバーの起動前に DEEP_AGENTIC_CORE_MCP_WORKSPACE_ROOT をその親ディレクトリに設定してください。 ユーザーガイドに正確なセットアップコマンドが記載されています。CI では、固定された Chaos v0.5.0 タグと最新の兄弟チェックアウトの両方を確認します。

ユーザーガイドと Chaos v0.5 API ガイドをご覧ください。

フェーズ 3 の完了（MCP 0.3.3）

• 検出結果の出所情報（3a）： lens.analyze_workflow の各推奨事項には provenance ブロックがあります。ここには、アーティファクト（workflow_id、正規化された sha256 ダイジェスト）、ワークフローのステップ（id、name、type、index）、 エビデンスのスパン ID、生成元が記載されます。resolved が true になるのは、 これらすべてが送信したアーティファクト内に存在する場合のみです。 provenance_summary では、そのような項目の数を確認できます。 モデルの入れ替えと Chaos の影響に関する検出結果には agenticlens>=0.6.1 が必要です。
• Chaos の結果を AIOS の実行として扱う（3b）： chaos.run_experiment は aios_run を付加します。これは agentic-chaos>=0.5.1 独自のエクスポーターが生成する AI Operations v0.4-draft Run であり、仕様アダプター（aios_export.aligned）で確認されます。 chaos.export_aios_run は、コードを実行せずに保存済みレポートまたはセッションレポートを変換します。
• スクリプトポリシー（3b）： DEEP_AGENTIC_CORE_MCP_ALLOWED_SCRIPT_GLOBS と DEEP_AGENTIC_CORE_MCP_DENIED_SCRIPT_GLOBS によって、chaos.run_experiment が実行できる ワークスペースのスクリプトを絞り込めます。拒否設定が優先され、.venv、site-packages、 .git は常に拒否されます。
• バージョンルーティングと適合性（3c）： spec.validate_artifact は、アーティファクトの spec_version が指定するスキーマセットに対して検証し、対応するスキーマのないマーカーを拒否します。 その際、該当する v0.5 のルール（AIOS-0.5-V01…V06）を示します。 conformance セクションには、すべての AIOS-0.4-* ルールがステータスとともに一覧表示され、 サーバーでの表示とは分けられています。ルールおよび互換性カタログには ai-operations-spec>=0.5.1 が必要です。

ワークスペースのチェックアウトから examples/phase3_walkthrough.py を実行すると、 4 つすべてをエンドツーエンドで確認できます。

0.3.4 以降、ホスト型サービス https://mcp.deepagentlabs.io/mcp では同じ兄弟バージョンと仕様カタログが提供されているため、出所情報、適合性レポート、chaos.export_aios_run はローカルと同じようにホスト環境でも動作します。chaos.run_experiment のみ引き続きローカル限定です。

AgenticLens 0.7.0 の診断ツール（MCP 0.3.5）

• lens.diagnose_run — トレース Run（および任意の baseline 実行）を送信すると、 AgenticLens の診断レポートを取得できます。レポートには、信頼度と根拠となるスパンを含む 障害分類の診断、順位付き候補を含む障害のあるステップとエージェント、インシデントのタイムライン、 ベースラインに対する堅牢な異常、ガードレールのステータス（budget はスパン数、深さ、時間を制限）、 Markdown 形式の調査の概要（include_narrative、デフォルトは true）が含まれます。
• lens.score_analysis — 評価レポートを送信すると、決定論的なスコアとモデルベースのスコアが 分けて報告され、ジャッジのコストはエージェントのコストと区別され、評価者の判定が食い違った事例も 確認できます。

どちらのツールにも agenticlens>=0.7.0 が必要です。古いバージョンがインストールされている場合は、 明確な「利用不可」エラーを返しますが、他の Lens ツールはすべて引き続き動作します。 ホスト型イメージでは agenticlens==0.10.0 と agentic-chaos==0.8.0 が固定されています （MCP 0.3.13 以降）。

AgenticLens 0.8.0 スイートツール（MCP 0.3.9）

• lens.suite_from_traces — トレースの Run とスイートの name および version を送信すると、ドラフトのエージェント評価スイートが返されます。成功した各実行は、 ツールの軌跡と、余裕幅内のレイテンシ／コストを期待値とするケースになり、 needs_review とマークされ、PII はマスクされます（mask、strategy）。失敗した実行は、 理由とともに skipped に含まれます。
• lens.suite_check — スイートを送信すると、概要（分割、ドメイン、 タグ、ソース、レビュー状況）、完全一致／近似一致／競合する重複、および AgenticLens が実行する承認チェック（レビュー、種類と位置のみを示す未マスクの PII、 競合する重複）と、approvable が返されます。

どちらも読み取り専用で、何も保存しません。不変のスイートストアへの承認は、 ローカルでの agenticlens suite approve 手順として行います。どちらも agenticlens>=0.8.0 が必要です。古いインストール環境では「unavailable」エラーが返されますが、 ほかの Lens ツールは引き続き動作します。

AgenticLens 0.9.0 ModelFit ツール（MCP 0.3.11）

• lens.modelfit_recommend — 1 つ以上の実験レポート （agenticlens experiment run --save）、任意の ModelFit config （カテゴリ、制約、重み、候補カタログ、参照バリアント）、および任意の variant_metadata（バリアントごとのプロバイダー、デプロイメント、機能）を送信すると、 タスクカテゴリごとの推奨事項（ステータス、モデル、 信頼度、フォールバック、参照モデルに対するケースごとの削減額、高重大度のリスク）に加え、 ModelFit の完全なレポートとタスクレベルのモデルマトリックスが返されます。

制約はフェイルクローズ方式で評価されるため、制限を確実に満たす候補がないカテゴリは、 unfit_category_ids 内で no_feasible_model として返されます。各ソースの sha256 は、レポートの正規化された JSON のダイジェストです。このツールはモデルを呼び出さず、 何も保存しません。agenticlens>=0.9.0 が必要です。古いインストール環境では 「unavailable」エラーが返されますが、ほかの Lens ツールは引き続き動作します。

統合ワークフロー（MCP 0.4.0）

0.4.0 では、Phase 4（統合ワークフロー）が完了します。対象は core.compare_runs、 core.release_check、core.incident_summary、core.export_report、および resource://workflows/release-check リソースと core.release_check プロンプトです。MCP 自体は何も判定しません。比較は AgenticLens から取得され、 評価レポートは Agentic Evals のリリースゲートを通過します（すべての GateConfig のしきい値を適用し、デフォルトでは厳格に評価し、未知のキーは拒否します）。 また、カオスのエビデンスには chaos.run_experiment のレポートが必要です。

リリースチェックはフェイルクローズ方式で動作します。各ゲートは passed、failed、 invalid、missing のいずれかで、すべてのゲートが通過した場合に限り ready が true になります。 デフォルトでは、比較、評価、カオスのエビデンスがすべて必須です （required_evidence で対象を絞り込めます）。ホスト型 HTTP は 4 つのツールすべてに対応しています。 ホスト型のカオス実行は無効のままのため、ローカルで生成した chaos_report を渡してください。 エクスポートされるレポートは MCP ローカルのものであり、AIOS アーティファクトではありません。 同じリリースに含まれるほかのコンポーネントや依存関係の下限に変更はありません。 統合ワークフローガイドと examples/unified_release_check.pyをご覧ください。

MCP の機能（現行、0.4.0）

• core.health — 詳細な診断情報：アダプターの利用可否／バージョン、読み込まれたツール／リソース／プロンプトの数、ワークスペースのルート、直近の成功した呼び出し
• core.version — サーバーパッケージのバージョン
• core.verify — agenticlens/agentic-chaos/agentic-sidecar/ai-operations-spec への接続を確認し、準備状況を報告します
• core.session_state — アクティブなセッションに蓄積された内容を確認します
• core.compare_runs — リリースチェック用に保存された Lens のベースライン／候補の比較（lens.compare_runs と同じ動作）
• core.release_check — Lens の比較結果、Evals ゲートで評価された Evals レポート、カオスレポートに基づき、フェイルクローズ方式で準備状況を判定します。証拠が欠落している、不正な形式である、または呼び出しに失敗している場合、リリースをブロックします
• core.incident_summary — リグレッション、カオスによるクラッシュ／タイムアウト、失敗したケース、ブロックされたゲートを報告します。失敗がなければ no_signals を返します
• core.export_report — セッションの証拠を、MCP ローカルの単一の mcp.unified-report.v1 エンベロープとして出力します（AIOS アーティファクトではありません）
• lens.analyze_workflow — ワークフローアーティファクトに対して AgenticLens の推奨事項を実行します
• lens.report_summary — Markdown 形式のワークフローレポートを生成します
• lens.compare_runs — ベースライン／候補のトレース実行を比較してリグレッションを検出します
• lens.slo_summary — 評価レポートにリリースゲート形式の SLO しきい値を適用します
• evals.validate_artifact — ネイティブ Evals レポートとゲート判定をオフラインで検証します
• lens.audit_report — ケースごとの評価詳細を表示します。HTML を含めることもできます
• lens.diagnose_run — トレース実行を診断します：問題のあるステップとエージェント、タイムライン、異常、調査の説明（agenticlens>=0.7.0）
• lens.score_analysis — 評価レポートについて、決定論的スコアとモデルベースのスコア、判定コスト、評価者間の不一致を表示します（agenticlens>=0.7.0）
• lens.suite_from_traces — 成功したトレース実行からリグレッションスイートのケースを作成します。PII はマスキングされます（agenticlens>=0.8.0）
• lens.suite_check — スイートの概要、重複、未マスキングの PII、承認準備状況を確認します（agenticlens>=0.8.0）
• lens.modelfit_recommend — 厳格な制約のもと、実験レポートに基づいてタスクカテゴリごとのモデルを推奨します（agenticlens>=0.9.0）
• lens.routing_decide — モデルを呼び出さずに、ModelFit の証拠に基づいて実行時のモデル選択とフォールバックチェーンを説明します（agenticlens>=0.10.0）
• chaos.list_faults — 対応している障害の種類を一覧表示します
• chaos.run_experiment — 選択した障害を適用し、ワークスペースのサンドボックス内でポリシーチェックを通過したターゲットスクリプトを実行して、AIOS 実行エクスポートを添付します（実際のコードを実行します — SECURITY.md を参照）
• chaos.export_aios_run — カオスレポートを、検証済みの AI Operations v0.4-draft 実行アーティファクトに変換します（0.3.3 で追加。コードは実行しません）
• sidecar.status — インストール済み Sidecar ランタイム API を、実行中のタスク接続とは別に報告します（0.3.0 で追加）
• sidecar.module_inventory — インストール済みのサイドカーモジュール、フレームワークアダプター、統合プレースホルダーを確認します（0.3.0 で追加）
• spec.validate_artifact — アーティファクトの spec_version が指定するスキーマセットに照らしてワークフロー／実行アーティファクトを検証し、ルールを引用した適合性レポートを生成します

ツール呼び出しを順次実行する場合、任意の session_id 引数を使用してコンテキストを共有できます。これはインメモリのセッションストアに支えられています。詳しくは ROADMAP.md のフェーズ 2 を参照してください。

各フェーズで提供済みの機能と未対応の項目については ROADMAP.md を、入力スキーマの詳細とツールごとのメタデータについては docs/tools.md を参照してください（tools/registry.py から生成されます。このファイルの変更後に make docs を実行すると更新できます）。

ローカルインストールとリモートインストールのモード

コンテナー定義は deploy/docker にまとめられています。

• ローカル： pip install deep-agentic-core-mcp を実行してから、 deep-agentic-core-mcp を stdio 経由で実行します。ローカルセッションの動作に変更はありません。
• セルフホストのマルチユーザー HTTP（0.3.0 以降）：
  pip install 'deep-agentic-core-mcp[http]' でインストールしてから、deep-agentic-core-mcp-http を実行します。 起動前に、ユーザーごとに固有のベアラーキーと Redis URL を用意してください。設定が不足している場合、起動できません。
• AWS のホステッド登録： mcp.deepagentlabs.io を開いてユーザー ID と MCP キーを生成し、ベアラーキーを使って MCP クライアントを https://mcp.deepagentlabs.io/mcp に接続します。 DynamoDB はユーザーレコードとキーのハッシュを保存します。キーはすぐに使用でき、ページから交換または取り消しができます。パスワードやメールアドレスの確認は使用しません。 キーは復元できないため、必ず保存してください。AWS ガイドを参照してください。

HTTP サービスは /mcp でステートレスな MCP トランスポートを使用し、認証済みユーザーごとにスコープされた Redis ベースのワークフローセッションを使用します。ユーザーは同じ session_id を再利用できますが、互いのアーティファクトにアクセスすることはできません。ローカルの remote-chaos オーバーライドが設定されていても、HTTP 呼び出しで chaos.run_experiment を実行することはできません。

Render のデプロイ、設定、コンテナービルド、AWS のデプロイ要件、クライアントヘッダー、制限、認証情報のローテーションについては、リモートホスティングガイドと render.yaml を参照してください。create_app() は、統合やテスト向けに明示的な認証情報、セッションバックエンド、許可するホスト／オリジンも受け取ります。 MemorySessionStore は明示的に指定する開発用オプションです。CLI では Redis が必要です。

リポジトリの構成

mcp-server/
├── README.md
├── ROADMAP.md
├── pyproject.toml
├── server.json
├── .gitignore
├── docs/
│   ├── architecture.md
│   └── tools.md          # generated - see scripts/generate_tools_doc.py
├── examples/
│   ├── sample_workflow.json
│   ├── provenance_workflow.json
│   ├── phase3_walkthrough.py
│   └── chaos_target.py
├── scripts/
│   └── generate_tools_doc.py
├── src/
│   └── deep_agentic_core_mcp/
│       ├── __init__.py
│       ├── server.py
│       ├── transport_http.py
│       ├── config.py
│       ├── prompts/
│       │   ├── __init__.py
│       │   └── registry.py
│       ├── resources/
│       │   ├── __init__.py
│       │   └── catalog.py
│       ├── schemas/
│       │   ├── __init__.py
│       │   └── tooling.py
│       ├── services/
│       │   ├── __init__.py
│       │   ├── registry.py
│       │   └── session.py
│       ├── adapters/
│       │   ├── __init__.py
│       │   ├── agentic_chaos.py
│       │   ├── agenticlens.py
│       │   ├── agentic_sidecar.py
│       │   └── ai_operations_spec.py
│       └── tools/
│           ├── __init__.py
│           ├── registry.py
│           ├── chaos.py
│           ├── core.py
│           ├── lens.py
│           ├── sidecar.py
│           └── spec.py
└── tests/
    ├── test_chaos_aios_export.py
    ├── test_chaos_script_policy.py
    ├── test_degraded_boot.py
    ├── test_imports.py
    ├── test_lens_provenance.py
    ├── test_spec_conformance.py
    ├── test_registry.py
    ├── test_server.py
    └── test_session.py

MCP を中心とした構成

このリポジトリには、実用的な MCP サーバーに必要な標準レイヤーがすべて含まれている必要があります。

• 呼び出し可能な MCP ツールとその登録メタデータを格納する tools/
• 障害カタログ、テンプレート、ワークフロー例など、読み取り可能なアセットを格納する resources/
• サーバーを通じて公開する再利用可能なプロンプトテンプレートを格納する prompts/
• 型付きのリクエストおよびレスポンスのコントラクトを格納する schemas/
• ツールモジュールを薄く保つための共有オーケストレーションロジックを格納する services/。これにはインメモリセッションストア（services/session.py）が含まれます。
• agenticlens、agentic-chaos、agentic-sidecar、ai-operations-spec との統合境界を担う adapters/。依存先のリポジトリが存在しない場合でも、サーバーの起動時にクラッシュせず、各アダプターは "available": false を返します。

パッケージングと公開のモデル

1つのリポジトリで、ローカルの Python パッケージとホステッド HTTP サービスの両方をサポートします。 stdio のエントリーポイントは、オプションの HTTP 依存関係がなくても引き続き利用できます。 HTTP トランスポートと登録サポートは 0.3.0 から含まれます。それ以前の PyPI リリース 0.2.0 ではローカルの stdio を利用できます。

ワークフロー	トリガー	結果
.github/workflows/ci.yml	プルリクエスト	Python 3.10～3.13 でテストを実行し、配布物をビルドします。AWS のデプロイは行いません
.github/workflows/ci.yml	main へのプッシュ／マージ、または手動実行	テストとパッケージチェックを実行します。AWS のデプロイは行いません
.github/workflows/release-pypi.yml	v* バージョンタグのプッシュ	チェックを実行し、PyPI に公開し、GitHub リリースを作成し、MCP Registry のメタデータを公開した後、PyPI の公開成功後に AWS へデプロイします

main へのプッシュでは、PyPI への公開も AWS へのデプロイも行われません。バージョンタグによるリリースでは、PyPI への公開が成功した後に限り、同じタグ付きソースを AWS にデプロイします。パッケージのリリースには PyPI Trusted Publishing を使用します。 AWS のデプロイには、専用の IAM ユーザーの GitHub シークレットを使用します。リリースについては CONTRIBUTING.md を、デプロイの設定と制限については AWS CI ガイドを参照してください。

PyPI を使った検証では、上記の mcp-name マーカーが server.json の name フィールドと一致している必要があります。

次のステップ

フェーズ 2（セッション管理、詳細な診断、ツールの注釈、プロンプトレジストリ、core.verify）は0.2.0の時点で完了しており、フェーズ 3（3a AgenticLens、3b Agentic Chaos、3c AI Operations Specification、3d Sidecar の検出）は0.3.3の時点で完了しています。未完了の項目は次のとおりです（詳細はROADMAP.mdを参照してください）。

• Sidecar ランタイム制御：より高度な制御機能には、認証済みでタスクにスコープされたランタイムブリッジが必要です
• フェーズ 5（公開と導入） — 公開は自動化済みです。次は、フェーズ 4 から移行したホスト型アクセス制御です。キーごとのツールレベルの権限、ディスパッチ時のアクセス取り消し、認証済みの Tower／Sidecar の停止と取り消し、関連付けられた拒否の証拠、およびホスト型 Tower の認証情報が含まれます
• Control Tower の連携 — Tower 0.7.0 向けのローカルコネクターツールは 0.3.6 で提供されます。ホスト型のユーザーごとの認証情報のバインドは引き続き計画中です
• フェーズ 6 — 運用インテリジェンス機能

開発

一般的なタスクを簡略化するためのMakefileを用意しています。

make install     # install dev dependencies
make check       # run all quality gates (lint + format + typecheck + test)
make test-cov    # tests with coverage report
make docs        # regenerate docs/tools.md from tools/registry.py
make docs-check  # fail if docs/tools.md is out of date
make help        # list all available targets

備考

このスキャフォールドでは、GitHub の名前空間として io.github.deepagentlabs/deep-agentic-core-mcpを想定しています。最終的な公開アカウントまたは組織が変更された場合は、次を更新してください。

• この README のmcp-nameマーカー
• server.json
• pyproject.toml内のリポジトリ URL

運用上の安全性に関するロードマップ

責任範囲と依存関係については、計画中の安全性受け入れ基準を参照してください。これらの追加機能は、エンドツーエンドの封じ込めや完全性保護が実装済みであることを示すものではありません。

Sidecar v0.7 との互換性

Sidecar がインストールされている場合、sidecar.statusは、公開されている意思決定、プラン、ランタイムイベント、監査、ローカルオペレーター API を検出します。runtime_readyは意思決定 API がインストールされていることを意味します。runtime_connected=falseとmcp_runtime_controls=falseは、これらの MCP 検出ツールがアクティブなタスクに接続されていないことを明示します。sidecar.module_inventoryは、プレースホルダーを含むアダプターファイルを一覧表示します。ファイルが存在しても、フレームワークへの対応が保証されるわけではありません。MCP の起動に Sidecar は必要ありません。パッケージが利用できない場合は、利用不可の応答が返されます。

実行中のタスクを制御するには、Sidecar の認証済みローカル OperatorServer／CLI インターフェースを使用してください。詳細については、v0.7.0 ライブ運用ガイドを参照してください。Sidecar v0.7.0 は別途公開されています。このパッチは検出機能を改善しますが、MCP 経由のリモート停止／取り消しを有効にするものではありません。

Sidecar 0.8 との相互運用性

MCP サーバー 0.3.5 は、接続性、検出、トランスポートの所有権を維持します。Sidecar 0.8 では、クライアントアダプターと、サーバー側で強制適用される別プロセスの MCP 2.3.0 ゲートウェイの例が追加されます。これによって、このサーバーでのリモートオペレーターブリッジが有効になることも、公開ツールを通じて共有／排他的な設定が公開されることもありません。

Sidecar 0.8 では、共有／排他的なコンテキストのみ、ガードレールのみ、または両方を組み合わせた設定、ホストコンテキストの明示的な配信、およびガードレールの必須の合成が提供されます。排他的なルールによって共有の制限を弱めることはできません。フレームワーク間のプライバシー、取り消し、委任された権限は v0.9 で検証される予定です。安定したスキーマは v1.0 で提供されます。ネイティブの関連付けられた Lens 読み戻しには Lens 0.7.1 が必要です。兄弟パッケージはすべて任意の依存関係のままです。ランタイム要件がない限り、依存関係の下限は引き上げません。Sidecar 統合契約を参照してください。

Control Tower 0.6.0 コネクター（MCP 0.3.6）

ローカルの stdio では、実際に認証された Tower HTTP API を通じて、インベントリ／ステータス／バージョン／ポスチャー／エビデンス、インシデント、検出、調査、プレビュー、実行、検証を行う 12 個の tower.* ツールを公開します。AGENTICOPS_TOWER_URL（信頼できる HTTP(S) オリジン）、AGENTICOPS_TOWER_READ_TOKEN、および任意で別個の AGENTICOPS_TOWER_WRITE_TOKEN を設定してください。Tower パッケージのインポートは不要です。Tower がなくても、その他のツールはすべて動作します。Tower ツールは、利用不可であることを構造化データで返します。

tower.investigation プロンプトは、ホストモデルに対し、レコード ID とアーティファクト参照を引用し、不確実性や不足しているエビデンスを保持し、サポートされているステージング用ランブックのみを推奨し、Tower の HTTP／CLI を通じた承認は人間に委ねるよう指示します。承認資格情報はツール引数として受け付けられず、承認ツールを通じて公開されることもありません。実行には、Tower におけるプレビュー内容との完全一致を条件とする承認が必要です。モデルプロバイダーは引き続きクライアントが選択でき、いずれも同梱されません。

ユーザーごとの Tower 資格情報のバインドが実現するまで、ホスト型／リモートの MCP では Tower ツールが拒否されます。ローカルトークンをホスト型テナントが借用することはできません。リダイレクトは拒否され、レスポンスは 1 MiB に制限されます。また、分離された HTTP ワーカーによって合計 10 秒のタイムアウトが適用されます。タイムアウトが発生すると、アクションの結果が不明なままになる場合があります。再試行する前に Tower のインシデントを確認してください。URL とトークンは、信頼できるサーバー環境からのみ取得されます。Tower のオプションのコネクター追加機能には MCP >=0.3.6 が必要です。その他のプロデューサーに必要な最低バージョンは変更されません。

セットアップ、JSON リクエスト、解決済みおよびエスカレーション済みのネイティブ Lens/Evals の両方の手順については、Tower のコネクターガイドとインシデントガイドを参照してください。ネイティブプロデューサーの判断を置き換えることなく、高リスクのポスチャーを調べるには、status=unhealthy を指定した tower.agents、明示的な最小値を指定した tower.versions、または source=agentic-sidecar を指定した tower.evidence を使用してください。

ネイティブ Evals コントラクトの検証 — MCP 0.3.8

公開済みの Evals レポートおよびゲートのスキーマ（MCP 0.3.8 では 0.7.2、MCP 0.3.14 以降では 0.9.0）が、ネイティブのコンシューマーパスで適用されるようになりました。検証は同梱の上流コントラクトを使用してオフラインで実行されます。無効なアーティファクトは、フィールドレベルの診断とともに失敗します。ネイティブの判定結果と AIOS への適合性は、引き続き別個のものです。動作、例、移行を参照してください。

Agentic Evals 0.7.2 は、ネイティブレポート（schema_version: "1.0"）とゲート判定の JSON スキーマを公開し、オフラインで使用できる report_schema() および gate_decision_schema() アクセサーを提供します。コントラクト 1.x では追加的な変更が行われます。読み取り側は未知のフィールドを許容する必要があります。MCP spec.validate_artifact は AIOS アーティファクトを検証するものであり、ネイティブ Evals スキーマは検証しません。専用の Evals ツールと AIOS 評価エビデンスのエクスポートは、今後の対応予定です。

コントラクト、例、互換性ポリシーを参照してください。既存の依存関係のバージョン範囲で引き続き十分です。新しいアクセサーを直接使用するには、agentic-evals>=0.7.2 が必要です。このドキュメントの整合性を取るために、関連リポジトリでのパッチリリースは不要です。

AgenticLens 0.8.0 スイート管理

AgenticLens 0.8.0 では v0.6 のマイルストーンを達成しました。agenticlens.suites と agenticlens suite を使って、CSV/JSON のインポート、プロダクショントレース、 ユーザーフィードバックから回帰テストスイートを構築できます。保存前にデフォルトで PII をマスキングし（--no-mask で無効化できます）、重複や競合するラベルを検出し、 合成バリエーションと安定した分割を追加して、レビューを記録します。さらに、スイートを 変更不可能なハッシュ検証済みバージョンとして承認し、CI で検証、エクスポート、評価できます。 スイートは通常の agentic-evals TestSuite ファイルのままです。

MCP 0.3.9 では、読み取り専用で、アーティファクトを入力しアーティファクトを出力する ツールが 2 つ追加されました。 lens.suite_from_traces（成功した実行からケースのドラフトを作成し、デフォルトで PII を マスキングし、スキップした実行とその理由を示します）と、lens.suite_check（概要、 重複、マスキングされていない PII の場所、Lens が実行する承認チェックを表示します）です。 どちらも何も保存しません。承認と変更不可能なストアは、引き続きローカルの CLI/API 操作で 行います。ホストイメージでは agenticlens==0.8.0 を固定しています。

スイート管理ガイドを参照してください。

Evals 0.8.0 CLI 相互運用性

Evals 0.8.0 の CLI JSON レポートとゲート判定は 0.7.2 のワイヤーコントラクトを維持し、 evals.validate_artifact で検証できます。同梱されている上流の 0.7.2 スキーマと固定された コントラクトテスト依存関係は、引き続き互換性のベースラインです。JUnit と Markdown は 表示形式であり、ネイティブのバリデーター入力ではありません。このリリースでは MCP 実行 ツールやランタイム依存関係は追加されません。

CLI の使用方法と互換性を参照してください。

Evals 0.9.0 判定の信頼性（MCP 0.3.14）

MCP 0.3.14 には Evals 0.9.0 のネイティブレポートスキーマとゲートスキーマが同梱されているため、 evals.validate_artifact は、新しいオプションの判定概要、ライブターゲットの概要、および ケースごとの target_status フィールドを検証します。検証は引き続きオフラインで行われ、 構造のみを対象とします。MCP がゲートを再計算したり、利用できない判定を合格として扱ったりする ことはありません。ホストイメージでは agentic-evals==0.9.0 を固定しています。 互換性に関する注記を参照してください。

Chaos 0.7.0 相互運用性

Chaos 0.7.0 では、逐次的な障害カスケード、決定論的な単調ブレークポイント探索、合成応答の汚染 （プロンプト／ツール応答への指示やポリシーバイパスのペイロードを含みます）、明示的な価格に 基づく再試行コストの見積もりが追加されました。ネイティブの子イベント ID と障害タイプは そのまま維持されます。カスケード ID／ステージと、汚染の戦略／ペイロード／シードは、 イベントの詳細情報として追加されます。既存のレポートリーダーと AIOS エクスポートとの 互換性は維持されます。

v0.7 ガイドとオフラインの合成例を参照してください。 この例には、観測された合成ディスパッチと、バイパスされたネガティブコントロールが含まれます。 インジェクションまたはリカバリーだけでは、封じ込めが証明されたことにはなりません。 新しい共有スキーマ、自動アダプター、ホスト型の実行機能、封じ込めの保証は導入されません。

MCP 0.3.10 では、公開イメージが Chaos 0.7.0 に固定されます。既存のレジストリでは poisoned_response が検出されます。信頼されたローカルスクリプトではカスケード／検索 API を 使用できます。新しい MCP ツールは追加されません。ホスト型 HTTP では引き続き chaos.run_experiment が拒否されます。

Control Tower 0.7.0 フリート運用

Tower 0.7.0 では、環境／機能を固定したターゲティング、一括の希望設定、個別の承認、永続化されたターゲットごとの結果、および Python、HTTP、CLI を通じた、制限付きの停止／MCP 権限取り消し確認が追加されます。フリート全体の原子性や自動ロールバックは保証されません。タイムアウトまたは要求済みのコマンドは、ホスト側での照合が必要です。

ローカル MCP 0.3.6 の調査ツールは引き続き互換性があります。Tower 0.7 の一括エンドポイントは Python／HTTP／CLI 専用です。MCP には新たなフリート書き込みツールや承認ツールは追加されず、ホスト型 Tower の制限も引き続き適用されます。

既存のオプション依存関係の範囲で引き続き十分です。兄弟ランタイムやネイティブ証拠スキーマの変更は必要ありません。このドキュメントの整合性調整にパッチリリースは不要です。運用ガイドを参照してください。

運用ワークフローとパッケージの境界については、ローカル Tower 互換性ガイドを参照してください。

AgenticLens 0.9.0 ModelFit

AgenticLens 0.9.0 では v0.7 マイルストーンとして、記録された実験レポートに基づき、タスクカテゴリごとにモデルを推奨する agenticlens.modelfit と agenticlens modelfit を提供します。品質、コスト、レイテンシ、安全性、プロバイダー、デプロイに関する厳格な制約に従い、制約を満たせない場合はフェイルクローズします。また、信頼度、説明、代替案、プロバイダーの多様性を考慮したフォールバック、実験の証拠に基づくコスト削減額、品質リスク、およびタスクレベルのモデルマトリクスも提供します。

MCP 0.3.11 では、提供されたレポートを対象とする読み取り専用の lens.modelfit_recommend ツールが追加され、ホスト型イメージは agenticlens==0.9.0 に固定されます。実験の実行は引き続きローカルの agenticlens experiment run ステップで行います。ModelFit はモデルを推奨しますが、トラフィックのルーティングは行いません。

ModelFit ガイドを参照してください。

AgenticLens 0.10.0 ルーティング（MCP 0.3.12）

lens.routing_decide は、提供された ModelFit の report、request（request_id、category_id）、および任意のルーティング policy に基づいて、ルートの判断理由を説明します。制約、信頼度、優先順位付きターゲット、フォールバックチェーン、ポリシー／レポートのハッシュを返します。enforce を含むすべてのモードで読み取り専用です。モデルの呼び出し、コールバック、人による承認の実行、監査ファイルへの書き込みは行いません。executed は常に false です。ルーティングできない判断は、ネイティブ結果でブロック／エスカレーションされたままになります。古い Lens のインストールでは、このツールのみが明示的な利用不可エラーを返します。

{
  "report": {"...": "supply the complete ModelFit report"},
  "request": {"request_id": "opaque-123", "category_id": "orders"},
  "policy": {"minimum_confidence": "medium"}
}

ホスト型イメージは agenticlens==0.10.0 に固定され、agentic-chaos==0.7.0 は引き続き使用されます。ワークスペースのソースは、兄弟仮想環境内の古いコピーより優先されます。コールバックの実行と監査の境界については、Lens ルーティングガイドを参照してください。サイドカーの権限、Tower の承認、Evals のスコアリング、Chaos のフォールト、AIOS の共有スキーマは、引き続きそれぞれ独立して管理されます。

Chaos 0.8.0 の相互運用性

Chaos 0.8.0 では、次の機能が追加されます。

• 複数ステージのカオスワークフロー：ステップ、定常状態のヘルスチェック、並列ブランチ、再開可能な承認ゲート、再利用可能なテンプレート
• 宣言型の YAML/JSON/TOML 実験。ターゲットを実行しない検証と、cron スケジュールのプレビューに対応
• すべての組み込みフォールトと cascade() での Scope による爆発範囲の制御（ステップ、プロバイダー、除外）。カスタムフォールトでは BaseFault.__init__ の呼び出し、scope の設定、または in_scope() のオーバーライドによって利用できます
• ファンアウトに応じてフォールトの配置に重み付けするトポロジーファザー

ネイティブのイベント ID とフォールトタイプに変更はありません。ワークフローの来歴情報（detail.workflow）と、オプションの ChaosReport.workflow サマリーが追加されます。ワークフローのステップは 1 つのネイティブレポートに統合され、コントラクトと AIOS エクスポートに使用されます。

v0.8 ガイドとオフラインの例をご覧ください。ワークフローのステータス、ヘルスチェック、ファズの結果は、レジリエンスの証拠です。スコア、リリースゲート、封じ込めの証明ではありません。新しい共有スキーマ、自動アダプター、ホスト型の実行機能は導入されません。

MCP 0.3.13 では、公開イメージが Chaos 0.8.0 に固定されています。chaos.export_aios_run は、統合レポートのワークフローサマリーをプロデューサー拡張に含めます。また、既存のレジストリがフォールトを検出します。ワークフロー、実験、ファジングは Python/CLI によるオーケストレーションであり、新しい MCP ツールではありません。ホスト型 HTTP では引き続き chaos.run_experiment が拒否されるため、ホスト型サービスによって実験ターゲットが実行されることはありません。