Deep Agentic Core MCP

deep-agentic-core-mcp

Current release: 1.0.0

The local integration candidate adds offline validation for AIOS 0.4/0.6/0.8 draft families, held-byte provenance resolution and native access audit exports. Its coordinated baseline is version 1.0.0 of all seven ecosystem projects. Optional sibling packages retain their own contracts. See support, upgrade and rollback.

uv run python examples/compatibility_check.py

core.compatibility {} reports installed distribution observations; core.verify {} separately probes adapters. Neither certifies a production deployment. Package publication does not deploy the hosted AWS service.

Coordinated 1.0.0 milestone

Version 1.0.0 marks the coordinated DeepAgentLabs milestone on 2026-11-05. Development and roadmap delivery continue after this release. Existing draft and candidate schema markers retain their maturity; package versions do not certify AIOS conformance or production deployment readiness. Independent review, independent implementations, security/deployment acceptance, live-provider validation and the stable contract freeze remain tracked follow-up work. See the ecosystem release policy.

deep-agentic-core-mcp is the shared MCP server layer for the DeepAgentLabs ecosystem. It is designed to expose a single MCP interface that combines:

• agenticlens style workflow inspection, profiling, and analysis
• agentic-chaos style resilience testing and fault-injection workflows
• agentic-sidecar style supervision-readiness and module-surface discovery
• authenticated local Control Tower investigation, read-only fleet posture access and (since 0.5.1) Control Tower 0.9 runbook tools

It sits above the AI Operations Workflow Specification, exposing a unified MCP-native control surface over the shared operational model used by the reference implementations.

The goal is one MCP server, one package, and one registry identity rather than separate MCP servers for each product surface.

Connect and use

Start with the user and developer guide for hosted signup, MCP client connection, workflow analysis, evaluation reports, and local chaos/ Sidecar capabilities. Run the Python workflow example to send an exported workflow to the hosted service. The guide documents current integration availability and distinguishes implemented tools from future runtime work.

Idea

This project is the control plane between LLM hosts and the existing Python libraries:

• agenticlens remains the core profiling and analysis engine
• agentic-chaos remains the core chaos and resilience engine
• agentic-sidecar remains the core decision-supervision and governance engine
• agenticops-control-tower 0.11.0 provides the operator-facing control plane
• the AI Operations Workflow Specification remains the shared data contract
• deep-agentic-core-mcp becomes the MCP-native interface that hosts can call

That means MCP clients can connect once and access observability, chaos, sidecar discovery, and later Control Tower-aligned operations surfaces through one server.

What This Server Should Eventually Do

Planned capability areas:

• profile an agentic workflow and return structured telemetry summaries
• analyze workflow artifacts and surface optimization recommendations
• run controlled chaos experiments against target workflows
• expose installed Sidecar decision/runtime capabilities and module inventory; package readiness is distinct from a live task connection
• eventually expose Control Tower inventory and operator-facing control surfaces once that sibling package ships them
• compare normal versus chaos runs
• expose shared resources such as workflow schemas, run metadata, and saved reports

Design Principles

• One MCP identity: publish a single server to the MCP Registry
• Python-first: package and publish through PyPI
• Thin orchestration layer: reuse agenticlens, agentic-chaos, and agentic-sidecar instead of re-implementing their logic
• Local-first: work well as a stdio MCP server for developer workflows — this matters because chaos.run_experiment executes real code (see SECURITY.md), so this server is meant for trusted, local/stdio use; authenticated HTTP deployments disable code execution
• Dual transport, one tool surface: the optional Streamable HTTP transport (below) reuses stdio tools/resources/prompts, with remote script execution excluded

Agentic Chaos v0.5 compatibility (MCP 0.3.2)

Install agentic-chaos>=0.5.0 alongside the server to discover streaming, authentication, and context-length faults through chaos.list_faults. The existing local stdio chaos.run_experiment tool runs examples/chaos_stream_target.py with faults=["stream_cut"] and returns the native degraded event. Real sibling integration tests cover the catalog and experiment path. Chaos remains optional; no hard sibling dependency is introduced. Hosted HTTP rejects chaos execution.

The example is a repository file, not a wheel-installed asset. Clone the v0.3.2 source into a mcp-server directory and set DEEP_AGENTIC_CORE_MCP_WORKSPACE_ROOT to its parent directory before starting the server. The user guide provides exact setup commands. CI checks both the pinned Chaos v0.5.0 tag and the latest sibling checkout.

See the user guide and the Chaos v0.5 API guide.

Phase 3 completion (MCP 0.3.3)

