How do I use SimArch MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SimArch MCP Server Create a 3-agent org to audit our Q3 pricing and simulate 6 months out" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

SimArch MCP Server

Official

by isiraglobal

Overview Schema Source Related Servers Discussions Admin

Python

Local

SimArch — Simulation Architecture

Autonomous AI Organizations · Persistent Digital Workforce · Decision Intelligence · Time-Compressed World Simulation · Hardwired AI Tool Extension

License Python Version Tests Status MCP Localhost GitHub

Related MCP server: chaos-core-mcp

1. What is SimArch?

Build an organization. Give it a mission. Watch it work.

SimArch (Simulation Architecture) is an open-source platform for orchestrating autonomous AI organizations, operating persistent digital workforces, evaluating decision intelligence graphs, and executing time-compressed discrete-event world simulations.

SimArch is also designed to be hardwired directly as an extension into modern AI tools and agents (Claude Code, Cursor, Windsurf, Antigravity, and autonomous Python swarms).

Why SimArch?

Most multi-agent frameworks treat AI agents as conversational chat partners passing prompts back and forth. When applied to real-world software, research, or enterprise automation, chat-based frameworks suffer from:

No real accountability: Declaring "I have completed the task" in natural language without verifiable artifacts or code checks.
Unconstrained execution: Agents operating with unbounded tool privileges, circular dependencies, and infinite loops.
Lost state upon crash: Ephemeral memory lost whenever a process restarts or an exception occurs.
No strategic foresight: Inability to simulate organizational consequences (burn, churn, customer acquisition, runway) across months or years before executing.
Always-on localhost bloat: Spawning persistent background HTTP servers that occupy ports and consume resources when an agent only needs tool calling.

SimArch solves this by treating AI agents as contract-bound corporate employees:

Workers belong to formal Role Contracts with strict authority scopes, tool permissions, and budget caps.
Work moves through a 10-state persistent task DAG in SQLite with WAL mode, distributed leases, and crash recovery.
Every completed task requires an independent review verdict from an auditor role before unblocking dependent tasks.
Strategic decisions are scored using multi-criteria utility graphs and binary counterfactual flip conditions.
World simulations run discrete-event models advancing months in milliseconds with causal feedback loops.
The entire platform functions as an in-process extension or standard stdio MCP server, with zero open network ports by default.

2. How SimArch Differs from Conventional Agent Frameworks

Capability	Conventional Multi-Agent Frameworks	SimArch Autonomous Organizations
Accountability	Chat messages stating "done"	Verifiable deliverables, code artifacts, and independent auditor review verdicts
Governance	Freeform prompt instructions	Enforceable role contracts, tool whitelists, and runtime privilege escalation guards
Persistence	Ephemeral memory sessions	SQLite WAL store with thread-safe worker leases and automated crash recovery
Coordination	Ad-hoc message flooding	Directed task DAGs, topological unblocking, and cycle prevention
Strategic Decisions	Single-prompt heuristic opinions	Directed decision graphs, multi-criteria utility scoring, and counterfactual flip trees
World Simulation	Wall-clock sleep delays	Discrete-event simulation advancing years in milliseconds with causal feedback loops
Network Footprint	Always-on background web server	Locked & dormant by default; AI agent decides on-demand when to spin it up
AI Tool Integration	Bespoke wrappers or REST calls	Hardwired via Model Context Protocol (MCP stdio) for Claude Code, Cursor, etc.
Inference Cost	Requires expensive external API keys	Zero-cost deterministic local provider for 100% offline development and testing

3. Complete Architecture Overview

SimArch is built as a clean, modular monolith with explicit contracts between subsystems:

graph TD
    User([Human Operator / AI Tool / Agent]) --> Extension[SimArch AI Extension & MCP Stdio Server]
    
    subgraph Organization & Governance
        Extension --> Formation[Workforce Formation Planner]
        Formation --> Org[Organization & Role Contracts]
        Org --> PermEnforcer[Runtime Permission Enforcer]
    end

    subgraph Execution & Persistence
        Extension --> Engine[Task DAG & Workflow Engine]
        Engine --> Scheduler[Persistent Scheduler & Worker Leases]
        Scheduler --> Workers[Accountable Digital Workers]
        Workers --> Review[Independent Review & Audit Engine]
        Review --> Storage[(SQLite WAL Store & Audit Log)]
        PermEnforcer -. "Guards" .-> Workers
    end

    subgraph Intelligence & Simulation
        Extension --> Decision[Decision Intelligence Engine]
        Decision --> Counterfactual[Counterfactual Delta Analysis & Flip Trees]
        Extension --> Simulation[Discrete-Event World Simulation]
        Simulation --> MonteCarlo[Monte Carlo Scenario Projections]
    end

    subgraph Memory & Context Isolation
        Workers --> ScopedMemory[Scoped Memory Engine: Org/Dept/Project/Employee/Task]
        ScopedMemory --> Retrieval[Token-Budget Assembly & Contradiction Guard]
    end

    subgraph OnDemand Interface
        Extension --> LockController[Localhost Lock Controller]
        LockController -. "Unlocked by AI Agent on demand" .-> Dashboard[Operational Web Dashboard: 127.0.0.1:8400]
    end

4. Hardwired AI Extension & Localhost Locking

SimArch is hardwired to act as a native toolset for modern AI coding assistants and autonomous swarms.

4.1 Localhost Locking Policy (The AI Agent Decides)

