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 does this well by revealing the planning mechanism, tool execution path, escalation policy, and environmental requirements. However, it does not mention potential side effects of executing arbitrary tools, the eventual return value, or failure behavior, which keeps it from being fully 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?

The description is two sentences with no filler. The first sentence front-loads the core action and execution model, while the second delivers essential setup requirements. Every clause adds information, keeping the definition tight and 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 tool is complex—agent runtime, external escalation, multiple execution limits, and no output schema—so the description should explain what the agent returns or how results are delivered. It explains the pipeline and prerequisites but remains silent on output format, error handling, and whether execution is synchronous or cancellable. This is a notable gap given the tool's complexity.

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

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

The input schema has 100% parameter description coverage; task, maxToolCalls, maxIterations, and maxExecutionMs all have descriptive text. The description itself adds no parameter-specific meaning 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 begins with a specific verb-resource pair ('Run a task through the Needle agent runtime') and then details the execution pipeline: planning with the local model, executing tools via the workflow orchestrator, and escalating to OpenRouter only on low confidence or failure. This clearly differentiates it from sibling tools like llm_query (single query) and workflow_orchestrator (orchestration layer), making the tool's role 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 provides clear context on how the tool operates and states prerequisites (MITOSIS_AGENT_ENABLED=true, fetched engine), but it never explicitly says when to choose this tool over alternatives or when not to use it. The intended use is implied as multi-step autonomous tasks that benefit from planning and tool execution, but no sibling comparisons or exclusion conditions are given.

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, and the description does not disclose behavioral traits such as side effects, authentication requirements, rate limits, or error behavior. It only states outputs without contextualizing how the tool operates.

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 concise sentences that front-load the purpose and outputs. No redundant or unnecessary phrasing, though more detail could be added without harming 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 no annotations and no output schema, the description should cover return values, error handling, or constraints. It fails to do so, leaving the agent without sufficient context for 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 coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema; parameters are adequately documented in the schema itself.

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 analyzes performance metrics and efficiency of tool chains, listing specific outputs like execution time estimates, complexity analysis, and optimization suggestions. However, it does not differentiate from sibling tools like 'get_tool_chain_analysis' or 'analyze_with_sequential_thinking'.

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 on when to use this tool versus alternatives, no prerequisites or exclusions provided. The description lacks context for appropriate usage.

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 full burden but provides minimal behavioral info: it only states it analyzes tools. No mention of whether it is read-only, requires authentication, or what side effects occur.

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 short sentence with no redundancy. It is concise but lacks structure such as front-loading key information or separating different aspects.

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

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

Given no output schema and no annotations, the description should explain what the tool returns or its behavior. It does not mention return values, filtering behavior beyond parameters, or integration with sibling tools.

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 two parameters. The description adds no additional context beyond the schema; baseline 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 the verb 'Analyzes' and resource 'available tools from discovered MCP servers'. It distinguishes from more specific siblings like 'analyze_with_sequential_thinking' or 'get_tool_chain_analysis', but could be more precise about what the analysis entails.

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 vs alternatives. The description does not mention prerequisites, when not to use it, or point to sibling tools for more specific use cases.

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 full responsibility for behavioral disclosure. It only mentions 'uses sequential thinking', which is vague and does not reveal whether the tool is read-only, destructive, requires authentication, or has other behavioral traits.

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 short (one sentence, five words), which makes it concise, but it is under-specified for a tool with three parameters and a nested object. It effectively front-loads the main purpose but lacks necessary detail, warranting a mid 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?

Given the complexity of three parameters (including a nested object) and no output schema, the description is incomplete. It does not explain what the tool returns, prerequisites, or side effects, leaving important gaps for an agent using the 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 the baseline is 3. The description does not add any meaning beyond the schema's parameter descriptions; it is purely high-level and adds no value about parameters like 'criteria' or 'maxThoughts'.

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 analyzes complex workflows using sequential thinking, clearly identifying the action and resource. However, it does not distinguish itself from sibling tools like 'sequentialthinking' or 'analyze_tool_chain_performance', so it scores 4 rather than 5.

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 such as 'brainstorming' or 'sequentialthinking'. It lacks explicit context, conditions, or exclusions, resulting in poor usage 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?

