nucleus

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

The description does not disclose behavioral traits beyond listing actions and their parameters. The annotations provide readOnlyHint=false and destructiveHint=false, but several listed actions (e.g., rollback_ingestion, set_alert_threshold, spawn_agent) are potentially destructive, creating an annotation contradiction. No clarity on permissions, side effects, or irreversible changes is provided.

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 a well-structured list of actions with brief parameter summaries. While long (20 actions), it avoids extraneous text. However, a more compact format (e.g., table) could improve readability; current form is acceptable for a router tool.

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 (many sub-actions) and generic schema (action+params), the description covers sub-action names and parameters but lacks examples, return values, or detailed behaviors. The existence of an output schema mitigates some gaps, but the description could do more to explain usage patterns and edge cases.

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 only 'action' and 'params' with no descriptions (0% coverage), but the description lists each action's parameters (e.g., intent, review_path). This adds meaning by naming the params, but lacks types, formats, or detailed semantics, leaving ambiguity (e.g., what is 'intent'? 'file_path'? ).

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 'Agent spawning, critic, swarm, memory, ingestion & dashboard tools' and lists 20 sub-actions, providing a broad but specific purpose. It distinguishes from sibling nucleus_* tools by enumerating its capabilities, though it lacks a single verb-resource focus.

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 implies usage for the listed sub-actions (e.g., spawning agents, critiquing code) but does not provide explicit when-to-use or when-not-to-use guidance compared to sibling tools. No alternatives or exclusions are mentioned, relying on the action list to convey scope.

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

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

The description contradicts the annotation 'readOnlyHint: true' because it includes a 'log_event' action that appends data (a write operation). Additionally, it discloses useful behaviors like admin_query requiring an env variable and logging calls, but the contradiction undermines transparency.

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 structured as a bulleted list, which aids readability, but it is fairly lengthy and includes code-like parameter listings. It could be more concise by summarizing common parameters across actions.

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 presence of an output schema (not shown) and the complexity of four actions with distinct parameters, the description covers the essential behavioral details for each action. However, it lacks a general explanation of typical use cases beyond 'audit log'.

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 0% parameter description coverage, but the description compensates by detailing parameters for each action (e.g., event_type, actor, resource for log_event; team_id, since, until for query). This adds significant meaning beyond the generic 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 identifies the tool as an audit log with a hash chain, and lists four specific actions (log_event, query, admin_query, verify) with their purposes. This distinguishes it from sibling tools, which do not appear to have audit functionality.

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 states the tool is for audit logging and implicitly guides usage by enumerating actions and their parameters, but it does not explicitly state when to use this tool versus alternatives or when not to use it. No sibling tools overlap in function, so no explicit alternatives are needed.

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

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

Annotations indicate readOnlyHint=false (mutation possible), destructiveHint=false. The description adds that it detects role from env vars or registry, and explains the timeout range and default. It does not discuss multiple-call behavior but adds meaningful context beyond 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?

Description is front-loaded with a one-line summary, followed by technical context and 'Why this exists' section. Every sentence serves a purpose; no redundancy.

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 (two-step composition), full schema coverage, and presence of output schema, the description adequately explains the equivalence to two steps and role detection heuristics.

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: 'explicit role override' and explains timeout as 'max subscription duration (60..1800, default 270 under FastMCP context-cache TTL)', enriching schema fields.

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 does 'resolve canonical inbox + arm long-poll subscription' with a specific verb and resource. It explicitly distinguishes from sibling tool nucleus_relay_subscribe by explaining why this composite operation exists.

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 calls it the 'RECOMMENDED entry point for SessionStart auto-arming' and contrasts with nucleus_relay_subscribe, which requires knowing the canonical inbox. It lacks explicit 'when not to use' but provides clear context.

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

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

The description contradicts annotations: annotations set destructiveHint=false, but the description says 'write = the vendor CHANGES things (edit files, run commands, build/fix)' which is destructive. This is a clear contradiction, warranting a score of 1.

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 comprehensive but overly long. It repeats information (e.g., list action described twice) and includes verbose caveats that could be condensed. Still, it is well-structured with sections for each action.

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?

