Skip to main content
Glama

.brain โ€” the portable decision log

The portable decision log your AI tools all read. One MCP server. Any AI tool. Plain files.

PyPI version License: MIT MCP Compatible NPM nucleus-mcp MCP server

Every AI coding session starts by re-explaining context the last session already knew. .brain is a folder in your repo that Claude Code, Cursor, and Codex all read via one MCP server. Decisions, policies, plans โ€” written once, remembered across every session and every tool.

MIT licensed. File-based (plain JSON + markdown). No embeddings. No vendor lock-in.


Also included: nucleus-rabbithole

nucleus-mcp ships a second, fully independent tool: nucleus-rabbithole, a rabbit-hole depth tracker for focus-prone developers.

It gives your AI a push/pop depth stack, a context-switch thrash detector, an open-loop externaliser, and a weekly review โ€” all backed by local SQLite, no network, no daemon.

# Already installed with nucleus-mcp โ€” just run:
nucleus-rabbithole

Claude Code .mcp.json snippet:

{
  "mcpServers": {
    "nucleus-rabbithole": {
      "command": "nucleus-rabbithole",
      "args": []
    }
  }
}

Full documentation: docs/RABBITHOLE.md


Related MCP server: Astria-Index

Three Frontiers

The core loop that makes AI reliability compound over time:

  GROUND              ALIGN               COMPOUND
  โ”€โ”€โ”€โ”€โ”€โ”€              โ”€โ”€โ”€โ”€โ”€               โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
  Machine verifies    Human corrects      System learns

  AI writes code  โ†’  You fix a mistake โ†’  Delta recorded
  GROUND checks   โ†’  Verdict stored    โ†’  DPO pair created
  Receipt logged  โ†’  Event emitted     โ†’  Training data grows
       โ”‚                   โ”‚                    โ”‚
       โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
                    Reliability improves

GROUND โ€” 5-tier execution verification. Syntax, imports, tests, runtime. Goes outside the formal system to check the AI's work.

ALIGN โ€” One-call corrections. nucleus_align(action="correct", params={context, correction}). Each correction automatically records a verdict, creates a training pair, and emits an event.

COMPOUND โ€” Deltas measure the gap between intent and reality. Recurring patterns become strategy. Negative deltas become training signal.

Every tool response shows frontier health:

[frontiers: GROUND 42 | ALIGN 12 | COMPOUND 28]

Quick Start

Option A โ€” No install (ChatGPT, Claude, Perplexity):

Add https://relay.nucleusos.dev/mcp as a remote MCP server in your platform's connector settings. That's it โ€” your AI now has persistent memory.

Option B โ€” Local install (Cursor, Windsurf, Claude Desktop):

pip install nucleus-mcp
nucleus init --recipe founder

Two commands. Nucleus is running. AI outputs are now verified. nucleus init auto-configures your MCP client โ€” just restart it.


What It Does

114 MCP tools across 13 facades:

  • GROUND โ€” Execution verification (5 tiers: diff, syntax, imports, tests, runtime)

  • ALIGN โ€” Human corrections (verdict + delta + DPO + event in one call)

  • Memory โ€” Engrams that persist across sessions. Write once, recall forever.

  • Sessions โ€” Save context, resume later. Session arc shows your last 3 sessions.

  • Tasks โ€” Priority queue with escalation, HITL gates, and heartbeat monitoring.

  • Governance โ€” Kill switch, compliance configs (EU DORA, MAS TRM, SOC2), audit trails.

  • Orchestration โ€” Agent slots, multi-brain sync, task dispatch.

  • Archive โ€” Training pipeline (SFT + DPO), delta tracking, frontier health dashboard.

Benchmark: decision-retention-evals โ€” does your AI agent remember why the code is the way it is?


Nucleus Pro

Everything above is free (MIT). Nucleus Pro adds verifiable governance:

nucleus trial                              # 14-day free trial
nucleus compliance-check                   # Score your AI governance
nucleus audit-report --signed -o report.html  # Cryptographically signed report

$19/month or $149/year โ€” nucleusos.dev/pricing

Free

Pro

13 tools, 10 resources, 3 prompts

Yes

Yes

Persistent memory

Yes

Yes

Governance & HITL

Yes

Yes

Audit trails (DSoR)

Yes

Yes

Signed audit reports

-

Ed25519

Compliance exports

Score only

Full PDF/HTML

Priority issues

-

Yes


Install

One command installs the CLI and auto-configures every MCP client you have โ€” Claude Desktop, Claude Code, Cursor, Windsurf, and Antigravity โ€” backing up each config file it touches. No hand-editing JSON.

pip install nucleus-mcp      # or:  uvx nucleus-mcp  ยท  pipx install nucleus-mcp
nucleus init                 # seeds .brain/ and writes the MCP config for every client found

Then restart your AI client. To verify: your client's tool list now shows nucleus_* tools, or run nucleus doctor.

nucleus init writes a <config>.json.bak backup before editing, and never touches an existing nucleus entry unless you pass --force. Already have a .brain? Run nucleus setup to (re)configure clients without re-seeding it โ€” add --dry-run to preview the exact changes first.

Claude Desktop โ€” one-click bundle

A one-click nucleus.mcpb bundle for Claude Desktop is built via bash scripts/build_mcpb.sh (it will be attached to releases once the release workflow ships it). Opening the bundle with Claude Desktop uses Claude's built-in uv runtime to fetch and run nucleus-mcp โ€” no Python setup required.

No install (ChatGPT, Claude.ai, Perplexity)

Add https://relay.nucleusos.dev/mcp as a remote MCP server in your platform's connector settings. Persistent memory, nothing to install.

If a client isn't auto-detected, nucleus init prints a ready-to-paste mcpServers block and copies it to your clipboard, along with each client's config-file location. The full manual walkthrough lives in docs/QUICK_START.md.

Path Discovery

Nucleus finds your .brain automatically:

  1. NUCLEUS_BRAIN_PATH environment variable (explicit)

  2. Walk up from CWD looking for .brain/ directory

  3. Fall back to $HOME/.nucleus/brain


CLI

Nucleus has a full CLI alongside the MCP tools. Auto-detects TTY (table output) vs pipe (JSON).

# Memory
nucleus engram write my_key "insight here" --context Decision --intensity 7
nucleus engram search "compliance"
nucleus engram query --context Strategy --limit 10

# Tasks
nucleus task list --status READY
nucleus task add "Ship the feature" --priority 1

# Sessions
nucleus session save "Working on auth refactor"
nucleus session resume

# Health
nucleus status --health
nucleus sovereign

# Compliance
nucleus comply --jurisdiction eu-dora
nucleus audit-report --format html -o report.html

# Chat (multi-provider: Gemini, Anthropic, Groq)
nucleus chat

Pipe-friendly:

nucleus engram search "test" | jq '.key'
nucleus task list --format tsv | cut -f1,3

Compliance

One-command configuration for regulatory frameworks:

nucleus comply --jurisdiction eu-dora       # EU DORA
nucleus comply --jurisdiction sg-mas-trm    # Singapore MAS TRM
nucleus comply --jurisdiction us-soc2       # US SOC2

Jurisdiction

Retention

HITL Ops

Kill Switch

eu-dora

7 years

5 types

Required

sg-mas-trm

5 years

5 types

Required

us-soc2

1 year

3 types

Optional

global-default

90 days

2 types

Optional


Telemetry

Nucleus collects anonymous, aggregate usage statistics (command name, duration, error type, versions, OS). No engram content, no file paths, no prompts, no API keys, no PII โ€” ever.

nucleus config --no-telemetry
# or: NUCLEUS_ANON_TELEMETRY=false

See TELEMETRY.md for details.


Contributing

License

MIT ยฉ 2026 | hello@nucleusos.dev

Privacy

Nucleus is a local-first tool. All engrams, memories, and project state are stored on your machine in .brain/ โ€” no personal data is sent to any server unless you explicitly configure a remote relay.

Telemetry: Anonymous, aggregate usage statistics only (command name, duration, error type, versions, OS). No engram content, no file paths, no prompts, no API keys, no PII โ€” ever. Disable with nucleus config --no-telemetry or NUCLEUS_ANON_TELEMETRY=false.

Remote relay (optional): If you configure a remote relay endpoint, engram metadata is synced to your own relay server. You control the relay โ€” no third-party data sharing.

Contact: Privacy questions โ†’ hello@nucleusos.dev

Available Tools

12 tools
nucleus_agentsA
Destructive
Inspect

Manage multi-agent lifecycles including spawning specialized sub-agents, running automated code review and repair, orchestrating agent swarms for complex tasks, searching persistent memory, ingesting tasks from external sources, and viewing real-time dashboards. Use this tool when you need to create new agents, review or fix code, coordinate parallel work, or query the knowledge base. Do NOT use for individual task CRUD (use nucleus_tasks), session management (use nucleus_sessions), or cross-brain sync (use nucleus_federation). Actions: 'spawn_agent' creates a sub-agent with a specific role (reviewer/implementer/researcher) and goal (side effect: may start a new process). 'critique_code' runs automated code review on a file, returning issues and suggestions. 'fix_code' attempts automated repair of a described issue in a file. 'apply_critique' applies review feedback. 'orchestrate_swarm' coordinates multiple agents working on a complex task in parallel. 'search_memory' queries the persistent engram store by keyword (read-only). 'read_memory' retrieves a specific engram by key. 'ingest_tasks' imports tasks from external sources like GitHub issues, CSV, or JSONL files (side effect: creates tasks). 'rollback_ingestion' undoes a previous import (destructive: deletes imported tasks). 'ingestion_stats' shows import history. 'dashboard' shows live system metrics including agent count, task throughput, and memory usage. 'snapshot_dashboard'/'list_dashboard_snapshots' manage dashboard snapshots. 'get_alerts'/'set_alert_threshold' configure monitoring alerts. 'respond_to_consent'/'list_pending_consents' handle human-in-the-loop approval flows for sensitive operations. Prerequisites: .brain directory. Returns JSON with {success: boolean, data: object}. Example: {action: 'search_memory', params: {query: 'authentication', limit: 5}} returns {success: true, data: {results: [{key: 'engram_x', content: 'Auth uses JWT...', score: 0.95}]}}.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesSelect the agent management action. 'search_memory'/'read_memory'/'dashboard'/'get_alerts'/'ingestion_stats'/'list_pending_consents'/'session_briefing'/'list_dashboard_snapshots' are read-only. 'spawn_agent' creates a new sub-agent. 'critique_code'/'fix_code'/'apply_critique' handle automated code review and repair. 'orchestrate_swarm' coordinates parallel agents. 'ingest_tasks' imports from external sources. 'rollback_ingestion' is destructive (deletes imported tasks). 'set_alert_threshold' configures monitoring. 'respond_to_consent' approves/denies sensitive operations.
paramsNoAction-specific parameters as key-value pairs. spawn_agent: {role: string (required, 'reviewer'|'implementer'|'researcher'|'planner'), goal: string (required, what the agent should accomplish), tools: string[] (optional, tool names to grant access to)}. critique_code: {file_path: string (required, path to file to review), diff: string (optional, specific diff to focus review on)}. fix_code: {file_path: string (required), issue: string (required, description of the problem to fix)}. search_memory: {query: string (required, search term), limit: integer (optional, default 10)}. read_memory: {key: string (required, engram key)}. ingest_tasks: {source: string (required, 'github'|'csv'|'jsonl'), file_path: string (required, path to source file)}. set_alert_threshold: {metric: string (required, metric name), threshold: number (required), operator: string (optional, 'gt'|'lt'|'eq', default 'gt')}. handoff_task: {task_id: string (required), to_agent: string (required), context: object (optional)}. respond_to_consent: {consent_id: string (required), approved: boolean (required)}. rollback_ingestion/ingestion_stats/dashboard/snapshot_dashboard/list_dashboard_snapshots/get_alerts/list_pending_consents/session_briefing/register_session/apply_critique/orchestrate_swarm: no parameters needed.

TDQS

A4.9/5.0
Behavior5/5

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

Discloses side effects for spawn_agent ('may start a new process') and ingest_tasks ('creates tasks'), destructive nature of rollback_ingestion ('deletes imported tasks'), read-only status of several actions, prerequisites ('.brain directory'), and return format (JSON with success and data). This adds value beyond annotations by providing specific behavioral details.

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?

The description is thorough and well-organized, with a clear front-load of purpose and usage, followed by detailed action breakdowns. While every sentence adds value, the length could be slightly reduced by grouping similar actions; however, the structure is logical and easy to follow.

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

Completeness5/5

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

Given the complexity of the tool (20 actions, no output schema), the description is fully comprehensive: includes prerequisites, return format, example, side effects, and explicit mentions of destructive/read-only behaviors. No gaps remain for correct invocation.

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

Parameters5/5

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

