Analyze an objective and its context BEFORE committing to a plan (the Intent Analyzer stage of the Cognitive Core loop: objective -> context -> AI planning -> policy -> capability execution -> evaluation -> result). Uses whichever AI provider is currently active (see chaoscore_inspect target="providers") to produce structured analysis: key considerations, risks, and a recommended approach.

Does NOT produce an executable plan or take any action — call chaoscore_plan next for that.

Args:

• objective (string): The goal or question to reason about

• context (array): Background info as [{source, content}, ...]. Empty array if none.

• reasoning_effort (optional): Override the active provider's default reasoning effort ('none'|'low'|'medium'|'high'|'xhigh'|'max')

• response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: For JSON format: { "objective": string, "analysis": string, "keyConsiderations": string[], "risks": string[], "recommendedApproach": string, "model": string, "providerId": string }

Examples:

• Use when: "Should I migrate memory storage before or after the staging cutover?" -> reason about tradeoffs first

• Don't use when: You already know the approach and just need an executable plan -> use chaoscore_plan directly

Error Handling:

• Returns "Error: OPENAI_API_KEY is not set" (or the active provider's equivalent) if the provider isn't configured

Produce an ordered, executable plan for an objective, using ONLY capabilities currently in the capability registry (capability discovery). Uses the active AI provider to select capabilities and construct step inputs. This is the Planner stage of the Cognitive Core loop.

The returned plan.id must be passed to chaoscore_execute to run it, and is scoped to your MCP session. Planning does NOT execute anything and is NOT authorization to act — policy checks happen at execution time, per step.

Args:

• objective (string): The goal to produce a plan for

• context (array): Background info as [{source, content}, ...]. Include prior chaoscore_reason output here if you called it first.

• reasoning_effort (optional): Override the active provider's default reasoning effort

• response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: For JSON format: { "id": string, // pass this to chaoscore_execute "objective": string, "steps": [ { "id": string, "description": string, "capability": string, "input": object, "rationale": string } ], "createdAt": string, "model": string, "providerId": string }

Examples:

• Use when: "Draft a summary of these release notes" -> plan with a step using capability "cognition.generate_text"

• Don't use when: You want to actually run the plan -> follow up with chaoscore_execute(plan_id=...)

Error Handling:

• Returns "Error: OPENAI_API_KEY is not set" (or the active provider's equivalent) if the provider isn't configured

• If the model references an unregistered capability name, chaoscore_execute reports that step as failed with an "Unknown capability" error — call chaoscore_inspect(target="capabilities") to see what's available

Run a plan (or inline steps) through the remaining stages of the Cognitive Core loop: policy check -> capability selection -> execution -> evaluation. This is the only tool in this server that can have side effects, and only insofar as the capabilities it invokes do.

Each step is policy-checked individually before it runs (ALLOW / DENY / REQUIRE_APPROVAL — see chaoscore_inspect target="policy"). Steps that are DENY, or REQUIRE_APPROVAL and not yet confirmed, are reported as failed/skipped rather than silently dropped — read each step's error field. Every policy decision and capability call is recorded to the audit trail (chaoscore_inspect target="audit"). This is identical over stdio and over remote HTTP: there is no transport that can reach a capability without passing the policy engine.

Args:

• plan_id (string, optional): id from a prior chaoscore_plan call in this session

• steps (array, optional): inline steps [{description, capability, input, rationale}], alternative to plan_id

• confirmed (boolean): set true to also run steps that resolve to REQUIRE_APPROVAL (default: false)

• dry_run (boolean): if true, validates policy + input schema per step without calling any handler (default: false)

• response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: For JSON format: { "planId": string, "objective": string, "steps": [ { "stepId": string, "capability": string, "success": boolean, "output"?: any, "error"?: string, "policyDecision": { "decision": "allow"|"deny"|"require_approval", "allowed": boolean, "requiresConfirmation": boolean, "reason": string }, "durationMs": number } ], "evaluation": { "success": boolean, "summary": string, "notes": string[] }, "completedAt": string }

Examples:

• Use when: You have a plan_id from chaoscore_plan and are ready to run it -> chaoscore_execute(plan_id="...")

• Use when: A step came back REQUIRE_APPROVAL and you've now confirmed with the user -> re-run with confirmed=true

• Don't use when: You just want to see what a plan would do without side effects -> use dry_run=true

Error Handling:

• Returns "Error: plan_id not found in this session" if the plan wasn't created in the current MCP session

• Individual step failures do NOT throw — they appear in the steps array with success=false

Read-only introspection into Chaos Core's current state: registered capabilities, active policy, registered AI providers (and which one is answering reason/plan calls), the audit trail, memory store stats, and this session's most recent reasoning/plan/execution results. Never modifies anything, and never reveals credentials.

Capabilities, policy, memory, and audit are process-wide — a remote HTTP client and a local stdio client inspecting the same running server see the same values. The last_* targets and 'session' are scoped to your own MCP session.

Args:

• target ('capabilities'|'policy'|'providers'|'memory'|'audit'|'session'|'last_reasoning'|'last_plan'|'last_execution'): what to inspect

• response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: Varies by target. 'capabilities': list of {name, description, risk, inputSummary, readOnly, destructive}. 'policy': the active PolicyConfig. 'providers': list of {id, displayName, configured, active}. 'memory': {recordCount, backend}. 'audit': recent {type, ts, sessionId, planId, stepId, capability, ...}[] entries. 'session': {sessionId, startedAt}. For the last_* targets: the most recent ReasoningResult / Plan / ExecutionTrace produced in this session, or null if none yet.

Examples:

• Use when: "What can this server actually do?" -> target="capabilities"

• Use when: "Which model is actually answering my reason/plan calls right now?" -> target="providers"

• Use when: "Why did that step get blocked?" -> target="policy" or target="audit"

Error Handling:

• Never errors under normal use; unknown target values are rejected by schema validation before this tool runs

Persist a key/value record to Semantic Memory (durable, SQLite-backed), so it can be retrieved later with chaoscore_recall — in this session, in a future session, after a server restart, and from either transport. Writing to an existing key overwrites its value and updates its timestamp, making chaoscore_remember idempotent for a given key/value pair.

Memory is a property of the deployment, not of the connection: a record written over stdio is readable over HTTP and vice versa, provided both point at the same database file.

Args:

• key (string, 1-200 chars): Unique identifier for this memory

• value (string): The content to remember

• tags (array of strings): Optional tags for filtering later (default: [])

• ttl_seconds (number, optional): If set, the record is treated as expired (and excluded from chaoscore_recall) after this many seconds

• response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: For JSON format: { "key": string, "value": string, "tags": string[], "createdAt": string, "updatedAt": string, "expiresAt": string | null }

Examples:

• Use when: "Remember that the staging DB uses the Melbourne region" -> key="staging.region", value="Melbourne (australiaeast)"

• Don't use when: You need to search existing memories -> use chaoscore_recall instead

Error Handling:

• Returns "Error: ..." with the underlying SQLite error message if the write fails (e.g. disk full, path unwritable)

Search Semantic Memory records previously stored with chaoscore_remember. Supports exact key lookup, substring search over keys/values, and tag filtering. Expired records (past their ttl_seconds) are never returned. Reads the same durable store regardless of which transport you connected through.

Args:

• key (string, optional): Exact key to fetch one record directly

• query (string, optional): Substring to match against keys/values

• tags (array of strings): Only return records with ALL of these tags (default: [])

• limit (number, 1-100): Max results (default: 20)

• offset (number): Pagination offset (default: 0)

• response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: For JSON format (key lookup): { "key": string, "value": string, "tags": string[], ... } or null if not found For JSON format (search): { "total": number, "count": number, "offset": number, "records": [...], "has_more": boolean, "next_offset"?: number }

Examples:

• Use when: "What do we know about staging?" -> query="staging"

• Use when: "Get the exact record for key X" -> key="staging.region"

• Don't use when: You want to write/update a memory -> use chaoscore_remember instead

Error Handling:

• Returns "No memory found for key ''" (not an error) if an exact key lookup misses

• Returns empty records array (not an error) if a search finds nothing