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 -->

## Connect and use

Start with the [user and developer guide](docs/user-guide.md) for hosted signup,
MCP client connection, workflow analysis, evaluation reports, and local chaos/
Sidecar capabilities. Run [the Python workflow example](examples/hosted_workflow.py)
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` 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:

- 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](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`](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](docs/user-guide.md#chaos-v05-streaming-with-mcp-032)
provides exact setup commands. CI checks both the pinned Chaos `v0.5.0` tag
and the latest sibling checkout.

See [the user guide](docs/user-guide.md#chaos-v05-streaming-with-mcp-032) and
[the Chaos v0.5 API guide](https://github.com/DeepAgentLabs/agentic-chaos/blob/main/docs/v0.5.md).

## MCP Surface (current, `0.3.2`)

- `core.health` — rich diagnostics: adapter availability/version, loaded
  tool/resource/prompt counts, workspace root, recent successful calls
- `core.version` — server package version
- `core.verify` — checks agenticlens/agentic-chaos/agentic-sidecar/ai-operations-spec
  connectivity and reports readiness
- `core.session_state` — inspect what the active session has accumulated
- `lens.analyze_workflow` — run AgenticLens recommendations against a
  workflow artifact
- `lens.report_summary` — render a Markdown workflow report
- `lens.compare_runs` — compare baseline/candidate trace runs for
  regressions
- `lens.slo_summary` — apply release-gate style SLO thresholds to an
  evaluation report
- `lens.audit_report` — case-by-case evaluation detail, optionally with HTML
- `chaos.list_faults` — list the supported fault types
- `chaos.run_experiment` — run a workspace-sandboxed target script under
  selected faults ([executes real code — see `SECURITY.md`](SECURITY.md))
- `sidecar.status` — report installed Sidecar runtime APIs separately from
  live task connectivity (added in `0.3.0`)
- `sidecar.module_inventory` — inspect the installed sidecar
  modules, framework adapters, and integration placeholders (added in `0.3.0`)
- `spec.validate_artifact` — validate a workflow/run artifact against the AI
  Operations v0.4 draft

Sequential tool calls can share context via an optional `session_id`
argument, backed by an in-memory session store — see `ROADMAP.md` Phase 2.

See [ROADMAP.md](ROADMAP.md) for what's shipped per phase and what's still
open, and [docs/tools.md](docs/tools.md) for full input schemas and
per-tool metadata (generated from `tools/registry.py`, run `make docs` to
refresh it after changing that file).

## Local vs. remote install modes

Container definitions are grouped under [deploy/docker](deploy/docker/README.md).

- **Local:** `pip install deep-agentic-core-mcp`, then run
  `deep-agentic-core-mcp` over stdio. Local session behavior is unchanged.
- **Self-hosted multi-user HTTP (`0.3.0`+):** install with
  `pip install 'deep-agentic-core-mcp[http]'`, then run `deep-agentic-core-mcp-http`.
  Provision a unique bearer key per user
  and a Redis URL before startup. Missing configuration prevents startup.
- **Hosted AWS signup:** open [mcp.deepagentlabs.io](https://mcp.deepagentlabs.io)
  to generate a user identity and MCP key; connect your MCP client to
  `https://mcp.deepagentlabs.io/mcp` with its bearer key.
  DynamoDB stores user records and key hashes; keys work immediately and can be
  replaced or revoked through the page. No password or email verification is used.
  Save the key: it cannot be recovered. See [the AWS guide](deploy/aws/README.md).

The HTTP service uses stateless MCP transport at `/mcp` and Redis-backed
workflow sessions scoped to the authenticated user. Users can reuse the same
`session_id` without accessing each other's artifacts. HTTP calls cannot run
`chaos.run_experiment`, even if the local remote-chaos override is set.

See [the remote hosting guide](docs/remote-hosting.md) and `render.yaml` for Render deployment, configuration,
container builds, AWS deployment requirements, client headers, limits, and
credential rotation. `create_app()` also accepts explicit credentials, a
session backend, and allowed hosts/origins for integrations and tests.
`MemorySessionStore` is an explicit development option; the CLI requires Redis.

## Repository Layout

```text
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
│   └── 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_degraded_boot.py
    ├── test_imports.py
    ├── test_registry.py
    ├── test_server.py
    └── test_session.py
```

## MCP-Oriented Structure

This repository should have all of the standard layers we expect for a useful
MCP server:

- `tools/` for callable MCP tools and their registration metadata
- `resources/` for readable assets such as fault catalogs, templates, and
  workflow examples
- `prompts/` for reusable prompt templates exposed through the server
- `schemas/` for typed request and response contracts
- `services/` for shared orchestration logic that keeps tool modules thin,
  including the in-memory session store (`services/session.py`)
- `adapters/` for integration boundaries to `agenticlens`, `agentic-chaos`,
  `agentic-sidecar`, and `ai-operations-spec` — each degrades to
  `"available": false` rather t