Deep Agentic Core MCP server

deep-agentic-core-mcp

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
• future agenticops-control-tower style operator-facing control-plane access

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.

<!-- mcp-name: io.github.DeepAgentLabs/deep-agentic-core-mcp -->

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 remains the future 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:

is still under construction

• profile an agentic workflow and return structured telemetry summaries
• analyze workflow artifacts and surface optimization recommendations
• run controlled chaos experiments against target workflows
• expose sidecar readiness and scaffold inventory while the upstream runtime

surfaces once that sibling package ships them

• eventually expose Control Tower inventory and operator-facing control

reports

• compare normal versus chaos runs
• expose shared resources such as workflow schemas, run metadata, and saved

Design Principles

agentic-sidecar instead of re-implementing their logic

• 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

this matters because chaos.run_experiment executes real code (see SECURITY.md), so this server is meant for trusted, local/stdio use, not exposure to untrusted clients

• Local-first: work well as a stdio MCP server for developer workflows —

• Expandable: leave room for a later remote deployment mode if needed

MCP Surface (current, 0.2.0 plus unreleased work)

Shortened. The full README is on GitHub.