In automated multi-agent environments, running an always-on background web server listening on localhost (127.0.0.1:8400) creates unnecessary socket overhead, port collisions, and security exposure:

Zero Open Ports by Default: SimArch opens zero network sockets on startup. All operations (organization formation, task DAG execution, deliverable audits, decision scoring, and world simulations) run in-process or over standard I/O (stdio).
On-Demand Activation: If and only if the AI agent determines that a human operator would benefit from visual inspection (e.g. reviewing an interactive organization chart or decision tree), the agent calls:
```
{
  "name": "simarch_toggle_localhost",
  "arguments": { "enable": true, "port": 8400 }
}
```
Controlled Re-Locking: Once visual review is complete or the workflow finishes, the agent invokes simarch_toggle_localhost(enable=false) to terminate the server, release the socket, and lock localhost down again.

4.2 Native Model Context Protocol (MCP) Server

SimArch implements the standard Model Context Protocol (MCP) using standard input/output (stdio). This means AI tools run SimArch as a subprocess without network traffic or API keys.

You can inspect ready-to-copy JSON configuration snippets for your active IDE at any time:

simarch extension-config

4.3 Tool Configuration for Claude Code, Cursor, Windsurf, & Agents

A. Claude Code & Claude Desktop

Add to your claude_desktop_config.json (or pass to Claude Code via mcp.json):

{
  "mcpServers": {
    "simarch": {
      "command": "simarch-mcp",
      "args": []
    }
  }
}

B. Cursor & Windsurf

Create or update .cursor/mcp.json or .mcp.json in your project root (pre-configured in this repository):

{
  "mcpServers": {
    "simarch": {
      "command": "simarch",
      "args": ["mcp"]
    }
  }
}

C. Python Multi-Agent Frameworks (LangChain, CrewAI, AutoGen)

Export tool schemas directly to OpenAI or Anthropic format:

from simarch.extension import SimArchAIExtension

ext = SimArchAIExtension()

# OpenAI function calling format
openai_tools = ext.get_tool_definitions(format="openai")

# Anthropic tool format
anthropic_tools = ext.get_tool_definitions(format="anthropic")

4.4 Complete MCP Tools Reference

The following tools are exposed over MCP stdio and Python:

Tool Name	Parameters	Description
`simarch_toggle_localhost`	`enable: bool`, `port: int`	Controls Localhost: Starts or terminates `127.0.0.1:8400` on-demand when visual inspection is needed.
`simarch_form_organization`	`name: str`, `objective: str`, `scale: str`	Dynamically synthesizes an autonomous AI organization with roles, contracts, authority scopes, and budgets.
`simarch_create_task`	`project_id: str`, `org_id: str`, `assigned_role_id: str`, `objective: str`, `criteria: list`, `depends_on: list`	Adds an accountable task into the project DAG with acceptance criteria and dependencies.
`simarch_submit_deliverable`	`task_id: str`, `summary: str`, `evidence: list`, `artifacts: list`	Submits concrete evidence and advances task to independent auditor review.
`simarch_evaluate_decision`	`project_id: str`, `org_id: str`, `owner_role_id: str`, `objective: str`, `criteria: list`, `alternatives: list`	Computes weighted multi-criteria utility, select winner, outputs rationale, and generates binary flip trees.
`simarch_run_simulation`	`project_id: str`, `duration_days: int`, `marketing_spend: float`, `hiring_rate: float`	Runs discrete-event world simulation with causal feedback loops (cash, burn, churn, CAC, runway).
`simarch_get_project_status`	`project_id: str`	Returns current task DAG topology, unblocking progress, worker leases, and deliverable review states.
`simarch_query_memory`	`scope: str`, `scope_id: str`, `query: str`, `limit: int`	Retrieves context within isolated scopes (Organization, Department, Project, Employee, Task) with contradiction guards.

5. Core Architectural Pillars

5.1 Workforce Formation & Enforceable Role Contracts

SimArch rejects amorphous agent swarms. The WorkforceFormationPlanner analyzes a high-level corporate objective and constructs a formal team structure:

Role Contracts: Every employee has a defined title, authority scopes (e.g. ['technical_implementation'], ['deliverable_review']), and hourly billing budget.
Runtime Privilege Escalation Guard: The PermissionEnforcer validates every action against the assigned role's contract. If a worker attempts to audit their own task or call an unwhitelisted tool, SimArch rejects the action with an immutable audit violation.

5.2 10-State Task Lifecycle & Persistent DAG Execution

Tasks are nodes in a directed acyclic graph (DAG) tracked in SQLite with WAL mode. Every task progresses through 10 distinct states:

[DRAFT] ──> [READY] ──> [ASSIGNED] ──> [RUNNING] ──> [REVIEW] ──> [APPROVED] ──> [COMPLETED]
                ▲                                        │
                │                                        ▼
                └─────────────────────────────── [REVISION_REQUESTED]

[BLOCKED] ──> (Topologically unblocked when parent tasks complete) ──> [READY]
[CANCELLED] (Terminal administrative override)

Topological Unblocking: Tasks with unresolved dependencies remain BLOCKED. As parent tasks achieve COMPLETED, dependent tasks automatically promote to READY.
Worker Leases & Crash Recovery: Workers acquire a 30-second heartbeat lease on a task. If an agent crashes or disconnects, the persistent scheduler detects the expired lease, resets the task to READY, and reassigns it without data loss.

5.3 Independent Deliverable Review & Audit Protocol