The description covers setup, error handling, secret hygiene, and verification steps. It references an expected output schema (response fields) but the description itself is mostly complete. A slight deduction for not explicitly outlining all return fields, though output schema exists.

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 only has 'action' and a generic 'params' object with no property definitions (0% coverage). The description compensates fully by detailing each allowable parameter, their constraints, defaults, examples, and behavior differences (e.g., mode, expect_paths).

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: 'Hand a coding or review task to a cross-vendor lane — a cheap, non-Claude agent that does the work for you.' It distinguishes from sibling tools by explicitly advising against manual CLI use.

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: 'Use this INSTEAD OF shelling out to any CLI', explains when not to use it (manual CLI), and tells the user to first call 'list'. It also covers prerequisites and alternatives with concrete reasoning.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, but the description does not clarify the read-write nature of each sub-action. Terms like 'God Combo' are ambiguous and do not disclose side effects, auth requirements, or rate limits. The behavioral traits beyond annotations are minimally addressed.

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 due to listing over 30 sub-actions, which is appropriate for the tool's scope. However, the structure is a flat list that could benefit from grouping or a summary table. It is front-loaded with a one-line overview, but overall conciseness is compromised by the enumeration.

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 high complexity (many sub-actions, some with output details like context_graph), the description provides enough for basic understanding. However, many actions lack return value descriptions or behavioral nuance, and the presence of an output schema is not leveraged in the description. It is minimally 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?

The input schema is generic (action + params), but the description compensates by detailing parameters for most sub-actions (e.g., write_engram params: key, value, context?, intensity?). This adds significant meaning beyond the schema, despite a lack of formal parameter 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 explicitly lists many sub-actions with brief explanations, making it clear that this tool is a collection of memory, health, observability, and system administration functions. The title 'Memory & Engrams' provides some focus, but the broad scope is well-articulated through the action list.

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?

No guidance is provided on when to use this tool versus its many siblings (e.g., nucleus_agents, nucleus_audit). The description does not indicate which actions belong exclusively here or when to prefer a sibling tool, leaving the agent to infer usage without explicit direction.

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

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

Annotations indicate not read-only and not destructive, but the description adds little behavioral context beyond the action names. For example, it doesn't explain side effects of mounting servers or that actions like 'thanos_snap' might be experimental. The description is neutral and does not contradict annotations, but additional details would improve transparency.

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 a concise summary line, but the subsequent list of 14 actions is lengthy and somewhat repetitive. It could be more structured (e.g., grouping actions by category). The use of inline parameter lists makes it dense but not optimally scannable.

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?

Despite mentions of an output schema in context, the description does not explain what actions return (e.g., list features returns an array, generate_proof returns a document). It also omits behavioral details like pagination, error handling, or rate limits. For a tool with many sub-actions, this is incomplete.

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 is generic (action + params object) with 0% coverage, so the description bears full responsibility for parameter documentation. The description lists parameters for each action, often with optional markers ('?'), adding significant meaning. However, the format is informal and some parameters lack clarity (e.g., 'result' in validate).

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 handles 'Feature tracking, proof generation & MCP server mounting' and lists specific actions. The purpose is well-defined, distinguishing it from sibling tools that likely focus on other domains. However, the title 'Feature Flags' is slightly narrow given the server mounting capabilities.

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?

No guidance is provided on when to use this tool versus sibling tools like 'nucleus_agents' or 'nucleus_infra'. There is no mention of prerequisites, context, or when not to use it. The description simply lists actions without usage recommendations.

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

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

Annotations already indicate non-read-only and non-destructive behavior. The description adds actions that are clearly mutating (join, leave, route) but does not elaborate on side effects, permissions, or other behavioral traits beyond what annotations provide.

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 concise and front-loaded with a domain statement, followed by a clear action list. Minor redundancy (e.g., 'Get' in two actions) could be trimmed, but overall efficient.

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 has an output schema (not shown) and multiple sub-actions, the description covers the main actions and their purposes. However, it lacks details on the overall invocation pattern (e.g., required action field, optional params) and does not explain return values, leaving some gaps 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?