Adds extensive meaning beyond the schema: describes required fields, optional fields, allowed values (e.g., role enum), defaults, and provides an example usage. Covers all 20 actions with specific parameter structures, fully compensating for the schema's generic parameter description.

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

Purpose5/5

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

The description clearly states the tool manages multi-agent lifecycles with specific verbs and resources (spawn, critique, fix, orchestrate, search, ingest, etc.) and explicitly distinguishes from sibling tools like nucleus_tasks, nucleus_sessions, and nucleus_federation.

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

Usage Guidelines5/5

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

Provides explicit when-to-use ('when you need to create new agents, review or fix code, coordinate parallel work, or query the knowledge base') and when-not-to-use with named alternatives ('Do NOT use for individual task CRUD (use nucleus_tasks), session management (use nucleus_sessions), or cross-brain sync (use nucleus_federation)').

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

nucleus_engramsAInspect

Store, query, and search persistent memory (engrams) that survives across AI sessions, plus health monitoring and context graph visualization. Use this tool when you need to remember something for future sessions, recall past decisions, search the knowledge base, or check system health. Do NOT use for task tracking (use nucleus_tasks), session lifecycle (use nucleus_sessions), or agent coordination (use nucleus_agents). Engrams are the fundamental memory unit โ€” each has content, optional tags for categorization, source attribution, and arbitrary metadata. Actions: 'write_engram' persists new knowledge to .brain/engrams/ (side effect: creates a JSONL entry). 'query_engrams' retrieves engrams filtered by tag, context, or intensity. 'search_engrams' performs full-text search across all stored knowledge. 'health' checks brain directory integrity and returns file counts and sizes. 'version' returns Nucleus version, Python version, and platform info. 'audit_log' shows the decision audit trail with timestamps. 'morning_brief' generates a daily status report with task summaries, session history, and recommendations. 'governance_status' shows current security mode and lock state. 'context_graph' builds a relationship map between related engrams. 'engram_neighbors' traverses the graph from a specific engram. 'pulse_and_polish' analyzes engram quality and suggests improvements. 'fusion_reactor' cross-references multiple engrams to generate insights. 'billing_summary' shows resource usage. All read operations are non-destructive. Prerequisites: .brain directory must exist. Returns JSON with {success: boolean, data: object}. Example: {action: 'write_engram', params: {content: 'Auth uses JWT with 24h expiry', tags: ['architecture', 'auth']}} returns {success: true, data: {key: 'engram_a1b2c3', stored: true}}.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesSelect the engram or observability action. 'write_engram' persists new knowledge to disk. 'query_engrams' filters by context, tags, or intensity. 'search_engrams' does full-text search. 'health'/'version'/'audit_log'/'governance_status'/'billing_summary' are read-only diagnostics. 'morning_brief' generates a daily summary. 'context_graph'/'engram_neighbors'/'render_graph' map relationships between engrams. 'pulse_and_polish'/'fusion_reactor' are compound analysis operations.
paramsNoAction-specific parameters as key-value pairs. write_engram: {content: string (required, the knowledge to store), tags: string[] (optional, e.g. ['architecture','decision']), source: string (optional, origin attribution like 'code_review'), metadata: object (optional, arbitrary key-value data)}. query_engrams: {query: string (optional, filter text), limit: integer (optional, default 10, max results), tags: string[] (optional, filter by tags)}. search_engrams: {query: string (required, full-text search term), limit: integer (optional, default 10)}. audit_log: {limit: integer (optional, default 20), level: string (optional, 'info'|'warning'|'error')}. context_graph: {engram_id: string (optional, center node ID)}. engram_neighbors: {engram_id: string (required), depth: integer (optional, default 1, traversal depth)}. health/version/morning_brief/governance_status/billing_summary: no parameters needed.

TDQS

A4.9/5.0
Behavior5/5

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

Despite minimal annotations (all hints false), the description details side effects (e.g., 'write_engram creates a JSONL entry'), states that read operations are non-destructive, and mentions prerequisites (.brain directory must exist). It also enumerates all actions with their effects.

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?

The description is front-loaded with the core purpose and ends with a concrete example. However, it is somewhat verbose in listing all actions and could be more structured (e.g., bullet points). Each sentence generally earns its place.

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

Completeness5/5

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

Given the tool's complexity (13 actions, nested params, no output schema), the description covers all actions, prerequisites, return format, and examples. It is fully complete and leaves no ambiguity for an agent.

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

Parameters5/5

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

Input schema has 100% coverage, but the description adds significant value by explaining action-specific parameters (e.g., write_engram requires content, offers tags/source/metadata), providing examples, and clarifying defaults like limit=10.

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

Purpose5/5

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

The description explicitly states 'Store, query, and search persistent memory (engrams)' and distinguishes from sibling tools like nucleus_tasks, nucleus_sessions, and nucleus_agents. It provides a specific verb+resource and clear differentiation.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use (e.g., 'remember something for future sessions') and when-not-to-use scenarios with named alternatives, making it easy for an agent to choose correctly.

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

nucleus_featuresA
Destructive
Inspect

Track features through their lifecycle, generate cryptographic execution proofs for audit compliance, and mount external MCP servers as composable sub-tools. Use this tool when you need to register a feature, verify code execution, or integrate another MCP server. Do NOT use for task tracking (use nucleus_tasks), memory storage (use nucleus_engrams), or agent spawning (use nucleus_agents). Actions: 'add' creates a feature record with name, description, and initial status. 'update' changes feature status through its lifecycle (proposed/in_progress/done/cancelled). 'validate' marks a feature as verified with evidence. 'list' shows all features. 'get' retrieves one feature by ID. 'search' finds features by keyword. 'generate_proof' creates a cryptographic Ed25519-signed receipt of a code execution for audit compliance (side effect: writes to .brain/proofs/). 'get_proof'/'list_proofs' retrieve stored proofs. 'mount_server' connects an external MCP server as a sub-tool (side effect: spawns a child process). 'discover_tools' lists tools available on a mounted server. 'invoke_tool' calls a tool on a mounted server and returns its result. 'traverse_mount' navigates the mount hierarchy. 'thanos_snap'/'unmount_server' disconnect mounted servers (destructive: kills child process, removes mount config). Prerequisites: .brain directory. Mounting requires the external server command to be installed locally. Returns JSON with {success: boolean, data: object}. Example: {action: 'add', params: {name: 'JWT Auth', description: 'Token-based authentication', status: 'in_progress'}} returns {success: true, data: {feature_id: 'feat_xyz', created: true}}.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesSelect the feature, proof, or mount action. 'add'/'update'/'validate' manage feature lifecycle records. 'search'/'list'/'get'/'list_mounted'/'discover_tools'/'get_proof'/'list_proofs'/'traverse_mount' are read-only queries. 'generate_proof' creates a cryptographic execution receipt. 'mount_server' connects an external MCP server (spawns process). 'invoke_tool' calls a mounted server's tool. 'unmount_server'/'thanos_snap' disconnect and remove mounted servers (destructive: kills process).
paramsNoAction-specific parameters as key-value pairs. add: {name: string (required), description: string (required), status: string (optional, default 'proposed')}. update: {feature_id: string (required), status: string (required, 'proposed'|'in_progress'|'done'|'cancelled'), notes: string (optional)}. get: {feature_id: string (required)}. search: {query: string (required, keyword search)}. validate: {feature_id: string (required), evidence: string (optional)}. mount_server: {name: string (required, display name), command: string (required, executable path), args: string[] (optional, command arguments), env: object (optional, environment variables)}. invoke_tool: {server_name: string (required, mounted server name), tool_name: string (required), arguments: object (optional)}. generate_proof: {action: string (required, what was executed), evidence: object (required, execution artifacts)}. unmount_server: {name: string (required)}. list/list_mounted/discover_tools/get_proof/list_proofs/traverse_mount: no parameters needed.

TDQS

A4.9/5.0
Behavior5/5

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

Disclosures all side effects: writes to .brain/proofs/ for generate_proof, spawns child process for mount_server, kills process for thanos_snap/unmount_server. Annotations confirm destructiveHint=true, no contradiction.

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?

Well-structured with clear sections, front-loaded purpose, and example. Slightly long but every sentence adds value. Could be slightly more concise.

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

Completeness5/5

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

Given no output schema, it includes return format, example, and covers all 16 actions comprehensively with their effects. Sufficient for a complex tool.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds significant value by detailing action-specific required and optional parameters with examples and types beyond schema enums.

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

Purpose5/5

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

The description specifies verb+resource (track, generate, mount) and explicitly distinguishes from sibling tools by naming them (nucleus_tasks, nucleus_engrams, nucleus_agents) and stating what not to use the tool for.

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

Usage Guidelines5/5

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

Provides explicit when-to-use scenarios (register feature, verify execution, integrate MCP server) and when-not-to-use with sibling tool names. Also lists prerequisites like .brain directory and external server installation.

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

nucleus_federationAInspect

Coordinate multiple Nucleus brain instances across distributed environments by joining federations, syncing state between peers, and routing requests to the appropriate brain. Use this tool when multiple AI agents on different machines or projects need to share memory, synchronize decisions, or coordinate work across separate .brain directories. Do NOT use for single-brain agent coordination (use nucleus_agents), artifact sharing within one brain (use nucleus_sync), or session handoffs (use nucleus_sessions). Actions: 'status' returns current federation membership and connection state (read-only). 'join' connects the current brain to a named federation (side effect: writes federation config to .brain/federation/). 'leave' disconnects from a federation. 'peers' lists all connected brains with their last-sync timestamps. 'sync' replicates state between brains โ€” 'delta' mode merges only changes (safe), 'full' mode overwrites the target entirely (destructive). 'route' forwards a tool request to a specific peer brain and returns its response. 'health' checks connectivity and latency to all peers. Prerequisites: .brain directory. Federation requires filesystem access for local peers or network access for remote peers. Returns JSON with {success: boolean, data: object}. Example: {action: 'join', params: {federation_id: 'team-alpha', brain_path: '/shared/project/.brain'}} returns {success: true, data: {joined: true, peer_count: 3}}.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesSelect the federation action. 'status'/'peers'/'health' are read-only queries returning federation state. 'join' connects to a federation (writes config). 'leave' disconnects. 'sync' replicates data between brains โ€” 'full' mode is destructive and overwrites the target brain. 'route' forwards a request to a specific peer brain.
paramsNoAction-specific parameters as key-value pairs. join: {federation_id: string (required, unique federation name), brain_path: string (required, filesystem path to remote .brain directory)}. leave: {federation_id: string (required)}. route: {target_brain: string (required, brain identifier from 'peers' output), action: string (required, tool action to execute on remote), params: object (optional, parameters forwarded to remote tool)}. sync: {peer_id: string (required, brain identifier), mode: string (optional, 'full' overwrites target entirely or 'delta' merges changes only, default 'delta')}. status/peers/health: no parameters needed.

TDQS

A4.7/5.0
Behavior4/5

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

Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds context: joining writes config, full sync is destructive, and most actions are read-only. This goes beyond annotations, though it could explicitly state overall read-only status. No contradiction.

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 well-structured, starting with purpose, usage guidelines, then action details, prerequisites, return format, and an example. Every sentence is informative and necessary.

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

Completeness5/5

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

Given the tool's complexity (7 actions, side effects, nested params) and no output schema, the description covers all essential aspects: purpose, usage distinction, each action's behavior, side effects, prerequisites, and return format. It is fully complete.

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

Parameters4/5

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

Schema coverage is 100% and the description adds examples and clarifies action-specific parameters. For instance, it explains that 'route' requires target_brain and action, and 'sync' has mode with defaults. This adds value beyond the schema.

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

Purpose5/5

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

The description clearly states 'Coordinate multiple Nucleus brain instances' and lists all actions. It explicitly distinguishes from siblings like nucleus_agents, nucleus_sync, and nucleus_sessions, ensuring the agent knows when to use this tool.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use guidance ('when multiple AI agents... need to share memory') and when-not-to-use with alternative tool names. This is fully actionable for an AI agent.

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

nucleus_governanceA
Destructive
Inspect

