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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that agents run simultaneously, operate autonomously, and can read files, write code, and execute commands, signaling meaningful side effects. It does not detail failure/partial-result semantics, but the core behavior is transparent enough for selection.

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 action in the first sentence. The use-case sentence is useful. Minor redundancy exists because 'IN PARALLEL' and 'All agents run simultaneously' repeat the same idea, but the overall length is appropriate.

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?

For a tool with one nested parameter and no output schema, the description covers what an agent needs to decide to use it: parallel execution, per-agent model/task, code/file/command side effects, and combined results. It could go deeper on partial failures or limits, but the provided context is solid.

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 only top-level parameter, 'agents', has a schema description ('List of agents to run in parallel'), and required nested fields are documented in the schema. The tool description does not add parameter-level meaning beyond the schema, so with high schema coverage the baseline score of 3 applies.

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 opens with a specific verb and resource: 'Run multiple autonomous AI agents IN PARALLEL, each with its own model and task.' It clearly conveys a batch, parallel orchestration tool, which differentiates it from single-agent or status-related sibling tools. The divide-and-conquer examples reinforce what the tool is for without 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 gives concrete use cases: 'one agent codes while another tests' and splitting a large codebase across agents. This provides clear context for when to reach for this tool, though it does not explicitly state when not to use it or name alternative sibling 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 are provided, so the description carries the behavioral burden. It discloses the ReAct loop, autonomy, tool access, and the two-part return (final answer + full trace), which is meaningful transparency for an agent runner. It does not mention side-effect risk or auth requirements, but what it states is clear and non-contradictory.

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 compact sentences; the first sentence front-loads the core action and capabilities, and the second explains the execution model and return value. Nothing is wasted.

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 high parameter count, no output schema, and no annotations, the description supplies the essential behavior and return shape while the schema covers parameter details. It could note timeouts or side effects, but overall it is sufficient for an agent to invoke 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 description coverage is 100%, so the baseline 3 applies. The description adds examples of model IDs and providers and maps capabilities to tool names, but it does not significantly alter or deepen parameter 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?

States a specific verb and resource: 'Run an autonomous AI agent' with a concrete list of capabilities and a ReAct-loop execution model. This clearly identifies the tool as a single-agent orchestration run, though it does not explicitly contrast with subagent/multi-agent siblings.

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

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

No guidance about when to choose this over nexus_subagent_run, nexus_subagent_spawn, or nexus_agent_multi. The capability list implies use for end-to-end autonomous tasks, but there are no exclusions or alternative routing conditions.

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 the full behavioral disclosure burden. It only repeats the defaulting behavior already present in the schema and says nothing about response format, errors, authentication failures, rate limits, or side effects, which is a significant gap for a tool that calls external providers.

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 concise sentences with no filler. The core action is front-loaded in the first sentence, and the second sentence adds a useful usage detail about defaults 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?

The description provides enough to start using the tool with just a prompt, but it omits what the tool returns, which matters because there is no output schema. It also lacks guidance on provider configuration requirements or how this compares to agent-related sibling tools, leaving moderate 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 description coverage is 100%, so the schema already documents all six parameters. The description adds no parameter-level meaning beyond the schema, such as examples, constraints, or relationships between provider and model, so the baseline score 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?

Description states a specific verb and resource: 'Send a prompt to any AI provider', with concrete provider examples. It clearly conveys the tool's function, though it does not explicitly differentiate it from sibling tools like nexus_agent_run or nexus_subagent_run.

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 gives useful context about default provider/model behavior and the option to override it. However, it does not state when to prefer this tool over alternatives such as agent_run, subagent_run, or plan_execute, leaving the choice partly implied.

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 absent, so the description must disclose behavior on its own. It never says whether configuration changes are persistent, global, immediately applied, or what happens to existing keys/settings when only a partial config is sent; it also doesn't warn about sensitive API key handling. This is a meaningful gap for a state-changing 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?

The description is just two sentences and front-loads the action before moving to the dashboard pointer. The phrase 'directly from chat' adds little because all MCP tools are invoked from chat, so it is the only mildly redundant element.

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?

For a mutation tool with no output schema and no annotations, the definition omits expected results (confirmation/errors), persistence/scope, and any prerequisites like existing provider records. The input schema covers parameters, but the description does not round out the call context sufficiently.

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

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

Schema coverage is 100%, so the schema alone documents all five parameters and the provider enum. The description only restates the parameter themes (API keys, base URLs, enable/disable) and adds no extra meaning such as defaults, precedence, or validation rules.

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 uses a specific verb and resource ('Configure a provider') and lists concrete settings (API keys, base URLs, enable/disable), making the core action clear. It does not explicitly contrast with adjacent tools like nexus_reauth or nexus_switch_model, so sibling differentiation is only implicit.

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?