The input schema has 0% description coverage, so the description must compensate. It partially explains parameters for 'join' (seed_peer) and 'route' (task_id, profile?), but omits params for other actions. This provides some added meaning but is incomplete.

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 states the tool is for 'Federation management for multi-brain coordination' and lists specific actions, making the purpose clear. However, it doesn't explicitly state that it's a command dispatcher pattern, which could be more precise.

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?

No guidance is given on when to use this tool versus alternatives like nucleus_route or nucleus_sync. The description does not specify conditions or exclusions for each action.

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

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

The annotations already set destructiveHint: true. The description adds that delete_file requires confirm=true and is HITL, but overall it does not disclose other behavioral traits like what happens on failure, authorization needs, or side effects for the many actions. The sub-action descriptions are brief and lack detail.

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 a lengthy list of 19 sub-actions with inline parameter docs. It lacks front-loading of key information and is not concise for an AI agent. Many sentences could be consolidated or referenced from structured metadata.

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?

Despite having an output schema (not shown), the description does not explain return values, error handling, or how to correctly structure the params object per action. For a complex tool with many sub-actions, more detail is needed to ensure 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 description coverage is 0%, so the description must compensate. It lists each action with its parameters (e.g., 'lock - params: {path}'), which provides meaning beyond the minimal schema. However, the params object is not formally described, and the agent must infer valid properties per action. It adds partial value but is not comprehensive.

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 states 'Governance, Hypervisor & security tools for the Nucleus Agent OS.' but the tool itself is a generic dispatcher for many sub-actions (e.g., lock, delete, compliance). It fails to distinguish from siblings like nucleus_audit or nucleus_plan_execute, which have specific purposes. The purpose is too broad and not centered on a clear verb+resource.

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?

No guidance is provided on when to use this tool versus sibling tools. The description lists sub-actions but does not explain the context or conditions for invoking them, nor does it offer alternatives for overlapping functionality.

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

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

Annotations indicate destructiveHint true and openWorldHint true, but the description adds little beyond that. It mentions 'file changes', 'cloud', 'marketing & strategy' but does not explain what side effects or state changes occur, nor what authentication or rate limits apply.

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 and lists many sub-actions, but the overall structure is unclear. It front-loads 'Infrastructure: file changes, cloud, marketing & strategy tools' which is too vague to be useful, and the subsequent list is not organized in a way that clarifies the tool's purpose.

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 sub-actions, open-world schema, destructive behavior), the description is far from complete. It lacks information on what each action returns, error scenarios, and how the 'params' object is used, despite the presence of an output schema.

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 2 params with 0% description coverage. The description provides informal param hints for some actions (e.g., params: {project?, region?}) but does not define valid values for the 'action' parameter or the structure of the 'params' object. This is insufficient for correct invocation.

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 states 'Infrastructure: file changes, cloud, marketing & strategy tools' which is vague and does not clearly define the tool's core purpose. It lists sub-actions but fails to differentiate from sibling tools like nucleus_orchestration or nucleus_governance, all part of the nucleus family.

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?

No guidance is provided on when to use this tool versus alternatives. The description simply enumerates actions without specifying contexts or prerequisites, leaving the agent without decision support.

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

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

With no annotations provided, the description carries the full burden and discloses key behaviors: creates a GitHub issue on a public repo (cross-machine visible), stores locally, and requires gh CLI authentication. It could mention if there are any rate limits or side effects like notification triggers, but overall sufficiently transparent for a feedback tool.

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?