Enforce file integrity, security posture, and automated verification loops for the Nucleus Agent OS. Use this tool when you need to lock files against modification, switch security modes, or run auto-fix cycles. Do NOT use for task management (use nucleus_tasks), session state (use nucleus_sessions), or memory storage (use nucleus_engrams). Actions: 'lock' sets an immutable flag on a file preventing modification. 'unlock' removes that flag (destructive: re-enables writes). 'set_mode' switches between 'red' (restricted, blocks dangerous ops) and 'blue' (permissive) security modes. 'auto_fix_loop' runs a verify-diagnose-fix-retry cycle: it executes your verification_command, and if it fails, attempts to fix the file, then retries until the command passes or max retries exceeded. 'delete_file' permanently removes a file (destructive, irreversible). 'watch' monitors a file path and returns changes detected within the duration window. 'curl' proxies HTTP requests through Nucleus egress controls. 'pip_install' installs Python packages with governance audit logging. 'status' returns current security mode and lock state. 'list_directory' returns directory contents. Side effects: lock/unlock modify filesystem extended attributes. delete_file removes data permanently. Prerequisites: .brain directory must exist. Returns JSON with {success: boolean, data: object}. Example: {action: 'auto_fix_loop', params: {file_path: 'src/app.py', verification_command: 'python -m py_compile src/app.py'}} returns {success: true, data: {iterations: 2, fixed: true}}.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesSelect the governance action to execute. 'auto_fix_loop' runs automated verification and repair. 'lock'/'unlock' control file immutability. 'set_mode' changes security posture between 'red' (restricted) and 'blue' (permissive). 'delete_file' is destructive and irreversible. 'status'/'list_directory' are read-only. 'curl' proxies external HTTP requests through egress controls. 'pip_install' installs packages with audit logging.
paramsNoAction-specific parameters as key-value pairs. auto_fix_loop: {file_path: string (required, path to verify), verification_command: string (required, shell command that returns exit code 0 on success)}. lock: {path: string (required, file or directory to make immutable)}. unlock: {path: string (required, file or directory to make writable again)}. set_mode: {mode: string (required, 'red' or 'blue')}. list_directory: {path: string (optional, defaults to .brain root)}. delete_file: {path: string (required, DESTRUCTIVE โ€” permanently removes file)}. watch: {path: string (required, file or directory to monitor), duration: integer (optional, seconds to watch, default 30)}. curl: {url: string (required), method: string (optional, 'GET'|'POST'|'PUT'|'DELETE', default 'GET'), headers: object (optional), body: string (optional)}. pip_install: {package: string (required, PyPI package name)}. status: no parameters needed.

TDQS

A4.8/5.0
Behavior5/5

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

Disclose side effects (lock/unlock modify extended attributes, delete_file permanent removal), prerequisites (.brain directory must exist), and destructive actions. Annotations already set destructiveHint=true, readOnlyHint=false; description adds concrete context.

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?

Description is lengthy but well-structured: starts with general purpose, then usage guidelines, then systematic action breakdown. Each sentence earns its place given tool complexity.

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

Completeness5/5

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

Covers all actions, parameters, side effects, prerequisites, and return format (JSON success/data). Even includes an example. No output schema needed; description suffices.

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

Parameters4/5

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

Schema coverage is 100%, so baseline 3. Description adds value with detailed parameter descriptions per action and a concrete example for auto_fix_loop, going beyond schema.

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

Purpose5/5

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

Description clearly states purpose: enforce file integrity, security posture, and automated verification loops. It distinguishes from sibling tools by explicitly excluding task management, session state, and memory storage.

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

Usage Guidelines5/5

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

Explicitly states when to use ('lock files, switch security modes, run auto-fix cycles') and when not to use ('Do NOT use for task management...'), with alternative tools named.

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

nucleus_infraAInspect

Monitor infrastructure health, manage Google Cloud Platform services, track file changes across your project, and generate strategic planning reports. Use this tool when you need operational awareness of your development environment, GCP service status, or strategic recommendations. Do NOT use for code-level tasks (use nucleus_tasks), memory (use nucleus_engrams), or deployment orchestration (use nucleus_sync with deploy actions). Actions: 'file_changes' lists recently modified files in the project directory with timestamps and sizes (read-only, useful for detecting unexpected modifications). 'gcloud_status' checks Google Cloud Platform availability and incident status. 'gcloud_services' lists all enabled GCP services for a project (requires project_id). 'list_services' shows locally running services detected on common ports. 'status_report' generates a formatted markdown or JSON summary of brain health, task status, session state, and frontier metrics. 'synthesize_strategy' analyzes accumulated data (engrams, patterns, metrics) and recommends strategic actions. 'optimize_workflow' suggests process improvements for a named area. 'manage_strategy' reads and writes strategy documents to .brain/strategy/ (side effect: creates or modifies files). 'update_roadmap' modifies roadmap items in .brain/roadmap.json (side effect: modifies file). 'scan_marketing_log' analyzes marketing-related log entries. Prerequisites: .brain directory. GCloud actions require 'gcloud' CLI installed and authenticated via 'gcloud auth login'. Returns JSON with {success: boolean, data: object}. Example: {action: 'file_changes', params: {since: '24h', path: 'src/'}} returns {success: true, data: {changes: [{path: 'src/app.py', modified: '2026-04-04T10:00:00Z', size: 1234}]}}.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesSelect the infrastructure, cloud, or strategy action. 'file_changes'/'gcloud_status'/'gcloud_services'/'list_services'/'status_report' are read-only queries. 'scan_marketing_log' analyzes log data. 'synthesize_strategy'/'optimize_workflow' generate recommendations without side effects. 'manage_strategy' reads or writes strategy documents to disk. 'update_roadmap' modifies the roadmap file.
paramsNoAction-specific parameters as key-value pairs. file_changes: {since: string (optional, ISO date like '2026-04-01' or relative like '24h'|'7d', default '24h'), path: string (optional, directory to scan, default project root)}. gcloud_services: {project_id: string (required, GCP project ID, e.g. 'my-project-123')}. status_report: {format: string (optional, 'markdown'|'json', default 'markdown'), scope: string (optional, 'full'|'summary', default 'full')}. update_roadmap: {item: string (required, roadmap item name), status: string (required, new status value), notes: string (optional)}. optimize_workflow: {target_area: string (required, area to analyze, e.g. 'testing'|'deployment'|'code_review')}. manage_strategy: {operation: string (required, 'read'|'write'), key: string (optional, strategy document name), value: string (optional, content for write)}. gcloud_status/list_services/scan_marketing_log/synthesize_strategy: no parameters needed.

TDQS

A4.5/5.0
Behavior4/5

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

The description discloses which actions are read-only (e.g., 'file_changes'/'status_report') and which have side effects (e.g., 'manage_strategy' creates/modifies files). It also notes the return format ({success, data}). Annotations are consistent (readOnlyHint: false fits the mix of actions).

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?

The description is thorough and well-structured: starts with overall purpose, lists actions, prerequisites, return format, and ends with an example. Every sentence adds value. Could be slightly more concise, but the detail is justified given the tool's complexity.

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?

Given the tool's many actions and nested parameters, the description is highly complete. It covers all actions, their behavior, prerequisites, and return format. No output schema exists, but the description provides the JSON structure. Minor omissions: no explanation of 'scan_marketing_log' beyond 'analyzes marketing-related log entries'; still, overall very good.

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

Parameters4/5

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

The input schema has 100% coverage with descriptions for both parameters. The description adds significant additional semantics: it explains each action's purpose, lists sub-parameters for params with formats and defaults, and provides an example. This goes beyond schema documentation.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Monitor infrastructure health, manage Google Cloud Platform services, track file changes across your project, and generate strategic planning reports.' It distinguishes itself from siblings by explicitly listing what not to use it for and suggesting alternative tools (nucleus_tasks, nucleus_engrams, nucleus_sync).

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use the tool ('when you need operational awareness...') and when not to use it ('Do NOT use for code-level tasks...'). It also lists prerequisites (gcloud CLI, .brain directory) and the return format, helping agents determine appropriateness.

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

nucleus_orchestrationA
Destructive
Inspect

Get strategic awareness of all active work through satellite overviews, commitment tracking, open loop management, pattern detection, and data export. Use this tool when you need a high-level view of project state, want to track promises made during sessions, identify recurring patterns, or export data. Do NOT use for individual task CRUD (use nucleus_tasks), session management (use nucleus_sessions), or slot-based sprint execution (use nucleus_slots). Actions: 'satellite' returns a comprehensive bird's-eye view of tasks, sessions, commitments, health scores, and frontier status โ€” the best starting point for understanding current state. 'scan_commitments' extracts promises and action items from session transcripts. 'list_commitments' shows all tracked commitments. 'close_commitment' marks a commitment as fulfilled with a resolution note. 'commitment_health' scores how well commitments are being met. 'open_loops' shows unfinished work items that need closure. 'add_loop' registers something that needs follow-up. 'patterns' detects recurring themes across sessions and tasks. 'metrics' shows system-wide statistics (tool usage, event counts, memory growth). 'export' dumps data in json/csv/markdown format. 'weekly_challenge' generates a focused challenge based on recent activity. 'archive_stale' removes commitments older than N days (destructive: deletes records). Prerequisites: .brain directory with session history for best results. Returns JSON with {success: boolean, data: object}. Example: {action: 'satellite'} returns {success: true, data: {tasks: {total: 12, in_progress: 3}, sessions: {active: 'sess_abc'}, commitments: {open: 5, overdue: 1}}}.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesSelect the orchestration action. 'satellite'/'list_commitments'/'commitment_health'/'open_loops'/'patterns'/'metrics' are read-only overviews. 'scan_commitments' analyzes session transcripts to extract promises. 'close_commitment' resolves a tracked commitment. 'add_loop' registers an open item. 'export' generates formatted output. 'weekly_challenge' creates a focus challenge. 'archive_stale' removes old commitments (destructive: deletes data).
paramsNoAction-specific parameters as key-value pairs. close_commitment: {commitment_id: string (required), resolution: string (required, how the commitment was fulfilled)}. add_loop: {description: string (required, what needs follow-up), context: string (optional, background info), priority: string (optional, 'high'|'medium'|'low', default 'medium')}. export: {format: string (optional, 'json'|'csv'|'markdown', default 'json'), target: string (optional, file path to write to)}. archive_stale: {days_old: integer (required, commitments older than this many days are removed)}. scan_commitments: {session_id: string (optional, defaults to current session)}. satellite/list_commitments/commitment_health/open_loops/patterns/metrics/weekly_challenge: no parameters needed.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations indicate destructiveHint: true; description confirms archive_stale is destructive. Highlights read-only nature of many actions. No contradictions with annotations.

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?

Well-structured with action list and examples, though somewhat lengthy. Front-loaded with purpose and usage guidelines.

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

Completeness5/5

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

Covers all 12 actions with their effects, parameter details, and return shape. No output schema but description explains JSON response format with example.

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

Parameters4/5

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

Schema description coverage is 100%, but description adds extra value by specifying required fields and optional defaults for each action (e.g., close_commitment requires commitment_id and resolution).

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

Purpose5/5

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

The description clearly defines the tool's purpose: providing strategic awareness through satellite overviews, commitment tracking, and pattern detection. It distinguishes from sibling tools by explicitly excluding individual task CRUD, session management, and slot sprint execution.

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

Usage Guidelines5/5

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

Explicitly states when to use (high-level view, track promises, patterns, export) and when not to use (nucleus_tasks, nucleus_sessions, nucleus_slots). Also mentions prerequisites (.brain directory) for best results.

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

nucleus_sessionsA
Destructive
Inspect

Manage session lifecycles with save/resume, structured event logging, key-value state persistence, and named checkpoints for rollback. Use this tool to maintain continuity across AI conversations, track what happened during a work session, and hand off context between sessions or agents. Do NOT use for persistent knowledge (use nucleus_engrams), task tracking (use nucleus_tasks), or multi-agent sync (use nucleus_sync). Actions: 'start' begins a new session with a stated goal and optional tags. 'save' persists current session state to .brain/sessions/. 'resume' restores a previous session with full context including events, state, and active tasks. 'end' closes the active session and records duration. 'emit_event' appends a structured event to the session log (side effect: writes to events.jsonl). 'read_events' retrieves event history with optional filters. 'get_state' reads the session's key-value state. 'update_state' sets a key-value pair. 'checkpoint' creates a named snapshot of current state for later rollback. 'resume_checkpoint' restores state from a checkpoint. 'handoff_summary' generates context for transitioning to a new session or agent. 'archive_resolved' removes completed sessions (destructive: deletes session files). 'garbage_collect' removes stale sessions older than threshold (destructive). Prerequisites: .brain directory. Returns JSON with {success: boolean, data: object}. Example: {action: 'start', params: {goal: 'Fix authentication bug', tags: ['backend', 'auth']}} returns {success: true, data: {session_id: 'sess_abc123', started: true}}.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesSelect the session lifecycle action. 'start'/'end' control session boundaries. 'save'/'resume' persist and restore full session context. 'emit_event' appends to the event log (write). 'read_events'/'get_state'/'list'/'check_recent'/'handoff_summary' are read-only. 'update_state' modifies key-value session state. 'checkpoint'/'resume_checkpoint' create and restore named rollback points. 'archive_resolved'/'garbage_collect' are destructive cleanup operations that delete session data.
paramsNoAction-specific parameters as key-value pairs. start: {goal: string (required, session objective), tags: string[] (optional, categorization)}. save: {session_id: string (optional, auto-detected from active session), notes: string (optional)}. resume: {session_id: string (required, ID from 'list' output)}. emit_event: {event_type: string (required, e.g. 'decision'|'error'|'milestone'), data: object (required, event payload)}. read_events: {session_id: string (optional, defaults to active), limit: integer (optional, default 20), event_type: string (optional, filter by type)}. update_state: {key: string (required), value: any (required)}. checkpoint: {label: string (required, descriptive name like 'before-refactor')}. resume_checkpoint: {checkpoint_id: string (required)}. handoff_summary: {target_agent: string (optional, who receives the handoff)}. end/list/check_recent/get_state/archive_resolved/garbage_collect/propose_merges: no parameters needed.

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already indicate destructiveHint=true. The description adds specific details about destructive actions ('archive_resolved: deletes session files', 'garbage_collect: removes stale sessions') and side effects ('emit_event writes to events.jsonl'). It also mentions prerequisites (.brain directory). However, it doesn't cover error scenarios or idempotency beyond what's implied.

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?