It establishes a clear context for use ('directly from chat') and steers 'full management' to the web dashboard, which is a weak when-not signal. It offers no guidance on when to prefer nexus_configure over sibling tools such as nexus_reauth for authentication issues.

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, the description carries the burden of revealing behavior, and it does so meaningfully: participants respond in parallel, see all prior contributions, run in rounds, and Opus ultimately decides. It also discloses that research mode uses tools such as file/web search and cross-references findings. It does not cover cost, auth, or side effects, but the core execution model is transparent.

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: the core action, mode explanations, parallel round behavior, and use-case list are all useful and non-redundant. It is front-loaded with the verb and outcome, and it remains compact despite covering a complex 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?

For a complex council tool with no output schema and five parameters, the description lays out the workflow, participant interaction model, mode variations, and intended use cases. It leaves out return-value details, but 'Opus makes the final decision' sufficiently communicates the outcome. The description is complete enough for an agent to decide whether to call it and roughly how it will behave.

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, but the description adds value by explaining what each mode means behaviorally (build collaboratively, challenge adversarially, investigate with tools). This supplements the enum's short schema descriptions with operational detail, particularly the cross-referencing aspect of research mode.

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 action ('convene a multi-model council') and the resource ('AI agents deliberate in rounds... Opus makes the final decision'). It also defines three distinct modes—DISCUSSION, EBATE, ESEARCH—and lists concrete use cases, making the tool's purpose unmistakable and distinguishing it from the subtool/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?

It explicitly claims the tool for specific use cases: 'Use this for architecture decisions, code reviews, security audits, complex analysis.' This provides clear context for when to invoke it, though it does not explicitly name alternatives or state when not to use it.

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, the description carries the disclosure burden. It states the scope (all providers/models) and mentions status indicators, which implies a read-only inventory operation. It does not explicitly confirm read-only behavior or describe how statuses are determined, leaving some ambiguity.

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?

A single, front-loaded sentence states the action, object, output feature, and filter option without wasted words. Every phrase adds useful 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?

For a one-optional-param listing tool, this is nearly complete: the agent knows the action, scope, and filter. The only minor gap is that status indicator semantics and provider ID values are not expanded, but no output schema exists to fill that in.

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%: the provider parameter has a clear description and is optional. The description reinforces this by restating the optional filter, but adds no new format or value information 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 opens with the specific action 'List' and names the resource: all available AI providers and their models, plus status indicators. This clearly differentiates it from siblings like nexus_switch_model and nexus_configure, which perform different 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?

The description gives no when-to-use guidance or alternatives; 'Optionally filter by a specific provider' is parameter usage, not tool selection guidance. An agent cannot tell from the description when listing models is preferred over switch_model or configure.

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 the core execution model well: independent steps run in parallel, dependent steps wait and receive prior-step context, and the orchestrator/executor division of labor. It does not cover failure semantics, side effects, or resource consumption, but the essential behavioral traits are explicitly stated.

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 four substantive sentences are tight, front-loaded, and each carries meaning: purpose, parallelism, dependency behavior, and mode selection. The closing tagline "Opus plans, Nexus executes" is redundant with the opening sentence and adds branding rather than information, costing the description a perfect score.

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?

For a complex orchestration tool with no output schema and no annotations, the description explains the execution model but omits return format, failure flow behavior, and how results correlate to step IDs, which an agent needs to interpret outcomes. The rich, self-documenting schema (100% parameter coverage including on_failure and inject_context_from) compensates significantly, making this adequate but with clear 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 every parameter including nested step properties is already documented, setting the baseline at 3. The description adds genuine value by giving selection criteria for the mode enum ('agent' = file access/code execution, 'prompt' = analysis/review) that the schema does not provide, helping agents choose correctly.

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?

"Execute a structured multi-step plan where Claude is the orchestrator and Nexus agents do the work" states a specific verb, resource, and scope in one sentence. The parallel/dependency execution model clearly distinguishes it from single-agent siblings like nexus_agent_run or nexus_agent_multi, even without naming them.

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 actionable within-tool guidance ("Use mode='agent' for steps that need file access/code execution. Use mode='prompt' for analysis/review steps") but never says when to choose this tool over its 14 siblings, such as nexus_agent_run or nexus_council. Usage context is implied rather than explicit, and no alternatives or exclusions are named.

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, the description carries the full burden for behavioral disclosure. 'Check' implies a read-only action, and 'Returns per-step results and metadata' states an observable behavior, but it does not explicitly guarantee no side effects, mention prerequisites, or describe error cases.

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 concise sentences with purpose first and return behavior second. There is 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?

