Skip to main content
Glama

nucleus_federation

Coordinate multiple AI agents across distributed environments by joining federations, syncing state between peers, and routing requests to the appropriate brain.

Instructions

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

Input Schema

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

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

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

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

Conciseness5/5

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

The description is well-structured, starting with purpose, usage guidelines, then action details, prerequisites, return format, and an example. Every sentence is informative and necessary.

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

Completeness5/5

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

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

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

Parameters4/5

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

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

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

Purpose5/5

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

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

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

Usage Guidelines5/5

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

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

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/eidetic-works/nucleus-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server