• Finding provenance (3a): every lens.analyze_workflow recommendation has a provenance block. It names the artifact (workflow_id, canonical sha256 digest), the workflow step (id, name, type, index), the evidence span IDs and the producer. resolved is true only when all of these exist in the artifact you sent, and provenance_summary counts how many do. Needs agenticlens>=0.6.1 for model-swap and chaos-impact findings.
• Chaos results as AIOS runs (3b): chaos.run_experiment attaches aios_run, an AI Operations v0.4-draft Run built by agentic-chaos>=0.5.1's own exporter and checked by the spec adapter (aios_export.aligned). chaos.export_aios_run converts a saved or session report without running any code.
• Script policy (3b): DEEP_AGENTIC_CORE_MCP_ALLOWED_SCRIPT_GLOBS and DEEP_AGENTIC_CORE_MCP_DENIED_SCRIPT_GLOBS narrow which workspace scripts chaos.run_experiment may run. Deny wins, and .venv, site-packages and .git are always denied.
• Version routing and conformance (3c): spec.validate_artifact validates against the schema set the artifact's spec_version names and rejects markers it has no schema for, citing the applicable v0.5 rule (AIOS-0.5-V01…V06). Its conformance section lists every AIOS-0.4-* rule with a status, separate from server presentation. Needs ai-operations-spec>=0.5.1 for the rule and compatibility catalogs.

Run examples/phase3_walkthrough.py from a workspace checkout to see all four end to end.

Since 0.3.4 the hosted service at https://mcp.deepagentlabs.io/mcp ships the same sibling versions and spec catalogs, so provenance, conformance reports and chaos.export_aios_run behave the same hosted as locally. Only chaos.run_experiment stays local-only.

AgenticLens 0.7.0 diagnosis tools (MCP 0.3.5)

• `lens.diagnose_run` — send a trace Run (and optional baseline runs) and get AgenticLens's diagnosis report: failure-taxonomy diagnoses with confidence and supporting spans, the faulty step and agent with ranked candidates, the incident timeline, robust anomalies against the baseline, guardrail status (budget caps spans, depth, and time), and an investigation narrative in Markdown (include_narrative, default true).
• `lens.score_analysis` — send an evaluation report and get deterministic and model-based scores reported separately, judge cost kept apart from agent cost, and the cases where evaluators disagree.

Both need agenticlens>=0.7.0; with an older install they return a clear "unavailable" error and every other Lens tool keeps working. The hosted images pin agenticlens==0.14.0, agentic-evals==0.12.0, agentic-chaos==0.11.0 and agentic-sidecar==0.11.0 (MCP 0.8.0).

AgenticLens 0.8.0 suite tools (MCP 0.3.9)

• `lens.suite_from_traces` — send trace Runs plus a suite name and version and get a draft agentic-evals suite: each successful run becomes a case expecting its tool trajectory and latency/cost within a margin, marked needs_review, with PII masked (mask, strategy). Failed runs come back in skipped with a reason.
• `lens.suite_check` — send a suite and get its summary (splits, domains, tags, sources, review status), exact/near/conflicting duplicates, and the approval checks AgenticLens would run (review, unmasked PII by type and location only, conflicting duplicates), plus approvable.

Both are read-only and store nothing; approving into the immutable suite store stays a local agenticlens suite approve step. Both need agenticlens>=0.8.0; older installs get an "unavailable" error while other Lens tools keep working.

AgenticLens 0.9.0 ModelFit tool (MCP 0.3.11)

• `lens.modelfit_recommend` — send one or more experiment reports (agenticlens experiment run --save), an optional ModelFit config (categories, constraints, weights, candidate catalog, reference variant) and optional variant_metadata (provider, deployment, capabilities per variant), and get a recommendation per task category: status, model, confidence, fallback, per-case savings against the reference, and high-severity risks, plus the full ModelFit report and task-level model matrix.

Constraints fail closed, so a category with no candidate that provably meets its limits comes back as no_feasible_model in unfit_category_ids. Each source's sha256 is the digest of the report's canonical JSON. The tool calls no model and stores nothing. It needs agenticlens>=0.9.0; older installs get an "unavailable" error while other Lens tools keep working.

Unified workflows (MCP 0.4.0)

0.4.0 completes Phase 4 (Unified Workflows): core.compare_runs, core.release_check, core.incident_summary and core.export_report, plus the resource://workflows/release-check resource and a core.release_check prompt. MCP judges nothing itself: comparisons come from AgenticLens, evaluation reports go through the Agentic Evals release gate (every GateConfig threshold, strict by default, unknown keys rejected), and chaos evidence must be a chaos.run_experiment report.

The release check fails closed. Each gate is passed, failed, invalid or missing, and ready is true only when all of them pass; by default the comparison, evaluation and chaos evidence are all required (required_evidence narrows that). Hosted HTTP supports all four tools; pass a locally produced chaos_report because hosted chaos execution stays disabled. The exported report is MCP-local, not an AIOS artifact. No sibling release or dependency floor changes. See the unified workflows guide and examples/unified_release_check.py.

Hosted access control (MCP 0.5.0)

0.5.0 adds per-key tool permissions to hosted HTTP. Each key can carry allow and deny tool globs, an expiry and a task scope. The server enforces them at dispatch, outside the model. Before each handler runs, it re-authenticates the key and reloads its policy, so a revoked, narrowed or expired key is refused for qu