The description is well-structured: beginning with overarching purpose, then listing actions with details, prerequisites, return format, and an example. It front-loads the key message. However, it is somewhat lengthy, but every part earns its place.

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

Completeness5/5

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

Given the tool's complexity (16 actions, nested params), the description covers all actions, parameter requirements, return format, prerequisites, and provides an example. No output schema exists, but the return JSON structure is described. This is thorough.

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

Parameters4/5

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

Schema coverage is 100%, so the description supplements with detailed parameter explanations for each action (e.g., start requires goal, emit_event requires event_type and data). This adds significant value beyond the enum list, earning above the baseline 3.

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

Purpose5/5

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

The description clearly states the tool's function: 'Manage session lifecycles with save/resume, structured event logging, key-value state persistence, and named checkpoints for rollback.' It also distinguishes from sibling tools by specifying what not to use it for, e.g., 'Do NOT use for persistent knowledge (use nucleus_engrams), task tracking (use nucleus_tasks), or multi-agent sync (use nucleus_sync).'

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

Usage Guidelines5/5

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

Explicitly says when to use ('maintain continuity across AI conversations, track what happened during a work session, and hand off context') and when not to use, with alternatives for each exclusion. This is a model of clear guidelines.

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

nucleus_slotsAInspect

Structure focused work into time-boxed slots, run automated sprints that claim and execute tasks, and manage multi-sprint missions with automatic sequencing. Use this tool when you want to organize execution into focused work periods, automate task execution cycles, or track progress toward multi-sprint goals. Do NOT use for individual task CRUD (use nucleus_tasks), session lifecycle (use nucleus_sessions), or strategic overview (use nucleus_orchestration). Actions: 'orchestrate' assigns tasks to time-boxed slots based on a strategy (fifo/priority/balanced). 'autopilot_sprint' runs an automated 25-minute pomodoro-style work cycle โ€” it claims the next task, executes it, records results, and moves to the next until time expires. 'start_mission' creates a multi-sprint goal with automatic sprint sequencing. 'status_dashboard' shows all active slots, their assigned tasks, and progress. 'mission_status' shows progress toward a mission goal. 'slot_complete' marks a slot as finished with a result summary. 'slot_exhaust' marks a slot as time-expired without completion. 'force_assign' overrides automatic slot assignment (destructive: replaces current slot occupant). 'halt_sprint' pauses an active autopilot sprint. 'resume_sprint' continues a halted sprint. Prerequisites: .brain directory with tasks in the queue. Sprints require claimable tasks to be available. Returns JSON with {success: boolean, data: object}. Example: {action: 'autopilot_sprint', params: {duration_minutes: 25, focus_tags: ['backend']}} returns {success: true, data: {sprint_id: 'sprint_001', tasks_completed: 3, duration: '24m'}}.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesSelect the slot, sprint, or mission action. 'status_dashboard'/'mission_status' are read-only progress views. 'orchestrate' assigns tasks to time-boxed slots. 'autopilot_sprint'/'autopilot_sprint_v2' run automated work cycles. 'start_mission' creates multi-sprint goals. 'slot_complete'/'slot_exhaust' close slots. 'force_assign' overrides slot assignment (destructive: replaces occupant). 'halt_sprint'/'resume_sprint' pause and continue sprint execution.
paramsNoAction-specific parameters as key-value pairs. orchestrate: {strategy: string (optional, 'fifo'|'priority'|'balanced', default 'priority'), max_slots: integer (optional, default 3, maximum concurrent slots)}. slot_complete: {slot_id: string (required), result: string (required, completion summary)}. slot_exhaust: {slot_id: string (required)}. force_assign: {slot_id: string (required), task_id: string (required)}. start_mission: {name: string (required), goal: string (required, mission objective), sprint_count: integer (optional, default 3)}. autopilot_sprint: {duration_minutes: integer (optional, default 25, pomodoro-style), focus_tags: string[] (optional, only claim tasks with these tags)}. mission_status: {mission_id: string (optional, defaults to active mission)}. status_dashboard/halt_sprint/resume_sprint: no parameters needed.

TDQS

A4.1/5.0
Behavior1/5

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

The description states that force_assign is destructive, while annotations set destructiveHint=false. This is a direct contradiction. Per scoring rules, score 1 for contradiction.

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?

The description is lengthy but well-structured: summary, usage guidance, action list, prerequisites, return format, example. Front-loaded with key info. A slight trim could improve conciseness, but it earns a 4 for clarity and organization.

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

Completeness5/5

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

Given the tool's complexity (multiple actions, nested params), the description covers prerequisites, return format, and provides an example. No output schema exists, but the description compensates fully. Complete for an AI agent to invoke correctly.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds extensive detail beyond the schema: for each action, it lists specific parameter keys, defaults, and descriptions. Without the description, the 'params' object would be opaque; the description makes each action's parameters clear.

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

Purpose5/5

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

The description clearly states the tool organizes work into time-boxed slots, runs automated sprints, and manages missions. It lists all specific actions with explanations, making the purpose unmistakable and distinguishing it from siblings.

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

Usage Guidelines5/5

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

Explicitly states when to use (organize execution into focused work periods) and when NOT to use (individual task CRUD with nucleus_tasks, session lifecycle with nucleus_sessions, strategic overview with nucleus_orchestration). Names specific alternatives, providing clear guidance.

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

nucleus_syncAInspect

Coordinate state across multiple AI agents, store and retrieve named artifacts, manage trigger-based automation, and orchestrate deployments. Use this tool when multiple agents need to share data, when you need to persist artifacts for cross-session use, or when managing deployment workflows. Do NOT use for persistent memory (use nucleus_engrams), session state (use nucleus_sessions), or task assignment (use nucleus_tasks). Actions: 'identify_agent' registers the current agent's identity in the brain. 'sync_status' shows sync state. 'sync_now' forces immediate state replication between brains (may overwrite remote data). 'write_artifact' stores a named data blob in .brain/artifacts/ for cross-session sharing (side effect: creates file). 'read_artifact' retrieves a stored artifact. 'list_artifacts' shows all stored artifacts. 'trigger_agent' dispatches an event to another registered agent. 'get_triggers'/'evaluate_triggers' manage automated trigger rules. 'start_deploy_poll' begins monitoring a deployment service for readiness. 'check_deploy' queries deployment status. 'complete_deploy' marks deployment as finished. 'smoke_test' validates a deployed service endpoint by hitting its URL. 'shared_read'/'shared_write'/'shared_list' manage a shared key-value store visible to all agents. Prerequisites: .brain directory. Sync operations require at least two configured brains. Deploy actions require network access. Returns JSON with {success: boolean, data: object}. Example: {action: 'write_artifact', params: {name: 'api_schema', content: '{...}', mime_type: 'application/json'}} returns {success: true, data: {stored: true, path: '.brain/artifacts/api_schema'}}.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesSelect the synchronization, artifact, trigger, or deployment action. 'identify_agent'/'sync_status'/'read_artifact'/'list_artifacts'/'get_triggers'/'check_deploy'/'shared_read'/'shared_list' are read-only. 'sync_now' forces state replication (may overwrite remote). 'write_artifact'/'shared_write' persist data. 'trigger_agent' dispatches events to other agents. 'evaluate_triggers' runs all trigger rules. 'start_deploy_poll'/'smoke_test' interact with external services.
paramsNoAction-specific parameters as key-value pairs. write_artifact: {name: string (required, unique identifier), content: string (required, artifact data), mime_type: string (optional, default 'text/plain')}. read_artifact: {name: string (required)}. trigger_agent: {agent_id: string (required), event: string (required, event name), payload: object (optional)}. start_deploy_poll: {service: string (required, service name), environment: string (required, e.g. 'production'|'staging')}. smoke_test: {url: string (required, endpoint URL), expected_status: integer (optional, default 200)}. shared_write: {key: string (required), value: any (required)}. shared_read: {key: string (required)}. sync_now: {target: string (optional, target brain path)}. identify_agent/sync_status/list_artifacts/get_triggers/evaluate_triggers/check_deploy/complete_deploy/shared_list/sync_auto/sync_resolve: no parameters needed.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations provide basic safety hints, and the description adds significant behavioral context: sync_now may overwrite remote data, write_artifact creates a file, deploy actions require network access, and return format is JSON. Does not contradict annotations.

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?

Well-structured: high-level summary, action list, prerequisites, return format, example. Front-loaded with key info. Slightly verbose but effective.

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?

Comprehensive for a multi-action tool: covers all actions, prerequisites, return format, and example. Lacks error handling details but sufficient for agent selection.

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

Parameters4/5

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

Schema coverage is 100%, baseline 3. Description adds extra context beyond schema: explains each action's purpose, provides parameter examples and requirements (e.g., write_artifact requires name and content).

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

Purpose5/5

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

The description clearly states the tool coordinates state across agents, stores artifacts, manages triggers, and orchestrates deployments. It explicitly distinguishes from siblings like nucleus_engrams, nucleus_sessions, and nucleus_tasks.

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

Usage Guidelines5/5

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

Explicitly states when to use (multiple agents need to share data, persist artifacts, manage deployments) and when not to use (persistent memory, session state, task assignment), providing alternative tool names.

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

nucleus_tasksAInspect