Every sentence earns its place: a clear purpose, a 'WHEN TO USE' section, and behavioral notes. No filler, and the structure is front-loaded for quick scanning.

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 output schema exists (so return values are covered) and the tool's purpose is straightforward, the description covers all essential aspects: purpose, usage scenarios, side effects, and prerequisites (gh CLI). No gaps.

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 is 3. The description does not add extra meaning beyond the parameter names and types; it lists feedback_type, subject, body, reporter, repo_path but offers no additional context like allowed values or formatting tips.

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 'Report friction/bugs/enhancements to the nucleus team' with a specific verb and resource, and the sibling tools are all other nucleus operations, none of which overlap with feedback functionality.

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 'WHEN TO USE:' with concrete scenarios like lane misbehaves, task fails, confusing SPEC.md, or improvement idea, giving clear context for when to invoke this tool.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool creates .brain/, a SPEC.md template, and git tags, but does not detail other side effects like whether the lane starts immediately or the reversibility of actions. The force parameter hint about isolation guards adds some transparency, but overall depth is moderate.

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 primary purpose and includes a clear usage guideline. It is composed of a few sentences but could be more concise by merging repetitive statements. Nonetheless, every sentence adds value.

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 has 6 optional parameters and an output schema (not shown), the description covers the high-level operation and artifacts. It explains the daemon roles and the type of tasks suitable. It lacks specifics on next steps (e.g., using nucleus_lane_start), but overall is adequate for an agent to decide when to use this 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 description coverage is 100%, so the baseline is 3. The description adds minor context about artifacts created (e.g., '.brain/', SPEC.md, git tag) that relate to parameters like tag and spec_path, but does not significantly augment the parameter meanings already provided in 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 the tool sets up an autonomous task-execution loop in a git repo, explaining it runs daemons, creates .brain/, SPEC.md template, and pins via git tag. This distinguishes it from sibling lane tools like nucleus_lane_start and nucleus_lane_stop which likely manage an existing lane.

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 includes a 'WHEN TO USE' section that explicitly tells the agent to use this tool when they have a list of tasks to batch-execute automatically. However, it does not mention when not to use it or provide direct alternatives among siblings, though it implicitly differentiates from other lane tools.

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

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

No annotations provided, so description carries full burden. It explains background daemon behavior, executor invoking LLM CLI, and secretary verification, but omits details like auth requirements, error handling, or whether it modifies state.

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?

Concise and well-structured: front-loaded with action, then usage guidance. Every sentence adds value without redundancy.

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?

Output schema exists, so return value detail is unnecessary. Covers purpose, when to use, and high-level behavior. Could mention success indicators (e.g., daemon PIDs) but adequate for a launch 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%, so baseline is 3. Description adds context about secretary verifying results (relating to no_secretary) but otherwise does not enhance parameter meaning beyond the schema descriptions.

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 'Start autonomous lane daemons (watcher + executor + secretary) in background', specifying the verb, resource, and components. It distinguishes from sibling tools like nucleus_lane_init and nucleus_lane_stop by its launch role.

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?

Includes explicit 'WHEN TO USE: after nucleus_lane_init and SPEC.md is written', providing prerequisite context. Also notes that the tool 'runs until nucleus_lane_stop is called', giving lifecycle guidance. Lacks direct when-not-to-use but overall clear.

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

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

No annotations provided, so the description carries the full burden. It discloses the tool checks status (read-only behavior) and lists what it checks. While it doesn't explicitly state non-destructiveness or idempotency, the context implies a safe query operation.

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?

Two sentences with a 'WHEN TO USE' section. Front-loaded with purpose. Every sentence adds value with no redundancy or filler.

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 that an output schema exists (though not shown), the description adequately covers what the tool returns and its main use cases. It is sufficiently complete for a status-check 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% for the single parameter (repo_path). The description does not add extra meaning beyond the schema's 'Path to the git repo (default: current directory).' Baseline of 3 is appropriate.

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 'Check lane status' and lists specific items: task counts (PENDING/IN_PROGRESS/DONE/CONFIRMED), daemon health, spec verification. This distinguishes it from sibling lane management tools like start, stop, or init.

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 two usage scenarios: after starting a lane to monitor progress, and before starting to check if a lane is already running. This gives clear context for when to use the tool.

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

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

No annotations are provided, so the description must fully disclose behavior. It only states 'Stop all running lane daemons' but lacks details on side effects, reversibility, or what happens to ongoing tasks, which is insufficient for a destructive operation.

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 very concise with no wasted words, and includes a helpful usage tip, though it lacks structural elements like bullets.

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?

