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

No annotations are provided, so the description bears the full burden of behavioral disclosure. It only states the action, omitting prerequisites (e.g., existence of a current plan), side effects (e.g., modifies in-memory plan vs saved plan), and error behavior. 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?

The description is a single sentence with no wasted words. It front-loads the primary purpose effectively, which is exactly what a concise description should do.

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

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

The description is too terse for a mutation tool with no annotations. It does not explain the dependency on a current plan, the workflow in which add_todo fits, or what happens if the plan state is invalid. This lack of context could lead to incorrect usage.

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

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

The input schema provides 100% coverage with descriptions for all four parameters. The tool description adds no additional parameter meaning, so the schema carries the load. 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-resource pair ('Add a new todo item') and clarifies scope ('to the current plan'). This clearly distinguishes it from siblings like remove_todo, get_todos, and update_todo_status, which deal with different actions.

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

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

Usage is implied: it is for adding new todo items to the current plan. However, there is no explicit guidance on when to use this instead of update_todo_status or what conditions must exist (e.g., an active plan). No alternatives or exclusions 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 must carry the burden of behavioral disclosure. While 'Get' implies a read operation, it does not explicitly state read-only behavior, what happens if no plan exists, or whether there are side effects. The description is minimal and lacks detail about error conditions or output nuances.

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

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

The description is a single sentence that communicates the core purpose with no redundancy or unnecessary detail. It is well-structured and front-loaded, immediately stating what the tool does.

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 params, no output schema), the description is mostly adequate but lacks details on the expected format of the 'formatted text' and possible error conditions if no plan is available. It is complete enough for a trivial getter, but could benefit from mentioning when the plan is populated or how the output is structured.

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

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

The tool has zero parameters, and the schema shows no properties, so there are no parameter semantics to clarify. The description adds no parameter information, which is appropriate; a baseline score of 4 is warranted for a 0-param tool.

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 ('current implementation plan'), and specifies the output format ('as formatted text'). It distinguishes itself from sibling tools like get_todos and save_plan by focusing on the overall plan, not individual todo items.

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, such as get_todos or start_planning. It does not mention prerequisites, exclusions, or typical scenarios, leaving the agent to infer from the tool name alone.

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

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

No annotations are provided, so the description carries the full burden. It clearly indicates a read-only operation and adds the 'current plan' scope, but it does not disclose return format, ordering, or behavior when no plan is active. For a simple getter, this is 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?

The description is a single concise sentence ('Get all todos in the current plan') that conveys all essential information without redundancy or filler. 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?

For a zero-parameter read-only tool, this description is nearly complete. It states the resource and scope. There is no output schema, so the description could theoretically mention the return format, but 'get all todos' sufficiently implies the response. Sibling tool names further clarify 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 tool has zero parameters, so the schema fully covers parameter semantics. With 0 params, the baseline is 4; the description adds no parameter-related detail, but none is needed.

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

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

The description uses a specific verb ('Get'), identifies the resource ('all todos'), and scopes it ('current plan'). It clearly distinguishes this from sibling tools like get_plan (plan-level data) and add_todo/remove_todo/update_todo_status (mutating operations).

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 the current plan' implies this is the read-only counterpart to the todo mutation tools, but the description does not explicitly state when to use this tool over alternatives or mention exclusions. No direct alternative or when-not-to-use guidance is 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 must convey behavioral traits. The verb 'Remove' clearly signals a mutating operation, and no contradictory behavior is stated. However, it does not disclose whether the removal is permanent, any required prerequisites, or side effects on the plan.

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, direct sentence with no redundancy. It is appropriately sized and front-loaded with the action.

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

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

For a one-parameter mutation with no output schema or annotations, the description clearly states the action and scope. However, it omits details about return values, error conditions, or prerequisites, and the meaning of 'current plan' is left implicit. These gaps limit its completeness.

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

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

The schema fully documents todoId, and the description adds the important context that removal occurs 'from the current plan', which hints that todoId must belong to an active plan. This contextualizes the parameter beyond its basic ID label.

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 'Remove' with resource 'a todo item' and scope 'from the current plan', clearly distinguishing it from sibling tools like add_todo, get_todos, and update_todo_status.

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

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

The description implies a use case (removing an item) but provides no explicit guidance on when to use this tool over alternatives such as update_todo_status (which changes status) or explicit exclusions. Sibling tools exist but are not referenced.

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

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

With no annotations, the description must disclose behavioral traits. It only says 'save' without indicating whether it overwrites an existing plan, persists to storage, requires an active planning session, or returns any confirmation. This omission leaves significant ambiguity for a write operation.

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

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

The description is a single, front-loaded sentence that efficiently communicates the core action. No filler words or redundant information are present.

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 description omits important context such as prerequisites, side effects, and how it fits into the overall planning workflow. Given the lack of annotations and output schema, the description alone is insufficient for an agent to fully understand usage.

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

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

Schema coverage is 100% for the single 'plan' parameter, which already explains 'The implementation plan text to save'. The description adds no additional meaning beyond the schema, 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 clearly states the action ('Save') and the resource ('current implementation plan'), which distinguishes it from siblings like get_plan (retrieve) and add_todo. However, 'current' is somewhat ambiguous and does not explicitly clarify the scope relative to other planning tools.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as after start_planning or for saving a draft versus a finalized plan. No context or exclusions are given.

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

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

No annotations are provided, and the description only states the action without disclosing behavioral traits such as whether it overwrites an existing session, requires a prerequisite, or has side effects. This leaves the agent without critical safety/state information.

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 contributes to conveying the tool's purpose, making it highly concise and well-structured.

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

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

For a session-initiating tool, the description lacks important context about what happens to an existing session, whether the operation is destructive, and how it relates to sibling tools like get_plan or save_plan. The absence of annotations makes this gap more significant.

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 provides 100% coverage for the single parameter 'goal' with a clear description. The tool description adds no additional semantic detail beyond mentioning 'goal', so the baseline score of 3 applies.

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

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

The description 'Start a new planning session with a goal' uses a specific verb ('start') and resource ('planning session'), and clearly distinguishes from sibling tools like save_plan or update_goal, which imply saving or modifying rather than initiating.

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 'new planning session' implies usage when beginning a fresh session, but it does not explicitly state when to use versus alternatives or mention exclusions. There is no guidance about using update_goal for existing sessions.

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

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

With no annotations, the description must disclose behavioral traits. It only says 'update' with no mention of side effects, error conditions (e.g., no current goal), or whether changes are permanent. This is minimal transparency 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?

The description is a single sentence with no redundant wording. It is front-loaded with the action and resource, making it immediately clear and efficient.

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

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

For a simple mutation tool with one parameter and no output schema, the description adequately covers what it does. The only ambiguity is 'current goal', but this is a domain concept that may be established by sibling tools, so it does not hinder the agent's basic understanding.

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 fully describes the 'description' parameter. The tool description adds meaningful context by specifying 'current goal', which clarifies which goal is being updated—information not present in the schema. This extra context earns a score above the baseline.

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

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

The description clearly states the action ('Update') and the resource ('description of the current goal'). It is specific and unambiguous, differentiating it from sibling tools that deal with plans and todos rather than the goal's 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?

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., a current goal must exist) or exclude scenarios where another tool like start_planning or save_plan might be more appropriate. The usage context is only implied.

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

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

No annotations are provided, so the description carries the full burden. It implies a mutating action but doesn't disclose side effects, error handling, permissions, or response behavior. For a write operation, this is a significant 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, clear sentence that is front-loaded with the specific action. Every word earns its place, with no unnecessary detail or verbosity.

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

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

For a simple two-parameter update tool, the description is minimally adequate. However, it lacks usage context and behavioral details that would be helpful given the absence of annotations and output schema, leaving gaps around expected results and side effects.

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 complete descriptions for both parameters (todoId and isComplete), so the description adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate given the 100% schema description coverage.

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

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

The description clearly states it updates the completion status of a todo item, which is a specific action on a specific resource. This distinguishes it from sibling tools like add_todo/remove_todo and update_goal, which handle different aspects.

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 doesn't mention that this should be used for toggling completion status rather than adding/removing todos or updating other goal properties.

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