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

With no annotations, the description is the only behavioral disclosure. It correctly indicates the core mutation (a child is added under a parent) and implies the parent must already exist, but it does not mention side effects, persistence, return value, or whether the operation evaluates or validates the child. This is adequate but carries clear gaps.

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 one short sentence with no filler, redundancy, or buried information. It front-loads the action and resource. For a simple mutation whose parameters are fully documented in the schema, this level of brevity 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?

The description plus the complete schema covers the basic operation and all required parameters. However, with no annotations and no output schema, an agent is left unsure whether the created thought is returned, whether the tree is updated in place, or how sessionId affects the operation. That makes it minimally viable but not fully complete.

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

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

Input schema description coverage is 100%, so every parameter — treeId, parentId, content, metadata, sessionId — already has a meaningful description. The tool description adds no new parameter-level meaning, but the schema carries that burden, so a 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 ('Add'), the resource ('a child thought'), and the target ('an existing thought'), so the basic intent is unambiguous. It does not explicitly differentiate from sibling tools like generate_children or generate_and_evaluate_children, which also produce child thoughts. This prevents a 5 but is well above a vague or tautological description.

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 choose add_child over the many related sibling tools. There are no alternatives named, no exclusions, and no stated conditions such as 'use this for a single manual child rather than generated children.' The agent is left to infer selection from the tool name and schema.

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 transparently states the key mutation ('marking all descendants as pruned'), but it does not clarify whether the specified thought itself is also affected, whether pruning is reversible, or what downstream effects pruned descendants have.

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 filler. The verb and object are front-loaded, and the consequence is stated immediately in a participial phrase.

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 two required string parameters and full schema coverage, so the core invocation is understandable. However, without annotations or an output schema, the description leaves ambiguity around reversibility, whether the thought itself is pruned, and how this differs from prune_tree.

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%: treeId is described as 'The ID of the tree' and thoughtId as 'The ID of the thought to backtrack from'. The description helps by tying thoughtId to the backtracking operation, but it adds no new parameter-level details 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 opens with a specific verb ('Backtrack') and resource ('a thought'), then specifies the exact outcome ('marking all descendants as pruned'). It is not a tautology and conveys a distinct operation, but it does not explicitly differentiate the tool from sibling tools such as prune_tree.

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 wording implies the tool should be used when you want to abandon a thought branch by pruning all its descendants. However, it gives no explicit when-to-use guidance, no exclusions, and no mention of how it relates to alternatives like prune_tree, move_subtree, or select_thought.

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 must fully disclose behavior. It does indicate destructive bulk clearing, but it omits critical context: irreversibility, what 'all' is scoped to (session, workspace, or global), whether strategies are deleted or emptied, and whether confirmation is required.

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 filler. Every word earns its place for a tool with no parameters, making it highly 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?

Even with no parameters and no output schema, a destructive bulk operation needs more context: the scope of 'all', reversibility, and what exactly gets cleared (tree structures, strategy configurations, associations). The description lacks these essential details, leaving an agent to guess at the operational impact.

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, so the description carries no parameter documentation burden. The empty schema is trivially complete, and the baseline for zero-parameter tools is 4.

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

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

The description 'Clear all trees and strategies' states a specific verb (clear) and a broad resource (all trees and strategies), making it distinguishable from sibling tools like clear_tree, clear_strategy, or delete_tree. The scope 'all' conveys a bulk operation, though the difference between clearing and deleting is not explained.

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

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

No guidance is provided on when to use this tool versus alternatives such as clear_tree, clear_strategy, or delete_session_trees. The description does not specify selection criteria, prerequisites, or situations where this bulk clear should be preferred.

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, but 'Clear' is ambiguous: it does not disclose whether the strategy is deleted, reset, or emptied, what side effects occur, whether the operation is reversible, or whether permission is required. This is insufficient for a mutation 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?

A single, focused sentence with no filler. All words contribute to the meaning, and the key target (specific strategy by ID) 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?

The tool is simple, but the lack of behavioral detail and usage context leaves an agent unable to fully predict what will happen. With no output schema and no annotation, the description should explain the effect and result of clearing a strategy.

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 single parameter is already well documented. The description adds no new meaning beyond 'by ID', matching the baseline of 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?

Description is 'Clear a specific strategy by ID' — a specific verb, resource, and targeting mechanism. It clearly distinguishes clear_strategy from siblings like clear_tree and clear_everything by naming the strategy resource and ID-based targeting.

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 use this tool versus alternatives like delete_session_trees, clear_tree, clear_everything, or get_strategy. The description implies the action but provides no context for selection or prerequisites.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. 'Clear' implies a mutation, but the description does not state whether the tree structure is preserved, whether descendants are affected, or whether the operation is reversible.

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 that front-loads the action and object. It contains no filler, though its brevity contributes to the lack of contextual detail penalized elsewhere.

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 annotations and no output schema, this description is incomplete. An agent cannot determine the difference between clearing and deleting a tree, what happens to child nodes, or whether the operation affects session or strategy 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?

The input schema already documents treeId with the description 'The ID of the tree to clear,' and schema coverage is 100%. The description's 'by ID' is redundant, and no additional parameter meaning is provided. 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 uses a specific verb ('Clear') and resource ('a specific tree'), and it identifies the tree by ID. However, it does not distinguish 'clear' from sibling operations like delete_tree, and the meaning of 'clear' remains ambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives such as delete_tree, prune_tree, or clear_strategy. There are no conditions, exclusions, or references to other tools, leaving the agent to infer the appropriate 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose the key trait — deep copy with new IDs — but it does not address side effects such as whether the original tree stays untouched, what happens to existing thoughts in the target strategy, or how namePrefix affects the clone.

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 tightly worded sentence with the primary behavior front-loaded and the important deep-copy semantics placed in a parenthetical. There is no filler or redundant restatement of the tool name.

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 3-parameter tool with no annotations and no output schema, the description captures the core operation but leaves return expectations, when-to-choose-over-move_tree_to_strategy, and side-effect details unstated. It is minimally viable but not fully complete.

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

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

Schema description coverage is 100%, so the schema already documents treeId, namePrefix, and strategyIdOrName. The description adds general deep-copy context but does not clarify parameter edge cases such as ambiguous strategy names or optional prefix behavior beyond what the schema already states.

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 action ('Clone... into a strategy') and resource (a tree), and clarifies semantics with 'deep copy with new IDs for tree and all thoughts.' This naturally distinguishes it from move_tree_to_strategy without needing to name the 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 phrasing implies a copy operation rather than a move, so an agent can infer when to use it, but there is no explicit guidance, prerequisite, or pointer to move_tree_to_strategy as the alternative. The description does not state whether the target strategy must already exist or whether create_strategy should be called first.

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 of behavioral disclosure. It states that a new Strategy is created but does not explain behavior around duplicate names, validation, persistence, permissions, or what response the agent should expect after creation. For a mutating tool, this is a meaningful 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 sentence with no redundant filler. It front-loads the action ('Create a new Strategy') and then gives the purpose, making it easy to scan and understand.

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 parameter schema is sufficient, but with no output schema and no annotations, the description omits what happens on success, duplicate-name behavior, and any exclusions. It is minimally viable but not fully complete for an agent deciding whether and how to invoke it.

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%, with the schema already explaining 'name' and 'description' well. The description adds conceptual context about grouping related trees but no new parameter-level 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 uses the specific verb 'Create' with the resource 'Strategy' and adds a clear purpose ('grouping related trees for long-term reasoning initiatives'). This distinguishes create_strategy from sibling tools like list_strategies, get_strategy, and clear_strategy without needing the schema.

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 'for grouping related trees for long-term reasoning initiatives' implies when the tool is relevant, but there is no explicit when-to-use or when-not-to-use guidance. It also does not point to alternatives such as list_strategies or get_strategy, leaving usage to inference.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states that a new tree is created and does not mention what happens on success, whether data is persisted, how sessions interact, or any side effects. For a mutating tool 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 sentence with no filler. It front-loads the core purpose and omits redundant detail that is already in the schema.

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 and no annotations, the description leaves important context unexplained: return value, behavior of maxDepth/metadata/sessionId, and how this tool relates to sibling session and strategy tools. For a creation tool with 5 parameters, this is not complete enough.

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 parameter semantics are already well-defined there. The description's mention of 'root thought and goal' echoes two required parameters but adds no new meaning or format details beyond what the schema provides. 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 uses a specific verb ('Create') and a clear resource ('a new Tree of Thoughts') and names the essential components (root thought and goal). This distinguishes it from sibling tools that operate on existing trees, like add_child, delete_tree, or get_tree.

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 intended usage is implied: use this when you want to create a new tree. However, it gives no explicit guidance about when not to use it, nor does it reference alternatives like clone_tree_to_strategy or add_child for related operations. The context is clear but exclusions are absent.

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 disclosing behavior. It explicitly states that the tool deletes all trees and thoughts for a session, clearly communicating the destructive scope. It does not mention irreversibility explicitly, but 'Delete all' conveys the destructive nature sufficiently for this simple 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 a single, focused sentence that front-loads the action and scope. There is no filler or repetition of schema details, making it easy 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 one-parameter destructive tool with no output schema, the description adequately specifies what is deleted and for which session. It is slightly incomplete in that it does not warn about irreversibility or confirm cascading deletion of thoughts beyond the main phrase, but overall it is sufficient 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?

Schema description coverage is 100% and the sessionId parameter is already described as 'The session ID to delete trees for'. The tool description adds little beyond that, so the schema carries the semantic weight; 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 ('Delete'), the resource ('all trees and thoughts'), and the scope ('associated with a specific session ID'). This distinguishes it from related tools like list_trees_by_session and delete_tree without requiring the reader to inspect schemas.

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 word 'for cleanup' implies the intended use case, but there is no explicit guidance on when to choose this over delete_tree or when not to use it. Sibling alternatives are not mentioned, so an agent must infer the usage from the name and description.

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 explaining behavioral side effects. It states that a tree is deleted but does not disclose whether deletion cascades to children, whether it is irreversible, what permissions are required, or what the response indicates. This leaves the agent without insight into destructive consequences.

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 filler. The action and target are front-loaded and every word contributes to meaning, making it optimally concise for such 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 one-parameter tool with no output schema and no annotations, the description is minimally adequate. It tells the agent what input is needed and what effect occurs. However, it does not explain the return value or any cascading side effects, which would be valuable for a destructive operation.

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 already describes treeId as 'The ID of the tree to delete' with 100% coverage. The description does not add further semantic detail, so it stays at the baseline for fully documented schemas.

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 ('Delete'), the resource ('a tree'), and the identifying input ('by ID'). It is distinguishable from broader operations like delete_session_trees or clear_tree, though it does not explicitly contrast itself with those 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?

The phrase 'Delete a tree by ID' implies the tool should be used when a specific treeId is known and that single tree must be removed. However, it provides no explicit guidance about when not to use this tool or where alternatives like delete_session_trees would be more appropriate.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not reveal whether this mutates stored state, whether it writes evaluation results to the tree, or what the response contains. The claim that score can be '0-1 or 0-100' actively misleads, since the schema enforces 0-100 only, undermining trust in the description.

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 brief and front-loads the core verb and resource, which is efficient. However, it earns no extra credit for conciseness because one of its few details ('0-1') is inaccurate and the term 'multi-criteria fields' is vague, making the sentence compact but not sharp.

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 7 parameters, 3 required, nested objects, no output schema, and no annotations, this description is too thin to fully guide an agent. It does not explain what criteriaScores represents, how score relates to the optional criteria, whether inputs are persisted, or what success/failure looks like after 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?

Although the schema has 100% parameter coverage, the description introduces confusion by allowing a '0-1' score scale that the schema contradicts. It also refers vaguely to 'optional multi-criteria fields' without explaining how criteriaScores, risk, creativity, or reasoning map to that phrase, providing no additional clarity beyond the schema.

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

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

The description clearly identifies the action ('Evaluate a thought') and the primary resource ('thought'), which distinguishes it from sibling tools like verify_thought or refine_thought at a basic level. The mention of a score and optional multi-criteria fields adds specificity, though '0-1 or 0-100' is ambiguous and conflicts with the schema's 0-100 range.

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 use this tool versus alternatives like verify_thought, select_thought, or self_reflect_thought. It does not state any prerequisites, such as needing an existing tree and thought, nor does it clarify whether this tool is for recording an evaluation versus merely scoring one.

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 of behavioral disclosure. It fails to state whether exploration mutates the tree, triggers evaluation, or merely reads/steps through thoughts, and it says nothing about return values or side effects.

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 that front-loads the core purpose and enumerates the supported strategies. It is efficiently worded, though it lacks any additional structural elements such as usage notes or examples.

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 five parameters, a nested stop criteria object, no output schema, and no annotations, the description is too sparse. It does not clarify what the tool returns, whether exploration has side effects, or how stop criteria and beam width interact with the chosen strategy.

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 description coverage is 100%, so the input schema already documents all parameters, including strategy enum values and stop criteria. The description adds no semantic detail beyond what the schema provides, which meets the baseline but does not exceed 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 uses a clear verb ('explore'), a specific resource ('thought tree'), and the mode ('systematic branching strategy') with listed strategies. It conveys the tool's function but does not explicitly differentiate it from sibling tools like visualize_tree or get_tree_structure.

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 a systematic branching strategy such as BFS, DFS, beam, or best-first is desired. However, it gives no explicit guidance about when not to use it or how it compares to alternative exploration/traversal 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?

With no annotations, the description carries the full burden of behavioral disclosure, but it only mentions the generate-and-evaluate action. It does not disclose whether the tree is mutated, what is returned, or the state change semantics, and it overstates LLM judge usage even though useLLMJudge is optional in the schema.

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 filler. It front-loads the core operation and the key distinguishing feature, 'in one call', making it easy to scan.

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 seven-parameter tool with no output schema and no annotations, this one-sentence description is insufficient. An agent cannot infer the return value, side effects on the tree, default evaluation behavior when useLLMJudge is false, or how metadata and diversityPrompt influence the operation.

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 for parameter semantics is met. The tool description adds little beyond the schema except the 'LLM judge' hint, which is somewhat misleading because useLLMJudge is optional and defaultScore can be used instead.

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 combined operation: generate child thoughts and evaluate them. The phrase 'in one call' distinguishes this tool from sibling tools like generate_children and evaluate_thought without requiring the agent to open the schema.

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 this tool is the combined alternative to generate_children and evaluate_thought, but it never explicitly says when to use it versus those separate tools. It also does not clarify when to set useLLMJudge versus relying on defaultScore, so usage guidance is mostly inferred.

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 carry full behavioral disclosure. It states that children are generated, but does not reveal whether they are persisted to the tree, added as temporary outputs, or require a separate add_child call. Side effects, return behavior, and relationship to evaluation are all undisclosed.

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 the core action front-loaded. The parenthetical '(thought generation tool)' is slightly redundant but harmless and brief. Overall it is efficient and easy to scan.

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 five parameters, no annotations, no output schema, and many closely related sibling tools, this description is too sparse. It does not explain return values, mutation effects, or how it differs from generate_and_evaluate_children, leaving an agent under-equipped to correctly invoke it in 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 description coverage is 100%, so the baseline is 3 and the description need not re-explain parameters. The description's mention of 'N' and 'diverse' aligns with numChildren and diversityPrompt, but it adds no semantic value beyond the schema.

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

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

The description states a specific verb and resource: generate N diverse child thoughts for a parent thought. It clearly conveys the core action and resource, and the 'diverse' qualifier gives useful specificity. However, it does not explicitly distinguish itself from siblings like generate_and_evaluate_children or add_child, leaving the differentiation to names rather than description.

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 want to diversify a parent thought) but provides no explicit guidance on when not to use it or which alternative to prefer. Given sibling tools like generate_and_evaluate_children exist, the missing explicit routing is a notable gap.

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 behavioral disclosure. It states the core read behavior and the optional sorting, but does not explain what 'best' means, whether prior evaluation is required, or what the return shape looks like. Some context is provided, but richer detail is missing.

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 sentence with no fluff, front-loaded with the verb and resource. Every word contributes to the 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?

The tool has no output schema and no annotations, so the description should explain what is returned and any prerequisites. It only says 'best evaluated thoughts' without defining 'best', the return format, or whether evaluations must already exist. A getter with this little context leaves an agent guessing.

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 three parameters. The description adds only the notion of optional sorting, which aligns with sortBy. This meets the baseline for schema-covered parameters.

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 ('Get') and the resource ('best evaluated thoughts in a tree'), and mentions optional sorting. While it does not explicitly differentiate from sibling tools, the focus on 'best evaluated thoughts' is specific enough to be distinct from get_thought or get_tree_structure.

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 use this tool versus alternatives like get_thought, evaluate_thought, or get_tree_structure. No exclusions or alternative conditions are mentioned.

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 clearly states a read-only style operation ('Get all thoughts') and its scope ('across all trees for a specific session ID'), but it does not disclose return format, potential size, pagination, ordering, or any side effects. This is adequate but not rich.

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 that front-loads the core action and scope and ends with the purpose. There is no fluff or repeated schema 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 is low complexity—one required parameter and no nested objects—so the description covers the basic invocation need. However, with no output schema and no annotations, the description does not specify what the returned 'thoughts' look like, how they are organized, or whether any response limits apply, leaving a moderate 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%: sessionId is already described as 'The session ID to get context for'. The description adds only the word 'specific', which does not substantially increase meaning beyond the schema. 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 uses a specific verb ('Get') with a clear resource ('all thoughts across all trees') and a clear scope ('for a specific session ID'). It also states the purpose ('to understand the full context'), making it easy to distinguish from related tree/session tools like get_tree_structure or list_trees_by_session.

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 use this tool versus alternatives, such as list_trees_by_session, get_tree, or get_tree_structure. It implies a use case ('understand the full context'), but it does not state exclusions, prerequisites, or preferred 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?

With no annotations provided, the description carries the behavioral disclosure burden. It usefully reveals case-insensitive matching and that names can be used in place of IDs, but it does not mention read-only behavior or what happens when no strategy is found.

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 short sentence fully fronts the operation and includes only meaningful information: the resource, identifier modes, and case-insensitivity. No redundancy.

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

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

For a single-parameter, no-output-schema getter, the description and input schema are largely sufficient to invoke the tool correctly. The main gaps are explicit sibling-tool routing and not-found/return behavior, which are minor for this simple read operation.

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 already documents 'id' as 'The ID or name of the strategy', so baseline is 3. The description adds value by explicitly noting case-insensitive lookup, which is important for correctly passing name values.

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 action and resource: 'Get a strategy by ID or name'. It also adds a useful qualifier (case-insensitive) and distinguishes itself from sibling list/context tools by focusing on a single strategy lookup.

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?

Usage is implied: use this when you need a single strategy and have its ID or name. However, it does not explicitly contrast with alternatives like list_strategies for enumeration or get_strategy_context for context-specific 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, the description carries the burden of behavioral disclosure. It adds useful behavioral context by stating the result combines strategy, trees, and basic statistics as an aggregate view, and 'Get' implies a read operation. It does not go further into error behavior, permissions, or what 'basic statistics' includes, so it is adequate but not rich.

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 one tight sentence that front-loads the core action and result, with a parenthetical that clarifies the aggregation scope. Every word earns its place; there is no fluff or repetition of the parameter schema.

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-parameter read-style tool with no output schema, the description gives a sufficient mental model of what will be returned: the strategy, its trees, and aggregated basic statistics. It could be more explicit about which statistics are included or how this relates to session context, but these are minor gaps for such a simple 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?

The single parameter strategyIdOrName is 100% documented in the schema with 'The ID or name of the strategy', so the schema already carries the semantic weight. The description adds nothing specific about the parameter, which is acceptable given the high schema coverage; 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 names a specific verb ('Get'), a resource ('strategy'), and the returning content ('trees and basic statistics'), and clarifies the view is aggregated across trees. This distinguishes it from nearby siblings like get_strategy or list_trees_by_strategy by making the scope explicit.

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 'aggregated view across trees' implies this tool is for strategy-level overview, which gives some usage context. However, it does not explicitly state when to use this tool over get_strategy, get_tree_stats, or list_trees_by_strategy, nor does it mention any exclusions.

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

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

No annotations are provided, so the description carries the full burden. It surfaces a read operation through 'Get', but does not disclose behavior such as what is returned, whether not-found errors occur, or how treeId scopes the retrieval. For an unannotated getter this is underwhelming.

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 with no wasted words. It is appropriately brief for a simple getter, though it leaves out useful context that could have been added without bloat.

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 getter with full schema coverage, the description is basically adequate to invoke it: provide treeId and thoughtId. But with no output schema, it doesn't describe what the response contains, and it provides no context on when this tool is the right choice among many thought-related siblings.

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% because both treeId and thoughtId have descriptions in the input schema. The description adds no extra parameter meaning, 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 'Get a specific thought by ID' states a clear verb and resource, and the 'by ID' qualifier distinguishes it from list-style siblings like get_best_thoughts. It doesn't explicitly name a sibling or describe scope, so it falls short of the strongest examples.

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

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

No guidance is given for when to use this tool versus alternatives such as get_tree_structure, get_best_thoughts, or evaluate_thought. The description implies a simple retrieval but provides no explicit 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool retrieves a tree; it does not mention return format, behavior when the tree is not found, whether the result includes nested children, or any side-effect-free guarantee beyond the meaning of 'Get'.

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, economical sentence with no filler or redundancy. Every word contributes to the core purpose, and the key qualifier 'by ID' 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?

Despite the low parameter count, the lack of an output schema and the large number of sibling tree-related tools make the description incomplete. An agent cannot tell what 'a tree' means here versus get_tree_structure or list_trees, and the return value is not described.

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 treeId parameter is already described as 'The ID of the tree to retrieve'. The description merely restates this in prose and adds no additional semantic value beyond the schema.

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

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

The description uses a clear verb ('Get') and resource ('a tree') with a scoping qualifier ('by ID'), which is specific and unambiguous as a retrieval operation. However, it does not distinguish itself from siblings like get_tree_structure or list_trees, so it is not fully differentiated.

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 guidance about when to use this tool versus siblings such as get_tree_structure, get_tree_stats, or list_trees. No exclusions, alternatives, or contextual conditions are mentioned.

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 responsibility for disclosing behavior. It states that statistics are retrieved, but does not indicate whether this is read-only, what data the response contains, whether it has side effects, or how it handles missing or invalid tree IDs. This leaves a meaningful 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 concise sentence with no redundant words. It is front-loaded and easy to parse. However, it errs toward underspecification, so it does not achieve the highest conciseness score where every word fully earns its place by adding necessary context.

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 (one parameter, no nested objects), but the description is too vague about what 'statistics' actually includes. With no output schema and no annotations, the agent has no idea what the tool returns or what scenarios call for it. A bit more specificity, such as the kinds of metrics covered, is needed for proper 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?

The input schema has 100% description coverage: treeId is described as 'The ID of the tree.' The description adds no additional parameter semantics, but the schema already handles the single parameter adequately, so a 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 states a clear action ('Get statistics') and a clear resource ('a tree'), which is enough to distinguish it from generic tree retrieval tools like get_tree. However, it does not explicitly differentiate itself from siblings such as get_tree_structure or get_best_thoughts, and 'statistics' remains somewhat underspecified.

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. It does not mention what kind of statistics are relevant, when get_tree or get_tree_structure would be more appropriate, or any exclusions. The agent must infer usage entirely from naming.

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

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

No annotations are provided, so the description must carry the behavioral burden. It does convey that this is a read operation returning hierarchy, but it leaves unclear details such as whether the entire nested tree is returned, whether ordering is stable, or what happens for missing tree IDs.

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. It is concise and easy to parse, though it is brief enough that it does not earn the top score for structural richness.

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 required parameter and a simple read operation, the description is minimally adequate. However, with no output schema and many closely related sibling tools, it does not clarify what shape the hierarchical structure takes or when this tool is preferable to get_tree.

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 for the single parameter treeId, so the baseline is 3. The description adds no additional parameter-level meaning beyond what the schema already documents.

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 (get) and the target resource (hierarchical structure of a tree). However, it does not distinguish this from sibling tools like get_tree, get_tree_stats, or visualize_tree, so an agent must infer the difference.

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 guidance on when to use this tool versus alternatives such as get_tree or list_trees. With many sibling tools operating on trees, the lack of explicit usage context forces the agent to guess.

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. The verb 'Get' implies a safe read-only operation, but the description does not disclose what 'version information' includes or what the response format will be. It offers basic behavior but lacks richer context.

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

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

The entire description is a single sentence that gets straight to the point. Every word contributes meaning, and the resource is front-loaded.

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

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

Given the simplicity of the tool — no parameters, no annotations, no output schema — the description is nearly complete. A slight gap is that 'version information' could mean a simple string or a structured object, but the purpose is clear enough for an agent to invoke the tool and interpret the returned data.

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 schema description coverage is 100%, so no parameter documentation is needed. Per baseline for 0-param tools, the description sufficiently avoids any parameter ambiguity.

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

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

The description uses a direct verb 'Get' and clearly identifies the resource: version information of the ToT MCP server. It is unambiguous and distinct from all sibling tools, none of which relate to version retrieval.

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 context is clear: this tool is for retrieving server version information. No alternatives or exclusions are needed because no sibling tool serves a similar purpose. The absence of explicit when-to-use guidance is acceptable given the unique, self-evident function.

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 itself must establish the tool's behavior. 'List' implies a read-only operation and 'all strategies' sets scope, but the description adds no detail about permissions, workspace scope, ordering, or return behavior. Adequate but minimal.

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

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

A single front-loaded sentence states action, object, and optional filter with zero redundancy. 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?

For a simple one-optional-parameter list operation with no output schema, the description is sufficient: it communicates the operation, the resource, the optional filter, and implicitly the return of strategies. It is not missing critical information an agent would need to invoke 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% for the only parameter, status, including its enum values and optionality. The description echoes that status is an optional filter but adds no syntax 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 'List' with the resource 'all strategies' and the optional status filter, making it easy to distinguish from sibling tools like get_strategy or clear_strategy. It states scope precisely and is not a tautology.

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 conveys a clear use case—enumerating strategies, optionally by status—but provides no explicit when-to-use versus alternatives such as get_strategy or list_trees_by_strategy. The guidance remains implied rather than 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?

With no annotations, the description carries the full burden of behavioral disclosure. 'List all trees' only restates the operation implied by the name and does not state whether the operation is read-only, what data is returned, how scope is determined, or any side effects. It adds minimal value beyond the tool name.

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 extremely concise and front-loaded, with no wasted words. However, it is so terse that it borders on under-specification, leaving important context about scope and output to be inferred.

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

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

Despite having zero parameters and no output schema, the description is incomplete for an agent trying to select the correct tool. It does not clarify whether 'all trees' means all trees in the current session, all trees across all sessions, or all trees within a strategy, and it does not describe the return format. Sibling tools with more specific names highlight the ambiguity.

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, so no parameter documentation is needed. The schema coverage is trivially 100%, and the description does not need to explain parameter semantics. The baseline score of 4 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: 'List all trees'. It distinguishes scope as 'all', but does not explicitly differentiate from sibling tools like list_trees_by_strategy or list_trees_by_session, so the distinction is left to the tool name.

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. Given sibling tools with similar names and overlapping purposes, the description should explain when 'list_trees' is the right choice (e.g., listing across all sessions or strategies) versus list_trees_by_strategy or list_trees_by_session.

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 indicating the tool is a read-only listing operation. The verb 'List' implies a non-destructive read, and 'all trees associated with a session ID' states the core behavior. However, it does not disclose whether any side effects, auth requirements, ordering, or pagination happen. This is a basic but acceptable level of transparency.

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

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

One sentence with no redundant phrasing. The verb, resource, filter, and purpose are all front-loaded and clear.

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 list tool with one parameter and no output schema, this description is nearly sufficient. It explains what the tool does and why it is used, though it stops short of describing the return format or behavior when no trees match the session. This is a minor gap for straightforward call/invocation decisions.

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 sessionId parameter is already described as the filter. The description adds only the phrase 'specific session ID,' which does not materially improve semantic understanding 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 ('List') and resource ('all trees') and clearly scopes it to a specific session ID. It distinguishes this tool from siblings like list_trees and list_trees_by_strategy by the session-based filter.

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 'for context maintenance' implies a use case, but the description does not explicitly say when to use this tool over alternatives like list_trees_by_strategy or get_session_context. No exclusions or alternative routing 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 carries the full burden. It only states the basic action and parameter, without disclosing details like pagination, ordering, matching rules (case sensitivity, partial matches), whether it returns tree IDs or full objects, or error behavior if the strategy is not found. It adds only minimal behavioral context beyond the schema.

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, focused sentence with no fluff. It front-loads the main action and scope. It is appropriately sized for a simple tool, though it could have been 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?

The tool is simple (one parameter, no output schema), so minimal description may suffice. However, given the crowded sibling context (list_trees, list_trees_by_session, move_tree_to_strategy, etc.), the description leaves ambiguity about what 'belongs to a strategy' means (e.g., direct children vs. all descendants) and the return format. It is adequate but not complete.

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

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

The schema describes the parameter as 'The ID or name of the strategy' at 100% coverage. The description repeats the same idea ('by ID or name') without adding new meaning. Baseline 3 is appropriate because the schema already covers the parameter.

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 resource ('trees belonging to a strategy'), with a clarifying parenthetical '(by ID or name)'. This distinguishes it from sibling tools like list_trees (all trees) and list_trees_by_session (by session). The agent can easily tell what this tool does.

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 the use case: when you want trees filtered by a strategy identifier or name. However, it does not explicitly mention when not to use it or point to alternatives like list_trees or list_trees_by_session. The usage context is clear but not formally routed.

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 must carry the full burden of behavioral disclosure. It does so by mentioning cycle detection, depth validation, and dry-run mode for safe preview, which reveals important safety and validation behavior beyond the basic move operation. It stops short of describing failure responses or reversibility, but the key behavioral traits are covered.

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 wasted words. The core purpose is front-loaded, followed by valuable behavioral details. Every clause adds information the agent needs.

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 moderately complex mutation tool with no annotations and no output schema, the description covers purpose, constraints, and validation behaviors, but leaves gaps: what happens when cycle detection fails, whether the operation is atomic, and what the return value is. Adequate, but not fully complete.

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

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

The input schema covers 100% of the 4 parameters with clear descriptions, so the baseline is 3. The description adds only that dry-run mode is a safe preview, which is helpful but not essential beyond the schema's own parameter description. No parameters are left undocumented.

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 'Move a subtree to a new parent within the same tree', which states a specific verb, resource, and scope. It also distinguishes itself from sibling tools like move_tree_to_strategy (which implies moving across strategies) and add_child, 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 phrase 'within the same tree' gives clear context and implicitly warns against using this tool for cross-tree moves, which is what move_tree_to_strategy or clone_tree_to_strategy would handle. It does not explicitly name alternatives or state when-not-to-use, but the constraint is enough for reasonable 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?

There are no annotations, so the description must carry the behavioral disclosure burden. It does disclose that the operation is lightweight and preserves original tree IDs, which rules out a copy-style side effect. But it does not state whether the tree is removed from its previous strategy, whether the operation is reversible, or whether additional consequences such as auth or updated references apply.

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

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

The entire definition is one short sentence, with the main action front-loaded and the key behavioral qualifier in a compact parenthetical. Every word contributes meaning; there is no filler or repetition.

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 with fully documented input schema and no output schema, the core call is adequately described. However, because annotations are absent, side effects such as what happens to the previous strategy association are left implicit, and no alternative tool is named to help an agent route around edge cases.

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

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

Schema description coverage is 100%, with 'treeId' described as the ID of the tree to move and 'strategyIdOrName' as the ID or name of the target strategy. The tool description adds no parameter-level detail beyond what the schema already 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 names the action ('Move'), the resource ('a tree'), and the destination ('a strategy'), and the parenthetical 'lightweight operation that preserves original tree IDs' helps distinguish it from a clone operation. This is a specific, unambiguous verb+resource statement. It does not need to name siblings to be clearly scoped.

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?

Because the description says 'lightweight operation that preserves original tree IDs,' an agent can infer this is preferable when it wants to avoid a heavy clone. However, it never explicitly tells the agent when to use this tool instead of clone_tree_to_strategy or move_subtree, and it provides no exclusions or prerequisites.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states that it adds and evaluates a child thought, implying persistence and mutation, but does not disclose side effects, idempotency, permission requirements, return behavior, or whether the evaluation is stored. This is a significant gap for a mutating 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 a single concise sentence that front-loads the primary action ('Add a child thought and evaluate it in one call') and then adds the key differentiator ('auto-evaluation helper, optional multi-criteria fields'). No word 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?

For a tool with 9 parameters, nested objects, no output schema, and no annotations, the description provides insufficient operational context. It does not explain required fields, how criteriaScores are used, what the response contains, or the relationship to the tree structure. An agent would need to infer most invocation details from the schema alone.

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 100% of parameters with descriptions, so the baseline is 3. The description adds marginal context by mentioning 'optional multi-criteria fields', which hints at criteriaCores and related scoring parameters, but does not meaningfully enhance schema documentation.

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

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

The description uses a specific verb and resource: 'Add a child thought and evaluate it in one call'. It clearly names the combined action and differentiates it from siblings like add_child and evaluate_thought by presenting itself as an auto-evaluation helper, so an agent can select it without opening the schema.

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 'in one call (auto-evaluation helper)' implies the intended use as a convenience wrapper around adding and evaluating, but it does not explicitly state when to prefer this over alternatives like evaluate_thought or generate_and_evaluate_children. No exclusions or when-not-to-use guidance is 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It says thoughts below a threshold will be pruned, but it does not disclose whether pruning is irreversible, whether it affects descendant thoughts or whole subtrees, whether thresholds are inclusive/exclusive, or whether any permission is needed. 'Prune' implies destructive behavior, but the scope and side effects are unclear.

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 fluff or repetition. It front-loades the core action and threshold condition. However, it is so terse that it omits behavioral context that would make it easier to use.

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?

Even though the schema documents all parameters, the tool has no annotations and no output schema. A destructive operation like pruning needs more context: does it remove thoughts permanently, does it cascade to children, what does it return, and can it be reversed. The description is not complete enough for an agent to safely call this tool without 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?

Input schema covers all parameters at 100% with descriptions for treeId, threshold, and riskThreshold. The description adds no new semantic detail beyond 'optionally by risk threshold', which merely restates the optional parameter. With full schema coverage, 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 uses a specific verb ('prune') and identifies the resource ('thoughts') with the criteria (evaluation threshold, optional risk threshold). It is distinct from siblings like delete_tree, clear_tree, and backtrack, though it does not name them. The phrase 'a certain evaluation threshold' is slightly vague but understandable.

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

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

No guidance is given about when to use this tool versus alternatives such as delete_tree, backtrack, or clear_tree. The description implies pruning thoughts below a threshold but does not state conditions, prerequisites, or cases where a different tool should be chosen.

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 responsibility for disclosing behavior. It reveals the operation uses an LLM and aims to improve alignment, but it does not explain whether the original thought is modified in place, whether a new thought is created, whether the original is preserved, or what the return value is. This missing side-effect and outcome information is a significant gap for a tool that presumably mutates the thought tree.

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 the verb and resource placed at the beginning, and every word contributes to the meaning. 'Using LLM' is slightly redundant within an LLM-based system but is not wasteful. The structure is easily scannable and appropriately concise.

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 no annotations and no output schema, the description is too sparse. It does not specify return values, side effects, preconditions (e.g., whether the thought must already exist in the tree), or how the result is surfaced. While the schema is complete for parameter names, the behavioral context is insufficient for an agent to call the tool with full confidence.

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 both parameters (treeId, thoughtId) are clearly documented as IDs. The description adds no parameter-specific detail beyond the general notion of 'a thought' and 'the goal', so it does not enhance the schema. Baseline 3 applies because the schema already handles 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 uses a specific verb ('refine') and resource ('a thought') and states the objective ('better align with the goal'), which clearly conveys the intended action and differentiates it from evalution, verification, and selection operations. However, it doesn't explicitly reference sibling tools, and 'the goal' is an assumed context that could be ambiguous without surrounding system knowledge.

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 'to better align with the goal' implies a use case: when a thought needs adjustment toward the goal. However, there is no explicit when-to-use versus when-not-to-use guidance, no preconditions, and no comparisons to alternatives such as evaluate_thought or self_reflect_thought. The context is implied rather than clearly spelled out.

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 responsibility for disclosing side effects. It reveals that the operation persists state but does not state whether it overwrites a previous snapshot, whether it is idempotent, whether prior changes must exist, or what happens on success/failure.

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 filler or redundancy. Every word earns its place, and the main verb 'save' appears first.

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 0-parameter tool with no output schema, the description gives the core operation but leaves scope ambiguous: 'current state' could mean session, tree, or global storage. It also does not explain return or success behavior, so an agent can call it but cannot fully predict its consequences.

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 an empty input schema, so there are no parameter meanings for the description to clarify. Per the zero-parameter baseline, the description adequately covers the input contract by not omitting anything relevant.

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 action ('save') and a clear object ('current state to storage'), so an agent can infer the tool's basic purpose. It does not explicitly differentiate from sibling tools, but no sibling offers an equivalent save/persistence operation, making the purpose reasonably distinct.

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 guidance on when to invoke this tool versus alternatives. The word 'Manually' implies it is used for explicit, user-triggered persistence, but no conditions, prerequisites, or alternative tool references 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?

With no annotations, the description carries the full burden of behavioral disclosure. It states that the operation changes state ('Mark') and requires prior verification, but doesn't disclose whether selection is reversible, whether selecting one thought deselects others, or what downstream effects selection may have. For a simple state-changing tool this is marginal but not 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 a single sentence with a parenthetical precondition, containing no redundant words. The action is front-loaded, and the constraint is attached with minimal overhead.

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 state-marking tool with no output schema, the description provides the essential context: the action, the target resource, and the required precondition. It does not explain failure behavior or downstream effects, but these are less critical for such a simple operation.

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%, as both treeId and thoughtId have descriptions. The tool description adds no additional parameter semantics beyond what the schema already provides, so 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 uses a specific verb, 'Mark', and a clear resource, 'thought', and names the resulting state: 'selected for further exploration'. It distinguishes select_thought from sibling tools like verify_thought or evaluate_thought by targeting a selection state, though it does not explicitly name any alternative tool.

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 parenthetical gives an explicit precondition: the thought must be verified first. This gives clear context that select_thought should not be called before verify_thought, effectively excluding unverified thoughts. It does not describe alternative tools or broader use cases, but the workflow implication is clear.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does reveal the internal mechanism (LLM self-reflection) and the output concept (critique and improved version), which is useful. However, it does not clarify whether the original thought is mutated, whether the improved version is persisted, or what the actual return shape is.

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 filler words. It efficiently conveys the core action and method, though it is arguably too terse to cover usage or side-effect guidance.

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 two required parameters, no output schema, no annotations, and a large set of sibling tools that operate on thoughts, the description is not complete enough. It fails to distinguish this tool from refine_thought/evaluate_thought and does not clarify whether the tool modifies the thought tree or only returns a critique.

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 additional meaning beyond the schema's own descriptions for treeId and thoughtId; it only indirectly implies both are needed for 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 ('Get'), a clear resource ('a critique and improved version of a thought'), and the method ('using LLM self-reflection'). It is unambiguous about the tool's basic function, but it does not differentiate it from similarly named siblings like refine_thought or evaluate_thought.

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 about when to use this tool versus alternatives such as refine_thought, evaluate_thought, verify_thought, or select_thought. The description implies a use case but never states it explicitly, nor does it offer exclusions or 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?

With no annotations provided, the description must shoulder the burden of disclosing behavior. It says the tool 'analyzes' and 'returns recommendations', implying a read-only advisory role, and enumerates the kinds of recommendations. However, it does not explicitly state that the tree is not modified or describe the shape/ordering of the returned recommendations.

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 wordy but structured, front-loading the core usage condition. It repeats the same idea multiple times: being 'unsure what to do next' is echoed in 'tree feels stuck' and 'need guidance on the best next step', making it slightly longer than necessary.

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 gives a strong sense of when to call the tool and what general categories of recommendations to expect, which is adequate for a simple 3-parameter tool. Yet the lack of an output schema means the agent is not told the exact recommendation payload fields, priorities, or how to interpret conflicting suggestions, leaving some 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?

The input schema already documents all three parameters with 100% coverage. The description adds no extra detail about treeId, focusThoughtId, or maxSuggestions beyond what the schema provides, so 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 specific purpose: analyze the current Tree of Thoughts state and return prioritized actionable recommendations. It distinguishes itself from execution tools by listing recommendation categories (generate children, evaluate thoughts, prune branches, etc.), though it never references a sibling by name.

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 clearly frames when to use the tool: 'when you are unsure what to do next', 'when the tree feels stuck, has many pending items, or you need guidance on the best next step'. It does not explicitly state when not to use it or name alternatives, but the conditions are specific enough for an agent to decide.

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 behavioral disclosure. It clearly communicates that this is a state-changing 'mark as verified' operation and that it is a prerequisite for selection. However, it leaves some behavioral details implicit: it does not mention reversibility, what happens when called on an already verified thought, or any side effects beyond the verified flag. The core state change is disclosed, but not deeply.

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 exactly two sentences with no wasted words. The primary action is front-loaded ('Mark a thought as verified'), and the requirement about selection is placed immediately after, making the purpose crisp and scannable. It is an appropriate size for this 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 simple three-parameter tool with a fully descriptive schema, the description supplies the essential semantic context: the verification action is a deliberate post-confirmation state change that gates selection. It does not document return values or edge cases, but with no output schema and low complexity, that is not a critical gap. The description and schema together give an agent enough to call 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 parameter meanings are already fully documented. The description adds no specific parameter-level information beyond what the parameters' descriptions already provide. This matches the baseline of 3 when 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 uses a specific verb and resource: 'Mark a thought as verified' makes the primary action unambiguous. It adds meaningful context by stating the purpose ('after confirming its findings') and the consequence ('Required before a thought can be selected'), which clearly separates this from vague or tautological tool descriptions.This is a well-defined state transition rather than just a restatement of the name.

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 states when the tool is relevant (after findings are confirmed and before a thought may be selected), which gives the agent a usable precondition. It does not explicitly name alternatives or exclusions, but the surrounding sibling tools do not present a direct alternative verification path.Condition is enough to guide basic 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?

With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'human-readable format.' The non-destructive, read-only nature is merely implied by the verb 'visualize,' not stated. The base64-encoding behavior for PNG/SVG and the ascii default live in the schema, and the description does not mention side effects, permissions, or output characteristics beyond format names.

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 11-word sentence that front-loads the verb and resource and then enumerates the formats with zero filler or repetition. Nothing could be cut without losing information, and no word is wasted. Exemplary 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?

For a low-complexity 2-parameter tool with full schema coverage, the description plus schema give an agent nearly everything needed to call it correctly: the purpose, the format choices, the default, and return behavior for image formats. The only gap is the absence of sibling-selection guidance and explicit confirmation of non-mutation, which keep it from a 5.

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 treeId and the format enum, including the ascii default and the base64 return behavior for PNG/SVG. The description's format list merely mirrors the enum without adding meaning. Baseline 3 is correct because 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 states a specific verb ('Visualize') and resource ('a tree') and enumerates the five output formats (ASCII, Mermaid, DOT, PNG, SVG), which clearly distinguishes it from sibling data-retrieval tools like get_tree and get_tree_structure. The phrase 'human-readable format' signals a rendering/presentation tool rather than a raw-data or mutation tool. Self-sufficient and 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 offers no guidance on when to use this tool versus alternatives, even though siblings like get_tree_structure could plausibly overlap. No selection criteria, exclusions, or prerequisites are given. An agent must infer when the rendering tool is the appropriate choice instead of a structure or data tool.

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