The tool is simple with one optional parameter and an output schema, so completeness is adequate. However, the missing behavioral transparency reduces the score.

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% for the single parameter repo_path, so the description does not need to add information. It adds no additional meaning 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 the verb 'Stop' and the resource 'all running lane daemons', distinguishing it from sibling tools like nucleus_lane_start and nucleus_lane_status.

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 explicitly provides two scenarios for use: 'when all tasks are CONFIRMED' or 'you want to pause autonomous execution', offering clear contextual guidance.

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

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

Annotations provide minimal behavior info, but the description fully discloses long-poll (60s timeout), auto-acking, and the return structure. It explains that calling the tool blocks up to 60s and auto-acks the message, which is critical behavior beyond 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?

The description is well-structured: a brief definition, behavioral details, the loop pattern, and return format. Every sentence adds value, and it is front-loaded with the most important 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?

Despite the missing parameter description, the tool is simple and the description covers its core purpose, behavior, usage loop, and return schema. The output schema exists and complements the description. Overall, it provides sufficient context for an agent to use the tool 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 0% and the description fails to explain the 'recipient' parameter. While it states 'No args needed', it provides no insight into what the parameter does, leaving the agent to guess its purpose.

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 'Get the next unread relay message' and places it as the agent's idle loop, distinguishing it from siblings like nucleus_relay and nucleus_relay_subscribe by its unique polling + auto-ack pattern.

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 describes the calling pattern with a loop: call, handle message or None, re-call. Advises to always re-arm and never sit idle. Mentions that no separate inbox/ack dance is needed and role is auto-detected.

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

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

Annotations indicate not readOnly, not destructive, not openWorld. The description adds minimal behavioral context; it lists actions but does not disclose side effects, authorization needs, or limitations. Some sub-actions (e.g., archive_stale) may be destructive, conflicting with destructiveHint=false, but the description itself 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?

The description is lengthy but organized as a list with sub-actions. The front-loaded summary is vague; the structure is functional but could be more concise and clearer for AI parsing.

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?

The tool has many sub-actions, and the description covers most but not all parameter details. Missing information like default values, enum choices, and action-specific behavior under different params. An output schema exists but does not compensate for incomplete action descriptions.

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 0%, so the description must compensate. It lists actions and some parameters (e.g., detail_level, tier, commitment_id), adding meaning beyond the schema. However, it is not exhaustive and lacks structure for an AI to infer all valid parameter options.

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 lists many sub-actions but lacks a clear, specific verb+resource statement of what the tool does overall. 'Satellite view, commitments, loops, patterns & metrics' is vague and does not distinguish it from sibling tools.

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?

No explicit guidance on when to use this tool versus alternatives. The description merely enumerates sub-actions without explaining context or providing exclusions.

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

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

No annotations are provided, so the description must carry the full burden. It discloses internal steps (parses plan, creates tasks, starts mission with budget/time limits) and mentions the return value (mission status string). It could mention side effects like cost usage, but the schema covers budget limits. Overall, good 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?

The description is two sentences long with a clear 'WHEN TO USE' marker. It is front-loaded with the core purpose, followed by behavioral details. No extraneous content.

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 has 4 parameters and an output schema, the description adequately explains the internal process (parsing, task creation, mission start) and return value. The output schema covers return details, so the description is complete enough without needing to elaborate further.

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 is 3. The description mentions budget and time limits, but the schema already describes these as 'Mission spend cap' and 'Mission time cap.' The description reinforces but does not add significant new meaning 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 'Execute a plan file autonomously,' which is a specific verb-resource pairing. It distinguishes from sibling tools like nucleus_plan_import (which imports but does not execute) and nucleus_plan_list (which lists plans), making the purpose 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?

The description includes a 'WHEN TO USE' condition: 'you have a plan file (.brain/plans/*.md) you want executed autonomously.' This provides clear context but does not explicitly mention when not to use or name alternative tools, though the sibling list implies alternatives.

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

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

With no annotations provided, the description discloses the key trait (import without starting mission, tasks become PENDING). However, it omits details like behavior on duplicate imports or error handling, which would enhance transparency.

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 concise with two clear sentences plus a specialized usage section, no redundant information, and the key purpose is front-loaded.

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 simplicity (single parameter, no annotations, output schema exists), the description adequately covers the import action and usage context. Minor omission: no mention of success/failure indications, but output schema likely covers that.

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?