A core law of SimArch: A worker cannot approve their own work.

When a specialist submits a deliverable, the task enters REVIEW.
SimArch assigns an independent Auditor Role (Quality & Verification Auditor).
The auditor inspects concrete evidence against acceptance criteria. If criteria are unmet, the auditor issues a REVISION_REQUESTED verdict with actionable feedback, returning the task to the DAG.

5.4 Decision Intelligence & Binary Counterfactual Trees

Strategic choices are not left to conversational guesswork:

Multi-Criteria Utility Scoring: Alternatives are scored across weighted criteria (e.g., Security, Simplicity, Cost, Performance).
Grounded Winning Rationale: The winning alternative is justified by an explicit mathematical breakdown.
Binary Alternative Trees & Flip Conditions: SimArch calculates the exact sensitivity threshold required for the runner-up to beat the winner:
"If Distributed Cluster cost dropped by $15,000.00 or risk decreased from high to low, the decision would flip."
Counterfactual Delta Analysis: Computes cost and risk deltas between chosen options and rejected alternatives.

5.5 Time-Compressed Discrete-Event World Simulation

SimArch decouples simulation time from human wall-clock time. Simulating 365 days of company operations executes in under 20 milliseconds:

Causal Feedback Equations: $$\text{Monthly Burn} = (\text{Team Size} \times \text{Salary}) + \text{Marketing Spend}$$ $$\Delta \text{Customers} = \left(\frac{\text{Marketing Budget}}{\text{CAC}}\right) \times \left(1 + \frac{\text{Product Readiness}}{100}\right) - \text{Churn}$$
Runway & Insolvency Tracking: Automatically computes when cash reaches zero under current burn rates.
Monte Carlo Analysis: Runs hundreds of iterations across parameter distributions to output $P_{10}$, $P_{50}$, and $P_{90}$ projections.

5.6 Scoped Memory Isolation & Contradiction Guard

Memories are partitioned across five strict tiers:

ORGANIZATION: Company bylaws, regulatory guidelines, and global architecture.
DEPARTMENT: Functional procedures (engineering, finance, legal).
PROJECT: Specific milestones, acceptance criteria, and deliverable history.
EMPLOYEE: Private working scratchpads (isolated from peer specialists).
TASK: Ephemeral execution context.

Contradiction Guard: When an agent attempts to record a memory that asserts the opposite of an existing recorded invariant, SimArch flags the contradiction and downweights the assertion during context assembly.

5.7 Controlled Self-Improvement Loop

SimArch learns from execution performance through an 8-stage adaptation lifecycle:

$$\text{OBSERVE} \longrightarrow \text{PROPOSE} \longrightarrow \text{EVALUATE} \longrightarrow \text{APPROVE} \longrightarrow \text{VERSION} \longrightarrow \text{DEPLOY} \longrightarrow \text{MONITOR} \longrightarrow \text{ROLLBACK}$$

Security Invariant: The adaptation engine strictly forbids modifying security rules, authorization checks, budget caps, or core runtime code. Any proposal attempting privilege modification is automatically rejected.

6. Installation & Quickstart

6.1 Installation

Prerequisites

Python 3.10, 3.11, 3.12, or 3.13
SQLite 3.35+ (standard library)

Clone & Install

git clone https://github.com/isiraglobal/SimArch.git
cd SimArch
pip install -e .

6.2 Zero-Cost Smoke Test (100% Offline)

SimArch comes with an offline deterministic local provider that requires zero external API keys or network calls. Run the comprehensive smoke test:

simarch smoke-test

Or execute the standalone Python demonstration:

python3 examples/first_organization.py

6.3 On-Demand Operational Web Dashboard

While localhost is locked by default during automated agent workflows, you can start the operational web dashboard on-demand:

simarch serve --port 8400

Open http://127.0.0.1:8400 to inspect:

Organization Hierarchy: Dynamic role contracts, authority scopes, and budget limits.
Project DAG: Interactive graph showing READY, BLOCKED, RUNNING, and COMPLETED tasks.
Deliverables & Reviews: Auditor feedback, verification evidence, and audit trails.
Decision Intelligence: Utility score rankings and binary comparison trees.
Simulation: 12-month discrete-event cash curves, customer acquisition, and Monte Carlo runs.
Audit Log: Immutable append-only record of all runtime events.

7. Python Agentic SDK Usage

Any Python AI agent, swarm, or script can import and use the extension directly without any network overhead:

from simarch.extension import SimArchAIExtension

# 1. Initialize Extension (Zero open ports, SQLite WAL persistence)
ext = SimArchAIExtension()

# 2. Form Autonomous Organization from Objective
org = ext.form_organization(
    name="Vanguard Intelligence",
    objective="Autonomous security audit and compliance reporting",
    scale="compact"
)
print("Formed Organization:", org["name"], "Roles:", len(org["roles"]))

# 3. Create Strategic Task in DAG
task = ext.create_task(
    project_id="proj_alpha",
    org_id=org["org_id"],
    assigned_role_id=org["roles"][1]["id"],
    objective="Audit authentication gateway for privilege escalation",
    acceptance_criteria=["Zero unauthorized role elevations", "Pass regression suite"]
)
print("Created Task:", task["task_id"], "State:", task["state"])