Manage a priority task queue with escalation, human-in-the-loop (HITL) gates, and cognitive depth tracking to prevent context-switch overhead and rabbit-holing. Use this tool when you need to create, assign, update, or track work items. Do NOT use for persistent knowledge storage (use nucleus_engrams), session management (use nucleus_sessions), or multi-agent coordination (use nucleus_agents). Actions: 'add' creates a new task with a priority level (critical/high/medium/low) and optional tags. 'list' shows tasks filtered by status โ€” returns an array of task objects. 'get_next' returns the highest-priority unclaimed task. 'claim' assigns a task to the current agent (side effect: sets status to in_progress). 'update' changes task status (pending/in_progress/done/blocked) with optional notes. 'escalate' flags a task for human review with a reason. 'import_jsonl' bulk-imports tasks from a JSONL file. 'depth_push' increments cognitive nesting depth (tracks how deep into subtasks you've gone). 'depth_pop' decrements it. 'depth_show' returns current depth and max. 'depth_reset' clears depth to zero. 'depth_set_max' sets the maximum allowed depth โ€” system warns when exceeded. 'depth_map' visualizes the full depth tree. 'context_switch' saves current task state and loads another task's context. All mutations write to .brain/tasks/. Prerequisites: .brain directory. Returns JSON with {success: boolean, data: object}. Example: {action: 'add', params: {title: 'Fix auth bug', priority: 'high', tags: ['backend']}} returns {success: true, data: {task_id: 'task_x1y2', created: true}}.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesSelect the task management action. 'add' creates a new task. 'list'/'get_next'/'depth_show'/'depth_map'/'context_switch_status' are read-only. 'claim' assigns a task to the current agent. 'update' changes task status. 'escalate' flags for human review. 'import_jsonl' bulk-imports from file. 'depth_push'/'depth_pop'/'depth_reset'/'depth_set_max' track cognitive nesting depth. 'context_switch' saves and restores working context between tasks.
paramsNoAction-specific parameters as key-value pairs. add: {title: string (required), description: string (optional), priority: string (optional, 'critical'|'high'|'medium'|'low', default 'medium'), tags: string[] (optional)}. update: {task_id: string (required), status: string (required, 'pending'|'in_progress'|'done'|'blocked'), notes: string (optional)}. claim: {task_id: string (required)}. escalate: {task_id: string (required), reason: string (required, why escalation is needed)}. depth_set_max: {max_depth: integer (required, typically 3-5)}. context_switch: {to_task_id: string (required)}. import_jsonl: {file_path: string (required, path to .jsonl file with task objects)}. list: {status: string (optional, filter by 'pending'|'in_progress'|'done'|'blocked'), limit: integer (optional, default 20)}. get_next/depth_push/depth_pop/depth_show/depth_reset/depth_map/context_switch_status/context_switch_reset: no parameters needed.

TDQS

A4.9/5.0
Behavior5/5

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

Disclosures beyond annotations include side effects (claim sets status to in_progress), file system writes to .brain/tasks/, prerequisites (.brain directory), and return format. No contradiction with annotations; description adds substantial behavioral context.

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?

Description is lengthy but well-organized with clear sectioning of actions. Every sentence contributes to understanding, though it could be slightly more condensed. Front-loaded purpose and usage guidance is good.

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

Completeness5/5

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

Given the tool's complexity with 15+ actions and nested parameters, the description covers all actions, parameter details, return JSON shape, and provides an example. No output schema exists, but the description explains return structure adequately.

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

Parameters5/5

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

Schema description coverage is 100%, but description adds significant meaning by detailing action-specific parameter requirements including required fields, defaults, and optional parameters for each action. The example further clarifies usage.

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

Purpose5/5

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

Description clearly states it manages a priority task queue with escalation, HITL gates, and cognitive depth tracking. It explicitly distinguishes from sibling tools like nucleus_engrams, nucleus_sessions, and nucleus_agents, making the purpose precise and unambiguous.

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

Usage Guidelines5/5

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

Provides explicit when-to-use (create, assign, update, track work items) and when-not-to-use (persistent knowledge, session management, multi-agent coordination) with specific alternatives. This gives clear guidance for correct selection.

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

nucleus_telemetryAInspect

Configure LLM model tiers, record interaction telemetry for training signal generation, track costs, and manage safety controls including kill switches and notification pausing. Use this tool when you need to set which AI models are used for different task types, log usage data, check cost dashboards, or control emergency stops. Do NOT use for persistent memory (use nucleus_engrams), task management (use nucleus_tasks), or agent lifecycle (use nucleus_agents). Actions: 'set_llm_tier' configures which model (opus/sonnet/haiku) to use for specific task contexts. 'get_llm_status' returns current tier configuration. 'record_interaction' logs a tool invocation with token counts and latency for training signal generation (side effect: appends to telemetry log). 'value_ratio' calculates cost-effectiveness metrics across recent interactions. 'check_kill_switch' queries whether all operations should halt โ€” returns boolean. 'pause_notifications' temporarily stops PEFS alert delivery. 'resume_notifications' re-enables alerts. 'record_feedback' captures human ratings (1-5 scale) on AI outputs for DPO training pairs. 'mark_high_impact' flags an interaction for human review. 'agent_cost_dashboard' shows per-agent token spending and cost breakdown. 'request_handoff' initiates a work transfer between agents. 'dispatch_metrics' shows tool dispatch statistics. Prerequisites: .brain directory. Kill switch state persists in .brain/governance/kill_switch.json. Returns JSON with {success: boolean, data: object}. Example: {action: 'record_feedback', params: {interaction_id: 'int_abc', rating: 5, comment: 'Perfect fix'}} returns {success: true, data: {recorded: true, dpo_pair_created: true}}.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesSelect the telemetry or safety control action. 'get_llm_status'/'value_ratio'/'check_kill_switch'/'agent_cost_dashboard'/'dispatch_metrics'/'check_protocol'/'get_handoffs' are read-only queries. 'set_llm_tier' changes model configuration. 'record_interaction'/'record_feedback'/'mark_high_impact' write telemetry data to disk. 'pause_notifications'/'resume_notifications' toggle PEFS alert delivery. 'request_handoff' initiates agent-to-agent work transfer.
paramsNoAction-specific parameters as key-value pairs. set_llm_tier: {tier: string (required, 'opus'|'sonnet'|'haiku'), context: string (optional, task type this tier applies to, e.g. 'code_review')}. record_interaction: {tool_name: string (required), tokens_in: integer (required), tokens_out: integer (required), latency_ms: integer (required)}. record_feedback: {interaction_id: string (required), rating: integer (required, 1 to 5 scale), comment: string (optional)}. mark_high_impact: {interaction_id: string (required), reason: string (required, why this is high-impact)}. request_handoff: {from_agent: string (required), to_agent: string (required), context: object (required, handoff payload with task info)}. get_llm_status/value_ratio/check_kill_switch/pause_notifications/resume_notifications/check_protocol/get_handoffs/agent_cost_dashboard/dispatch_metrics: no parameters needed.

TDQS

A4.9/5.0
Behavior5/5

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

Discloses behavioral traits beyond annotations: notes side-effects (record_interaction appends to telemetry log), persistence (kill switch state in .brain/governance/kill_switch.json), and categorizes actions as read-only vs write. No contradiction with annotations (readOnlyHint=false is consistent with mixed operations).

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?

The description is long but well-structured: starts with a summary, then usage guidance, then action-by-action details. Every sentence adds value. Minor deduction for length; could be slightly more concise without losing information.

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

Completeness5/5

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

Completely covers the tool's complexity: 14 actions, nested params, no output schema. Provides prerequisites (.brain directory), file path for kill switch, return format, and an example. No missing information needed for correct invocation.

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

Parameters5/5

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

Schema already covers 100% of parameters with descriptions, but the description adds further details: example values for enums (opus/sonnet/haiku), clarifies which actions need parameters, and provides an example with return shape. This goes beyond the schema's minimal description.

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

Purpose5/5

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

The description clearly states it configures LLM tiers, records telemetry, tracks costs, and manages safety controls. It lists specific actions grouped by purpose and explicitly differentiates from sibling tools by stating what it is NOT for (nucleus_engrams, nucleus_tasks, nucleus_agents).

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

Usage Guidelines5/5

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

Explicitly provides use contexts ('when you need to set which AI models...') and lists alternatives for other tasks. The description gives clear when-to-use and when-not-to-use guidance with named sibling tools.

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.

  1. 12 tool updates
    • Addednucleus_agents
    • Addednucleus_engrams
    • Addednucleus_features
    • Addednucleus_federation
    • Addednucleus_governance
    • Addednucleus_infra
    • Addednucleus_orchestration
    • Addednucleus_sessions
    • Addednucleus_slots
    • Addednucleus_sync
    • Addednucleus_tasks
    • Addednucleus_telemetry
  2. 8 tool updatesv1.8.8
    • Removednucleus_engrams
    • Removednucleus_features
    • Removednucleus_federation
    • Removednucleus_governance
    • Removednucleus_orchestration
    • Removednucleus_sessions
    • Removednucleus_sync
    • Removednucleus_tasks
  3. 12 tool updatesv1.8.6
    • Removednucleus_agents
    • Changednucleus_engrams2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Select the engram or observability action. 'write_engram' persists new knowledge. 'query_engrams' filters by context/tags. 'search_engrams' does full-text search. 'health'/'version'/'audit_log' are read-only diagnostics. 'morning_brief' generates a daily summary. 'context_graph' maps engram relationships."New value: +"Select the engram or observability action. 'write_engram' persists new knowledge to disk. 'query_engrams' filters by context, tags, or intensity. 'search_engrams' does full-text search. 'health'/'version'/'audit_log'/'governance_status'/'billing_summary' are read-only diagnostics. 'morning_brief' generates a daily summary. 'context_graph'/'engram_neighbors'/'render_graph' map relationships between engrams. 'pulse_and_polish'/'fusion_reactor' are compound analysis operations."
      • changedInput schema / properties / params / description
        Previous value: -"Action-specific parameters as key-value pairs. write_engram: {content: string (required, the knowledge to store), tags: string[] (optional, categorization), source: string (optional, origin attribution), metadata: object (optional, arbitrary key-value data)}. query_engrams: {query: string (optional), limit: integer (default 10), tags: string[] (optional filter)}. search_engrams: {query: string (required, search term), limit: integer (default 10)}. audit_log: {limit: integer (default 20), level: string ('info'|'warning'|'error')}. context_graph: {engram_id: string (optional, center node)}. engram_neighbors: {engram_id: string (required), depth: integer (default 1, traversal depth)}."New value: +"Action-specific parameters as key-value pairs. write_engram: {content: string (required, the knowledge to store), tags: string[] (optional, e.g. ['architecture','decision']), source: string (optional, origin attribution like 'code_review'), metadata: object (optional, arbitrary key-value data)}. query_engrams: {query: string (optional, filter text), limit: integer (optional, default 10, max results), tags: string[] (optional, filter by tags)}. search_engrams: {query: string (required, full-text search term), limit: integer (optional, default 10)}. audit_log: {limit: integer (optional, default 20), level: string (optional, 'info'|'warning'|'error')}. context_graph: {engram_id: string (optional, center node ID)}. engram_neighbors: {engram_id: string (required), depth: integer (optional, default 1, traversal depth)}. health/version/morning_brief/governance_status/billing_summary: no parameters needed."
    • Changednucleus_features2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Select the feature, proof, or mount action. 'add'/'update'/'validate' manage feature records. 'search'/'list'/'get' are read-only queries. 'generate_proof' creates audit-grade receipts. 'mount_server' connects external MCP servers. 'unmount_server'/'thanos_snap' disconnect them (destructive)."New value: +"Select the feature, proof, or mount action. 'add'/'update'/'validate' manage feature lifecycle records. 'search'/'list'/'get'/'list_mounted'/'discover_tools'/'get_proof'/'list_proofs'/'traverse_mount' are read-only queries. 'generate_proof' creates a cryptographic execution receipt. 'mount_server' connects an external MCP server (spawns process). 'invoke_tool' calls a mounted server's tool. 'unmount_server'/'thanos_snap' disconnect and remove mounted servers (destructive: kills process)."
      • changedInput schema / properties / params / description
        Previous value: -"Action-specific parameters as key-value pairs. add: {name: string (required), description: string (required), status: string (default 'proposed')}. update: {feature_id: string (required), status: string ('proposed'|'in_progress'|'done'|'cancelled'), notes: string (optional)}. get: {feature_id: string (required)}. search: {query: string (required)}. mount_server: {name: string (required, display name), command: string (required, executable), args: string[] (optional), env: object (optional, environment variables)}. invoke_tool: {server_name: string (required), tool_name: string (required), arguments: object (optional)}. generate_proof: {action: string (required, what was executed), evidence: object (required, execution artifacts)}."New value: +"Action-specific parameters as key-value pairs. add: {name: string (required), description: string (required), status: string (optional, default 'proposed')}. update: {feature_id: string (required), status: string (required, 'proposed'|'in_progress'|'done'|'cancelled'), notes: string (optional)}. get: {feature_id: string (required)}. search: {query: string (required, keyword search)}. validate: {feature_id: string (required), evidence: string (optional)}. mount_server: {name: string (required, display name), command: string (required, executable path), args: string[] (optional, command arguments), env: object (optional, environment variables)}. invoke_tool: {server_name: string (required, mounted server name), tool_name: string (required), arguments: object (optional)}. generate_proof: {action: string (required, what was executed), evidence: object (required, execution artifacts)}. unmount_server: {name: string (required)}. list/list_mounted/discover_tools/get_proof/list_proofs/traverse_mount: no parameters needed."
    • Changednucleus_federation2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Select the federation action. 'status'/'peers'/'health' are read-only queries. 'join'/'leave' modify federation membership. 'sync' replicates data between brains ('full' mode is destructive โ€” overwrites target). 'route' forwards requests to other brains."New value: +"Select the federation action. 'status'/'peers'/'health' are read-only queries returning federation state. 'join' connects to a federation (writes config). 'leave' disconnects. 'sync' replicates data between brains โ€” 'full' mode is destructive and overwrites the target brain. 'route' forwards a request to a specific peer brain."
      • changedInput schema / properties / params / description
        Previous value: -"Action-specific parameters as key-value pairs. join: {federation_id: string (required, unique federation name), brain_path: string (required, path to remote .brain)}. leave: {federation_id: string (required)}. route: {target_brain: string (required, brain identifier), action: string (required, tool action to execute), params: object (optional, forwarded parameters)}. sync: {peer_id: string (required), mode: string ('full' overwrites target or 'delta' merges, default 'delta')}. health: no parameters needed. peers: no parameters needed. status: no parameters needed."New value: +"Action-specific parameters as key-value pairs. join: {federation_id: string (required, unique federation name), brain_path: string (required, filesystem path to remote .brain directory)}. leave: {federation_id: string (required)}. route: {target_brain: string (required, brain identifier from 'peers' output), action: string (required, tool action to execute on remote), params: object (optional, parameters forwarded to remote tool)}. sync: {peer_id: string (required, brain identifier), mode: string (optional, 'full' overwrites target entirely or 'delta' merges changes only, default 'delta')}. status/peers/health: no parameters needed."
    • Changednucleus_governance2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Select the governance action to execute. 'auto_fix_loop' runs automated verification and repair. 'lock'/'unlock' control file immutability. 'set_mode' changes security posture. 'delete_file' is destructive and irreversible. 'curl' proxies external HTTP requests. 'pip_install' installs packages into the current environment."New value: +"Select the governance action to execute. 'auto_fix_loop' runs automated verification and repair. 'lock'/'unlock' control file immutability. 'set_mode' changes security posture between 'red' (restricted) and 'blue' (permissive). 'delete_file' is destructive and irreversible. 'status'/'list_directory' are read-only. 'curl' proxies external HTTP requests through egress controls. 'pip_install' installs packages with audit logging."
      • changedInput schema / properties / params / description
        Previous value: -"Action-specific parameters as key-value pairs. auto_fix_loop: {file_path: string (required, path to verify), verification_command: string (required, shell command that returns 0 on success)}. lock/unlock: {path: string (required, file or directory path)}. set_mode: {mode: string (required, 'red' or 'blue')}. list_directory: {path: string (defaults to brain root)}. delete_file: {path: string (required, DESTRUCTIVE)}. watch: {path: string (required), duration: integer (seconds, default 30)}. curl: {url: string (required), method: string (default 'GET'), headers: object, body: string}. pip_install: {package: string (required, PyPI package name)}."New value: +"Action-specific parameters as key-value pairs. auto_fix_loop: {file_path: string (required, path to verify), verification_command: string (required, shell command that returns exit code 0 on success)}. lock: {path: string (required, file or directory to make immutable)}. unlock: {path: string (required, file or directory to make writable again)}. set_mode: {mode: string (required, 'red' or 'blue')}. list_directory: {path: string (optional, defaults to .brain root)}. delete_file: {path: string (required, DESTRUCTIVE โ€” permanently removes file)}. watch: {path: string (required, file or directory to monitor), duration: integer (optional, seconds to watch, default 30)}. curl: {url: string (required), method: string (optional, 'GET'|'POST'|'PUT'|'DELETE', default 'GET'), headers: object (optional), body: string (optional)}. pip_install: {package: string (required, PyPI package name)}. status: no parameters needed."
    • Removednucleus_infra
    • Changednucleus_orchestration2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Select the orchestration action. 'satellite'/'list_commitments'/'open_loops'/'patterns'/'metrics' are read-only overviews. 'scan_commitments' analyzes session transcripts. 'close_commitment' resolves a tracked promise. 'archive_stale' is destructive. 'export' generates formatted output."New value: +"Select the orchestration action. 'satellite'/'list_commitments'/'commitment_health'/'open_loops'/'patterns'/'metrics' are read-only overviews. 'scan_commitments' analyzes session transcripts to extract promises. 'close_commitment' resolves a tracked commitment. 'add_loop' registers an open item. 'export' generates formatted output. 'weekly_challenge' creates a focus challenge. 'archive_stale' removes old commitments (destructive: deletes data)."
      • changedInput schema / properties / params / description
        Previous value: -"Action-specific parameters as key-value pairs. close_commitment: {commitment_id: string (required), resolution: string (required, how it was fulfilled)}. add_loop: {description: string (required), context: string (optional), priority: string ('high'|'medium'|'low', default 'medium')}. export: {format: string ('json'|'csv'|'markdown', default 'json'), target: string (optional, file path)}. archive_stale: {days_old: integer (required, commitments older than this are removed)}. scan_commitments: {session_id: string (optional, defaults to current session)}. satellite: no parameters needed. metrics: no parameters needed."New value: +"Action-specific parameters as key-value pairs. close_commitment: {commitment_id: string (required), resolution: string (required, how the commitment was fulfilled)}. add_loop: {description: string (required, what needs follow-up), context: string (optional, background info), priority: string (optional, 'high'|'medium'|'low', default 'medium')}. export: {format: string (optional, 'json'|'csv'|'markdown', default 'json'), target: string (optional, file path to write to)}. archive_stale: {days_old: integer (required, commitments older than this many days are removed)}. scan_commitments: {session_id: string (optional, defaults to current session)}. satellite/list_commitments/commitment_health/open_loops/patterns/metrics/weekly_challenge: no parameters needed."
    • Changednucleus_sessions2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Select the session lifecycle action. 'start'/'end' control session boundaries. 'save'/'resume' persist and restore context. 'emit_event'/'read_events' manage the event log. 'checkpoint'/'resume_checkpoint' create rollback points. 'archive_resolved'/'garbage_collect' are destructive cleanup operations."New value: +"Select the session lifecycle action. 'start'/'end' control session boundaries. 'save'/'resume' persist and restore full session context. 'emit_event' appends to the event log (write). 'read_events'/'get_state'/'list'/'check_recent'/'handoff_summary' are read-only. 'update_state' modifies key-value session state. 'checkpoint'/'resume_checkpoint' create and restore named rollback points. 'archive_resolved'/'garbage_collect' are destructive cleanup operations that delete session data."
      • changedInput schema / properties / params / description
        Previous value: -"Action-specific parameters as key-value pairs. start: {goal: string (required, session objective), tags: string[] (optional)}. save: {session_id: string (optional, auto-detected), notes: string (optional)}. resume: {session_id: string (required)}. emit_event: {event_type: string (required), data: object (required, event payload)}. read_events: {session_id: string (optional), limit: integer (default 20), event_type: string (optional filter)}. update_state: {key: string (required), value: any (required)}. checkpoint: {label: string (required, descriptive name)}. resume_checkpoint: {checkpoint_id: string (required)}. handoff_summary: {target_agent: string (optional)}."New value: +"Action-specific parameters as key-value pairs. start: {goal: string (required, session objective), tags: string[] (optional, categorization)}. save: {session_id: string (optional, auto-detected from active session), notes: string (optional)}. resume: {session_id: string (required, ID from 'list' output)}. emit_event: {event_type: string (required, e.g. 'decision'|'error'|'milestone'), data: object (required, event payload)}. read_events: {session_id: string (optional, defaults to active), limit: integer (optional, default 20), event_type: string (optional, filter by type)}. update_state: {key: string (required), value: any (required)}. checkpoint: {label: string (required, descriptive name like 'before-refactor')}. resume_checkpoint: {checkpoint_id: string (required)}. handoff_summary: {target_agent: string (optional, who receives the handoff)}. end/list/check_recent/get_state/archive_resolved/garbage_collect/propose_merges: no parameters needed."
    • Removednucleus_slots
    • Changednucleus_sync2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Select the synchronization or deployment action. 'identify_agent'/'sync_status' are read-only. 'sync_now' forces a sync (may overwrite remote state). 'write_artifact'/'shared_write' persist data. 'trigger_agent' dispatches events. 'start_deploy_poll'/'smoke_test' manage deployments."New value: +"Select the synchronization, artifact, trigger, or deployment action. 'identify_agent'/'sync_status'/'read_artifact'/'list_artifacts'/'get_triggers'/'check_deploy'/'shared_read'/'shared_list' are read-only. 'sync_now' forces state replication (may overwrite remote). 'write_artifact'/'shared_write' persist data. 'trigger_agent' dispatches events to other agents. 'evaluate_triggers' runs all trigger rules. 'start_deploy_poll'/'smoke_test' interact with external services."
      • changedInput schema / properties / params / description
        Previous value: -"Action-specific parameters as key-value pairs. write_artifact: {name: string (required, unique identifier), content: string (required), mime_type: string (default 'text/plain')}. read_artifact: {name: string (required)}. trigger_agent: {agent_id: string (required), event: string (required), payload: object (optional)}. start_deploy_poll: {service: string (required), environment: string (required, e.g. 'production')}. smoke_test: {url: string (required), expected_status: integer (default 200)}. shared_write: {key: string (required), value: any (required)}. shared_read: {key: string (required)}. sync_now: {target: string (optional, brain path)}."New value: +"Action-specific parameters as key-value pairs. write_artifact: {name: string (required, unique identifier), content: string (required, artifact data), mime_type: string (optional, default 'text/plain')}. read_artifact: {name: string (required)}. trigger_agent: {agent_id: string (required), event: string (required, event name), payload: object (optional)}. start_deploy_poll: {service: string (required, service name), environment: string (required, e.g. 'production'|'staging')}. smoke_test: {url: string (required, endpoint URL), expected_status: integer (optional, default 200)}. shared_write: {key: string (required), value: any (required)}. shared_read: {key: string (required)}. sync_now: {target: string (optional, target brain path)}. identify_agent/sync_status/list_artifacts/get_triggers/evaluate_triggers/check_deploy/complete_deploy/shared_list/sync_auto/sync_resolve: no parameters needed."
    • Changednucleus_tasks2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Select the task management action. 'add' creates a new task. 'list'/'get_next' are read-only. 'claim'/'update'/'escalate' modify task state. 'depth_*' actions track cognitive nesting. 'context_switch' saves and restores working context between tasks."New value: +"Select the task management action. 'add' creates a new task. 'list'/'get_next'/'depth_show'/'depth_map'/'context_switch_status' are read-only. 'claim' assigns a task to the current agent. 'update' changes task status. 'escalate' flags for human review. 'import_jsonl' bulk-imports from file. 'depth_push'/'depth_pop'/'depth_reset'/'depth_set_max' track cognitive nesting depth. 'context_switch' saves and restores working context between tasks."
      • changedInput schema / properties / params / description
        Previous value: -"Action-specific parameters as key-value pairs. add: {title: string (required), description: string (optional), priority: string ('critical'|'high'|'medium'|'low', default 'medium'), tags: string[] (optional)}. update: {task_id: string (required), status: string ('pending'|'in_progress'|'done'|'blocked'), notes: string (optional)}. claim: {task_id: string (required)}. escalate: {task_id: string (required), reason: string (required)}. depth_set_max: {max_depth: integer (required, typically 3-5)}. context_switch: {to_task_id: string (required)}. import_jsonl: {file_path: string (required, path to .jsonl file)}. list: {status: string (optional filter), limit: integer (default 20)}."New value: +"Action-specific parameters as key-value pairs. add: {title: string (required), description: string (optional), priority: string (optional, 'critical'|'high'|'medium'|'low', default 'medium'), tags: string[] (optional)}. update: {task_id: string (required), status: string (required, 'pending'|'in_progress'|'done'|'blocked'), notes: string (optional)}. claim: {task_id: string (required)}. escalate: {task_id: string (required), reason: string (required, why escalation is needed)}. depth_set_max: {max_depth: integer (required, typically 3-5)}. context_switch: {to_task_id: string (required)}. import_jsonl: {file_path: string (required, path to .jsonl file with task objects)}. list: {status: string (optional, filter by 'pending'|'in_progress'|'done'|'blocked'), limit: integer (optional, default 20)}. get_next/depth_push/depth_pop/depth_show/depth_reset/depth_map/context_switch_status/context_switch_reset: no parameters needed."
    • Removednucleus_telemetry
  4. 12 tool updatesv1.8.5
    • Changednucleus_agents2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"The action to execute."New value: +"Select the agent management action. 'search_memory'/'read_memory'/'dashboard'/'get_alerts'/'ingestion_stats' are read-only. 'spawn_agent' creates new agents. 'critique_code'/'fix_code' review and repair code. 'ingest_tasks' imports external tasks. 'rollback_ingestion' is destructive. 'set_alert_threshold' configures monitoring."
      • changedInput schema / properties / params / description
        Previous value: -"Parameters vary by action. spawn_agent: {role, goal, tools[]}. critique_code: {file_path, diff}. fix_code: {file_path, issue}. search_memory: {query, limit}. ingest_tasks: {source, file_path}. set_alert_threshold: {metric, threshold, operator: 'gt'|'lt'|'eq'}. handoff_task: {task_id, to_agent, context{}}."New value: +"Action-specific parameters as key-value pairs. spawn_agent: {role: string (required, e.g. 'reviewer'|'implementer'|'researcher'), goal: string (required), tools: string[] (optional, tool names to grant)}. critique_code: {file_path: string (required), diff: string (optional, specific diff to review)}. fix_code: {file_path: string (required), issue: string (required, description of the problem)}. search_memory: {query: string (required), limit: integer (default 10)}. ingest_tasks: {source: string (required, 'github'|'csv'|'jsonl'), file_path: string (required)}. set_alert_threshold: {metric: string (required), threshold: number (required), operator: string ('gt'|'lt'|'eq', default 'gt')}. handoff_task: {task_id: string (required), to_agent: string (required), context: object (optional)}."
    • Changednucleus_engrams2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"The action to execute."New value: +"Select the engram or observability action. 'write_engram' persists new knowledge. 'query_engrams' filters by context/tags. 'search_engrams' does full-text search. 'health'/'version'/'audit_log' are read-only diagnostics. 'morning_brief' generates a daily summary. 'context_graph' maps engram relationships."
      • changedInput schema / properties / params / description
        Previous value: -"Parameters vary by action. write_engram: {content, tags[], source, metadata{}}. query_engrams: {query, limit, tags[]}. search_engrams: {query, limit}. audit_log: {limit, level}. context_graph: {engram_id}. engram_neighbors: {engram_id, depth}."New value: +"Action-specific parameters as key-value pairs. write_engram: {content: string (required, the knowledge to store), tags: string[] (optional, categorization), source: string (optional, origin attribution), metadata: object (optional, arbitrary key-value data)}. query_engrams: {query: string (optional), limit: integer (default 10), tags: string[] (optional filter)}. search_engrams: {query: string (required, search term), limit: integer (default 10)}. audit_log: {limit: integer (default 20), level: string ('info'|'warning'|'error')}. context_graph: {engram_id: string (optional, center node)}. engram_neighbors: {engram_id: string (required), depth: integer (default 1, traversal depth)}."
    • Changednucleus_features2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"The action to execute."New value: +"Select the feature, proof, or mount action. 'add'/'update'/'validate' manage feature records. 'search'/'list'/'get' are read-only queries. 'generate_proof' creates audit-grade receipts. 'mount_server' connects external MCP servers. 'unmount_server'/'thanos_snap' disconnect them (destructive)."
      • changedInput schema / properties / params / description
        Previous value: -"Parameters vary by action. add: {name, description, status}. update: {feature_id, status, notes}. get: {feature_id}. search: {query}. mount_server: {name, command, args[], env{}}. invoke_tool: {server_name, tool_name, arguments{}}. generate_proof: {action, evidence{}}."New value: +"Action-specific parameters as key-value pairs. add: {name: string (required), description: string (required), status: string (default 'proposed')}. update: {feature_id: string (required), status: string ('proposed'|'in_progress'|'done'|'cancelled'), notes: string (optional)}. get: {feature_id: string (required)}. search: {query: string (required)}. mount_server: {name: string (required, display name), command: string (required, executable), args: string[] (optional), env: object (optional, environment variables)}. invoke_tool: {server_name: string (required), tool_name: string (required), arguments: object (optional)}. generate_proof: {action: string (required, what was executed), evidence: object (required, execution artifacts)}."
    • Changednucleus_federation2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"The action to execute."New value: +"Select the federation action. 'status'/'peers'/'health' are read-only queries. 'join'/'leave' modify federation membership. 'sync' replicates data between brains ('full' mode is destructive โ€” overwrites target). 'route' forwards requests to other brains."
      • changedInput schema / properties / params / description
        Previous value: -"Parameters vary by action. join: {federation_id, brain_path}. leave: {federation_id}. route: {target_brain, action, params{}}. sync: {peer_id, mode: 'full'|'delta'}."New value: +"Action-specific parameters as key-value pairs. join: {federation_id: string (required, unique federation name), brain_path: string (required, path to remote .brain)}. leave: {federation_id: string (required)}. route: {target_brain: string (required, brain identifier), action: string (required, tool action to execute), params: object (optional, forwarded parameters)}. sync: {peer_id: string (required), mode: string ('full' overwrites target or 'delta' merges, default 'delta')}. health: no parameters needed. peers: no parameters needed. status: no parameters needed."
    • Changednucleus_governance2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"The action to execute."New value: +"Select the governance action to execute. 'auto_fix_loop' runs automated verification and repair. 'lock'/'unlock' control file immutability. 'set_mode' changes security posture. 'delete_file' is destructive and irreversible. 'curl' proxies external HTTP requests. 'pip_install' installs packages into the current environment."
      • changedInput schema / properties / params / description
        Previous value: -"Parameters vary by action. auto_fix_loop: {file_path, verification_command}. lock/unlock: {path}. set_mode: {mode: 'red'|'blue'}. list_directory: {path}. delete_file: {path}. watch: {path, duration}. curl: {url, method, headers, body}. pip_install: {package}."New value: +"Action-specific parameters as key-value pairs. auto_fix_loop: {file_path: string (required, path to verify), verification_command: string (required, shell command that returns 0 on success)}. lock/unlock: {path: string (required, file or directory path)}. set_mode: {mode: string (required, 'red' or 'blue')}. list_directory: {path: string (defaults to brain root)}. delete_file: {path: string (required, DESTRUCTIVE)}. watch: {path: string (required), duration: integer (seconds, default 30)}. curl: {url: string (required), method: string (default 'GET'), headers: object, body: string}. pip_install: {package: string (required, PyPI package name)}."
    • Changednucleus_infra2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"The action to execute."New value: +"Select the infrastructure or strategy action. 'file_changes'/'gcloud_status'/'list_services'/'status_report' are read-only. 'gcloud_services' requires project_id. 'manage_strategy'/'update_roadmap' modify persistent data. 'synthesize_strategy'/'optimize_workflow' generate recommendations."
      • changedInput schema / properties / params / description
        Previous value: -"Parameters vary by action. file_changes: {since, path}. gcloud_services: {project_id}. status_report: {format: 'markdown'|'json', scope}. update_roadmap: {item, status, notes}. optimize_workflow: {target_area}."New value: +"Action-specific parameters as key-value pairs. file_changes: {since: string (optional, ISO date or relative like '24h'), path: string (optional, directory to scan)}. gcloud_services: {project_id: string (required, GCP project ID)}. status_report: {format: string ('markdown'|'json', default 'markdown'), scope: string (optional, 'full'|'summary')}. update_roadmap: {item: string (required, roadmap item name), status: string (required, new status), notes: string (optional)}. optimize_workflow: {target_area: string (required, area to analyze)}. manage_strategy: {operation: string ('read'|'write'), key: string, value: string}."
    • Changednucleus_orchestration2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"The action to execute."New value: +"Select the orchestration action. 'satellite'/'list_commitments'/'open_loops'/'patterns'/'metrics' are read-only overviews. 'scan_commitments' analyzes session transcripts. 'close_commitment' resolves a tracked promise. 'archive_stale' is destructive. 'export' generates formatted output."
      • changedInput schema / properties / params / description
        Previous value: -"Parameters vary by action. close_commitment: {commitment_id, resolution}. add_loop: {description, context, priority}. export: {format: 'json'|'csv'|'markdown', target}. archive_stale: {days_old}. scan_commitments: {session_id}."New value: +"Action-specific parameters as key-value pairs. close_commitment: {commitment_id: string (required), resolution: string (required, how it was fulfilled)}. add_loop: {description: string (required), context: string (optional), priority: string ('high'|'medium'|'low', default 'medium')}. export: {format: string ('json'|'csv'|'markdown', default 'json'), target: string (optional, file path)}. archive_stale: {days_old: integer (required, commitments older than this are removed)}. scan_commitments: {session_id: string (optional, defaults to current session)}. satellite: no parameters needed. metrics: no parameters needed."
    • Changednucleus_sessions2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"The action to execute."New value: +"Select the session lifecycle action. 'start'/'end' control session boundaries. 'save'/'resume' persist and restore context. 'emit_event'/'read_events' manage the event log. 'checkpoint'/'resume_checkpoint' create rollback points. 'archive_resolved'/'garbage_collect' are destructive cleanup operations."
      • changedInput schema / properties / params / description
        Previous value: -"Parameters vary by action. start: {goal, tags[]}. save: {session_id, notes}. resume: {session_id}. emit_event: {event_type, data{}}. read_events: {session_id, limit, event_type}. update_state: {key, value}. checkpoint: {label}. resume_checkpoint: {checkpoint_id}."New value: +"Action-specific parameters as key-value pairs. start: {goal: string (required, session objective), tags: string[] (optional)}. save: {session_id: string (optional, auto-detected), notes: string (optional)}. resume: {session_id: string (required)}. emit_event: {event_type: string (required), data: object (required, event payload)}. read_events: {session_id: string (optional), limit: integer (default 20), event_type: string (optional filter)}. update_state: {key: string (required), value: any (required)}. checkpoint: {label: string (required, descriptive name)}. resume_checkpoint: {checkpoint_id: string (required)}. handoff_summary: {target_agent: string (optional)}."
    • Changednucleus_slots2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"The action to execute."New value: +"Select the slot or sprint action. 'status_dashboard'/'mission_status' are read-only. 'orchestrate' assigns tasks to slots. 'autopilot_sprint' runs automated work cycles. 'start_mission' creates multi-sprint goals. 'force_assign' overrides slot assignment. 'halt_sprint'/'resume_sprint' control execution."
      • changedInput schema / properties / params / description
        Previous value: -"Parameters vary by action. orchestrate: {strategy, max_slots}. slot_complete: {slot_id, result}. force_assign: {slot_id, task_id}. start_mission: {name, goal, sprint_count}. autopilot_sprint: {duration_minutes, focus_tags[]}."New value: +"Action-specific parameters as key-value pairs. orchestrate: {strategy: string (optional, 'fifo'|'priority'|'balanced'), max_slots: integer (default 3)}. slot_complete: {slot_id: string (required), result: string (required, completion summary)}. force_assign: {slot_id: string (required), task_id: string (required)}. start_mission: {name: string (required), goal: string (required), sprint_count: integer (default 3)}. autopilot_sprint: {duration_minutes: integer (default 25, pomodoro-style), focus_tags: string[] (optional, filter tasks by tag)}. mission_status: {mission_id: string (optional, defaults to active mission)}. halt_sprint: no parameters needed. resume_sprint: no parameters needed."
    • Changednucleus_sync2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"The action to execute."New value: +"Select the synchronization or deployment action. 'identify_agent'/'sync_status' are read-only. 'sync_now' forces a sync (may overwrite remote state). 'write_artifact'/'shared_write' persist data. 'trigger_agent' dispatches events. 'start_deploy_poll'/'smoke_test' manage deployments."
      • changedInput schema / properties / params / description
        Previous value: -"Parameters vary by action. write_artifact: {name, content, mime_type}. read_artifact: {name}. trigger_agent: {agent_id, event, payload{}}. start_deploy_poll: {service, environment}. smoke_test: {url, expected_status}. shared_write: {key, value}. shared_read: {key}."New value: +"Action-specific parameters as key-value pairs. write_artifact: {name: string (required, unique identifier), content: string (required), mime_type: string (default 'text/plain')}. read_artifact: {name: string (required)}. trigger_agent: {agent_id: string (required), event: string (required), payload: object (optional)}. start_deploy_poll: {service: string (required), environment: string (required, e.g. 'production')}. smoke_test: {url: string (required), expected_status: integer (default 200)}. shared_write: {key: string (required), value: any (required)}. shared_read: {key: string (required)}. sync_now: {target: string (optional, brain path)}."
    • Changednucleus_tasks2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"The action to execute."New value: +"Select the task management action. 'add' creates a new task. 'list'/'get_next' are read-only. 'claim'/'update'/'escalate' modify task state. 'depth_*' actions track cognitive nesting. 'context_switch' saves and restores working context between tasks."
      • changedInput schema / properties / params / description
        Previous value: -"Parameters vary by action. add: {title, description, priority: 'critical'|'high'|'medium'|'low', tags[]}. update: {task_id, status: 'pending'|'in_progress'|'done'|'blocked', notes}. claim: {task_id}. escalate: {task_id, reason}. depth_set_max: {max_depth}. context_switch: {to_task_id}. import_jsonl: {file_path}."New value: +"Action-specific parameters as key-value pairs. add: {title: string (required), description: string (optional), priority: string ('critical'|'high'|'medium'|'low', default 'medium'), tags: string[] (optional)}. update: {task_id: string (required), status: string ('pending'|'in_progress'|'done'|'blocked'), notes: string (optional)}. claim: {task_id: string (required)}. escalate: {task_id: string (required), reason: string (required)}. depth_set_max: {max_depth: integer (required, typically 3-5)}. context_switch: {to_task_id: string (required)}. import_jsonl: {file_path: string (required, path to .jsonl file)}. list: {status: string (optional filter), limit: integer (default 20)}."
    • Changednucleus_telemetry2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"The action to execute."New value: +"Select the telemetry or control action. 'get_llm_status'/'value_ratio'/'check_kill_switch'/'agent_cost_dashboard'/'dispatch_metrics' are read-only. 'set_llm_tier' changes model config. 'record_interaction'/'record_feedback'/'mark_high_impact' write telemetry data. 'pause_notifications'/'resume_notifications' toggle alerts."
      • changedInput schema / properties / params / description
        Previous value: -"Parameters vary by action. set_llm_tier: {tier: 'opus'|'sonnet'|'haiku', context}. record_interaction: {tool_name, tokens_in, tokens_out, latency_ms}. record_feedback: {interaction_id, rating, comment}. mark_high_impact: {interaction_id, reason}. request_handoff: {from_agent, to_agent, context{}}."New value: +"Action-specific parameters as key-value pairs. set_llm_tier: {tier: string (required, 'opus'|'sonnet'|'haiku'), context: string (optional, task type this applies to)}. record_interaction: {tool_name: string (required), tokens_in: integer (required), tokens_out: integer (required), latency_ms: integer (required)}. record_feedback: {interaction_id: string (required), rating: integer (required, 1-5 scale), comment: string (optional)}. mark_high_impact: {interaction_id: string (required), reason: string (required)}. request_handoff: {from_agent: string (required), to_agent: string (required), context: object (required, handoff payload)}. check_kill_switch: no parameters needed."
  5. 12 tool updatesv1.8.3
    • Changednucleus_agents3 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Action to execute (see tool description)"New value: +"The action to execute."
      • addedInput schema / properties / action / enum
        Added value: +[
        +  "spawn_agent",
        +  "apply_critique",
        +  "orchestrate_swarm",
        +  "search_memory",
        +  "read_memory",
        +  "respond_to_consent",
        +  "list_pending_consents",
        +  "critique_code",
        +  "fix_code",
        +  "session_briefing",
        +  "register_session",
        +  "handoff_task",
        +  "ingest_tasks",
        +  "rollback_ingestion",
        +  "ingestion_stats",
        +  "dashboard",
        +  "snapshot_dashboard",
        +  "list_dashboard_snapshots",
        +  "get_alerts",
        +  "set_alert_threshold"
        +]
      • changedInput schema / properties / params / description
        Previous value: -"Action parameters"New value: +"Parameters vary by action. spawn_agent: {role, goal, tools[]}. critique_code: {file_path, diff}. fix_code: {file_path, issue}. search_memory: {query, limit}. ingest_tasks: {source, file_path}. set_alert_threshold: {metric, threshold, operator: 'gt'|'lt'|'eq'}. handoff_task: {task_id, to_agent, context{}}."
    • Changednucleus_engrams3 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Action to execute (see tool description)"New value: +"The action to execute."
      • addedInput schema / properties / action / enum
        Added value: +[
        +  "health",
        +  "version",
        +  "audit_log",
        +  "write_engram",
        +  "query_engrams",
        +  "search_engrams",
        +  "governance_status",
        +  "morning_brief",
        +  "pulse_and_polish",
        +  "self_healing_sre",
        +  "fusion_reactor",
        +  "context_graph",
        +  "engram_neighbors",
        +  "render_graph",
        +  "billing_summary"
        +]
      • changedInput schema / properties / params / description
        Previous value: -"Action parameters"New value: +"Parameters vary by action. write_engram: {content, tags[], source, metadata{}}. query_engrams: {query, limit, tags[]}. search_engrams: {query, limit}. audit_log: {limit, level}. context_graph: {engram_id}. engram_neighbors: {engram_id, depth}."
    • Changednucleus_features3 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Action to execute (see tool description)"New value: +"The action to execute."
      • addedInput schema / properties / action / enum
        Added value: +[
        +  "add",
        +  "list",
        +  "get",
        +  "update",
        +  "validate",
        +  "search",
        +  "mount_server",
        +  "thanos_snap",
        +  "unmount_server",
        +  "list_mounted",
        +  "discover_tools",
        +  "invoke_tool",
        +  "traverse_mount",
        +  "generate_proof",
        +  "get_proof",
        +  "list_proofs"
        +]
      • changedInput schema / properties / params / description
        Previous value: -"Action parameters"New value: +"Parameters vary by action. add: {name, description, status}. update: {feature_id, status, notes}. get: {feature_id}. search: {query}. mount_server: {name, command, args[], env{}}. invoke_tool: {server_name, tool_name, arguments{}}. generate_proof: {action, evidence{}}."
    • Changednucleus_federation3 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Action to execute (see tool description)"New value: +"The action to execute."
      • addedInput schema / properties / action / enum
        Added value: +[
        +  "status",
        +  "join",
        +  "leave",
        +  "peers",
        +  "sync",
        +  "route",
        +  "health"
        +]
      • changedInput schema / properties / params / description
        Previous value: -"Action parameters"New value: +"Parameters vary by action. join: {federation_id, brain_path}. leave: {federation_id}. route: {target_brain, action, params{}}. sync: {peer_id, mode: 'full'|'delta'}."
    • Changednucleus_governance3 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Action to execute (see tool description)"New value: +"The action to execute."
      • addedInput schema / properties / action / enum
        Added value: +[
        +  "auto_fix_loop",
        +  "lock",
        +  "unlock",
        +  "set_mode",
        +  "list_directory",
        +  "delete_file",
        +  "watch",
        +  "status",
        +  "curl",
        +  "pip_install"
        +]
      • changedInput schema / properties / params / description
        Previous value: -"Action parameters"New value: +"Parameters vary by action. auto_fix_loop: {file_path, verification_command}. lock/unlock: {path}. set_mode: {mode: 'red'|'blue'}. list_directory: {path}. delete_file: {path}. watch: {path, duration}. curl: {url, method, headers, body}. pip_install: {package}."
    • Changednucleus_infra3 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Action to execute (see tool description)"New value: +"The action to execute."
      • addedInput schema / properties / action / enum
        Added value: +[
        +  "file_changes",
        +  "gcloud_status",
        +  "gcloud_services",
        +  "list_services",
        +  "scan_marketing_log",
        +  "synthesize_strategy",
        +  "status_report",
        +  "optimize_workflow",
        +  "manage_strategy",
        +  "update_roadmap"
        +]
      • changedInput schema / properties / params / description
        Previous value: -"Action parameters"New value: +"Parameters vary by action. file_changes: {since, path}. gcloud_services: {project_id}. status_report: {format: 'markdown'|'json', scope}. update_roadmap: {item, status, notes}. optimize_workflow: {target_area}."
    • Changednucleus_orchestration3 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Action to execute (see tool description)"New value: +"The action to execute."
      • addedInput schema / properties / action / enum
        Added value: +[
        +  "satellite",
        +  "scan_commitments",
        +  "archive_stale",
        +  "export",
        +  "list_commitments",
        +  "close_commitment",
        +  "commitment_health",
        +  "open_loops",
        +  "add_loop",
        +  "weekly_challenge",
        +  "patterns",
        +  "metrics"
        +]
      • changedInput schema / properties / params / description
        Previous value: -"Action parameters"New value: +"Parameters vary by action. close_commitment: {commitment_id, resolution}. add_loop: {description, context, priority}. export: {format: 'json'|'csv'|'markdown', target}. archive_stale: {days_old}. scan_commitments: {session_id}."
    • Changednucleus_sessions3 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Action to execute (see tool description)"New value: +"The action to execute."
      • addedInput schema / properties / action / enum
        Added value: +[
        +  "save",
        +  "resume",
        +  "list",
        +  "check_recent",
        +  "end",
        +  "start",
        +  "archive_resolved",
        +  "propose_merges",
        +  "garbage_collect",
        +  "emit_event",
        +  "read_events",
        +  "get_state",
        +  "update_state",
        +  "checkpoint",
        +  "resume_checkpoint",
        +  "handoff_summary"
        +]
      • changedInput schema / properties / params / description
        Previous value: -"Action parameters"New value: +"Parameters vary by action. start: {goal, tags[]}. save: {session_id, notes}. resume: {session_id}. emit_event: {event_type, data{}}. read_events: {session_id, limit, event_type}. update_state: {key, value}. checkpoint: {label}. resume_checkpoint: {checkpoint_id}."
    • Changednucleus_slots3 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Action to execute (see tool description)"New value: +"The action to execute."
      • addedInput schema / properties / action / enum
        Added value: +[
        +  "orchestrate",
        +  "slot_complete",
        +  "slot_exhaust",
        +  "status_dashboard",
        +  "autopilot_sprint",
        +  "force_assign",
        +  "autopilot_sprint_v2",
        +  "start_mission",
        +  "mission_status",
        +  "halt_sprint",
        +  "resume_sprint"
        +]
      • changedInput schema / properties / params / description
        Previous value: -"Action parameters"New value: +"Parameters vary by action. orchestrate: {strategy, max_slots}. slot_complete: {slot_id, result}. force_assign: {slot_id, task_id}. start_mission: {name, goal, sprint_count}. autopilot_sprint: {duration_minutes, focus_tags[]}."
    • Changednucleus_sync3 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Action to execute (see tool description)"New value: +"The action to execute."
      • addedInput schema / properties / action / enum
        Added value: +[
        +  "identify_agent",
        +  "sync_status",
        +  "sync_now",
        +  "sync_auto",
        +  "sync_resolve",
        +  "read_artifact",
        +  "write_artifact",
        +  "list_artifacts",
        +  "trigger_agent",
        +  "get_triggers",
        +  "evaluate_triggers",
        +  "start_deploy_poll",
        +  "check_deploy",
        +  "complete_deploy",
        +  "smoke_test",
        +  "shared_read",
        +  "shared_write",
        +  "shared_list"
        +]
      • changedInput schema / properties / params / description
        Previous value: -"Action parameters"New value: +"Parameters vary by action. write_artifact: {name, content, mime_type}. read_artifact: {name}. trigger_agent: {agent_id, event, payload{}}. start_deploy_poll: {service, environment}. smoke_test: {url, expected_status}. shared_write: {key, value}. shared_read: {key}."
    • Changednucleus_tasks3 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Action to execute (see tool description)"New value: +"The action to execute."
      • addedInput schema / properties / action / enum
        Added value: +[
        +  "list",
        +  "get_next",
        +  "claim",
        +  "update",
        +  "add",
        +  "import_jsonl",
        +  "escalate",
        +  "depth_push",
        +  "depth_pop",
        +  "depth_show",
        +  "depth_reset",
        +  "depth_set_max",
        +  "depth_map",
        +  "context_switch",
        +  "context_switch_status",
        +  "context_switch_reset"
        +]
      • changedInput schema / properties / params / description
        Previous value: -"Action parameters"New value: +"Parameters vary by action. add: {title, description, priority: 'critical'|'high'|'medium'|'low', tags[]}. update: {task_id, status: 'pending'|'in_progress'|'done'|'blocked', notes}. claim: {task_id}. escalate: {task_id, reason}. depth_set_max: {max_depth}. context_switch: {to_task_id}. import_jsonl: {file_path}."
    • Changednucleus_telemetry3 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Action to execute (see tool description)"New value: +"The action to execute."
      • addedInput schema / properties / action / enum
        Added value: +[
        +  "set_llm_tier",
        +  "get_llm_status",
        +  "record_interaction",
        +  "value_ratio",
        +  "check_kill_switch",
        +  "pause_notifications",
        +  "resume_notifications",
        +  "record_feedback",
        +  "mark_high_impact",
        +  "check_protocol",
        +  "request_handoff",
        +  "get_handoffs",
        +  "agent_cost_dashboard",
        +  "dispatch_metrics"
        +]
      • changedInput schema / properties / params / description
        Previous value: -"Action parameters"New value: +"Parameters vary by action. set_llm_tier: {tier: 'opus'|'sonnet'|'haiku', context}. record_interaction: {tool_name, tokens_in, tokens_out, latency_ms}. record_feedback: {interaction_id, rating, comment}. mark_high_impact: {interaction_id, reason}. request_handoff: {from_agent, to_agent, context{}}."
  6. 12 tool updatesv1.8.0
    • First observednucleus_agents
    • First observednucleus_engrams
    • First observednucleus_features
    • First observednucleus_federation
    • First observednucleus_governance
    • First observednucleus_infra
    • First observednucleus_orchestration
    • First observednucleus_sessions
    • First observednucleus_slots
    • First observednucleus_sync
    • First observednucleus_tasks
    • First observednucleus_telemetry

TDQS

A4.6/5.0

Scored across 12 tools

Disambiguation4/5

Most tools have distinct domains (memory, tasks, sessions, etc.) with explicit 'Do NOT use' guidance. However, orchestration's satellite overview and infra's status_report both provide high-level summaries, causing minor overlap.

Naming Consistency5/5

All tools follow the consistent pattern 'nucleus_<noun>', and actions within each tool use clear verb-noun style (e.g., add, list, get, update). No mixing of conventions.

Tool Count5/5

12 tools is well-scoped for a comprehensive agent operating system. Each tool covers a clear functional area without unnecessary bloat.

Completeness5/5

The tool set covers memory, tasks, sessions, agent coordination, security, infrastructure, telemetry, and more. It includes CRUD-like operations for most resources and handles lifecycle, state sharing, and automation.

Maintenance

ActivityActive
ResponsivenessSyncing

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Provides a persistent, vendor-neutral memory layer that allows AI tools and agents to share context and knowledge across different platforms while maintaining local data ownership. It enables users to store, recall, and manage structured memories through hybrid semantic search and automated context assembly.
    8 npm
    Apache 2.0
  • A
    license
    A
    quality
    C
    maintenance
    AI memory that works like yours. Neural pathway architecture gives your AI persistent recall, contextual awareness, and cross-session continuity the way human memory actually works. 14 MCP tools. Works with Claude Code, Cursor, Windsurf, and any MCP client. $50/mo unlimited.
    15
    MIT
  • A
    license
    A
    quality
    A
    maintenance
    A local memory layer for AI coding tools that stores user preferences, lessons, and project context as local files, exposed via MCP so different AI tools can share the same understanding of you.
    19
    380 PyPI
    160
    AGPL 3.0
  • A
    license
    B
    quality
    D
    maintenance
    A shared memory layer for AI agents โ€” one memory.md synced across Claude Desktop, Cursor, Claude Code, OpenAI Codex, and any MCP client.
    4
    2
    MIT