Although parameter schema coverage is 100%, the description adds context by specifying the expected file pattern (.brain/plans/*.md), which goes beyond the schema's generic 'Path to the plan markdown file'.

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 verb 'Import', the resource 'plan file', and the resulting state 'PENDING tasks', distinguishing it from sibling tools like nucleus_plan_execute that start a mission.

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 'WHEN TO USE' section explicitly specifies the exact scenario (have a plan file, want to load without starting a mission) and implicitly when not to use (when you want to start a mission), providing clear guidance.

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

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

No annotations provided, so the description carries full burden. It mentions the return format and edge case of missing directory returning []. However, it does not disclose any potential side effects or auth requirements, though the tool is read-only.

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?

Extremely concise: one sentence for main purpose, one line for usage guideline, then return format. No unnecessary words, front-loaded with key 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?

Given no parameters and a described output, the tool is well-documented. It covers purpose, usage timing, and return format. Minor omission: no mention of sorting or filtering, but not essential for simple listing.

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 no parameters (0 params, 100% coverage), so description does not need to add parameter details. Baseline for 0 params is 4.

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 'List available plan files in .brain/plans with task counts' and distinguishes from sibling tools like nucleus_plan_import and nucleus_plan_execute by specifying it is for discovery before those actions.

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?

Includes explicit 'WHEN TO USE' section that tells the agent to use this tool for discovering plan files before importing or executing. While it doesn't explicitly list when not to use, the context is clear and sufficient.

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

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

The description discloses important behavioral traits beyond annotations, such as bearer token resolution per role ('Bearer resolves per-role... never passed via this tool's prompt surface'), auto-fill of 'sender' and 'role' from session context, and the fact that 'status' is a diagnostic with no server call. It also explains the authentication mechanism, which is not covered by annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false). This adds valuable context for safe usage.

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 with clear action headers and bullet-like formatting, making it easy to scan. It front-loads the overall purpose and then details each action concisely. Each sentence adds value, covering return shapes and optional fields without excessive verbosity.

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, authentication, env vars), the description covers the essential aspects: actions, parameters, return values, and auth mechanism. However, it lacks mention of error handling beyond the optional 'error' field, rate limits, or the relationship to sibling tools like 'nucleus_relay_subscribe'. The agent may need additional context for robust usage.

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 description provides detailed parameter semantics for each action, compensating for the input schema which has 0% description coverage. For example, it lists all parameters for 'post' (to, subject, body, sender?, priority?, in_reply_to?, context?, id?, from_session_id?) and explains aliases and auto-fill behavior. However, not all parameters (e.g., 'priority', 'context') are explained in depth, leaving some ambiguity.

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 is a 'Relay-substrate facade' with actions 'post / read / ack / status', identifying its core purpose of relay messaging. It lists specific actions like 'send a relay envelope' and 'list inbox messages', making the purpose distinct. However, it does not explicitly differentiate from the sibling tool 'nucleus_relay_subscribe', which could cause ambiguity for an AI agent.

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?

There is no explicit guidance on when to use this tool versus alternatives like 'nucleus_relay_subscribe'. The description focuses on how each action works but does not provide context about when to choose this tool over others. An AI agent would need to infer usage from the action names alone, lacking clear decision criteria.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safety. The description adds significant behavioral details: it's a long-poll, server holds subscription, watches inbox dir, and fires info-level notifications. 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?

The description is well-structured and front-loaded with the core purpose. It includes historical context (PR #1, bug details) that might be slightly verbose but is relevant for understanding. Every sentence contributes meaning, though a minor trim could enhance conciseness.

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 (long-poll, server-side subscription, looping requirement), the description covers all necessary aspects: functionality, usage instructions, parameter details, and even backstory. An output schema exists, so return values are not needed in the description. It is fully sufficient for an AI agent to use 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% with detailed descriptions for all three parameters. The description adds extra context: for inbox_filter, it explains bypassing role detection and recommends it for deterministic arming; for timeout_seconds, it provides reasoning about TTL. 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 the tool's core function: 'Long-poll subscription that pushes ctx.info() on each new inbox file.' It differentiates from sibling tools like nucleus_relay by specifying it's a subscription mechanism, and explains the inbox_filter parameter for bypassing role detection, which further distinguishes its use case.

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?

Explicit guidance is provided: 'Call once at session start (e.g. via SessionStart hook).' It also advises using inbox_filter when role detection is unreliable, and mentions the looping requirement for persistent coverage. This gives clear context on when and how to use the tool versus alternatives.

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

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

Annotations already indicate readOnly and non-destructive behavior. The description adds transparency by detailing the routing logic (complexity tiers, cost estimation) and the return structure (provider, model, cost, sovereignty tier). 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?

The description is concise, using a clear heading and bulleted list to describe the action and its parameters. Every sentence provides necessary information without redundancy, and the structure is easily scannable.

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?

The description covers the tool's core purpose, parameters, and return values adequately for its complexity. The presence of an output schema reduces the need for detailed return descriptions. However, it lacks information on error handling or preconditions, which are minor gaps.

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 0% description coverage and only defines action and params as generic objects. The description compensates by detailing expected parameters (prompt, complexity with enum, context, estimated_output_tokens) and their meanings, providing essential clarity 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 explicitly states the tool routes a prompt to the optimal model tier, specifying it selects the cheapest capable model. This clearly distinguishes it from sibling tools like nucleus_agents or nucleus_delegate, which handle different concerns.

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 explains that the tool is for routing prompts to cost-optimal models, but it does not provide explicit guidance on when to use it versus alternatives, nor does it mention prerequisites or exclusions. Usage is implied but not fully contextualized.

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

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

Discloses behavioral traits beyond annotations, such as mandatory session start protocol, environment variable requirements (NUCLEUS_ROLE_CREDENTIAL), and flags like [T3.11] for versioning. However, side effects or error conditions are not detailed.

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 and dense due to listing many actions with inline parameters. Structured as a list, but could be more concise by grouping common params or using references. Some redundancy exists (e.g., 'actions:' header).

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 (many actions, generic schema), the description covers actions and parameters adequately but lacks examples, error handling, or return value explanations. Output schema exists, reducing the need for return descriptions, but still feels incomplete for invoking 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?

Since schema coverage is 0%, the description compensates by listing parameters for each action (e.g., 'params: {context, active_task?, ...}') with optional indicators. This adds significant meaning beyond the generic input schema, though types and constraints are missing.

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 'Session management, events, state & checkpoint tools' and lists all actions with specific verbs and resources, distinguishing it from sibling tools focused on other domains like agents or audit.

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?

No explicit guidance on when to use this tool versus alternatives. While actions are listed, there is no mention of when not to use it or comparison to sibling tools like nucleus_agents or nucleus_tasks.

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

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

The description lists both read-only (status_dashboard, mission_status) and mutating actions (orchestrate, slot_complete, etc.), providing basic behavioral insight beyond the annotations (readOnlyHint=false). However, it does not disclose side effects, permissions, or destructive potential explicitly.

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 a compact list that packs many actions into a small space, but the format is dense and lacks explicit grouping or headers. It is somewhat efficient but could benefit from clearer structuring.

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, many parameters) and the generic input schema, the description covers actions and their params but omits usage context, error conditions, and output details. The presence of an output schema partially compensates.

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?

With 0% schema coverage, the description must compensate. It lists parameter names and types for each action (e.g., 'params: {slot_id?, model?}'), but lacks explanations of what each parameter does or valid values, leaving ambiguity.

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 title 'Slots & Sprints' and description 'Orchestration slots, sprints & mission management' clearly convey the tool's domain. The action list further specifies available operations, distinguishing it from sibling tools like nucleus_orchestration or nucleus_plan_execute.

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?

No guidance is provided on when to use this tool versus alternatives such as nucleus_orchestration or nucleus_plan_execute. The description merely lists actions without any context about selection criteria or prerequisites.

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

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

Annotations are present (all false) but minimal. The description does not add behavioral context beyond listing sub-actions and their parameters. It fails to disclose whether specific sub-actions are destructive, require authentication, or have side effects, which is a significant gap for a tool with write operations like write_artifact and trigger_agent.

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 excessively long (50+ lines) and lacks hierarchical structure or a concise summary. Important information is buried in a flat list, making it hard for an AI agent to parse quickly. While detailed, it is not efficiently organized.

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 (many sub-actions, minimal schema, and an output schema that is not visible), the description provides a broad overview but lacks depth on return values, error handling, and when to use each sub-action. It is adequate but leaves gaps for an agent to fill.

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 only defines 'action' and 'params', with 0% schema description coverage. The description compensates by listing parameters for each sub-action, though some are terse (e.g., 'enable' without type). This adds significant meaning beyond the schema, but misses explicit types, defaults, or constraints.

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 title 'Cross-Agent Sync' and the leading sentence clearly state the tool's domain: sync, artifact, trigger, and deploy management for multi-agent coordination. The long list of sub-actions distinguishes it from sibling tools, though some sub-actions (e.g., relay, marketplace) may overlap with other tools, creating potential ambiguity.

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 no guidance on when to use this tool versus alternatives like nucleus_relay or nucleus_agents. It does not state prerequisites, conditions, or exclusions for the various sub-actions, leaving the agent to infer usage context.

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

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

Annotations already indicate non-read-only and non-destructive behavior. The description adds some behavioral details (e.g., 'Atomically claim', 'Go deeper into subtopic') but lacks information on permission requirements, side effects of updates, or the effect of depth actions on tasks.

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 a long list that, while organized by action, is verbose and could be more concise. Each action's line includes both explanation and parameters, but the overall structure is adequate.

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 sub-actions, depth tracking, context-switching), the description covers all actions and their parameters. An output schema exists, so return values are not required. The description is complete enough for an agent to understand the scope and usage of each sub-action.

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?

With schema description coverage at 0%, the description provides parameter names and optionality (e.g., 'params: {status?, priority?, skill?, claimed_by?, required_role?}') for each action, adding significant meaning beyond the generic input schema that only defines 'action' and 'params'.

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 covers 'Task management, depth tracking & ADHD context-switch tools' and lists specific sub-actions with verb+resource patterns (e.g., 'claim - Atomically claim a task'), making the purpose distinct from sibling tools like nucleus_agents or nucleus_audit.

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?

No guidance is provided on when to use this tool versus alternatives. The description simply enumerates actions without explaining when each sub-action is appropriate or how it relates to other nucleus_ tools.

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

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

Annotations are present but both false (readOnly, destructive), offering no insight. The description lists actions but does not disclose side effects, authorization needs, or rate limits. Behavioral context is minimal.

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 structured as a concise list of actions with brief explanations. It begins with a high-level summary. While efficient, it could be more compact by omitting redundant phrasing.

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?

Despite many sub-actions and an output schema, the description lacks parameter details for most actions, prerequisites, return values, and error handling. An agent would struggle to use this tool correctly without additional information.

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 0%, so the description must compensate. It lists some per-action parameters (e.g., `{tier}`) but is incomplete and lacks types, constraints, or defaults. Many actions have no parameter details.

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 states the tool covers 'LLM tiers, telemetry, PEFS notifications & protocol tools' and lists specific actions, making the purpose clear. However, it serves as a dispatcher for multiple sub-actions rather than a single focused operation, reducing clarity slightly.

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?

No guidance is provided on when to use this tool versus sibling tools like nucleus_agents or nucleus_audit. The description does not specify context for invoking this tool or alternatives.

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

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

Describes non-blocking behavior, default timeout, and auto-detection of role. Annotations are present but the description adds significant behavioral context beyond them.

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?

Five sentences with no wasted words. Key purpose is front-loaded, followed by usage guidelines and parameter notes.

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 purpose, when to use, behavior, parameter details, and output. With an output schema present, no additional return value description is needed.

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 has 100% coverage with descriptions. The description adds value by explaining that no args are needed and how role detection works, going 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 it is a 'Quick scan for a PENDING task' that returns the task or None. It distinguishes itself from sibling tools like nucleus_relay by describing it as a fallback.

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 instructs the agent not to loop and explains that tasks arrive via relay push. Provides clear context on when this is appropriate as a fallback.

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