# 4. Submit Deliverable & Trigger Independent Auditor Review
review = ext.submit_deliverable(
    task_id=task["task_id"],
    summary="Authentication gateway audited. 0 elevations found.",
    evidence=["Regression test suite passed (100%)", "Audit log verified"],
    artifacts=["reports/auth_audit.json"]
)
print("Deliverable Review:", review["review_status"], "-", review["feedback"])

# 5. Multi-Criteria Decision Intelligence
decision = ext.evaluate_decision(
    project_id="proj_alpha",
    org_id=org["org_id"],
    owner_role_id=org["roles"][0]["id"],
    objective="Select encryption protocol",
    criteria=[
        {"name": "Security", "weight": 0.6, "description": "Cryptographic strength"},
        {"name": "Performance", "weight": 0.4, "description": "Throughput"}
    ],
    alternatives=[
        {"name": "ChaCha20-Poly1305", "description": "Fast AEAD", "scores": {"Security": 9.5, "Performance": 9.0}},
        {"name": "AES-256-GCM", "description": "Hardware accelerated", "scores": {"Security": 9.5, "Performance": 8.5}}
    ]
)
print("Winning Choice:", decision["chosen_option"])
print("Rationale:", decision["rationale"])

# 6. Run Time-Compressed World Simulation (365 days)
sim = ext.run_simulation(
    project_id="proj_alpha",
    duration_days=365,
    marketing_spend=12000.0,
    hiring_rate=2.0
)
print("Simulation complete. Final cash:", sim["final_cash"], "Customers:", sim["customer_count"])

# 7. Localhost is locked by default:
status = ext.get_localhost_status()
print("Localhost status:", status)  # {'active': False, 'locked': True}

# If the agent decides human visual review is helpful:
ext.toggle_localhost(enable=True, port=8400)
# ... human reviews at http://127.0.0.1:8400 ...
# Agent locks it back down:
ext.toggle_localhost(enable=False)

8. Real Execution Output (Smoke Test)

Below is the verified output from executing the end-to-end first organization workflow:

════════════════════════════════════════════════════════════════════
       SIMARCH END-TO-END DEMONSTRATION: FIRST ORGANIZATION         
════════════════════════════════════════════════════════════════════

Step 1: Business Objective:
  Research autonomous AI architecture and implement an evidence-backed verification engine.

Step 2: Organization Formed: Nexus Research Labs (org_8946f305fb10)
  • Project Coordinator (coordinator) - Authority: ['*']
  • Lead Research Analyst (specialist) - Authority: ['technical_implementation', 'task_execution']
  • Quality & Verification Auditor (auditor) - Authority: ['deliverable_review', 'compliance_signoff']

Step 3: Strategic Project Initialized: SimArch Genesis (proj_09fdb7fd8c2f)
  • Task 1 created: Design architectural specification and modular component contracts. (READY)
  • Task 2 created: Implement verification state machine and independent review protocol. (BLOCKED - waiting for Task 1)

Step 4: Task 1 Delivered & Audited: APPROVED by Quality & Verification Auditor
  • Task 2 status automatically promoted: READY

Step 5: Decision Intelligence Evaluated:
  • Decision: Select primary runtime persistence engine for digital workforce state.
  • Selected Winner: SQLite with WAL & Thread-Safe Leases
  • Rationale: Alternative 'SQLite with WAL & Thread-Safe Leases' achieved the highest weighted utility score (9.33/10.0). Expected benefit: $9,500.00 at estimated cost: $0.00 with low risk.
  • Binary Comparison vs Runner-up: Distributed Multi-Node Cluster
  • Flip Condition: If Distributed Multi-Node Cluster's cost dropped by $15,000.00 or risk decreased from high to low.
  • Counterfactual Cost Delta: +$15,000.00

Step 6: Discrete-Event Simulation Executed:
  • Simulated 365 Days: Final Cash = $-2,200.00, Customers = 131

Step 7: Verifying Process Restart & Persistent Recovery:
  • Successfully recovered Project: SimArch Genesis (ACTIVE)
  • Task 1 recovered in terminal state: COMPLETED
  • Task 2 recovered in ready state: READY

✓ FIRST ORGANIZATION SMOKE TEST PASSED COMPREHENSIVELY.

9. Command-Line Interface (CLI) Reference

SimArch includes a full-featured Typer CLI for interactive operations and headless automation:

Command	Description	Example
`simarch mcp`	Launch native Model Context Protocol stdio server for AI tools	`simarch mcp`
`simarch extension-config`	Output ready-to-use JSON configs for Claude Desktop, Cursor, etc.	`simarch extension-config`
`simarch dashboard status`	Check if localhost web dashboard is active or locked	`simarch dashboard status`
`simarch dashboard start`	Unlock and spin up the localhost dashboard on-demand	`simarch dashboard start --port 8400`
`simarch dashboard stop`	Shut down dashboard and lock localhost ports	`simarch dashboard stop`
`simarch init`	Initialize database, WAL configuration, and workspaces	`simarch init --path ./.simarch`
`simarch smoke-test`	Run complete end-to-end first organization demonstration	`simarch smoke-test`
`simarch org create`	Dynamically synthesize an organization graph from an objective	`simarch org create --name "Acme AI" --objective "Build APIs"`
`simarch org list`	List all persisted organizations and executive hierarchies	`simarch org list`
`simarch project start`	Launch a new strategic initiative	`simarch project start --org <id> --name "Alpha" --objective "Specs"`
`simarch project status`	Inspect project task DAG, deliverables, and worker lease states	`simarch project status <project-id>`
`simarch project pause`	Pause an active project initiative	`simarch project pause <project-id>`
`simarch project resume`	Resume a paused project initiative	`simarch project resume <project-id>`
`simarch decision inspect`	Inspect multi-criteria evaluation, winning rationale, and binary tree	`simarch decision inspect <decision-id>`
`simarch sim run`	Execute discrete-event simulation with causal feedback loops	`simarch sim run --duration 365 --marketing 10000`
`simarch serve`	Launch web dashboard and REST API directly	`simarch serve --port 8400`

