Nucleus MCP
Nucleus MCP is a portable, file-based AI decision log and agent operating system providing 35+ tools across 13 facades for persistent memory, task orchestration, governance, and multi-agent coordination.
๐ง Memory (Engrams) โ Persistent key-value store with full-text search, context graphs, relationship traversal, and daily briefs.
โ Task Management โ Priority queue with escalation, human-in-the-loop gates, cognitive depth tracking, and bulk JSONL import.
๐ Session Lifecycle โ Start/save/resume sessions, emit structured events, manage key-value state, create checkpoints for rollback, and generate handoff summaries.
๐ Governance & Security โ File locking, red/blue security modes, automated verify-diagnose-fix-retry loops, egress-controlled HTTP proxying, package installs with audit logging, and compliance frameworks (EU DORA, SOC2, MAS TRM) with signed audit reports.
๐ค Multi-Agent Sync โ Cross-agent artifact sharing, shared key-value store, trigger-based automation, and deployment polling/smoke testing.
๐ Sprint & Slot Execution โ Time-boxed work slots with fifo/priority/balanced strategies, 25-minute autopilot sprints, and multi-sprint missions with automatic sequencing.
๐ Federation โ Connect and sync multiple brain instances across distributed environments, route requests to peers, and monitor connectivity/latency.
๐ค Agent Management โ Spawn sub-agents (reviewer, implementer, researcher, planner), run automated code review/repair, orchestrate swarms for parallel tasks, and import tasks from GitHub/CSV/JSONL.
๐ญ Orchestration & Strategy โ Satellite bird's-eye view of all active work, commitment tracking, pattern detection, and data export in JSON/CSV/Markdown.
๐ Telemetry & Safety โ LLM tier configuration, interaction logging for DPO training pairs, human feedback capture, kill switches, notification pausing, and per-agent cost dashboards.
๐๏ธ Infrastructure โ File change monitoring, GCP service status, local service detection, and strategic planning report generation.
๐ Features & Proofs โ Feature lifecycle tracking, cryptographic Ed25519-signed execution proofs for audit compliance, and mounting external MCP servers as composable sub-tools.
โ๏ธ Execution Verification (Align/Ground) โ One-call alignment corrections that record verdicts and create DPO training pairs, plus 5-tier code verification (syntax, imports, tests, runtime) with auto-fix loops.
Integrates with Codeium's Windsurf editor to synchronize project state, session memory, and decision history with other AI-powered development environments.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Nucleus MCPWhat decisions have we made about the architecture?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
.brain โ the portable decision log
The portable decision log your AI tools all read. One MCP server. Any AI tool. Plain files.
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-rabbitholeClaude 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 improvesGROUND โ 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 founderTwo 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 foundThen 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:
NUCLEUS_BRAIN_PATHenvironment variable (explicit)Walk up from CWD looking for
.brain/directoryFall 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 chatPipe-friendly:
nucleus engram search "test" | jq '.key'
nucleus task list --format tsv | cut -f1,3Compliance
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 SOC2Jurisdiction | Retention | HITL Ops | Kill Switch |
| 7 years | 5 types | Required |
| 5 years | 5 types | Required |
| 1 year | 3 types | Optional |
| 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=falseSee TELEMETRY.md for details.
Contributing
Bug? Open an Issue
Feature idea? Start a Discussion
Code? See CONTRIBUTING.md
Chat? Discord
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 toolsnucleus_agentsADestructiveInspect
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}]}}.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Select 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. | |
| params | No | Action-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
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.
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.
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.
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.
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.
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}}.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 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. | |
| params | No | 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. |
TDQS
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.
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.
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.
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.
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.
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_featuresADestructiveInspect
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}}.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 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). | |
| params | No | 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. |
TDQS
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.
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.
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.
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.
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.
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}}.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 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. | |
| params | No | 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. |
TDQS
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.
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.
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.
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.
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.
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_governanceADestructiveInspect
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}}.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 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. | |
| params | No | 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. |
TDQS
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.
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.
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.
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.
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.
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}]}}.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Select 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. | |
| params | No | Action-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
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.
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.
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.
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.
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.
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_orchestrationADestructiveInspect
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}}}.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 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). | |
| params | No | 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. |
TDQS
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.
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.
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.
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.
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.
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_sessionsADestructiveInspect
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}}.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 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. | |
| params | No | 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. |
TDQS
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.
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.
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.
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.
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.
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'}}.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Select 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. | |
| params | No | Action-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
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.
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.
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.
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.
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.
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'}}.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 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. | |
| params | No | 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. |
TDQS
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.
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.
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.
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.
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.
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}}.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 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. | |
| params | No | 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. |
TDQS
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.
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.
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.
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.
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.
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}}.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Select 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. | |
| params | No | Action-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
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.
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.
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.
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.
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.
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.
12 tool updates
- Added
nucleus_agents - Added
nucleus_engrams - Added
nucleus_features - Added
nucleus_federation - Added
nucleus_governance - Added
nucleus_infra - Added
nucleus_orchestration - Added
nucleus_sessions - Added
nucleus_slots - Added
nucleus_sync - Added
nucleus_tasks - Added
nucleus_telemetry
8 tool updates
v1.8.8- Removed
nucleus_engrams - Removed
nucleus_features - Removed
nucleus_federation - Removed
nucleus_governance - Removed
nucleus_orchestration - Removed
nucleus_sessions - Removed
nucleus_sync - Removed
nucleus_tasks
12 tool updates
v1.8.6- Removed
nucleus_agents - Changed
nucleus_engrams2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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." - changed
Input schema / properties / params / descriptionPrevious 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."
- Changed
nucleus_features2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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)." - changed
Input schema / properties / params / descriptionPrevious 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."
- Changed
nucleus_federation2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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." - changed
Input schema / properties / params / descriptionPrevious 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."
- Changed
nucleus_governance2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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." - changed
Input schema / properties / params / descriptionPrevious 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."
- Removed
nucleus_infra - Changed
nucleus_orchestration2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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)." - changed
Input schema / properties / params / descriptionPrevious 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."
- Changed
nucleus_sessions2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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." - changed
Input schema / properties / params / descriptionPrevious 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."
- Removed
nucleus_slots - Changed
nucleus_sync2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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." - changed
Input schema / properties / params / descriptionPrevious 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."
- Changed
nucleus_tasks2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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." - changed
Input schema / properties / params / descriptionPrevious 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."
- Removed
nucleus_telemetry
12 tool updates
v1.8.5- Changed
nucleus_agents2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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." - changed
Input schema / properties / params / descriptionPrevious 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)}."
- Changed
nucleus_engrams2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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." - changed
Input schema / properties / params / descriptionPrevious 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)}."
- Changed
nucleus_features2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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)." - changed
Input schema / properties / params / descriptionPrevious 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)}."
- Changed
nucleus_federation2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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." - changed
Input schema / properties / params / descriptionPrevious 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."
- Changed
nucleus_governance2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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." - changed
Input schema / properties / params / descriptionPrevious 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)}."
- Changed
nucleus_infra2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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." - changed
Input schema / properties / params / descriptionPrevious 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}."
- Changed
nucleus_orchestration2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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." - changed
Input schema / properties / params / descriptionPrevious 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."
- Changed
nucleus_sessions2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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." - changed
Input schema / properties / params / descriptionPrevious 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)}."
- Changed
nucleus_slots2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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." - changed
Input schema / properties / params / descriptionPrevious 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."
- Changed
nucleus_sync2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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." - changed
Input schema / properties / params / descriptionPrevious 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)}."
- Changed
nucleus_tasks2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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." - changed
Input schema / properties / params / descriptionPrevious 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)}."
- Changed
nucleus_telemetry2 fields changed- changed
Input schema / properties / action / descriptionPrevious 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." - changed
Input schema / properties / params / descriptionPrevious 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."
12 tool updates
v1.8.3- Changed
nucleus_agents3 fields changed- changed
Input schema / properties / action / descriptionPrevious value: -"Action to execute (see tool description)"New value: +"The action to execute." - added
Input schema / properties / action / enumAdded 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" +] - changed
Input schema / properties / params / descriptionPrevious 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{}}."
- Changed
nucleus_engrams3 fields changed- changed
Input schema / properties / action / descriptionPrevious value: -"Action to execute (see tool description)"New value: +"The action to execute." - added
Input schema / properties / action / enumAdded 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" +] - changed
Input schema / properties / params / descriptionPrevious 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}."
- Changed
nucleus_features3 fields changed- changed
Input schema / properties / action / descriptionPrevious value: -"Action to execute (see tool description)"New value: +"The action to execute." - added
Input schema / properties / action / enumAdded 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" +] - changed
Input schema / properties / params / descriptionPrevious 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{}}."
- Changed
nucleus_federation3 fields changed- changed
Input schema / properties / action / descriptionPrevious value: -"Action to execute (see tool description)"New value: +"The action to execute." - added
Input schema / properties / action / enumAdded value: +[ + "status", + "join", + "leave", + "peers", + "sync", + "route", + "health" +] - changed
Input schema / properties / params / descriptionPrevious 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'}."
- Changed
nucleus_governance3 fields changed- changed
Input schema / properties / action / descriptionPrevious value: -"Action to execute (see tool description)"New value: +"The action to execute." - added
Input schema / properties / action / enumAdded value: +[ + "auto_fix_loop", + "lock", + "unlock", + "set_mode", + "list_directory", + "delete_file", + "watch", + "status", + "curl", + "pip_install" +] - changed
Input schema / properties / params / descriptionPrevious 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}."
- Changed
nucleus_infra3 fields changed- changed
Input schema / properties / action / descriptionPrevious value: -"Action to execute (see tool description)"New value: +"The action to execute." - added
Input schema / properties / action / enumAdded value: +[ + "file_changes", + "gcloud_status", + "gcloud_services", + "list_services", + "scan_marketing_log", + "synthesize_strategy", + "status_report", + "optimize_workflow", + "manage_strategy", + "update_roadmap" +] - changed
Input schema / properties / params / descriptionPrevious 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}."
- Changed
nucleus_orchestration3 fields changed- changed
Input schema / properties / action / descriptionPrevious value: -"Action to execute (see tool description)"New value: +"The action to execute." - added
Input schema / properties / action / enumAdded value: +[ + "satellite", + "scan_commitments", + "archive_stale", + "export", + "list_commitments", + "close_commitment", + "commitment_health", + "open_loops", + "add_loop", + "weekly_challenge", + "patterns", + "metrics" +] - changed
Input schema / properties / params / descriptionPrevious 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}."
- Changed
nucleus_sessions3 fields changed- changed
Input schema / properties / action / descriptionPrevious value: -"Action to execute (see tool description)"New value: +"The action to execute." - added
Input schema / properties / action / enumAdded 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" +] - changed
Input schema / properties / params / descriptionPrevious 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}."
- Changed
nucleus_slots3 fields changed- changed
Input schema / properties / action / descriptionPrevious value: -"Action to execute (see tool description)"New value: +"The action to execute." - added
Input schema / properties / action / enumAdded value: +[ + "orchestrate", + "slot_complete", + "slot_exhaust", + "status_dashboard", + "autopilot_sprint", + "force_assign", + "autopilot_sprint_v2", + "start_mission", + "mission_status", + "halt_sprint", + "resume_sprint" +] - changed
Input schema / properties / params / descriptionPrevious 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[]}."
- Changed
nucleus_sync3 fields changed- changed
Input schema / properties / action / descriptionPrevious value: -"Action to execute (see tool description)"New value: +"The action to execute." - added
Input schema / properties / action / enumAdded 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" +] - changed
Input schema / properties / params / descriptionPrevious 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}."
- Changed
nucleus_tasks3 fields changed- changed
Input schema / properties / action / descriptionPrevious value: -"Action to execute (see tool description)"New value: +"The action to execute." - added
Input schema / properties / action / enumAdded 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" +] - changed
Input schema / properties / params / descriptionPrevious 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}."
- Changed
nucleus_telemetry3 fields changed- changed
Input schema / properties / action / descriptionPrevious value: -"Action to execute (see tool description)"New value: +"The action to execute." - added
Input schema / properties / action / enumAdded 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" +] - changed
Input schema / properties / params / descriptionPrevious 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{}}."
12 tool updates
v1.8.0- First observed
nucleus_agents - First observed
nucleus_engrams - First observed
nucleus_features - First observed
nucleus_federation - First observed
nucleus_governance - First observed
nucleus_infra - First observed
nucleus_orchestration - First observed
nucleus_sessions - First observed
nucleus_slots - First observed
nucleus_sync - First observed
nucleus_tasks - First observed
nucleus_telemetry
TDQS
Scored across 12 tools
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.
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.
12 tools is well-scoped for a comprehensive agent operating system. Each tool covers a clear functional area without unnecessary bloat.
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
Related MCP Connectors
AI memory layer โ one shared, persistent memory across every AI tool you connect.
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
Your versioned memory across every AI tool โ context maps, personal memory, and tasks over MCP.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides 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 npmApache 2.0
- AlicenseAqualityCmaintenanceAI 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.15MIT
- AlicenseAqualityAmaintenanceA 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.19380 PyPI160AGPL 3.0
- AlicenseBqualityDmaintenanceA shared memory layer for AI agents โ one memory.md synced across Claude Desktop, Cursor, Claude Code, OpenAI Codex, and any MCP client.42MIT