For a simple tool with one optional parameter, the description plus schema covers the main usage: what the tool checks, what it returns, and how to list recent plans. It could add explicit read-only wording or sibling differentiation, but nothing essential is missing for correct invocation.

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

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

The schema fully documents the single plan_id parameter with 100% coverage, so the description does not need to add much. The phrase 'previously executed plan' connects loosely to plan_id, but the description offers no extra format or behavior 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?

Uses a clear verb ('Check') and identifies the specific resource ('status of a previously executed plan'), while adding that it returns per-step results and metadata. It does not explicitly distinguish itself from sibling tools like nexus_status or nexus_subagent_status, so it stops short of full sibling differentiation.

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

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

The description gives no explicit guidance on when to call this tool instead of nexus_plan_execute, nexus_status, or nexus_subagent_status. The schema says plan_id can be omitted to list recent plans, but the description itself does not frame usage context or 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?

With no annotations, the description carries the full burden, and it discloses key behavior: it opens a browser, requires the user to log in and close it, and saves the session for future use. It does not mention potential blocking/timeout or whether existing sessions are invalidated, but the core interactive flow is transparent.

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?

Three concise sentences with no redundancy, front-loading the core action and then explaining the interactive steps and supported providers.

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?

For a simple 2-parameter interactive tool with no output schema, the description covers the action, user steps, outcome, and permitted values. It omits return-value details and timeout behavior, but these are not critical for invoking 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 description coverage is 100%, so the schema already documents provider and url. The description only repeats the provider list and gives no additional parameter nuances, so it stays at the baseline.

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 uses a specific verb ('Open') and resource ('browser window for re-authentication with a provider'), and details the expected flow. This clearly distinguishes it from sibling tools focused on subagents, model switching, and configuration, none of which handle authentication.

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?

It explains the intended use case (re-authentication) and lists supported providers, so an agent knows when it applies. It does not explicitly name alternatives or exclusions, but no sibling tool serves the same auth purpose, so this is clear enough.

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?

There are no annotations, so the description must communicate behavioral traits. It only states what it shows (status, latency, errors) but does not disclose whether it is read-only, whether it may make network calls, or any potential side effects. For a health check, read-only behavior is implied but not asserted.

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 single, tight sentence (15 words) that is front-loaded with the core purpose ('Health check all configured AI providers') followed by what is shown. No filler or redundant 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?

For a tool with one optional parameter, no output schema, and no annotations, the description covers the essential purpose and output adequately. It does not mention potential failure modes or output format, but for a health check, this may be sufficient. The description is complete enough to call the tool without further context.

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

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

Schema coverage is 100%, so the parameter 'provider' is already fully described in the schema ('Check a specific provider only (optional)'). The description does not add any additional meaning about the parameter. With high schema coverage, the 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 states a clear verb and resource: 'Health check all configured AI providers'. It also specifies what it shows (connection status, latency, errors). However, it does not explicitly distinguish itself from sibling tools like nexus_subagent_status or nexus_plan_status, though the subject matter (providers vs subagents) is implicitly different.

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 any alternative. It does not mention prerequisites, typical usage scenarios (e.g., 'check before making API calls'), or when not to use it. The use case is implied but not stated explicitly.

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 behavioral disclosure burden. It clearly states that execution is sequential, that intermediate steps are retained, and that both final and intermediate outputs are returned. It does not mention async behavior, costs, or failure handling, but the core behavioral contract is transparent.

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 no filler. The pipeline concept is front-loaded, followed by the ordering behavior and return format, so an agent grasps the essential information immediately.

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?

For a two-parameter tool with a thoroughly described schema, the description covers input semantics, process ordering, and return value. It could be more complete by clarifying whether execution is synchronous and how it relates to the subagent status/run siblings, but nothing critical is missing for basic 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 100%, and the schema already documents task, models, provider, model, role, maxTokens, temperature, and systemPrompt. The description adds ordering semantics, but the models property schema already states that the list is ordered and that later roles review/refine/synthesize, so the added value is limited.

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 identifies a specific workflow: sequential multi-model collaboration with first-model production, review/refinement, and optional synthesis. This distinguishes it from parallel collaboration siblings like nexus_council or nexus_agent_multi, though it does not name them explicitly.

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 when to use it: multi-stage sequential tasks where one model's output is refined by another. However, it provides no explicit when-to-use or when-not-to-use guidance, nor does it contrast with alternatives that also handle multi-model or multi-agent collaboration.

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 present, so the description carries the full burden. It discloses parallelism, blocking semantics ('Waits for all to complete'), and the return payload with metadata (text, latency, tokens, errors). It does not mention timeout, partial-failure handling, or side effects, but what is stated is substantial and relevant.

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?

Three short sentences, each earning its place: the core action, the blocking behavior, and the return value. There is no fluff or repetition, and the most important verb ('Execute') 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?

For a single-parameter tool with no output schema, the description is largely complete: it explains input provenance, execution semantics, and return metadata. A small gap is the lack of guidance on long-running behavior or cancellation, but 'Waits for all to complete' partially covers this.

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%, and the batchId parameter is already well explained as 'The batch ID returned by nexus_subagent_spawn'. The tool description reinforces the provenance of the parameter but adds no new format or constraint details 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 uses a specific verb and resource: 'Execute all tasks in a spawned batch in parallel.' It clearly identifies the operation and distinguishes it from siblings like status or spawn by focusing on execution of an already-spawned batch and explicitly referencing the spawn counterpart.

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 when to use the tool: when you have a batch ID from nexus_subagent_spawn and want to execute all tasks. It does not explicitly exclude alternatives like nexus_subagent_status or nexus_subagent_collab, but the context is clear enough for an agent to infer the correct invocation point.

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 transparency burden. It discloses the return contract (batch ID), the parallel nature of the spawned tasks, and the important lifecycle detail that execution happens later via nexus_subagent_run. It does not mention auth, rate limits, or cost implications, but the core behavioral contract is clear.

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 dense, front-loaded sentences with no filler. The first sentence states what the tool does; the second explains the task composition and points to the next tool. Every clause contributes useful 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?

The description is complete enough for correct invocation: required task fields are covered by the schema, and the description explains the return value and the next step. Minor gaps remain around failure modes, status checking, and permissions, but these do not block an agent from using 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 100%, so the schema already documents the tasks array, timeoutMs, and nested fields like prompt, provider, model, role, maxTokens, temperature, and systemPrompt. The description adds high-level context about "one or more" tasks and parallel execution, but it does not need to repeat parameter details. Baseline 3 applies.

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 starts with a specific action and resource: "Spawn one or more AI subagent tasks for parallel execution." It clearly explains what each task targets (provider/model/prompt) and what the tool returns (batch ID), making it easy to distinguish from the sibling nexus_subagent_run, which is the execution step.

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 clear workflow guidance by explicitly telling the agent to use nexus_subagent_run to execute the spawned batch. It does not spell out when to avoid this tool in favor of nexus_subagent_collab or nexus_subagent_status, but the parallel-batch framing gives sufficient context for most calls.

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 the behavioral disclosure burden. It does add useful context by naming the statuses returned and the default list-all-recent-batches behavior. However, it does not explicitly state that the operation is read-only or disclose potential limitations such as auth requirements or result pagination.

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 short sentences with no unnecessary content. The purpose is front-loaded, and the optional-parameter behavior is stated in the second sentence. This is concise and well structured.

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?

For a low-complexity tool with one optional parameter and no output schema, the description covers invocation and default behavior sufficiently. Mentioning 'with results' partially describes the return content, though the exact result shape is not specified; this is a minor gap.

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%, and the description duplicates the schema's guidance about omitting batchId to list all recent batches. It adds no meaningful parameter semantics beyond what the schema already provides, so the baseline score 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 uses a specific verb and resource: 'Check status of subagent batches', and lists the observable states (pending, running, completed). It clearly describes what the tool does, but it does not explicitly contrast it with sibling tools such as nexus_status or nexus_subagent_run, so full sibling differentiation is missing.

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 gives no guidance on when to choose this tool over alternatives like nexus_status or nexus_plan_status. The only usage instruction concerns omitting or providing batchId, which is parameter-level behavior rather than tool selection 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?

With no annotations, the description carries the full burden of behavioral disclosure. It usefully reveals that the switch is stateful and affects subsequent nexus_ask calls. However, it does not mention whether the change affects other tools, whether it persists across sessions, requires authentication, or returns any confirmation, leaving some behavioral ambiguity.

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 short sentences with no filler. The core action is front-loaded, and the persistent effect is stated immediately after, making it easy for an agent to parse quickly.

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?

For a simple two-parameter tool, the description captures the essential context: what the switch does and what the consequence is for future calls. It does not explain failure modes, return values, or interaction with sibling tools, but these are less critical given the schema already documents the available providers.

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 both provider and model are already documented. The description adds no additional parameter meaning beyond what the schema provides, which matches the baseline for full schema coverage.

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 primary action—switching the active AI provider and model—and names the affected resource ('active AI provider and model'). It also adds a scoping detail by linking the switch to subsequent nexus_ask calls. However, it does not explicitly distinguish itself from sibling tools like nexus_configure, which might also manage provider/model settings.

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 when to use the tool: when you need subsequent nexus_ask calls to use a different provider/model. It does not explicitly state alternatives or when not to use it, nor does it mention related tools like nexus_list_models or nexus_reauth that may be relevant before switching.

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