10. Repository Directory Layout

SimArch/
├── src/simarch/
│   ├── api/                 # FastAPI endpoints & Dashboard Server Manager
│   │   ├── app.py           # REST endpoints
│   │   └── server_manager.py# Localhost on-demand lock controller
│   ├── core/                # Configuration & logging
│   │   └── config.py        # Settings (dashboard_locked=True by default)
│   ├── db/                  # SQLite WAL persistence layer
│   │   ├── database.py      # Connection manager & foreign key enforcement
│   │   └── schema.py        # Schema DDL (organizations, roles, tasks, decisions, etc.)
│   ├── decision/            # Decision Intelligence Engine
│   │   ├── counterfactual.py# Counterfactual delta analysis & flip conditions
│   │   ├── graph.py         # Directed decision trees & comparison graphs
│   │   ├── intelligence.py  # Multi-criteria utility scoring
│   │   └── models.py        # Decision data contracts
│   ├── execution/           # Workflow & Execution Engine
│   │   ├── communication.py # Cross-department messaging
│   │   ├── engine.py        # 10-state task DAG & topological unblocking
│   │   ├── review.py        # Independent auditor deliverable verification
│   │   ├── scheduler.py     # Worker leases & crash recovery
│   │   └── smoke_test.py    # Reproducible first organization demonstration
│   ├── extension/           # Hardwired AI Tool Extension
│   │   └── toolkit.py       # SimArchAIExtension: unified in-process AI tools
│   ├── learning/            # Controlled Self-Improvement
│   │   ├── adaptation.py    # Staffing & trend signal evaluations
│   │   └── improvement.py   # 8-stage adaptation loop with security invariants
│   ├── mcp/                 # Native Model Context Protocol (MCP) Server
│   │   └── server.py        # Stdio JSON-RPC 2.0 server implementation
│   ├── memory/              # Scoped Memory & Context Isolation
│   │   ├── retrieval.py     # Relevance scoring & token-budget context assembly
│   │   └── scoped_memory.py # 5-tier isolation & contradiction guard
│   ├── models/              # Model Router & Inference Providers
│   │   ├── providers.py     # DeterministicLocalProvider (offline) & API providers
│   │   ├── registry.py      # Model capability registry
│   │   └── router.py        # Dynamic routing
│   ├── org/                 # Workforce Formation & Role Contracts
│   │   ├── formation.py     # Dynamic team synthesizer
│   │   ├── models.py        # Organization & role contract definitions
│   │   └── permissions.py   # Runtime privilege escalation enforcer
│   ├── simulation/          # Discrete-Event World Simulation
│   │   ├── engine.py        # Discrete-event runner & causal feedback equations
│   │   ├── models.py        # World state vector & events
│   │   └── scenarios.py     # Monte Carlo distributions & parameter perturbations
│   ├── ui/                  # Operational Web Dashboard
│   │   ├── static/          # CSS & JavaScript (dark glassmorphism theme)
│   │   └── templates/       # HTML template
│   ├── workspace/           # Sandboxed Workspace Provisioner
│   │   └── manager.py       # Path traversal checks & sandbox isolation
│   └── cli.py               # Typer CLI entrypoint
├── docs/                    # Architectural specifications & AI extension guides
│   ├── ai_extension_guide.md# Deep dive into AI tool integration
│   └── architecture.md      # Detailed modular monolith design
├── examples/
│   └── first_organization.py# Standalone first organization script
├── tests/                   # 36 comprehensive tests (82% coverage)
├── .cursor/mcp.json         # Pre-configured Cursor MCP tool configuration
├── .mcp.json                # Pre-configured root MCP configuration
├── pyproject.toml           # PEP 621 packaging metadata
├── LICENSE                  # Apache 2.0 License
├── CONTRIBUTING.md          # Community contribution guidelines
├── CODE_OF_CONDUCT.md       # Contributor code of conduct
├── SECURITY.md              # Security & vulnerability reporting policy
└── CITATION.cff             # Academic & industrial citation metadata

11. Configuration & Model Providers

SimArch operates 100% locally with zero external API keys required by default. To connect hosted frontier models, configure optional environment variables:

Variable	Description	Default
`SIMARCH_HOME`	Directory for persistent database and workspaces	`~/.simarch` or `./.simarch`
`SIMARCH_DEFAULT_MODEL`	Default inference model router profile	`deterministic-local`
`SIMARCH_ENABLE_DASHBOARD`	Enable localhost web dashboard on startup	`false` (locked by default)
`OPENAI_API_KEY`	Optional key for GPT-4o / hosted planning	`None` (auto-falls back if unset)
`ANTHROPIC_API_KEY`	Optional key for Claude 3.5 Sonnet	`None` (auto-falls back if unset)
`GEMINI_API_KEY`	Optional key for Gemini 1.5 Pro/Flash	`None` (auto-falls back if unset)

12. Security Architecture & Invariants

SimArch enforces security by construction:

