Nucleus MCP

by eidetic-works

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.8.11
Disambiguation4/5
Most tools have distinct domains (memory, tasks, sessions, etc.) with explicit 'Do NOT use' guidance. However, orchestration's satellite overview and infra's status_report both provide high-level summaries, causing minor overlap.
Naming Consistency5/5
All tools follow the consistent pattern 'nucleus_<noun>', and actions within each tool use clear verb-noun style (e.g., add, list, get, update). No mixing of conventions.
Tool Count5/5
12 tools is well-scoped for a comprehensive agent operating system. Each tool covers a clear functional area without unnecessary bloat.
Completeness5/5
The tool set covers memory, tasks, sessions, agent coordination, security, infrastructure, telemetry, and more. It includes CRUD-like operations for most resources and handles lifecycle, state sharing, and automation.
Average 4.7/5 across 12 of 12 tools scored. Lowest: 4.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 137 commits in the last 12 weeks
- Last stable release on June 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that force_assign is destructive, while annotations set destructiveHint=false. This is a direct contradiction. Per scoring rules, score 1 for contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured: summary, usage guidance, action list, prerequisites, return format, example. Front-loaded with key info. A slight trim could improve conciseness, but it earns a 4 for clarity and organization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple actions, nested params), the description covers prerequisites, return format, and provides an example. No output schema exists, but the description compensates fully. Complete for an AI agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds extensive detail beyond the schema: for each action, it lists specific parameter keys, defaults, and descriptions. Without the description, the 'params' object would be opaque; the description makes each action's parameters clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool organizes work into time-boxed slots, runs automated sprints, and manages missions. It lists all specific actions with explanations, making the purpose unmistakable and distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (organize execution into focused work periods) and when NOT to use (individual task CRUD with nucleus_tasks, session lifecycle with nucleus_sessions, strategic overview with nucleus_orchestration). Names specific alternatives, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses which actions are read-only (e.g., 'file_changes'/'status_report') and which have side effects (e.g., 'manage_strategy' creates/modifies files). It also notes the return format ({success, data}). Annotations are consistent (readOnlyHint: false fits the mix of actions).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough and well-structured: starts with overall purpose, lists actions, prerequisites, return format, and ends with an example. Every sentence adds value. Could be slightly more concise, but the detail is justified given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's many actions and nested parameters, the description is highly complete. It covers all actions, their behavior, prerequisites, and return format. No output schema exists, but the description provides the JSON structure. Minor omissions: no explanation of 'scan_marketing_log' beyond 'analyzes marketing-related log entries'; still, overall very good.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters. The description adds significant additional semantics: it explains each action's purpose, lists sub-parameters for params with formats and defaults, and provides an example. This goes beyond schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Monitor infrastructure health, manage Google Cloud Platform services, track file changes across your project, and generate strategic planning reports.' It distinguishes itself from siblings by explicitly listing what not to use it for and suggesting alternative tools (nucleus_tasks, nucleus_engrams, nucleus_sync).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool ('when you need operational awareness...') and when not to use it ('Do NOT use for code-level tasks...'). It also lists prerequisites (gcloud CLI, .brain directory) and the return format, helping agents determine appropriateness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide basic safety hints, and the description adds significant behavioral context: sync_now may overwrite remote data, write_artifact creates a file, deploy actions require network access, and return format is JSON. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: high-level summary, action list, prerequisites, return format, example. Front-loaded with key info. Slightly verbose but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a multi-action tool: covers all actions, prerequisites, return format, and example. Lacks error handling details but sufficient for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds extra context beyond schema: explains each action's purpose, provides parameter examples and requirements (e.g., write_artifact requires name and content).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool coordinates state across agents, stores artifacts, manages triggers, and orchestrates deployments. It explicitly distinguishes from siblings like nucleus_engrams, nucleus_sessions, and nucleus_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (multiple agents need to share data, persist artifacts, manage deployments) and when not to use (persistent memory, session state, task assignment), providing alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds specific details about destructive actions ('archive_resolved: deletes session files', 'garbage_collect: removes stale sessions') and side effects ('emit_event writes to events.jsonl'). It also mentions prerequisites (.brain directory). However, it doesn't cover error scenarios or idempotency beyond what's implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: beginning with overarching purpose, then listing actions with details, prerequisites, return format, and an example. It front-loads the key message. However, it is somewhat lengthy, but every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 actions, nested params), the description covers all actions, parameter requirements, return format, prerequisites, and provides an example. No output schema exists, but the return JSON structure is described. This is thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description supplements with detailed parameter explanations for each action (e.g., start requires goal, emit_event requires event_type and data). This adds significant value beyond the enum list, earning above the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Manage session lifecycles with save/resume, structured event logging, key-value state persistence, and named checkpoints for rollback.' It also distinguishes from sibling tools by specifying what not to use it for, e.g., 'Do NOT use for persistent knowledge (use nucleus_engrams), task tracking (use nucleus_tasks), or multi-agent sync (use nucleus_sync).'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use ('maintain continuity across AI conversations, track what happened during a work session, and hand off context') and when not to use, with alternatives for each exclusion. This is a model of clear guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclose side effects (lock/unlock modify extended attributes, delete_file permanent removal), prerequisites (.brain directory must exist), and destructive actions. Annotations already set destructiveHint=true, readOnlyHint=false; description adds concrete context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is lengthy but well-structured: starts with general purpose, then usage guidelines, then systematic action breakdown. Each sentence earns its place given tool complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all actions, parameters, side effects, prerequisites, and return format (JSON success/data). Even includes an example. No output schema needed; description suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds value with detailed parameter descriptions per action and a concrete example for auto_fix_loop, going beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states purpose: enforce file integrity, security posture, and automated verification loops. It distinguishes from sibling tools by explicitly excluding task management, session state, and memory storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('lock files, switch security modes, run auto-fix cycles') and when not to use ('Do NOT use for task management...'), with alternative tools named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint: true; description confirms archive_stale is destructive. Highlights read-only nature of many actions. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with action list and examples, though somewhat lengthy. Front-loaded with purpose and usage guidelines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all 12 actions with their effects, parameter details, and return shape. No output schema but description explains JSON response format with example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but description adds extra value by specifying required fields and optional defaults for each action (e.g., close_commitment requires commitment_id and resolution).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's purpose: providing strategic awareness through satellite overviews, commitment tracking, and pattern detection. It distinguishes from sibling tools by explicitly excluding individual task CRUD, session management, and slot sprint execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (high-level view, track promises, patterns, export) and when not to use (nucleus_tasks, nucleus_sessions, nucleus_slots). Also mentions prerequisites (.brain directory) for best results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects for spawn_agent ('may start a new process') and ingest_tasks ('creates tasks'), destructive nature of rollback_ingestion ('deletes imported tasks'), read-only status of several actions, prerequisites ('.brain directory'), and return format (JSON with success and data). This adds value beyond annotations by providing specific behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough and well-organized, with a clear front-load of purpose and usage, followed by detailed action breakdowns. While every sentence adds value, the length could be slightly reduced by grouping similar actions; however, the structure is logical and easy to follow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (20 actions, no output schema), the description is fully comprehensive: includes prerequisites, return format, example, side effects, and explicit mentions of destructive/read-only behaviors. No gaps remain for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds extensive meaning beyond the schema: describes required fields, optional fields, allowed values (e.g., role enum), defaults, and provides an example usage. Covers all 20 actions with specific parameter structures, fully compensating for the schema's generic parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages multi-agent lifecycles with specific verbs and resources (spawn, critique, fix, orchestrate, search, ingest, etc.) and explicitly distinguishes from sibling tools like nucleus_tasks, nucleus_sessions, and nucleus_federation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('when you need to create new agents, review or fix code, coordinate parallel work, or query the knowledge base') and when-not-to-use with named alternatives ('Do NOT use for individual task CRUD (use nucleus_tasks), session management (use nucleus_sessions), or cross-brain sync (use nucleus_federation)').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite minimal annotations (all hints false), the description details side effects (e.g., 'write_engram creates a JSONL entry'), states that read operations are non-destructive, and mentions prerequisites (.brain directory must exist). It also enumerates all actions with their effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and ends with a concrete example. However, it is somewhat verbose in listing all actions and could be more structured (e.g., bullet points). Each sentence generally earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 actions, nested params, no output schema), the description covers all actions, prerequisites, return format, and examples. It is fully complete and leaves no ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, but the description adds significant value by explaining action-specific parameters (e.g., write_engram requires content, offers tags/source/metadata), providing examples, and clarifying defaults like limit=10.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Store, query, and search persistent memory (engrams)' and distinguishes from sibling tools like nucleus_tasks, nucleus_sessions, and nucleus_agents. It provides a specific verb+resource and clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use (e.g., 'remember something for future sessions') and when-not-to-use scenarios with named alternatives, making it easy for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosures all side effects: writes to .brain/proofs/ for generate_proof, spawns child process for mount_server, kills process for thanos_snap/unmount_server. Annotations confirm destructiveHint=true, no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, front-loaded purpose, and example. Slightly long but every sentence adds value. Could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, it includes return format, example, and covers all 16 actions comprehensively with their effects. Sufficient for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value by detailing action-specific required and optional parameters with examples and types beyond schema enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies verb+resource (track, generate, mount) and explicitly distinguishes from sibling tools by naming them (nucleus_tasks, nucleus_engrams, nucleus_agents) and stating what not to use the tool for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use scenarios (register feature, verify execution, integrate MCP server) and when-not-to-use with sibling tool names. Also lists prerequisites like .brain directory and external server installation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosures beyond annotations include side effects (claim sets status to in_progress), file system writes to .brain/tasks/, prerequisites (.brain directory), and return format. No contradiction with annotations; description adds substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is lengthy but well-organized with clear sectioning of actions. Every sentence contributes to understanding, though it could be slightly more condensed. Front-loaded purpose and usage guidance is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity with 15+ actions and nested parameters, the description covers all actions, parameter details, return JSON shape, and provides an example. No output schema exists, but the description explains return structure adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but description adds significant meaning by detailing action-specific parameter requirements including required fields, defaults, and optional parameters for each action. The example further clarifies usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it manages a priority task queue with escalation, HITL gates, and cognitive depth tracking. It explicitly distinguishes from sibling tools like nucleus_engrams, nucleus_sessions, and nucleus_agents, making the purpose precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (create, assign, update, track work items) and when-not-to-use (persistent knowledge, session management, multi-agent coordination) with specific alternatives. This gives clear guidance for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral traits beyond annotations: notes side-effects (record_interaction appends to telemetry log), persistence (kill switch state in .brain/governance/kill_switch.json), and categorizes actions as read-only vs write. No contradiction with annotations (readOnlyHint=false is consistent with mixed operations).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured: starts with a summary, then usage guidance, then action-by-action details. Every sentence adds value. Minor deduction for length; could be slightly more concise without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completely covers the tool's complexity: 14 actions, nested params, no output schema. Provides prerequisites (.brain directory), file path for kill switch, return format, and an example. No missing information needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers 100% of parameters with descriptions, but the description adds further details: example values for enums (opus/sonnet/haiku), clarifies which actions need parameters, and provides an example with return shape. This goes beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it configures LLM tiers, records telemetry, tracks costs, and manages safety controls. It lists specific actions grouped by purpose and explicitly differentiates from sibling tools by stating what it is NOT for (nucleus_engrams, nucleus_tasks, nucleus_agents).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides use contexts ('when you need to set which AI models...') and lists alternatives for other tasks. The description gives clear when-to-use and when-not-to-use guidance with named sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![nucleus-mcp MCP server](https://glama.ai/mcp/servers/eidetic-works/nucleus-mcp/badges/card.svg)](https://glama.ai/mcp/servers/eidetic-works/nucleus-mcp)

Score Badge

Copy to your README.md:

[![nucleus-mcp MCP server](https://glama.ai/mcp/servers/eidetic-works/nucleus-mcp/badges/score.svg)](https://glama.ai/mcp/servers/eidetic-works/nucleus-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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