With no annotations provided, the description carries the full burden. It discloses that the tool relies on a generative model, requires specific environment configuration, and fails honestly without a key rather than producing template ideas. This is valuable behavioral context, though it does not describe output format or error details.

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

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

The description is a single sentence that front-loads the core purpose, then adds the key prerequisite and failure behavior. Every clause earns its place, with no redundant or filler 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?

For a tool with six parameters, no annotations, and no output schema, the description covers purpose and prerequisites but omits what the returned ideas look like and does not explain how parameters influence output. The schema fills parameter details, but the absence of output schema means the description should say more about return value shape.

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 additional meaning about topic, context, approach, ideaCount, constraints, or includeEvaluation beyond what the schema provides, so the baseline 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 states a specific verb and resource: 'Generate creative ideas via a generative model.' It clearly conveys what the tool does and hints at a distinction from template-based approaches with 'no template ideas,' though it does not explicitly name 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?

The description implies usage for creative idea generation and provides a prerequisite (CHAINING_LLM_ENABLED with OPENROUTER_API_KEY), but it does not explicitly state when to use this tool over alternatives like llm_query or suggest_skill_chain, nor does it mention 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?

No annotations provided, so description carries full burden. It only states basic function without disclosing behavioral traits like supported timezones, error handling, or edge 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 a single sentence with no unnecessary words. It is minimal and 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 moderate complexity of timezone conversion (DST, validation) and lack of output schema, the description is too sparse. It lacks necessary context about behavior and limitations.

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

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

Input schema has 100% coverage with parameter descriptions. The tool description adds no extra meaning beyond what schema already provides, so 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 clearly states the tool converts time between timezones, with a specific verb and resource. It is distinguishable from sibling `get_current_time` which retrieves current time, not conversion.

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, nor any exclusions or prerequisites. It only states the general purpose.

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 must fully disclose behavioral traits. It fails to mention side effects, state changes, permissions, or return format. The agent cannot infer whether this tool modifies state or requires prerequisites.

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 short but lacks front-loaded key information. While it states the basic purpose, it fails to earn its place by omitting critical details needed for correct usage.

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

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

Given the complexity (nested parameter 'criteria' with multiple sub-fields) and absence of an output schema, the description should explain return values or outcomes. It does not, leaving significant gaps for effective use.

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 input schema already documents both parameters clearly. The description adds no additional meaning beyond what the schema provides, meeting the baseline for high 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 'Generates optimal route suggestions for a given task' is nearly a tautology of the tool name. It does not clarify what 'route' means in this context (e.g., tool chain, path, sequence) or how it differs from related sibling tools like get_tool_chain_analysis or validate_tool_chain.

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, nor any conditions under which it should not be used. The single sentence offers no contextual instructions for the agent.

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; description is minimal. It discloses the basic behavior (get current time) but doesn't detail side effects, network usage, or accuracy guarantees.

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?

Single sentence, no redundancy, front-loaded with action and object. Appropriate length for a simple 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 tool with minimal complexity (1 param, no output schema, no annotations), the description is adequate. Could specify return format (e.g., time only vs datetime) but not critical.

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

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

Schema already describes the parameter (IANA timezone) with 100% coverage. Description adds 'specific timezone' but no new meaning beyond schema.

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

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

Description clearly states 'Get current time in a specific timezone', a specific verb+resource. It distinguishes from sibling 'convert_time' which likely converts between timezones.

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 on when to use this tool versus alternatives like 'convert_time' or when not to use it. Lacks context for tool selection.

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?

Without annotations, the description carries full burden. It correctly implies a read-only operation ('Get') but says nothing about error handling, authentication, or constraints beyond the ID. Adequate for a simple getter but lacks depth.

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, efficient sentence with no redundancy. Every word contributes to meaning.

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 parameter and no output schema, the description is adequate but incomplete: it does not mention the return format or what happens when the ID is invalid, leaving the agent with some uncertainty.

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, and the tool description adds little beyond 'by ID'. The schema already explains the parameter meaning, so the description adds marginal value.

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 retrieves a specific prebuilt prompt by ID, using the verb 'Get' and identifying the resource. It implicitly distinguishes from sibling `search_prompts` which would be used for finding prompts without a known ID.

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 `search_prompts`. It does not mention prerequisites, context, or when retrieval might fail.

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 convey behavioral traits. It only states 'Get', implying a read operation, but provides no details about errors, authorization requirements, rate limits, or response structure.

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 sentence with no wasted words. It is front-loaded with the main action and resource.

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 parameter and a read operation. However, there is no output schema and no additional context about what constitutes a 'resource set' or error cases. Given the sibling tools, more context would be helpful but the minimal description covers the core functionality.

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 'id' parameter is described). The description does not add any additional meaning beyond what the schema already provides, so score is at baseline 3.

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

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

The description clearly states the verb 'Get' and the resource 'specific resource set by ID'. It distinguishes from sibling 'search_resource_sets' which retrieves multiple sets, whereas this retrieves a single set by ID.

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 on when to use this tool versus alternatives like 'search_resource_sets'. The description does not explain under what circumstances one should choose this tool over others.

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 burden of behavioral disclosure. It does clarify that the tool returns the SKILL.md body and file manifest, and the schema documents truncation via maxChars. However, it does not mention error behavior, case sensitivity, what happens when a skill is missing, or whether the manifest is also truncated.

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, focused sentence that front-loads the core behavior and includes the purpose. There is no redundant or wandering text; every word earns its place.

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

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

The tool has only two parameters and no output schema, and the description adequately names the returned content (SKILL.md body and file manifest) and the intended use. It is slightly short on edge-case behavior such as error handling or truncation boundaries, but for a simple retrieval tool this is largely sufficient.

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 explains both parameters well. The description adds context about what the skill body is (SKILL.md) and mentions the file manifest, but it does not add substantial new meaning to the parameters beyond what is already 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 states a specific action ('Load') and a specific resource ('a skill's full instructions (SKILL.md body) plus its file manifest'). It also clearly identifies the intended use ('for injection into agent context or harness use'), which distinguishes this tool from siblings like list_skills or search_skills that only return metadata or search results.

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 clearly implies when to use this tool: when the agent needs the full SKILL.md body and file manifest rather than just skill names or search results. It does not explicitly exclude alternatives, but the wording 'full instructions... plus its file manifest' gives a clear context for selection.

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 burden. It only states the tool 'gets' analysis, with no disclosure of read-only status, side effects, cost, or any behavioral traits beyond the basic action.

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 sentence with no waste, but it is under-specified. It front-loads the purpose but lacks the detail needed to be fully helpful.

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

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

Given the complexity (nested objects, no output schema, no annotations), the description does not provide enough information. It fails to explain return values, side effects, or how to effectively use the parameters, leaving significant gaps for the 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?

Although schema description coverage is 100%, the parameter descriptions are minimal ('Input description for analysis', 'Optimization criteria') and the tool description adds no extra meaning. For a tool with nested objects, more guidance on structure and constraints is needed.

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 ('gets') and resource ('comprehensive analysis of available tools and suggested routes'). It is clear in what the tool does but does not differentiate from siblings like 'analyze_tools' or 'generate_route_suggestions', which have similar scopes.

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 on when to use this tool versus alternatives. The description does not state prerequisites, ideal contexts, or when not to use it, leaving the agent to infer usage from the name alone.

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 implies a read-only operation (listing), and there are no annotations to contradict. It adds context with 'discovered', suggesting the tool returns servers found through discovery, which is helpful for understanding behavior.

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 sentence that immediately conveys the tool's action and scope. No wasted words.

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 (no parameters, no output schema), the description sufficiently explains what it does. However, it could mention that the list reflects currently discovered servers, which is implied by 'discovered'.

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?

There are zero parameters, so the schema already covers everything. Per guidelines, baseline is 4. The description does not need to add parameter semantics.

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 verb 'list' and the resource 'MCP servers', making the purpose clear. It distinguishes from sibling tools which have unrelated functions.

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, nor any context about prerequisites or limitations. The description simply states what it does without usage advice.

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 behavioral burden and explicitly states 'Read-only; never executes skill scripts.' This is valuable safety-relevant context beyond the bare operation. It also names the source as the local skills catalog, giving additional behavioral grounding.

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 compact sentences with no filler. The core behavior is front-loaded, and the safety qualifier is added in a single short sentence. Every phrase earns its place.

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

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

For a zero-parameter, read-only listing tool, the description is complete: it states the operation, the scope, the source catalog, the returned fields, and the safety guarantee. No additional behavior, prerequisites, or output details are necessary for an agent to invoke this 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?

The tool has zero parameters, and the schema confirms this. With no parameters to document, the description does not need to add parameter-level meaning. The description already indicates what fields will be returned, which is sufficient.

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 ('List') and identifies the exact resource ('all discovered agent skills') and the source ('local skills catalog'). It also names the important fields returned (name, description, files), which clearly distinguishes this list operation from sibling tools like search_skills and get_skill.

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 clearly frames this as the tool for enumerating all discovered skills from the local catalog, which gives an agent context for when to choose it. It does not explicitly mention alternatives or exclusion rules, but the 'all' scope implicitly signals it is not for targeted search or retrieval.

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 of behavioral disclosure. It usefully reveals that the tool is a legacy compatibility API and that it routes via the Needle planner when MITOSIS_AGENT_ENABLED=true. However, it does not explain what happens when the flag is false, potential side effects, or error behavior.

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 compact and front-loaded, with the action and output stated immediately. The parenthetical legacy/routing note is informative without adding fluff. Every segment earns its place.

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

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

The tool is simple, and the description covers the core function and output shape, but the lack of an output schema and annotations means more contextual detail is needed. The description leaves unclear the default (non-MITOSIS) behavior and when an agent should prefer a non-legacy sibling tool, so completeness is adequate but 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?

Schema description coverage is 100%, and the schema already documents task as 'The complex task or objective to decompose.' The description's phrase 'complex goal' adds no new semantic detail beyond the schema, 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 clearly states a specific verb and object: 'Decompose a complex goal into ordered subtasks with recommended tool categories.' This is distinct from general query tools like llm_query or llm_summarize, though it does not explicitly differentiate itself from similar planning 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?

There is no explicit guidance on when to use this tool versus alternatives such as llm_suggest_route or generate_route_suggestions. The 'Legacy compat API' label hints at a compatibility role, but it does not state a preferred alternative or a clear selection condition.

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 burden. It usefully discloses OpenRouter/OpenAI compatibility and that the engine is disabled by default. It does not mention what happens when disabled, the response format, rate limits, or side effects, which are relevant for an LLM query 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?

One efficient sentence that front-loads the core action ('Execute a direct query') and appends two meaningful qualifiers (compatibility and default-disabled) without any wasted words.

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 core purpose is clear, but the absence of an output schema means the return value is left unspecified. The 'disabled by default' caveat is stated but not expanded (e.g., error behavior or configuration requirements), leaving some context 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 baseline is 3. The description adds no parameter-specific meaning beyond the schema entries; it only restates the direct-query context.

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 specific verb and resource: 'Execute a direct query using the internal LLM engine.' The phrase 'direct query' contrasts with specialized siblings like llm_summarize or llm_decompose_task, but does not explicitly name them or explain the distinction.

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 a raw, direct LLM query use case, which is a reasonable signal. However, it provides no explicit 'when to use vs alternatives' guidance among the many sibling LLM tools, and no exclusions or alternative tool names.

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 bears the full burden of behavioral disclosure. It mentions that the tool uses LLM intelligence and is a legacy API, but it does not disclose side effects, output format, latency/cost implications, or failure modes. Score and rank implies non-mutating behavior, but that is implicit.

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 front-loaded sentence that states purpose and legacy status without wasted words. The legacy note is packed into a compact bracketed clause that adds actionable routing 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 tool has a nested criteria object, no output schema, and no annotations, yet the description does not explain what the output looks like or how criteria affect behavior. The legacy note helps routing, but an agent would still be under-informed about expected results and success conditions.

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 50% and the description adds no parameter-level guidance. The task field is only described as 'Task description' in the schema, and the criteria object's boolean options are names alone with no explanation of how they influence scoring or ranking.

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: 'score and rank optimal multi-tool execution routes.' It also differentiates itself from agent_run by labeling this a legacy compatibility API, so an agent can tell what it does and how it relates to a sibling.

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 an explicit conditional alternative: prefer agent_run when MITOSIS_AGENT_ENABLED=true. This tells an agent when not to use this tool, though it does not spell out other comparison tools like generate_route_suggestions.

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. It states only that the tool compresses content, without revealing whether it is read-only, how it handles large inputs, what the output format is, or whether there are side effects such as external LLM calls.

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, focused sentence with no filler. It front-loads the action and lists concrete targets, earning its place with every word.

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 is mostly sufficient for basic invocation, and the schema covers parameter meanings. However, the absence of any return-format or behavioral details, combined with no annotations or output schema, leaves some gaps for an agent deciding whether this tool fits a workflow.

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 both parameters clearly. The description adds general context about the type of content (tool outputs, logs, results) but no additional detail about how maxWords behaves beyond the schema's stated default.

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 ('Compress') with clear targets ('verbose tool outputs, logs, or multi-step execution results'), making the tool's function clear. It does not explicitly contrast itself with sibling tools like llm_query or llm_decompose_task, so it stops short of full 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 implies when to use the tool—whenever there is verbose output or logs to condense—but gives no explicit 'when not to use' guidance or comparison to alternatives. The context is inferable but not explicitly stated.

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 exist, so the description must fully disclose behavior. It only states a simple load operation without mentioning side effects (e.g., file not found), permissions, or what is returned. This is insufficient for safe invocation.

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?

Single sentence with no filler. It is efficient, though marginally more context could be added without harming 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?

The tool has no output schema and no annotations. The description does not explain what happens after loading (e.g., returns instruction content) or error handling. For a simple load operation, 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 has 100% coverage with descriptions for both parameters. The description adds no extra semantics beyond the schema, so 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 clearly states it loads a custom instruction from the repository, with a specific verb and resource. It distinguishes from siblings like search_instructions (search vs load) and get_prompt (instruction vs prompt), though the term 'custom instruction' 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 on when to use this tool versus alternatives like get_prompt or search_instructions. No prerequisites or context for usage are provided.

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 bears full responsibility for behavioral disclosure. It only states the search function without revealing whether the operation is read-only, what it returns, or any side effects. Critical details like permission requirements or result limits are absent.

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 concise sentence with no extraneous information. It is front-loaded and efficient, but some might argue it is slightly under-specified for a tool with such minimal structured data.

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?

With only one parameter and no output schema, the description is simple. It covers the basic intent but lacks completeness in behavioral context (e.g., read vs. write, error behavior, result format). It is minimally adequate for a straightforward search 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% for the single parameter 'keywords'. However, the description in the schema ('Keywords to search for in instruction descriptions') essentially repeats the tool description. No additional semantic value is added beyond what the schema already provides.

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 searches custom instructions by keywords. It identifies the action ('Searches') and resource ('custom instructions'). However, it does not explicitly differentiate from the sibling tool 'search_prompts', which serves a similar purpose for prompts.

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 on when to use this tool versus alternatives like 'search_prompts' or 'load_instruction'. There is no mention of prerequisites or typical use cases, leaving the agent without contextual 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?

No annotations are provided, so the description carries full burden. It does not disclose search behavior like case sensitivity, pagination, sorting, or handling of no results. Only the basic search functionality is described.

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 sentence, concise and front-loaded with verb and resource. However, it is minimal and could benefit from additional helpful details without becoming verbose.

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 there are 3 parameters and no output schema, the description does not explain the result format, matching behavior, or how criteria combine. More context would improve agent selection and 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?

Schema description coverage is 100%, so each parameter is already documented. The description adds no extra meaning beyond summarizing the available filters (keywords, category, tags). Baseline 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 the action 'Search for prompts' and mentions filtering by keywords, category, or tags. It distinguishes from sibling tool 'search_instructions' which searches for instructions, but doesn't clarify what constitutes a 'prompt'.

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 on when to use this tool versus alternatives like 'search_instructions' or 'get_prompt'. There is no mention of prerequisites, when to avoid, or typical use cases.

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 present, so description must cover behavior. Only states it 'searches', but does not disclose side-effects (likely none), authentication needs, rate limits, or result format. Agent cannot infer safety or constraints.

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?

Single sentence, no fluff, directly conveys purpose. Could be slightly more informative without losing 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?

No output schema, so description should hint at return format (e.g., list of resource set objects). Missing pagination, ordering, or result limits. Incomplete for a search tool that returns multiple items.

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

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

Schema coverage is 100% and each parameter is described in the schema. The description adds 'by keywords, category, or tags' which aligns but does not provide additional nuance 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?

Clear verb 'Search' and resource 'resource sets', with search dimensions (keywords, category, tags) specified. Differentiates from siblings like search_instructions by focusing on resource sets, but does not explicitly contrast with 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?

No guidance on when to use this tool vs alternatives. Does not mention when not to use, prerequisites, or typical scenarios.

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 states that results are 'ranked matches,' which is a genuine behavioral trait, and that they are intended for chaining. However, it doesn't describe ranking criteria, return shape, or absence of side effects, leaving the agent to infer the read-only nature of a search.

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, each earning its place: the first states the action and scope, the second states the output and intended use. The main idea is front-loaded with no redundant 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 two-parameter search tool this is adequate, but not complete. It lacks explicit guidance on when to choose this over siblings, and because there is no output schema, the agent only learns that matches are 'ranked' without knowing what fields the matches will contain.

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 covers both parameters at 100%, so the baseline is 3. The description adds useful meaning by explaining that the query matches against 'names and descriptions,' which the schema's 'keywords describing the capability needed' does not specify. Limit semantics are fully covered by 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 ('Search') and resource ('skills catalog'), and specifies the search scope ('names and descriptions'), making it clear this is a keyword-based search rather than a list-all or get-by-ID operation. However, it doesn't explicitly differentiate itself from sibling tools like list_skills or get_skill, so it falls short of a perfect 5.

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 phrase 'by keywords' and 'for chaining' implies this is the tool to use when a capability is described in words and the result will feed into further tool calls. It gives no explicit when-not-to-use guidance or alternatives, so usage context is only 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by explaining that thoughts become observations in AgentState, that Needle determines the next action (call_tool/revise/complete/escalate), and that results feed subsequent steps. This goes beyond the schema by clarifying the execution flow and side effects, though it does not detail every state mutation or edge case.

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 only two sentences, with the primary action and result flow front-loaded. The first sentence explains the tool's role and the second provides the session continuation caveat. Every clause earns its place; there is no filler or repetition of schema 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's complexity (12 parameters, no output schema, no annotations), the description covers the essential behavioral protocol: single-step thinking, AgentState recording, and Needle's decision loop. It does not explain all branching/revision parameters, but those are documented in the input schema. The overall invocation context is sufficiently complete for an agent to use it 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 is 3. The description adds minimal parameter-level insight beyond the schema, only mentioning sessionId for continuation. Since each parameter already has a descriptive schema entry, the description does not need to compensate, but it also does not add meaningful extra semantics.

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 what the tool does: 'Think one step with the Mitosis agent: your thought is recorded as an observation in AgentState, Needle decides the next action...' This is a specific verb-resource pairing with a distinct mechanism. It is easily distinguishable from sibling tools like analyze_with_sequential_thinking, which focus on analysis of chains rather than performing a single 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 context on when to invoke this tool: each call represents exactly one thinking step in a larger agent-driven process, and 'Pass sessionId to continue a session' indicates usage for ongoing sessions. It does not explicitly name alternatives or exclusion conditions, but the core usage context is unambiguous.

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 behavioral disclosure burden. It does disclose deterministic matching, labeled recommendations, and the combination of skills+tools into a chain. It does not state whether the chain is executed, what the return value contains, or any side effects or restrictions.

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 compact and front-loaded: the first sentence states the planning action, and the second clarifies the output nature. The parenthetical 'deterministic catalog match, labeled' is dense but useful for sibling differentiation without adding excessive length.

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 a single task parameter, the purpose and general output shape are conveyed. However, with no annotations and no output schema, the agent must still infer whether the chain is actually executed, what 'labeled' means, and how this differs from LLM-planning siblings. It is adequate but 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 only parameter, task, already has a description in the schema, and schema coverage is 100%. The tool description adds no additional parameter-level detail, so it meets the schema-covered baseline but does not go beyond it.

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 specific action: 'Plan a task with Needle over registry tools and attach skill recommendations per step.' It also signals that it combines skills+tools into one executable chain, which distinguishes it from pure skill-search siblings. However, terms like 'Needle' and 'labeled' are unexplained, leaving some 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 phrase 'deterministic catalog match' implies this tool is appropriate when a deterministic, catalog-based plan is preferred, and 'one executable chain' suggests use when an executable plan is needed. However, it does not explicitly compare against sibling tools like llm_suggest_route or state when not to use 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 provided, so description carries full burden. It honestly describes the validation checks and implies non-destructive behavior. No inconsistencies or missing critical behavioral traits.

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 efficiently state overall purpose and specific checks. No extraneous information, front-loaded with action verb.

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?

With no output schema, the description misses what the tool returns (e.g., validation report). It covers input and behavior adequately but lacks output details for completeness.

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 descriptions for all parameters. The description reinforces the parameter meanings by listing the checks, adding value beyond schema alone.

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 validates tool chains for correctness, dependencies, and potential issues. It lists specific checks (circular dependencies, tool availability, parameter compatibility), distinguishing it from siblings like analyze_tool_chain_performance.

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 (when validation is needed) but does not explicitly state when not to use or provide alternatives among siblings. Usage context is clear but lacks explicit 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 are provided, so the description must disclose behavioral traits on its own. It only says 'request cancellation' and does not state whether the operation is asynchronous, idempotent, or what effects it has on the running workflow. For a mutating workflow operation, this is a significant transparency gap.

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, front-loaded sentence with no wasted words. It is appropriately concise for a one-parameter tool, though slightly more behavioral context could have been included without harming clarity.

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 one-parameter tool with full schema coverage, this is minimally adequate. The main missing piece is information about what happens when the cancellation request is made or how the response should be interpreted, which an agent may need for reliable use.

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 workflowId parameter is documented as 'Workflow identifier to cancel'. The tool description adds no extra parameter meaning, but the schema already covers what the agent needs to invoke the tool 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?

The description uses a specific verb ('request cancellation') and identifies the resource ('running workflow'), making the tool's function immediately clear. It is also easily distinguished from sibling tools like workflow_status, which is about checking status rather than canceling.

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 explicit guidance about when to use this tool versus alternatives such as workflow_status or workflow_orchestrator. There is no mention of prerequisites, such as verifying the workflow is running, or of situations where cancellation should not be attempted.

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 disclose behavioral traits. It mentions 'dependency management and error handling' but omits details like destructiveness, permissions, or side effects. For a complex orchestrator, more transparency is needed.

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 sentence, front-loaded with the core purpose, and no unnecessary words. However, it could be slightly more informative without sacrificing 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 (7 parameters, nested objects, no output schema, no annotations), the description is inadequate. It does not explain return values, side effects, or usage notes, leaving agents underinformed.

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 parameters. The description adds no additional semantics beyond the tool's purpose. Baseline 3 is appropriate as the schema does the heavy lifting.

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 executes 'complex multi-server workflows' with 'dependency management and error handling', which differentiates it from sibling tools like sequentialthinking or analyze_tools. However, 'workflows' could be more specific about coordinating other MCP 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 implies complex multi-server scenarios but does not state when not to use it or provide 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 provided, the description carries the full burden. 'Get... status and step results' indicates a read-only operation, but it does not disclose any additional behavioral traits such as whether the workflow must already be complete, whether it polls or returns immediately, or what statuses are possible. This is acceptable but thin.

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, tightly scoped sentence that front-loads the operation and key object. Every phrase contributes meaning, and 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 one-parameter read tool, the description plus schema covers the core need: what to call, how to identify the workflow, and what kind of information is returned. The lack of an output schema means some detail about the exact result structure is absent, but the description names 'status and step results' sufficiently for basic use.

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 explains that workflowId is the identifier returned by workflow_orchestrator or agent_run. The description merely repeats this information without adding new meaning, so the baseline 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 a specific verb ('Get') and resource ('current status and step results of a workflow'). It also identifies which tools create such workflows, which helps distinguish from workflow_cancel and the broader orchestration tools. It does not explicitly contrast itself with a specific sibling, but the meaning is 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 gives clear context: use it for workflows executed by workflow_orchestrator or agent_run, and the parameter description states the workflowId comes from those tools. It does not explicitly say when not to use it or name alternatives, but the intended trigger context is clear enough.

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