Zero Open Ports by Default: No listening sockets until explicitly unlocked by an authorized AI agent or developer.
Principle of Least Privilege: Roles possess only the tools and decision scopes explicitly granted in their contracts.
Lease Expiration & Crash Recovery: Worker leases automatically expire after 30 seconds, preventing stalled task locks.
Path Traversal Protection: Sandboxed workspaces validate all paths against sandbox root boundaries before reading or writing.
Audit Immutability: All state transitions, deliverable reviews, decisions, and administrative actions append to an indexed, queryable audit log.
Immutable Security Invariant: The self-improvement engine is hardcoded to reject any proposal attempting to alter security boundaries or authorization checks.

13. Current Capabilities & Roadmap

Current Capabilities (v0.1.0 Implemented)

Hardwired AI Extension & Native stdio Model Context Protocol (MCP) server
Dynamic organization synthesis & enforceable role contracts
10-state task DAG lifecycle with topological unblocking
SQLite WAL persistence with worker leases and crash recovery
Independent deliverable review protocol & auditor role enforcement
Multi-criteria decision intelligence, binary trees & counterfactual delta analysis
Discrete-event simulation engine with causal feedback loops & Monte Carlo projections
5-tier scoped memory isolation & contradiction guard
Zero-cost deterministic local model provider for 100% offline runs
On-demand operational web dashboard & Typer CLI
36 verified tests with 82% test coverage

Planned Roadmap

Distributed PostgreSQL storage backend driver
Live streaming telemetry over WebSockets in dashboard
Sandboxed Docker container execution for arbitrary code tasks
Multi-organization federation & inter-company contract negotiations

14. Contributing

We welcome contributions from the community! Please read our Contributing Guide and Code of Conduct before opening a pull request.

To run the test suite locally:

pytest tests -v --cov=simarch

15. License

SimArch is open-source software licensed under the Apache License, Version 2.0.

16. Citation

If you use SimArch in academic or industrial research, please cite:

@software{simarch2026,
  author = {SimArch Contributors},
  title = {SimArch: Simulation Architecture for Autonomous AI Organizations & Persistent Digital Workforce},
  year = {2026},
  url = {https://github.com/isiraglobal/SimArch}
}

Available Tools

6 tools

simarch_create_taskC

Creates an accountable work task within a project DAG with acceptance criteria and dependencies.

Name	Required	Description	Default
`budget`	No
`org_id`	Yes	Organization ID
`priority`	No		normal
`objective`	Yes	Detailed task objective
`project_id`	Yes	Project ID
`dependencies`	No	Prerequisite task IDs
`assigned_role_id`	Yes	Role ID responsible for the task
`acceptance_criteria`	No	Verifiable acceptance criteria

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the task is created within a project DAG and includes acceptance criteria and dependencies, but it does not describe required permissions, side effects, validation behavior, idempotency, or what is returned after creation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no wasted language. It quickly establishes the core action and the task features that matter most.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an eight-parameter mutation tool with no annotations and no output schema, the description is too thin. It does not explain dependency semantics, acceptance criteria format, role assignment, or the effects of creating a task within the DAG.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75%, so most parameters are documented in the schema already. The description mentions acceptance criteria and dependencies, but it does not clarify budget or priority defaults, nor does it add meaningful semantics beyond the schema for the remaining parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: "Creates an accountable work task within a project DAG." It clarifies that acceptance criteria and dependencies are part of the task definition, but it does not explicitly distinguish this tool from siblings such as simarch_submit_deliverable or simarch_run_simulation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not state when this tool should be used versus alternatives, nor does it name any sibling tools or exclusions. Usage is only implied by the verb "Creates," leaving the agent to infer the appropriate context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

simarch_evaluate_decisionC

Scores multi-criteria decision alternatives, chooses the optimal option, and outputs winning rationale with a binary tree.

Name	Required	Description
`org_id`	Yes	Organization ID
`criteria`	Yes
`objective`	Yes	Decision goal
`project_id`	Yes	Project ID
`alternatives`	Yes
`owner_role_id`	Yes	Role ID making the decision

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions scoring, selection, and output of a binary tree, but does not explain whether the decision is persisted, what permissions are required, whether the evaluation is deterministic, or what the binary tree output contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the core actions without any wasted words. It is appropriately sized for a tool summary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with six required parameters, complex nested inputs, no annotations, and no output schema, the description is too sparse. It does not explain the expected structure of criteria and alternatives, the meaning of the binary tree output, or any operational context needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 67%, and the schema documents org_id, objective, project_id, and owner_role_id. The description adds no parameter-level detail beyond implying criteria and alternatives, and it does not clarify the complex nested structures for criteria weights or alternative scores.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs and resources: scores multi-criteria alternatives, chooses the optimal option, and outputs winning rationale with a binary tree. This clearly distinguishes it from the sibling tools, which cover unrelated tasks like forming organizations and running simulations, though it does not explicitly name those siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 versus alternatives, nor any prerequisites or exclusions. It only states what the tool does, leaving the agent to infer that it should be used when evaluating decision alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

simarch_form_organizationB

Synthesizes an autonomous AI organization with roles, contracts, authority, and tool permissions from an objective.

Name	Required	Description	Default
`name`	Yes	Organization name
`scale`	No		auto
`objective`	Yes	High level mission statement

TDQS

B3.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations at all, the description carries the full burden, and it does disclose the artifacts produced (roles, contracts, authority, tool permissions) — useful context the schema does not provide. However, it omits whether the organization is persisted, whether an existing one is overwritten, whether generation is LLM-driven/non-deterministic, and what the response returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence that front-loads the verb and enumerates the outputs. No filler, no repetition of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter generation tool with no annotations and no output schema, the description gives a reasonable picture of what is produced but leaves the return shape, persistence semantics, and the meaning of "scale" unexplained. An agent can call it, but not predict the cost or result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 67% and the uncovered parameter is the important one: "scale" (auto/compact/standard/enterprise) has no description in either the schema or the description text. The description only implicitly evokes "objective" ("from an objective") and says nothing about how name or scale shape the synthesized organization.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ("Synthesizes") and a specific resource ("an autonomous AI organization with roles, contracts, authority, and tool permissions"), plus the input it derives from ("an objective"). The purpose is clearly distinct from siblings like simarch_run_simulation or simarch_evaluate_decision, though the description never names or contrasts them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when this should be invoked versus alternatives such as simarch_run_simulation, nor any prerequisite or exclusion. The reader can infer it is a setup/formation step, but nothing in the text confirms sequencing or conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

simarch_run_simulationC

Runs a discrete-event business simulation over time (months/years) evaluating cash, revenue, CAC, churn, and runway.

Name	Required	Description	Default
`name`	No		Scenario Run
`project_id`	Yes	Project ID
`random_seed`	No
`duration_days`	No
`marketing_budget`	No

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full disclosure burden. It never says whether the run is persisted, whether it is deterministic given random_seed, how expensive/long the computation is, or how errors surface – the key behavioral facts for a simulation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded sentence with zero filler, and the scope/duration framing comes before the metric list. It is efficient, though a flat single sentence gives no structural separation between what it does and what it returns.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With five parameters, no annotations, no output schema, and 80% of parameters undocumented, the description should explain the seed's determinism role, the budget's influence, and whether results are stored. Listing the evaluated metrics partially covers return semantics but leaves the operational picture incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 20% (effectively just 'Project ID'), yet the description mentions no parameters at all. 'months/years' hints at duration_days and the cash/CAC metrics hint at marketing_budget, but random_seed (a determinism control) and name are entirely unaddressed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Runs a discrete-event business simulation') plus the time horizon and the metrics it evaluates, which makes it obviously distinct from any sibling tool. It does not explicitly name a sibling or a boundary case, so it falls just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Use is only implied by the word 'simulation' – there is no statement of when to call this versus alternatives, no prerequisites (e.g., a configured project), and no guidance on when not to use it. An agent must infer the trigger condition entirely.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

simarch_submit_deliverableB

Submits verified findings and evidence for a completed task to initiate independent review.

Name	Required	Description
`summary`	Yes	Summary of work completed
`task_id`	Yes	Task ID
`evidence`	No	Concrete proofs and verification statements
`findings`	No	Structured findings dictionary

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full behavioral burden. It does disclose the meaningful downstream consequence — submission triggers independent review — which is valuable context not in any structured field. But it omits whether submission is final/irreversible, what permissions are needed, or what happens if evidence is rejected, which are significant gaps for a mutation-style tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with the action front-loaded and the consequence trailing; no filler. It could have used one more short clause (e.g., irreversibility) but nothing present is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a nested-object parameter, no annotations, and no output schema, the description is only just adequate. It tells the agent the call starts a review but not what the review produces, whether the submission is final, or how evidence is validated — leaving notable gaps an agent would want filled.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both optional and required parameters are already documented in the schema. The description's mention of 'findings and evidence' loosely maps to two parameters but adds no format, size, or structural detail beyond what the schema provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('submits verified findings and evidence') plus the downstream effect ('to initiate independent review'), so the agent knows exactly what the call does. It does not differentiate from siblings, but the siblings (run_simulation, create_task, toggle_localhost) don't overlap in function, so ambiguity is low.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'for a completed task' implies a precondition (task must be finished and findings verified), which is useful implied guidance. However there is no explicit when-to-use/when-not guidance, no mention of alternatives, and no statement about what to do if review is already underway.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

simarch_toggle_localhostA

Decide whether to unlock and start the local HTTP dashboard server or keep it locked and dormant. Call enable=true only when human visual inspection is needed.

Name	Required	Description	Default
`port`	No	Loopback port
`enable`	Yes	True to start local dashboard on 127.0.0.1, False to stop and lock it

TDQS

A3.8/5.0

Behavior3/5

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 the lock/dormant vs unlocked/running state model and the 127.0.0.1 binding indirectly, but says nothing about what happens to live dashboard state on disable, port-in-use behavior, persistence after the session, or any access-control implication of starting an HTTP server.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, decision stated first, gating condition second. No filler and nothing buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter boolean toggle with a fully documented schema and no output schema, the description covers the decision and the safety-relevant condition. Minor gaps around lifecycle side effects and return/error behavior, but an agent can call it correctly as written.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both `enable` (start/stop) and `port` (loopback port) are already documented. The description adds a usage condition for `enable` but nothing beyond the schema about `port` or defaults, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb+resource: toggling the local HTTP dashboard server between unlocked/running and locked/dormant. The sibling tools are simulation/org/deliverable oriented, so the domain is obviously different, though the description never explicitly differentiates itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Call enable=true only when human visual inspection is needed" gives an explicit gating condition for the on-path, and the opening sentence implies the default is to leave it locked and dormant. No named alternative tool or exclusions beyond that.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.1.0Oct 27, 2026
- First observedsimarch_create_task
- First observedsimarch_evaluate_decision
- First observedsimarch_form_organization
- First observedsimarch_run_simulation
- First observedsimarch_submit_deliverable
- First observedsimarch_toggle_localhost

Deploy Server

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

TDQS

B3.4/5.0

Scored 2026-10-27 20:25 across 6 tools

Disambiguation5/5

Each tool targets a distinct action and resource: forming an organization, running a simulation, toggling the dashboard, creating tasks, submitting deliverables, and evaluating decisions. The only adjacency is create_task/submit_deliverable, but their descriptions clearly separate creation from submission/review initiation.

Naming Consistency5/5

All tools use a consistent simarch_ prefix followed by verb_noun snake_case names. The pattern is predictable throughout with no mixed conventions.

Tool Count5/5

Six tools is a well-scoped surface for an organization simulation server, and each tool maps to a meaningful phase of the workflow. Nothing appears redundant or excessive.

Completeness3/5

Core creation/execution/submission/evaluation operations are present, but the surface lacks read/list/update/delete operations for tasks and organizations, plus explicit retrieval of simulation history or results. The deliverable workflow also initiates review without a clear tool for performing or closing that review.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

mcp
ai.orgsdk
Hosted runtime for persistent agent teams, durable workflows, memory, schedules, and goals.
Agent Orchestration Autonomous Agents Knowledge & Memory
2
https://relay.orgsdk.ai/mcp
Proofable MCP B
io.github.proofable
Context and control for any AI. Agent identity, scoped access, and proof across tools.
Security Agent Orchestration Autonomous Agents
351
https://mcp.proofable.me/mcp
Kujolang.ai MCP
io.github.kujolang
AI-native programming language and toolchain for accountable, verifiable agent-driven development.
Developer Tools Documentation Access Autonomous Agents
1
https://mcp.kujolang.ai/mcp
Finch
io.github.finchagentic
Agentic AI runtime: persistent memory, vault, autonomous agents, deep research, DeFi execution.
Autonomous Agents Knowledge & Memory Blockchain
1
https://mcp.finchagentic.com/mcp

Related MCP Servers

Agentic Control Framework
Autonomous Agents Agent Orchestration Developer Tools
FutureAtoms
A
license
D
quality
D
maintenance
AI-native orchestration layer with 80+ tools for task management, code editing, browser automation, terminal control, and persistent memory across CLI, local MCP, and cloud deployments.
Updated a year ago (2025-09-20 10:26 UTC)
69
9 npm
31
ISC
chaos-core-mcp
Autonomous Agents AI & Machine Learning Knowledge & Memory
chaosbrewing
F
license
A
quality
C
maintenance
Enables AI agents to hand high-level objectives to a decision-making core that autonomously reasons, plans, enforces deterministic policy, executes capabilities, evaluates outcomes, and persists semantic memory over stdio or Streamable HTTP.
Updated 2 months ago (2026-08-23 09:48 UTC)
6
-
AYA MCP
Autonomous Agents Design Tools
sztlink
A
license
Not graded
quality
B
maintenance
Enables creative software agents to operate within bounded, temporary workcells, handling scored objectives through autonomous inspect, execute, capture, and correct loops while producing evidence-backed receipts for human review.
Updated a month ago (2026-09-15 19:45 UTC)
Apache 2.0
context-crystal
Knowledge & Memory Coding Agents Developer Tools
oswaldo
A
license
B
quality
A
maintenance
Sovereign, deterministic, local-first context and DAG lifecycle engine with native stdio MCP server for autonomous AI coding agents.
Updated 15 days ago (2026-10-13 23:46 UTC)
17
MIT

SimArch — Simulation Architecture

Table of Contents

1. What is SimArch?

Why SimArch?

2. How SimArch Differs from Conventional Agent Frameworks

3. Complete Architecture Overview

4. Hardwired AI Extension & Localhost Locking

4.1 Localhost Locking Policy (The AI Agent Decides)

4.2 Native Model Context Protocol (MCP) Server

4.3 Tool Configuration for Claude Code, Cursor, Windsurf, & Agents

A. Claude Code & Claude Desktop

B. Cursor & Windsurf

C. Python Multi-Agent Frameworks (LangChain, CrewAI, AutoGen)

4.4 Complete MCP Tools Reference

5. Core Architectural Pillars

5.1 Workforce Formation & Enforceable Role Contracts

5.2 10-State Task Lifecycle & Persistent DAG Execution

5.3 Independent Deliverable Review & Audit Protocol

5.4 Decision Intelligence & Binary Counterfactual Trees

5.5 Time-Compressed Discrete-Event World Simulation

5.6 Scoped Memory Isolation & Contradiction Guard

5.7 Controlled Self-Improvement Loop

6. Installation & Quickstart

6.1 Installation

Prerequisites

Clone & Install

6.2 Zero-Cost Smoke Test (100% Offline)

6.3 On-Demand Operational Web Dashboard

7. Python Agentic SDK Usage

8. Real Execution Output (Smoke Test)

9. Command-Line Interface (CLI) Reference

10. Repository Directory Layout

11. Configuration & Model Providers

12. Security Architecture & Invariants

13. Current Capabilities & Roadmap

Current Capabilities (v0.1.0 Implemented)

Planned Roadmap

14. Contributing

15. License

16. Citation

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers