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

With zero annotations, the description carries the full burden and delivers richly: cycle rejection, automatic output capture, the `<camelCase flow name>Output` naming convention with numeric suffixes, array-of-outputs when a target runs multiple times, and the rule that composed-scenario entries never capture output. This far exceeds what any annotation set would typically provide.

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

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

The information density is justified by the tool's complexity, but the whole description is one massive unbroken block of parenthetical asides and nested clauses, making it hard to scan. It is front-loaded with the core purpose, yet would benefit from paragraph breaks per parameter. It earns its length but not its structure.

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 an 8-parameter tool with no output schema and no annotations, it is remarkably complete — covering target selection, dataset resolution, YAML fallback, postprocessing scope, and output capture semantics. The main gap is the required scenarioId parameter, which is never explained, and project is only documented in the schema. Minor omissions against a very high overall bar.

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 only 13%, so the description must compensate, and it does: datasetTokens (comma/space-separated, blank=first/default, multiple = sequential runs), useYaml/yaml (raw fallback, YAML/JSON object or list semantics, yaml ignored unless useYaml true), and postprocess (evaluated per run, receives params plus in-scope names, must return the whole params object). It leaves only scenarioId and project undescribed, which are largely self-evident.

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 precise statement of the verb and resource: append a flow OR another scenario to a scenario's composed sequence as a run config. It also differentiates from siblings — explicitly contrasting with live_replay_flow's dataset/params resolution and naming the composeScenarioId alternative. Purpose is unmistakable.

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 states when to use flowId (the common case) vs composeScenarioId, and warns that compose is rejected on composition cycles. It also scopes postprocess to live_replay_scenario/live_start_scenario_run. It does not explicitly say 'for immediate execution use live_replay_scenario' as an exclusion, but the references to live tools provide enough routing 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?

Without annotations, the description carries the full burden. It transparently explains the batch behavior, single undo entry, and placement rules (end of array by default, parentPath for nested bodies). It does not mention failure modes or validation, but the core behavior is well described.

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

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

The description is concise and front-loaded with the main purpose. It uses a clear structure, explains the difference from add_step, and provides a practical example without unnecessary 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?

The description is largely self-contained and provides enough context to use the tool, especially with the reference to add_step for placement rules. However, it does not specify all parameter meanings or edge cases, and there is no output schema, but the essential usage context is covered.

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 only 20% (only 'project' has a description). The tool description does not explain flowId, parentPath, or 'at' parameters, relying on reference to add_step. While the 'steps' parameter is thoroughly described in the schema, the missing explanations for other key parameters limit clarity.

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

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

The description clearly states the tool's function: adding a batch of steps to a flow in a single operation, distinguishing it from add_step. The verb 'Add' and resource 'steps to a flow' are explicit, and the contrast with add_step makes the purpose unambiguous.

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

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

It explicitly states when to use this tool over add_step ('avoids an add_step-per-step round trip when recording several steps at once') and provides a concrete example (live exploration session). This gives clear guidance on 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?

The description discloses the default append behavior and nested insertion via parentPath, but with no annotations it leaves side effects, validation, ordering behavior with the 'at' parameter, and failure modes undocumented.

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 top-level description is short and front-loaded with the core action. The step parameter's embedded documentation is dense and long, but it carries relevant authoring detail for a complex nested object.

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

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

The description covers the main use case and nested insertion, but it omits key context such as how the 'at' index behaves, what parentPath should look like, and what the tool returns or does on invalid input. These gaps matter for correct invocation.

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

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

The step parameter is described in considerable detail and project has a helpful default note, but flowId, at, and parentPath lack direct schema-level explanations. The intended format and semantics of at and parentPath are only partially inferable.

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 a step to a flow') and the primary resource. It also distinguishes the single-step insertion behavior from sibling tools like add_multiple_steps and update_step.

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

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

It gives one useful usage hint about parentPath for nested bodies, but it does not explicitly explain when to choose add_step over add_multiple_steps or update_step. This is a notable gap given the sibling toolset.

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 takes on the burden of explaining side effects. It clearly states that a new placement is created and that repeated calls do not move or merge, and it explains how dataset fields are used. It does not cover errors or permissions, but the primary behavior is transparent.

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

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

The description is overly long, run-on, and packed with nested parentheticals, making it harder to parse than necessary. Key points like 'new placement' and dataset fallback are repeated or buried in complex clauses.

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 lack of an output schema, the description covers the essential context: what the tool does, how duplicate calls behave, and how the dataset-related parameters function. The main remaining gap is a clearer explanation of what a 'saved run' means in practice, but overall the tool is reasonably 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 description adds meaningful detail beyond the sparse schema coverage, especially for datasetTokens, useYaml, yaml, and path. It clarifies that scenarioId refers to an existing scenario and that project falls back to an environment variable, though project is only explained in the schema.

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

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

The description clearly states the action as placing an existing scenario at a suite folder path, and it distinguishes this from a bare reference and from moving/merging. The phrase 'SAVED RUN, not a bare reference' is somewhat ambiguous, but the core purpose is identifiable.

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 provides useful guidance on duplicate behavior and the default dataset fallback when omit all three dataset-related fields. However, it does not explicitly explain when to prefer this tool over sibling tools like move_suite_entry or remove_from_suite, and the mention of add_flow_to_scenario could confuse 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 must carry the full behavioral burden. It discloses that the call returns immediately regardless of match, and that a match moves the connection from unverified to connected. It also advises verification, which is helpful. However, it doesn't specify what happens on a non-match (e.g., silent failure) or any potential side effects like invalidating existing connections, leaving some gaps for a tool with no annotation coverage.

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

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

The description is two sentences, front-loaded with the purpose and immediately providing the critical usage detail. Every sentence earns its place: the first states what and why, the second gives the exact input and verification step. No redundant information, perfectly sized for the tool's simplicity.

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

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

For a simple one-parameter tool with no output schema and no annotations, the description covers the essential aspects: what it does, how to use it, and how to confirm the result. It lacks explicit error handling or edge-case descriptions, but for this straightforward operation the provided guidance is sufficient. A minor gap is not addressing what happens if the session name is incorrect, but the verification advice mitigates that.

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

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

The schema already covers the parameter fully (100% coverage), so the baseline is 3. The description adds meaningful context by specifying the parameter must be the exact session name from the target panel's UI and providing an example, which clarifies the expected format beyond the schema's simple description. This elevates the score to 4.

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

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

The description clearly states the tool's purpose: establishing trust with a side panel via its session name. It distinguishes itself by noting it is 'the only way to do so' and explains the state transition from unverified to connected. This is specific and unambiguous, easily differentiating it from sibling tools.

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

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

Provides explicit usage instructions: pass the exact session name from the panel's UI, with an example. It also tells the agent to verify the result via live_status or the UI afterward, covering the correct workflow. While it doesn't explicitly state when not to use, it implies this is the sole method for connecting, so no alternative is needed.

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

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

The description explicitly discloses key side effects and behaviors: it creates a single undo entry on the target flow only, never modifies the source, and deep-clones nested Conditional/Repeat/Iterate bodies. These details go beyond the schema and provide essential transparency given the absence of annotations.

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

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

The description is concise, consisting of two sentences that first state the primary function and then provide supplementary details. It is well-structured, front-loading the core action and following with relevant nuances, with no redundant or extraneous information.

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

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

Given the tool's complexity with 8 parameters, the description covers the essential aspects: the operation, the range semantics, deep-copy behavior, and side-effect implications. It does not specify return values or error handling, but with no output schema and typical expectations, the description is sufficiently complete for an agent to understand and invoke the tool correctly.

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

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

The schema covers 88% of parameters with descriptions, and the tool description adds meaning to the range parameters (from, to) by explaining their 0-based inclusive nature and their scoping to sourceParentPath. It also clarifies the relationship between sourceFlowId and targetFlowId via the description on targetFlowId, though sourceFlowId itself lacks a schema description and is not elaborated in the tool description.

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

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

The description clearly states the tool's function: copying a contiguous run of steps from one flow into another, including the ability to copy within the same flow. It also specifies the semantic details of the range (inclusive 0-based indices) and the deep-cloning behavior, leaving no ambiguity about what the 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 provides practical use cases, such as splitting a flow or reusing steps from another flow, and contrasts this with manually reading and re-adding steps. It implicitly guides when to use this tool over a manual alternative, though it does not explicitly name sibling tools for comparison.

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

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

The description implies creation of a flow but does not mention side effects, error conditions, or required permissions. No annotations are provided to supplement this.

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 gets straight to the point without superfluous details.

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 parameter explanations and any success/failure behavior leaves gaps for an agent trying 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 only 43%, and the description does not explain the purpose of key parameters like id, name, folder, or description.

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 (create) and the resource (flow), and is distinct from sibling tools like list_flows and delete_flow.

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

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

There is no explicit guidance on when to use this tool versus alternatives, but the intent is obvious given the tool 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?

The description implies a write operation but does not disclose side effects, such as whether existing page objects are overwritten, whether directories are created, or what the response contains. With no annotations (e.g., destructiveHint), the agent cannot infer safety or failure behavior.

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

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

The description is a single concise sentence that immediately communicates the core action and object. No unnecessary words or filler.

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

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

The description lacks essential context for correct invocation: no mention of return format, error conditions, interaction with 'folder' and 'project' defaults, or relationship to project structure. Given the sparse schema and no annotations, this is a notable 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?

Only 'name' is required and self-explanatory; 'folder' and 'project' have no schema descriptions. The 'project' description clarifies its default, but 'folder' semantics remain unclear, so parameter meaning is only partially covered beyond the schema.

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

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

The description clearly states the action ('create') and the resource ('a new, empty page object'), making the tool's purpose unambiguous. It is distinct from related sibling tools like create_flow or create_scenario.

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 or prerequisites. It does not mention whether a project context is required, how 'folder' is resolved, or any conditions that would make this tool inappropriate.

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 discloses a mutation (create) but does not explain what 'empty' means in practice, what the return value is (no output schema exists), whether an id is auto-generated, or any side effects. For a creation tool with zero annotation coverage, 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 efficient sentence with the key qualifier front-loaded, but it borders on under-specification rather than genuine conciseness — it earns its brevity at the cost of omitting useful behavioral and parameter 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?

For a 7-parameter creation tool with no output schema and no annotations, the description is incomplete. An agent cannot determine what the tool returns, whether optional params (project, folder) affect behavior, or what 'empty' means operationally. More context is needed.

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

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

Schema coverage is 43%, below the 50% threshold, so the description must compensate for the undocumented parameters (id, name, folder, description). It adds nothing about any of the 7 parameters. The description's 'empty' hint touches scenario state, not 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?

Description states a clear verb (create), resource (scenario), and a meaningful qualifier ('empty') that implies the scenario starts with no flows/steps. The resource name distinguishes it from sibling create_* tools (create_flow, create_util, create_page_object), though it doesn't explicitly name them.

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

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

Usage is implied by the resource name — you create a scenario when you need a new scenario — but there is no explicit guidance on when to use this vs alternatives, nor any prerequisites mentioned (e.g., whether a project or folder must exist first). Adequate but leaves inference to the agent.

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

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

With no annotations, the description carries the burden. It indicates a creation operation ('Create') and specifies 'empty' (no params, empty body), which implies a side effect of adding a new resource. However, it does not mention what happens if the group does not exist, whether the operation can overwrite, or what the return value or error cases are. This leaves some behavioral aspects 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 that directly states the action, the object, and a key default behavior. It avoids unnecessary detail and is well-structured, with no redundancy or fluff.

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 absence of an output schema and sparse parameter descriptions, the description should compensate with more context. It does not explain what the created utility function entails beyond being empty, how to later modify it, or what success/failure responses look like. The reference to sibling tools is useful but not comprehensive enough for full 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?

Only the 'project' parameter has a description in the schema. The description adds some meaning to 'groupName' by stating 'Lands in the given group' and explaining the default, but 'name' and 'folder' are not elaborated. With only 25% schema coverage, the description does not sufficiently explain all parameters for an agent to use them confidently.

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

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

The description clearly states the tool's purpose: 'Create a new, empty shared utility function' with the verb 'Create' and object 'utility function'. It also specifies the default group and mentions the function is empty. This distinguishes it from other util-related tools like list_utils (listing) and delete_util (deletion).

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 some guidance by mentioning the default group and referencing related tools ('see list_util_groups/create_util_group'). However, it does not explicitly state when to use this tool over alternatives or when not to use it. The reference to sibling tools is helpful but indirect.

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 states the creation action and auto-creation context, but does not mention error behavior (e.g., if the group already exists), side effects, or any other operational details. Basic transparency is present but incomplete.

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

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

The description is concise and logically structured: it states the action, then explains the auto-creation behavior, then clarifies when this tool is needed. It avoids unnecessary detail while providing essential 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?

For a simple creation tool, the description covers the main purpose and usage condition. It does not describe return values or error handling, but no output schema is present and the core context is sufficient for a 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?

Only the 'project' parameter has a schema description; 'name' and 'folder' are undefined. The tool description does not clarify the meaning or format of 'folder' or any constraints on 'name'. Parameter semantics are therefore weak, leaving the agent to guess.

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

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

The description clearly states the tool's purpose: creating a new, empty util group. It distinguishes this from automatic group creation, and the verb 'create' precisely indicates the action. The resource and scope are 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?

Explicitly explains when to use the tool: only to create an empty group in advance, since groups are auto-created when placing utils. This gives direct usage guidance and prevents unnecessary calls.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what files are deleted but does not mention whether the operation is irreversible, whether it affects dependent scenarios or references, whether it requires special permissions, or what happens on error. A destructive operation like this needs more context to be safely invoked.

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, efficient sentence that leads with the verb and resource, then lists the affected files. No filler, no repetition, and the key information 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 that the tool is a destructive delete with no output schema and no annotations, the description is incomplete. It does not state whether the operation is idempotent, what response or error handling to expect, or whether deleting a flow could break references from scenarios or suites. An agent has to infer too much.

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

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

Schema description coverage is 50%: the 'project' parameter is documented in the schema, but 'flowId' is not. The tool description adds no information about either parameter—it does not explain what flowId refers to, how to obtain it, or how the project parameter interacts with the environment variable. The description fails to compensate for the missing 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 clearly states the action (delete) and the resource (a flow), and even enumerates the exact files removed (.flow.json, .flow.ts, flowData.ts). This makes the tool's purpose unambiguous and distinguishes it from creation, listing, or metadata 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?

There is no guidance on when to use this tool versus alternatives like create_flow or set_flow_meta. No mention of prerequisites, sequencing, or cases where deletion is inappropriate. The description simply states what it does, leaving usage decisions entirely to the agent.

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

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

With no annotations, the description carries full burden. It discloses the failure condition (if bound to a flow step) but does not mention other side effects like irreversibility or cascading deletions. It is partially transparent but leaves room for more detail on the deletion's impact.

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

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

The description is a single, tightly worded sentence with a parenthetical caveat. No redundant information, no fluff, and the key point (delete action + precondition) 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 description gives enough context to use the tool correctly: what it deletes, when it might fail, and a suggested pre-check. It does not mention output or return value, but since no output schema is provided and the operation is straightforward, the information is sufficient.

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

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

Schema covers the 'project' parameter with a description, but 'name' lacks schema documentation. The description clarifies that 'name' refers to a page object and implies its role via the failure condition, adding some meaning beyond the schema. Coverage is approximately 50%, so the description partially compensates.

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 a page object') and adds a specific condition about failure, making it unambiguous. It also differentiates from other delete tools by specifying the target resource type.

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?

Provides a practical precondition: check get_flow first if a flow step might bind to the page object. This gives actionable guidance on when to invoke this tool and when to avoid it. Does not explicitly list alternatives, but the warning serves as a strong use-case indicator.

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

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

The description does not disclose any side effects, such as whether deletion is permanent, cascades to related entities, or requires confirmation. No annotations are provided to fill this gap, so the tool's behavior remains opaque.

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 unnecessary words, which is concise. However, it is too terse to be considered well-structured for an agent, as it omits critical usage details that would typically be part of a complete description.

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

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

With only two parameters and a simple operation, the description still fails to provide necessary context such as the effect of deletion, any dependencies, or error conditions. This makes the tool inadequate for an agent to use confidently without external knowledge.

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 provides a description for 'project' but not for 'scenarioId'. The description adds no additional meaning to either parameter, leaving 'scenarioId' undefined and not clarifying how it relates to the action.

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

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

The description states the primary action ('Delete') and the resource ('a scenario'), which clearly identifies the tool's purpose. However, it lacks additional context about the scenario's identity or scope, making it clear but not highly informative.

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 like 'create_scenario' or 'list_scenarios'. The description does not mention any conditions, prerequisites, or scenarios where deletion is 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?

With no annotations, the description carries the full burden. It clearly discloses that the deletion is a bare delete with no reference cascade, which is the most important side effect. It does not mention irreversibility explicitly, but 'delete' implies it.

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

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

The description is two sentences: the first states the purpose and the second states the critical caveat. It is concise, front-loaded, and every sentence 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?

Given the tool's destructive nature, the description includes the essential precondition (check references first) and even cross-references the same caveat on delete_page_object. No output schema exists, so return-value details are unnecessary.

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

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

The description does not add much parameter-level detail beyond the schema. It indirectly explains that 'name' identifies the utility function, and 'project' is already described in the schema with its default. This is adequate but not enhanced.

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

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

The description states a specific action and resource: 'Delete a shared utility function.' It clearly distinguishes this from deleting flows, page objects, or groups, and the caveat reinforces the tool's exact scope.

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

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

It explicitly warns that the tool does not check for references and tells the agent to check list_flows/get_flow first. This gives clear when-to-use guidance and prevents unsafe deletion.

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

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

With no annotations provided, the description carries the full burden. It discloses the non-destructive nature for member utils and the cascade of affected steps, which are significant side effects. It does not mention permissions or error behavior, but the key side effects 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 concise sentences with no fluff. The most important caveat (member utils are moved, not destroyed) is front-loaded, and the reference to set_util_group_name avoids repeating complex cascade details.

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

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

Given no output schema, the description covers the essential context: what is deleted, what happens to member utils, and how cascade behaves. It is sufficient for an agent to correctly invoke the tool without missing critical 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 'name' parameter is implied by the tool purpose and the description, even though the schema lacks a description. The 'project' parameter is described in the schema. The description adds enough context for the primary parameter, partially compensating for the 50% schema coverage.

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

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

Clearly states the action: deleting a util group. Explicitly distinguishes from destroying member utils by saying they are moved to 'custom-utils', which is critical for understanding the tool's actual effect.

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?

Explains the behavior of moving member utils and references set_util_group_name for cascade semantics. This gives good guidance, though it stops short of explicitly stating when to prefer this tool over alternatives like delete_util or set_util_group_name.

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 present, the description carries the burden of disclosing side effects. The verb 'Get' implies a read-only operation, but the description does not explicitly state that it has no side effects, nor does it mention permissions, errors, or rate limits.

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 unnecessary words. It efficiently communicates the tool's core purpose and scope.

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 read operation, the description is mostly complete: it identifies the resource and the level of detail returned. It could mention return format or error conditions, but these are not critical for basic 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 has two parameters, but only 'project' has a description; 'flowId' is undocumented. The tool description does not add meaning to either parameter, so the schema's low coverage is not compensated.

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 specifies the verb 'Get', the resource 'flow', and the scope 'full definition, including every step'. This distinguishes it from siblings like list_flows, which presumably returns summaries rather than complete definitions.

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 tool is used when a complete flow definition is needed, but it does not explicitly state when to prefer this over related tools like get_util or list_flows, nor does it mention any exclusions or alternatives.

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

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

Annotations are absent, so the description carries the full burden. It discloses the semantics of the locator expression, inferred parameters, and scoping behavior, which goes beyond a generic 'get' statement. However, it does not explicitly state read-only nature, permissions, or side effects (if any). The name implies a read operation, but the description does not confirm it.

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 dense but well-structured, front-loading the core purpose before diving into technical details. The examples and clarifications are relevant and earn their place, though it is longer than strictly necessary for a simple get operation.

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

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

With no output schema, the description compensates by explaining the return structure: locators with inferred parameters, raw expressions, and scoping rules. It also references 'extractPoParams' and the scopes map, giving the agent enough context to interpret results. It does not cover error cases or pagination, but for a single-object retrieval tool, it is reasonably 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 50% (only 'project' has a description). The description does not explain the 'name' parameter at all; it focuses on the output's selector expression, which is not a parameter. It adds no clarity on what 'name' should be or how to format it, leaving the agent to infer from the tool name and 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 clearly states the tool gets a page object's locators and scopes, with a specific verb and resource. It explains the selector expression format with examples, which distinguishes it from list_page_objects (which lists all) and create/delete operations. The purpose is unambiguous and actionable.

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 detailed guidance on interpreting the selector expression and scopes, but it never explicitly states when to use this tool versus alternatives like list_page_objects. An agent must infer from context that this is for retrieving details of a single page object; no exclusions or alternative recommendations 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 present, so the description carries the burden. The verb 'Get' suggests a read-only operation, but the description does not explicitly state that it has no side effects or mention any permissions or prerequisites.

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

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

The description is a single, concise sentence that efficiently conveys the tool's purpose and scope without extraneous information.

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

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

Given the simplicity of a get operation, the description is largely complete—it clarifies the resource and its content. However, the scenarioId parameter is not elaborated in either the schema or description, and no output format is specified, though that is less critical since no output schema exists.

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

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

The schema describes only one of two parameters (project) and the tool description adds no parameter details. The scenarioId parameter is not semantically explained beyond its name, leaving ambiguity about its format or required 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 clearly states the tool retrieves a scenario's full definition, specifying that it includes the composed flows and their parameters. This precisely distinguishes it from list_scenarios and other scenario-related 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 description implies use when the full scenario definition is needed, but it does not explicitly contrast with alternative tools like list_scenarios or mention any conditions for use. No guidance on when not to use it.

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

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

The verb 'Get' suggests a read-only operation, but there is no explicit statement about side effects, permissions, or data immutability. Since annotations are not provided, the description carries the full burden, and it does not fully disclose behavioral characteristics.

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

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

The description is concise, consisting of two sentences that cover the core purpose and a relevant usage detail. It is well-structured and free of unnecessary information.

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

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

The description does not specify the expected format of the 'name' parameter, nor does it describe the return value's structure. The reference to add_step's stepSchema doc is helpful but not self-contained. An agent would likely need to consult other tools or documentation to use this correctly.

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

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

The 'name' parameter is required but not described in the schema. The tool description implies it is the identifier of the utility, but it is ambiguous whether this is a composite key (groupName.methodName) or just the method name. The 'project' parameter is well-described, but the lack of clarity on 'name' significantly hampers correct usage.

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

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

The description clearly states the tool's purpose: to retrieve a shared utility function's full definition including groupName, params, and body. It also explains how a utility is referenced in a step, which helps distinguish it from listing all utilities.

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 this tool (when you need the full definition of a specific utility to construct a step), but it does not explicitly contrast it with list_utils or other alternatives. The reference to add_step's stepSchema doc gives some context but leaves the exact selection criteria implicit.

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

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

The verb 'get' indicates a read-only operation, and no side effects are implied. Since annotations are absent, the description carries the full burden, and it adequately conveys the safe, non-mutating nature of the tool, though it does not explicitly state 'read-only'.

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

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

The description is a single, concise sentence that front-loads the action and resource. No unnecessary words or redundancy. It is well-structured for quick parsing by an agent.

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?

This is a simple read operation. The description sufficiently specifies what the tool returns (metadata plus member utils' names/params) without requiring additional context. No output schema is provided, so no further detail is needed.

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

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

The schema covers 50% of parameters (project is described, name is not). The description does not explicitly describe 'name,' but its meaning as the group name is implied by the tool's purpose. The description partially compensates for the missing schema coverage, but not fully.

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

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

Description clearly states the action (get) and the resource (util group), and specifies the output (metadata plus member utils' names/params). This distinguishes it from siblings like list_util_groups (which likely lists only group names) and get_util (which gets a single util).

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 this tool (when you need metadata and member utils for a specific group), but does not explicitly contrast with alternatives like list_util_groups. The context is clear, but no exclusions or alternative recommendations 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, so the description carries the full burden for disclosing behavioral traits. It conveys a read-only action via the word 'Get', but it does not explicitly state side effects, permissions, or any other behavioral details. This is minimal but not misleading.

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 effectively communicates the tool's purpose without unnecessary words. It is well-structured and easy to parse.

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 getter with one parameter and no output schema, the description is largely complete. It specifies what is retrieved and, through the schema, how to specify the project. It could be improved by mentioning the return format, but that is not critical for a tool of this simplicity.

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 a detailed description for the 'project' parameter, covering its meaning and default value. Since schema coverage is 100%, the baseline is 3, and the tool description does not add any extra semantic meaning beyond what is already in the schema.

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

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

The description clearly states the verb 'Get' and the resource 'global variables (Variables tab)' for a project. This distinguishes it from sibling tools like set_variable and unset_variable, making its purpose unambiguous.

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

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

The description implies usage as a read operation to list global variables, but it does not explicitly state when to use it over alternatives, nor does it mention any exclusions. The context is clear from the name and semantics, but explicit guidance is 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, the description carries the burden. 'List' clearly indicates a read-only operation, and the mention of returned fields (id, name, step count) gives insight into behavior. It does not mention pagination or ordering, but for a simple list this is adequate.

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. It front-loads the verb and resource, then provides the return fields parenthetically. No redundant or irrelevant information.

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

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

Given the simplicity of the operation, the description is complete enough. It states the scope and the expected output fields, which is especially important since there is no output schema. It does not discuss edge cases or filtering, but these are not necessary for a straightforward list 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?

There is only one parameter, 'project', and the schema description fully explains its meaning and default behavior. The tool description adds no additional parameter information, so the schema alone carries the semantic weight.

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 (list), the resource (flows), and the scope (in a project). It also lists the specific fields returned (id, name, step count), which distinguishes it from sibling tools like list_utils or list_scenarios.

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 usage is implied by the resource type and the tool name, but it does not explicitly contrast with sibling tools or describe when to choose this over alternatives like list_utils or list_scenarios.

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

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

The description does not disclose behavioral aspects such as read-only status, side effects, or output format beyond a vague parenthetical. Since annotations are absent, the description carries the full burden, and it only says 'List' without explicitly stating that no modifications occur or what the response structure 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, concise sentence that efficiently communicates the tool's purpose and the key output fields. It contains no redundant or extraneous information, making it easy to parse.

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 operation, the description adequately covers the essential context: it specifies the resource type, the scope (project), and the expected output fields. Given that there is no output schema, this parenthetical helps fill the gap. It doesn't mention error handling or edge cases, but those are not typically required for a basic list 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 only parameter, 'project', is fully described in the schema with details about its meaning and default behavior. The description itself adds no additional semantic information beyond what the schema already provides, 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 clearly states the action (list page objects) and the resource (page objects in a project), with a helpful parenthetical on the returned fields. It doesn't explicitly contrast with sibling tools like get_page_object or list_flows, but the tool name and description make the purpose unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives. It doesn't mention conditions (e.g., 'use this to get an overview of all page objects') or when a different tool like get_page_object might be more appropriate. The description is purely declarative.

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 behavioral burden. It states the operation and return fields but does not disclose read-only nature, side effects, ordering, pagination, or any performance considerations. The description adds minimal behavioral context beyond the action itself.

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 action and resource. It includes the essential return fields without any unnecessary words or filler, making it efficient and easy to parse.

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 optional parameter and no output schema, the description provides the essential information: what is listed and which fields are returned. It does not explicitly state the return format (e.g., array of objects), but the parenthetical list of fields implies it. This is adequate for the tool's simplicity, though it could be slightly more explicit.

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 'project' is fully described in the schema with its path and default behavior via EASYSPEC_PROJECT. Since schema description coverage is 100%, the description adds no additional 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 clearly states the verb 'list', the resource 'scenarios', and the scope 'in a project', distinguishing it from siblings like list_flows and list_page_objects. It also specifies the returned fields (id, name, folder, composed flow count), making the purpose unambiguous.

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

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

The usage is implied: list scenarios when you need the scenario list for a project. However, there is no explicit guidance on when to use this versus get_scenario or other sibling tools, nor any exclusions or alternatives 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 present, the description carries full responsibility for disclosing behavioral traits. It accurately describes the read-only nature of listing entries and clarifies the semantics of suite entries (saved runs with independent params). However, it does not explicitly state that no modifications occur, though this is implied by the verb 'list'.

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

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

The description is two sentences and generally efficient. The first sentence lists returned fields, and the second clarifies the nature of suite entries. While slightly wordy with parenthetical explanations, the information is relevant and well-organized without unnecessary 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?

Given that there is no output schema, the description thoroughly explains what the tool returns, including field names and the semantic meaning of suite entries. It covers all necessary details for a caller to understand the expected output and behavior, making it complete for its low complexity.

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

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

The sole parameter 'project' is described in the schema with its type and default value. The tool description references 'a project' but adds no additional meaning beyond what the schema already provides. Since schema coverage is 100%, the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: listing suite entries in a project, and specifies the exact fields returned (id, folder path, scenario reference, and saved run params). It distinguishes the tool from siblings by emphasizing that suite entries are saved runs rather than bare references, which is a unique aspect.

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

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

The description explains what the tool does but does not provide explicit guidance on when to use it versus alternatives like list_scenarios or list_flows. The distinction from bare references is implicit but no direct comparative usage advice 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?

The description indicates this is a read-only listing operation, as implied by 'List'. It also discloses the behavior that 'custom-utils' always exists as a default group, even if never used. However, it does not explicitly state that no modifications are made, but the verb 'list' is sufficient for typical understanding.

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

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

The description is two sentences long and directly conveys the purpose and a key behavioral note. There is no redundant information, and the structure is clear and 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?

Since there is no output schema, the description specifies the returned information (name, folder, member count). It also explains the presence of the default group, covering an important edge case. This is sufficient for a list 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 provides a comprehensive description for the 'project' parameter, including its default from EASYSPEC_PROJECT. The tool description does not add further parameter details, but the schema coverage is 100%, so the baseline is appropriate. The parameter is optional and straightforward.

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

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

The description clearly states the tool's function: 'List util groups in a project' and specifies the returned fields (name, folder, member count). It distinguishes itself from sibling tools like list_flows and list_utils by focusing on util groups.

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

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

The description explicitly states when to use the tool: to list util groups in a project. It also provides useful context about the default 'custom-utils' group, helping the user understand expected output. The parameter for project path is described in the schema, so no ambiguity.

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

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

Without annotations, the description carries the full burden. It implies a read-only operation via the verb 'list' and identifies returned fields, but does not mention error conditions, permissions, or side effects. This is adequate but not comprehensive.

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, front-loading the action and including essential output details in parentheses without 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?

The description names the returned fields, which is critical given the absence of an output schema. It does not mention sorting, filtering, or error handling, but for a simple listing tool, the provided information is likely sufficient.

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

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

The single parameter 'project' is fully described in the schema, including its default from an environment variable. Since schema coverage is 100%, the description adds little beyond the schema, warranting a baseline score 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?

The description clearly states the tool's function: listing shared utility functions in a project, specifying the fields returned (name, groupName, folder, param count). This distinguishes it from sibling list tools like list_flows and list_page_objects.

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 purpose is clear from the name and description, making when to use it obvious in the context of sibling tools. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.

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

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

With no annotations provided, the description carries full responsibility for side effects. It transparently discloses that the operation force-detaches the run's target tab and stops an in-flight step immediately, and clarifies independence from the currently active tab.

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 slightly detailed but every sentence adds meaningful behavioral context, such as detachment and immediate stop semantics. It remains focused and avoids irrelevant information.

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

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

The description explains the operation's effect and side effects well, which is sufficient given there is no output schema. It does not specify return value or error behavior, but that is not essential for correctly invoking the tool.

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

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

Schema descriptions cover 67% of parameters, leaving runId undocumented in the schema. The prose clarifies that runId identifies the still-running run to cancel, while project and session are adequately described in the schema.

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

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

The description clearly states the action: cancels a still-running run by runId. It distinguishes this from related cancel operations for scenarios and suites by focusing on the run entity.

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 indicates the condition for use — a run that is still running — and references the familiar Cancel button behavior. It does not explicitly exclude scenario/suite runs, but the runId parameter and naming make the target 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 full responsibility. It explicitly reveals that the tool force-detaches the currently-executing flow's tab and interrupts an in-flight step, which is a notable side effect. This is transparent about the destructive nature of the 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 concise, consisting of two sentences, and directly addresses the tool's purpose and behavior. It is well-structured with no redundant information, though it could be slightly tighter by removing the em-dash clause.

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

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

The description covers the primary action and key behavioral consequences, but it does not mention the expected outcome (e.g., run status changed to canceled) or whether the run record remains available. Given that there is no output schema, some additional context about the result would improve completeness, but the description is adequate for basic usage.

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

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

The description mentions runId but does not clarify what it represents or how to obtain it, which is especially problematic because the schema lacks a description for runId. Project and session are already described in the schema, so the description adds no additional parameter meaning.

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 that the tool cancels a still-running scenario run by its runId, and provides specific behavioral details (stops before next flow, force-detaches tab) that distinguish it from related cancel tools like live_cancel_run and live_cancel_suite_run.

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

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

The description implies usage for scenario runs by naming the tool and describing scenario-specific behavior, but it does not explicitly mention alternatives or state when not to use it. The behavioral detail about stopping before the next flow and force-detaching the tab gives enough context for correct 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. It discloses significant behavioral traits: 'force-interrupts whatever's actually in flight on every worker tab right now' and 'stops every worker from picking up anything further off the queue', which gives a clear picture of the impact although it doesn't mention edge cases like already-completed runs.

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, well-structured sentence that leads with the action and resource, then provides necessary details, with no redundant words.

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

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

The description effectively conveys the purpose, behavior, and scope of the cancellation, including worker effects and queue stopping. It doesn't mention return values or error handling, but for a cancellation operation the provided context is sufficient.

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

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

The schema already covers project and session with descriptions, but runId lacks a description. The description clarifies runId as the identifier of the suite run, adding minimal semantic value beyond the name; overall, it does not significantly enhance parameter understanding beyond what is already provided.

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 ('Cancels') and the resource ('suite run'), and differentiates from the sibling live_cancel_scenario_run by specifying 'by its runId' and 'same as live_cancel_scenario_run does for a single scenario run', making its purpose unambiguous.

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

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

It provides explicit usage guidance by specifying the condition ('still-running suite run') and points to the alternative for single scenario runs, telling the agent when to use this tool versus a related 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?

With no annotations provided, the description carries the full burden. It explains the immediate-detach behavior versus the idle timeout, and mentions the side effect on the banner. It does not cover potential failure modes or idempotency, but for a simple detach action it is fairly 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 front-loaded with the main action but becomes verbose and somewhat repetitive, especially in the first sentence with the long parenthetical about other live_* tools. It could be trimmed without losing information.

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

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

For a simple detach action with no output schema, the description provides sufficient context: when to use, why, and the trade-off compared to other tools. It does not mention reconnect behavior, but that is not necessary for the core action.

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

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

Schema description coverage is 100% and both parameters have clear descriptions. The tool description itself does not add extra semantic detail about the parameters beyond what is in the schema, so it stays at the baseline for high coverage.

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

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

The description clearly states the tool's action (detaches chrome.debugger immediately) and distinguishes it from other live_* tools that keep the tab attached. It names the specific alternative behavior and the reason for it.

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

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

Explicitly instructs when to call the tool ('Call this when done with a live exploration/interaction sequence') and provides a concrete motivation (avoid lingering 'being debugged' banner). It also implicitly indicates when not to use it (when continued interaction is needed).

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

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

No annotations provided, so the description carries the burden. It describes the return contents but does not explicitly state whether the operation is read-only or has side effects, though the name and description imply a read-only query.

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 informative but slightly verbose. It is front-loaded with the primary purpose and includes useful context in the second sentence, without being excessively long.

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 lists what is returned (status, step statuses, error for failed steps) and states it works for both running and finished runs. This is sufficient given the absence of an output schema and the relatively simple input parameters.

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 covers runId as a required string and provides descriptions for project and session. The description adds meaning to runId by specifying it comes from live_start_run or live_replay_flow, helping the agent understand where the ID originates.

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?

Clearly states the tool retrieves full detail for a single run by ID, including status and per-step statuses and errors, distinguishing it from sibling tools like live_list_runs and live_get_suite_run.

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

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

Provides clear usage context: it is the follow-up after live_start_run or live_replay_flow to check if the run worked and where it failed. It also notes it works for both running and finished runs, though it does not explicitly contrast with alternative 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 burden of behavioral disclosure. It explains the return content (overall status, flow index, per-step detail via currentRun) and that it works for both running and finished runs. It doesn't explicitly state it's read-only, but the 'get' verb implies that. It adds useful 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?

The description is a single dense sentence that packs essential information without fluff. It front-loads the core purpose and then elaborates on the return structure. While slightly long, every clause earns its place; no wasted words.

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

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

Since there is no output schema, the description adequately explains the return structure and references live_get_run for shape, giving the agent a concrete expectation. It also covers both running and finished states. It doesn't mention potential errors or prerequisites, but for a single-item get operation this is sufficient.

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

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

Schema coverage is 67%, so runId lacks a schema description. The description compensates by explaining runId is the id of a scenario run started via live_start_scenario_run or live_replay_scenario. Project and session already have schema descriptions, so no additional meaning is needed there. The description adds value for the undocumented 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 clearly states the action (get full detail) and resource (one scenario run) and distinguishes it from siblings by specifying it's for scenario runs started via live_start_scenario_run or live_replay_scenario, and referencing live_get_run for single flows. This leaves no ambiguity about what the 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 indicates when to use it (for a specific scenario run, both running and finished) and implicitly contrasts with live_get_run for single flows. It doesn't explicitly list alternative tools like live_get_suite_run, but the scope is clear enough for an agent to choose correctly in most cases.

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

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

With no annotations provided, the description must disclose behavioral traits. It says 'full detail' but does not clarify the response structure, confirm read-only behavior, or mention error handling. As a get operation, it likely has no side effects, but this is unstated, leaving the agent guessing.

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 filler, front-loading the core purpose ('full detail') and the identifying key. Every word serves a purpose.

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

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

Given there is no output schema, the description should specify what 'full detail' includes or at least indicate the shape of the response. It does not mention how to obtain a runId (e.g., from live_list_suite_runs) or any potential error cases. For a simple get, it is adequate but leaves important gaps.

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

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

Schema coverage is 67% (project and session have descriptions; runId does not). The description mentions runId but only restates its name without adding format, provenance, or examples. It adds marginal value over the schema, which already documents project and session defaults.

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

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

The description clearly states the tool retrieves full detail for a single suite run, identified by runId, and specifies it pertains to runs started via live_run_suite. This distinct verb-resource pairing separates it from listing or cancellation 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 description provides clear context that this is for fetching details of a specific suite run, implying use when a runId is available. It does not explicitly name alternatives like live_list_suite_runs or exclude scenario runs, but the 'suite run' scope is clear. Lacks explicit when-not guidance.

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

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

With no annotations provided, the description carries the full behavioral burden. It states the tool is safe to poll, mentions the 30-run cap, and clarifies the scope to the current session. It does not mention any side effects, but for a read-only listing tool this is adequate.

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

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

The description is compact, information-dense, and free of redundancy. It packs purpose, scope, output summary, and behavioral guidance into three sentences without wasted words.

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

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

Given no output schema, the description compensates by explaining the two categories (current/history), the ordering and cap, and the summary fields per entry. It also points to live_get_run for full detail, making the tool's place in the workflow clear.

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 descriptions for both parameters (project and session) are clear and cover 100% of parameters. The tool description adds no extra parameter guidance, but the baseline of 3 is appropriate given full schema coverage.

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

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

Clearly states that it lists runs from the connected side panel, distinguishes between current and history, and summarizes the entry fields. It references live_get_run for full detail, providing differentiation from that sibling, though it does not explicitly contrast with other list-run tools like live_list_scenario_runs.

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

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

Explicitly advises that the tool is safe to poll repeatedly, which is a direct usage guideline. Recommends live_get_run when full per-step detail is needed, giving an alternative path. It does not specify when to prefer this over other run-listing tools, but the context is sufficient.

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

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

With no annotations provided, the description carries the full burden of conveying behavior. It explicitly states 'Safe to poll repeatedly,' indicating read-only and non-destructive operation. It also describes the output structure and the scope (connected side panel). It does not mention any side effects or error conditions, but the information given is sufficient for typical usage.

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

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

The description is concise yet information-dense, covering purpose, output structure, limitations, and usage guidance in two sentences. It is well-structured, with key details front-loaded and a clear pointer to a more detailed tool. There is no redundancy or extraneous content.

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

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

For a listing tool, the description is complete: it specifies what is listed, the categorization (current vs history), the cap of 30, and the summary fields included. It also explains when an additional tool (live_get_scenario_run) is needed for full detail. Since there is no output schema, the description's outline of the return structure is adequate.

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?

Both parameters are thoroughly described. The 'project' parameter explains its purpose and default behavior (falls back to EASYSPEC_PROJECT). The 'session' parameter clarifies when it's needed (only when multiple panels are connected) and points to live_status for context. This goes beyond the schema descriptions and adds meaningful semantic guidance.

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

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

The description clearly states the tool's function: listing scenario runs on the connected side panel, distinguishing between current and history runs. It also specifies the output fields (id, name, scenarioId, tabId, status, flows) and explicitly points to live_get_scenario_run for full detail, which differentiates it from related 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 gives practical usage guidance: it notes the tool is safe to poll repeatedly, explains the difference between current and history entries, and mentions the 30-item cap. It also directs users to live_get_scenario_run for detailed information. However, it doesn't explicitly state conditions for choosing this tool over other listing tools like live_list_runs, though the context makes it reasonably clear.

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

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

No annotations are present, so the description carries the burden. It discloses read-only intent through 'Lists' and 'Safe to poll repeatedly', and describes result limits and statuses, providing reasonable transparency about behavior.

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

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

Two focused sentences front-load the action and scope, then pack useful output details (statuses, attempts count, cap) without redundancy. 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?

No output schema exists, but the description compensates by enumerating output categories, statuses, and attempt counts. It covers the essential information a caller needs, though a formal return shape 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 coverage is 100% with clear descriptions for both parameters, so the description adds little beyond the schema. The interaction between project and session is not further clarified, but this is a minor gap.

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?

Clearly states the verb 'Lists' and the resource 'suite runs', scoped to the connected side panel. Distinguishes current versus history and mentions the per-scenario breakdown, which differentiates it from related live_* tools like live_list_runs.

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

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

Explicitly says it is safe to poll repeatedly and scopes the data to the current session and side panel. It does not name alternative tools or state when not to use it, but the context is clear enough for selection.

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

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

With no annotations provided, the description carries the full burden of disclosure. It explains the output includes tab id, title, url, active status, and the pinned target, which is valuable behavioral context. It does not mention side effects (likely none for a list operation), auth, or rate limits, but it conveys the essential behavior accurately.

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 and enumerates the returned fields. It includes a direct usage note without unnecessary verbosity, earning a top score for structure.

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

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

Given no output schema, the description sufficiently explains the return values (id, title, url, active, pinned). It also provides context about the pinned target and the prerequisite for live_switch_tab. For a read-only list tool, this is comprehensive.

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 covers both parameters (project and session) with descriptive text, so schema coverage is 100%. The description adds no additional parameter semantics 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 verb 'lists' and the resource 'every open tab in the side panel's browser window', enumerating the exact fields returned (id, title, url, active, pinned). It distinguishes itself from sibling tools like live_switch_tab (which switches) and live_new_tab (which creates) by focusing on enumeration.

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

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

The description explicitly instructs 'Call this before live_switch_tab to get a valid tabId', giving a clear when-to-use directive. It does not explicitly state when not to use it, but the context is sufficient for an agent to understand its purpose relative to the sibling live_* 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 disclosing side effects. It clearly states that a new tab is opened, that it becomes the pinned target for subsequent live_* calls, and that it may optionally navigate to a URL. It does not mention potential errors, permissions, or tab lifecycle details, but the core behavioral impact is transparent.

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

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

The description is two sentences, direct, and free of unnecessary detail. It front-loads the core action and then provides the optional url behavior, 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 simple tool with no output schema, the description covers the essential context: the action, the target-pinning effect, and the optional navigation parameter. It could mention what the tool returns or what happens if no tab can be opened, but such details are not required for basic usage and the description is sufficient for an agent to proceed.

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 describes project and session, but the url parameter lacks a schema description. The description adds meaning by explaining that url is optional and used for navigating the new tab, which partially compensates. However, it does not elaborate on url format, default behavior when omitted, or how project/session affect the tab, so the added semantic value is moderate.

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: opens a new browser tab and pins it as the target for subsequent live_* calls. It also distinguishes itself from siblings by emphasizing the 'new tab' creation and immediate targeting behavior, and it mentions the optional navigation via url.

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

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

The description implies usage by saying the new tab becomes the target for every other live_* call, and compares it to live_switch_tab. However, it does not explicitly state when to prefer this over live_switch_tab or live_list_tabs, nor does it provide clear when-not-to-use guidance.

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

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

With no annotations provided, the description carries the behavioral burden. It discloses the wait timeout, the user interaction requirement, and the non-parametric scope restriction. It does not mention potential side effects like tab focus changes, but the core behavior is transparent.

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

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

The description is a single verbose run-on sentence with repeated references to the side panel and page object. It contains valuable information but would benefit from clearer structure and more concise phrasing.

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

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

The description explains the return value (locator expression), prerequisites, timeout, and parameter usage. It lacks explicit error conditions or a formal return schema, but the information provided is sufficient for an agent to invoke the tool correctly.

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

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

The schema provides descriptions for project and session, and the tool description supplements scope and pageObject with meaningful details (e.g., scope must be non-parametric, pageObject restricts picking). This effectively covers all four parameters, though the schema itself only covers 50%.

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

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

The description clearly states the tool starts an interactive element picker on the side panel's target tab and returns a locator expression. It is specific about the action and resource, and it is distinct from sibling live_* 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 explains prerequisites (side panel open and connected), how to restrict picking via pageObject and scope, and how the result can be used with set_locator/set_scope. It lacks an explicit comparison to alternative tools, but the interactive nature 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 burden and discloses key behavioral facts: it uses the user's real session/login and targets a specific tab (pinned tab or active tab). It also states the requirement for an open connected side panel. It doesn't mention side effects like whether a run record is created, but for a replay action the core behavior is clear.

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

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

The description is two sentences with no redundancy. It front-loads the core action, then provides crucial environment and target details. Every clause adds value (live, side panel, real session, tab targeting) without unnecessary elaboration.

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

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

The description covers the essential context: what it does, where it does it, and preconditions (side panel connected, tab targeting). It does not mention return values or errors, but since there is no output schema and the action is straightforward replay, this is sufficient for a live interaction tool.

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

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

Schema description coverage is 60%, leaving flowId and params undocumented. The tool description mentions 'a single flow' which implies flowId but does not clarify the 'params' object or how it relates to flow execution. There is no additional explanation of the session parameter in the description, though the target tab behavior hints at session usage. Overall, the description does not compensate for the missing parameter documentation.

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

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

The description clearly states the action ('Replay a single flow live') and specifies the environment (side panel's connected browser tab, real chrome.debugger, user's real session). It distinguishes this from sibling tools like live_replay_scenario or live_run_step by explicitly saying 'single flow' and 'live'.

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 provides a prerequisite ('requires the side panel open and connected to this project') and explains the target tab selection logic. However, it does not explicitly mention alternative tools like live_replay_scenario for scenarios or live_run_step for individual steps, so guidance on when not to use this tool is implicit rather than explicit.

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

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

With no annotations provided, the description carries the full burden, and it discloses substantial behavior: real chrome.debugger and the user's real session/login, strict sequential execution, stopping at the first failed flow, output binding for later entries, and target-tab selection. It does not explicitly describe side effects on the live page or completion/return behavior, so it stops short of a 5.

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 dense but front-loaded with the core action and then adds necessary operational details. Every sentence contributes something important, though the output-binding sentence is complex and somewhat long.

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

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

The description covers prerequisites, target tab selection, failure behavior, and output binding, which is strong. However, with no output schema and no annotations, it omits what the call returns and whether it blocks or waits for completion, which is relevant for a live replay 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 covers 60% of parameters (dataset, project, session), but required scenarioId and the params object lack schema descriptions. The description adds some useful context by explaining that later entries' expression-mode params/postprocess can reference bound outputs, but it does not clarify how to supply scenario parameters or identify the scenario beyond the obvious implication.

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

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

The description states a specific action and resource: 'Replay a whole scenario live' and explains that it runs the scenario's composed flows sequentially in the side panel's connected browser tab. It also distinguishes itself from flow-level replay by emphasizing 'whole scenario' and comparing its failure behavior to a single flow.

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

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

The description gives clear usage context: it 'Requires the side panel open and connected' and explains which tab it targets ('pinned in the side panel's header, or the browser's actual active tab if none is pinned'). It does not explicitly name alternative tools or exclusion criteria, but the operational conditions are 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?

The description discloses that steps execute live, that execution 'stops at the first failing step', and that results contain one entry per attempted step. It also notes the side panel 'tab stays claimed' during the run. Since no annotations are provided, it appropriately carries the transparency burden, though it could explicitly mention potential side effects on application state.

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

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

The description is lengthy but dense, front-loading the core action and then layering details on behavior, guidance, and preconditions. It is well-structured and avoids redundant filler, earning a high score despite its length.

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

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

The description references related tools (get_flow, get_page_object, create_util), explains the distinction from 'raw' steps and util calls, and clarifies scoping rules. It provides enough context for an agent to understand when and how to use the tool, though it does not define an output schema for the 'results' field.

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 provides detailed descriptions for the 'steps' items, 'project', and 'session' parameters (e.g., defaults for 'project' and purpose for 'session'). The tool description adds behavioral context about variable sharing and step sequencing but does not add new parameter-specific definitions, so it provides limited supplemental meaning beyond the schema.

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

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

The description clearly states the tool 'runs a whole ordered sequence of plain steps' live against the side panel's target tab, distinguishing it from single-step tools like live_run_step. It also defines the scope (plain steps only, excluding Conditional/Repeat/Iterate) and the intent of sharing variable context.

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

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

It explicitly says 'Prefer this over several live_run_step calls back to back when the sequence is already decided' and warns that it 'Requires the side panel open and connected'. This gives clear when-to-use and precondition guidance, directly addressing alternatives.

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

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

The description discloses that the step runs live against the side panel's target tab and requires an open/connected side panel, and it notes the return shape. However, it does not explicitly warn that action steps can actually perform side effects in the browser, which is important for an execution tool with no annotations to fall back on.

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

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

The description is front-loaded with the core purpose and return behavior, then details the step object thoroughly. It is somewhat long and dense with run-on sections, but nearly every sentence carries necessary semantic information for correct invocation.

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 no output schema and no annotations, the description is remarkably complete: it specifies target selection, required connection state, return values, step shape, scope semantics, raw vs util behavior, and parameter defaults. An agent can invoke the tool correctly without needing additional 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 parameter descriptions go well beyond the minimal schema, providing a detailed field-by-field explanation for the nested step object, including selector expression syntax, scope naming/reuse rules, raw step limitations, util-call encoding, and the meaning of project and session. This gives an agent everything needed to construct correct arguments.

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 that the tool runs one plain step live against the side panel's target tab and returns the step's result, with concrete examples. It distinguishes itself from related tools by emphasizing single-step execution and excluding conditional/repeat/iterate step kinds.

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

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

It explains when the tool is useful—trying one action or reading page state without building a flow—and clarifies that raw steps are only for inline code, while util calls use a different kind. It doesn't explicitly name alternative tools like live_run_step_range or live_run_multiple_steps, but the single-step focus 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 provided, the description carries the full burden of explaining side effects. It states that the tool blocks until the slice finishes or fails, that the run moves from the current list to history, and that context is seeded from the chosen dataset/params or flow defaults. It does not discuss authentication or error handling, but the main behavioral consequences are disclosed.

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 overly long and repetitive, with the 'same as live_replay_flow' comparison, the 'from step 0' phrasing, and the context-seeding caveat repeated multiple times. It is front-loaded with the core purpose, but the dense parentheticals and run-on sentences make it harder to parse 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?

Given that there is no output schema, the description provides useful context about result granularity (one entry per step attempted), blocking behavior, and lifecycle status. It does not specify the exact return shape, but the essential operational context for calling the tool is present.

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 covers descriptions for from, to, dataset, project, and session, and the description adds important context about how dataset and params interact, including the fallback to flow defaults. It also explains that a missing param or state-var referenced by the steps will be undefined unless provided, which helps the agent supply the right arguments.

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 (runs a contiguous slice of a saved flow's top-level steps live as a tracked run) and distinguishes it from the sibling live_replay_flow by focusing on a partial range rather than a full replay. It also names the intended use case of re-verifying recently added or changed steps, making the tool's purpose unambiguous.

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

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

The description explicitly says when to use this tool instead of live_replay_flow: to re-verify just added/changed steps without running the full flow from step 0. It also gives operational prerequisites, such as requiring the side panel open and connected, and clarifies how the run appears in the Runs tab.

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

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

With no annotations, the description carries the full burden and does well: it discloses parallel tab usage, retry count, flaky-run reporting, async return behavior, run visibility, and the side panel requirement. It does not detail tab lifecycle or cancellation, but the most important behavioral aspects 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?

The description is dense and front-loaded with the core action, and every sentence adds useful information. It is somewhat long due to parenthetical clarifications, but this is a complex tool with retries, path semantics, and async behavior that benefit from explanation.

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

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

Given the tool's complexity and absent output schema, the description is complete enough: it explains asynchronous behavior, retries, flaky status, run visibility, path/scenario selection, and the side panel prerequisite. No critical operational detail appears to be missing.

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 leaves path and scenarioIds undescribed, but the description provides rich meaning for both: path expands suite entries, empty path means the whole tree, entries are not deduplicated, and scenarioIds bypasses suite membership with default datasets. The project and session parameters are already documented in the schema.

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

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

The description clearly states the tool's specific purpose: running a suite or single suite entry live, with parallel execution and retries. It also distinguishes the tool from sibling live replay/start tools by describing the returned runId and the visibility of individual scenario attempts.

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 gives clear usage context: requires the side panel to be open and connected, pass exactly one of path or scenarioIds, and poll for results because the call returns immediately. It does not explicitly contrast this tool with alternatives like live_start_run or live_replay_flow, but the suite-specific focus makes the intended use 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 provided, the description carries the full burden of disclosing behavior. It explains the target tab selection logic (pinned vs active), the JPEG format, and the requirement of an open, connected side panel. It does not mention error handling or return format, but for a read-only screenshot tool this is largely sufficient. A small gap is the absence of any caveat about what happens if the side panel is not connected, though the requirement statement implies 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 two sentences, front-loaded with the core purpose, then usage guidance, then a prerequisite. There is no redundancy or fluff; every clause 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 4-parameter tool with no output schema and no annotations, the description covers the core purpose, target selection, usage guidance, and a key prerequisite. It does not describe the exact return format (though 'JPEG screenshot' implies an image) or potential errors, but these are minor given the tool's simplicity and the completeness of the parameter schema.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters (project, quality, session, fullPage). The description adds no additional parameter-level semantics beyond what the schema provides. Per the rubric, the baseline is 3 when schema coverage is high, and the description does not enhance it.

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

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

The description states a specific action (capture a JPEG screenshot) and a specific resource (the side panel's target tab, with a clear definition of which tab that is). It also differentiates itself from the sibling live_snapshot by explicitly contrasting use cases, so an agent can immediately tell them apart.

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

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

It explicitly says to prefer live_snapshot for selector-finding and to reach for this tool when the question is genuinely visual (layout, colors, rendering). It also states a prerequisite: the side panel must be open and connected. This gives clear when-to-use and when-not-to-use guidance.

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

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

With no annotations, the description carries the full burden. It discloses the prerequisite (side panel open and connected) and describes the output format (text tree). It does not explicitly state read-only behavior, but 'snapshot' implies no side effects. It omits error handling or limits, but these are less critical for a read 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 sentence that efficiently packs the resource, format, use case, and prerequisite. It is informative without being verbose, and the main purpose is front-loaded.

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

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

For a simple snapshot tool with no output schema, the description explains the output format, the target tab selection logic, and the prerequisite. This is sufficient for an agent to understand what to expect and when to call 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?

The input schema has 100% description coverage for all three parameters, so the baseline is 3. The description does not add any extra meaning beyond what the schema already states, so it remains at the baseline.

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

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

The description states a specific verb+resource: it provides an ARIA snapshot of the side panel's target tab, described as a text tree of roles/names/values. It explicitly ties the purpose to finding selectors for live_run_step/add_step without a screenshot, clearly distinguishing it from visual screenshot tools.

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

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

It identifies the primary use case (finding a selector without a screenshot) and states a prerequisite (side panel open and connected). It implies it is an alternative to screenshots but does not explicitly name alternatives or specify when not to use it, so it falls short of fully explicit guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses the immediate return with a runId, the asynchronous nature, failure behavior when a run is already active, and the requirement for a connected side panel. It could mention side effects on run history more explicitly, but the core behavior is transparent.

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

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

The description is dense but not verbose. Each sentence serves a distinct purpose: main action, polling guidance, and failure/prerequisite conditions. No irrelevant detail is included.

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

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

Given there is no output schema, the description sufficiently explains what the caller receives (a runId), how to track progress, how to handle a busy tab, and what environment is required. It provides enough context for correct invocation.

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

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

The schema covers 60% of parameters. flowId and params lack descriptions, though their purposes are fairly inferable. The project, dataset, and session parameters are well explained, including default behavior and when session 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 clearly states the verb 'Starts a flow running live' and identifies the resource (a flow on the side panel's target tab). It also distinguishes this tool from live_replay_flow by noting it returns immediately instead of waiting.

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

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

The description explicitly contrasts with live_replay_flow, directs the user to poll live_get_run or live_list_runs, mentions the one-run-per-tab constraint, and points to live_cancel_run for freeing a busy tab. It also states the prerequisite that the side panel must be open and connected.

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

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

With no annotations, the description carries full burden. It discloses that it returns immediately with a runId, does not wait, fails fast if the tab already has a run or single-step Play active, and requires the side panel open and connected. This provides useful behavioral context beyond the schema, though it doesn't mention any side effects or permissions.

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 three sentences with no filler. The main action and immediate-return behavior are front-loaded, and the contrast with the sibling and follow-up steps are succinctly stated.

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 no output schema and no annotations, the description covers the essential usage: how to start, that it's non-blocking, how to monitor progress, failure conditions, and prerequisites. It also references the session parameter implicitly by mentioning 'target tab'. Nothing critical is missing for an agent to call 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 coverage is 60%, with descriptions for dataset, project, and session, but scenarioId and params lack descriptions. The tool description does not add any parameter-specific meaning beyond what the schema already provides, so it doesn't compensate for the uncovered 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?

States a specific verb 'starts' with a clear resource 'scenario' on the side panel's target tab, and contrasts with live_replay_scenario by noting it does not wait. This makes its purpose unambiguous and distinguishes it from 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?

Explicitly names live_replay_scenario as an alternative and clarifies when to use this one (non-blocking). It also instructs to poll live_get_scenario_run or live_list_scenario_runs, and gives failure conditions and prerequisites, so an agent knows exactly when to choose this tool.

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

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

With no annotations, the description carries full burden and excels: it discloses that `agentName` is stable and tied to a port slot, `sessions` are opaque connection IDs, and explicitly states the tool never reveals session names not already given by the user. This transparency exceeds basic expectations.

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?

Though lengthy, every sentence adds necessary context: purpose, usage examples, output field semantics, and security caveat. The main purpose is front-loaded, and the structure follows a logical flow from 'what' to 'how to use' to 'what it returns'.

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 fully covers the tool's behavior, output interpretation, and the security boundary. An agent has all information needed to call it correctly and understand the response, making it complete for this tool's complexity.

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

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

The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameters, and it instead explains the output fields (agentName, sessions) which is valuable context beyond the empty schema.

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

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

The description explicitly states the tool lists which projects have a connected side panel, identified by folder name, and frames it as a discovery step before targeting with other live_* tools. It clearly distinguishes itself from siblings by explaining its role in the live_* workflow.

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?

Provides explicit when-to-use guidance: call before omitting `project` on another live_* tool, and explains when to use the `session` parameter (when multiple panels are connected) to avoid ambiguity errors. It also explains how to use `agentName` for user approval, covering practical usage scenarios.

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

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

Describes the side effect of changing the target for subsequent live_* calls, but does not mention return values or error scenarios; still adequately transparent given no annotations.

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

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

Single, focused sentence that conveys the core behavior and the alternative usage without unnecessary 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?

Provides sufficient context for the tool's role and relationships to sibling tools, with no apparent missing information given the lack of output schema.

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

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

All parameters are covered in the schema with descriptions, and the tool description adds context on how tabId is used, slightly enhancing the schema's meaning.

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?

Clearly states the tool's function: pinning an already-open tab as the target for other live_* calls, and distinguishes from related tools like live_list_tabs and live_new_tab.

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

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

Explicitly explains when to omit tabId to revert to following the active tab, and references live_list_tabs for obtaining tab IDs, providing actionable guidance.

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

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

With no annotations, the description bears full responsibility for disclosing behavioral traits. It does not mention whether the move is destructive, requires permissions, whether the original placement is removed, or any side effects. This is a significant gap 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, front-loaded sentence with no wasted words. It communicates the core action efficiently, though it could add a bit more context without becoming verbose.

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

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

Without an output schema, annotations, or detailed parameter explanations, the description leaves out crucial context: what a suite placement is, how to obtain an entry id, what path expects, and potential side effects. An agent would need to inspect list_suites or other tools to fill gaps.

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

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

Schema coverage is only 33% (project has a description; entryId and path do not). The description adds minimal meaning by indicating entryId identifies a suite placement and path is the destination, but it does not specify path format (relative/absolute), constraints, or examples. Given the low coverage, the description should compensate but does not.

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 ('Move'), a resource ('suite placement'), and the target ('different folder path'). It references list_suites for the entry id, which distinguishes it from add/remove operations. The purpose is unambiguous and differentiates it from 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 description implies the entry id comes from list_suites, but it does not explicitly state when to use this tool versus alternatives like add_to_suite or remove_from_suite. There is no guidance on exclusions, prerequisites, or selection criteria beyond the inherent action of moving.

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 is the only source of behavioral information. It only says 'remove' without indicating permanence, side effects, or whether the dataset is deleted from disk or just unlinked. This lacks critical transparency for a destructive operation.

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

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

The description is a single, clear sentence with no redundancy or unnecessary detail. It is well-structured and easily readable, achieving high 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 description covers only the basic action and omits critical context such as prerequisites, expected effects, or failure modes. With no output schema or annotations, this leaves the agent under-informed 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 description mentions 'named' which hints that the 'name' parameter identifies the dataset, but the 'flowId' parameter is not explained. Since the schema coverage is only 33% (only 'project' has a description), the tool description adds minimal meaning beyond the schema and fails to compensate for the missing parameter documentation.

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

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

The description clearly states the action ('remove') and the target resource ('flow-data dataset'), making the primary purpose unambiguous. However, it does not explicitly differentiate from similar sibling tools like remove_scenario_dataset, though the resource type is specific enough to avoid major confusion.

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 conditions, prerequisites, or scenarios where this tool is preferred over others.

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

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

No annotations are provided, so the description carries the burden. It clearly states the removal action but does not specify side effects such as reindexing of remaining flows, error behavior on invalid index, or permanence. The transparency is adequate but not detailed.

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

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

One clear sentence, no redundancy. The essential information 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 simple mutation nature and no output schema, the description covers the necessary context. It could mention whether the removal is permanent or any return value, but these are not critical for a straightforward removal 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 covers only one of three parameters with a description (project), giving 33% coverage. The description partially compensates by explaining 'index' (by its index) and 'scenarioId' (a scenario), but does not define them fully or clarify the index type (e.g., zero-based).

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

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

The description states a specific action ('Remove'), a specific object ('one of a scenario's composed flows'), and the method ('by its index'). It clearly distinguishes from sibling tools like add_flow_to_scenario and remove_scenario_dataset.

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 action implies when to use it (when you need to remove a flow from a scenario by its index), but it does not explicitly contrast with alternatives or mention prerequisites like obtaining the index. The guidance is implied rather than explicit.

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

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

The description discloses the key side effect: it removes only the placement, leaving the underlying scenario and other placements intact. This is important transparency, especially since no annotations are provided. It doesn't mention error handling or permissions, but the core behavior is well explained.

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

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

The description is two concise sentences. It states the action, specifies the parameter, and adds a crucial side-effect clarification without any redundant wording. The structure is direct and easy to parse.

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

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

Given there is no output schema, the description covers the essential context: what the tool does, what it takes, and what it doesn't affect. The reference to 'list_suites' provides a helpful entry point. It could mention potential errors or prerequisites, but the core context is sufficient for an agent to decide when to use this tool.

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

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

The description clarifies the 'entryId' parameter by tying it to a suite placement and pointing to 'list_suites' for discovery. The 'project' parameter already has a description in the schema. Overall, the description adds meaningful context to the primary parameter, though it could elaborate on what an entry id represents.

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 (remove a suite placement), specifies the identifier (entry id), and distinguishes it from adding or moving entries. It also explicitly notes that the underlying scenario and other placements are unaffected, which sets it apart from similar 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?

It references 'list_suites' for obtaining the entry id, providing a natural precursor. The clarification that only the placement is removed (not the scenario) implicitly guides when to use this tool over more destructive alternatives, though it doesn't explicitly contrast with all sibling operations.

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. 'Remove' implies a mutating operation, but the description does not state whether removal is permanent, whether it fails if the locator does not exist, what side effects occur (e.g., affecting dependent steps), or any required permissions. This is a significant gap for a mutation tool with zero annotation coverage.

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 is front-loaded with the core purpose. There is no wasted wording. However, the extreme brevity borders on under-specification, omitting necessary context. It earns a 4 for being appropriately concise in structure, but the lack of detail prevents a 5.

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 three parameters, no output schema, and no annotations, the description is insufficiently complete. It states what the tool does but does not explain parameter semantics, usage conditions, or behavioral outcomes. An agent cannot reliably construct a correct invocation (e.g., knowing what 'method' refers to) or anticipate the result of the removal. The low schema coverage and missing annotations make this gap more severe.

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

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

The description adds no meaning to any of the three parameters. The input schema itself only describes 'project' (with a description), leaving 'method' and 'pageObject' undocumented. With schema coverage at 33%, the description should compensate by explaining these parameters, but it does not mention them at all. An agent cannot determine what values to provide for 'method' (e.g., CSS selector, XPath) or 'pageObject' beyond its name.

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 'Remove a locator from a page object' is a clear and specific verb-resource statement. It unambiguously identifies the action (remove) and the target (locator from a page object), which distinguishes it from sibling tools like set_locator (which adds a locator) and remove_scope (which removes a scope, not a locator). The purpose is immediately understandable without needing to inspect 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 gives no guidance on when to use this tool versus alternatives. It does not mention that it is the inverse of set_locator, nor does it clarify conditions for use (e.g., when a locator exists). An agent would have to infer usage from the name alone, which is insufficient for correct selection among many similar 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 full burden but only states the action; it does not disclose side effects, error conditions, permissions, or consequences of removing a field.

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 concise sentence with no unnecessary words, clearly 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?

The description is sufficient for a simple removal operation but lacks explicit parameter mapping and behavioral details. Given the low complexity, it is minimally adequate.

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 low (only project has a description). The description implies that 'name' refers to the field to remove, but does not explicitly map parameters or provide details beyond that inference.

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 (remove) and the object (a flow's output-data field), distinguishing it from set_output_field by the verb.

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 set_output_field or other removal tools, nor any conditions or context for its use.

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

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

The description indicates destructiveness by using 'remove', but lacks explicit warnings about permanence or cascading effects. Since no annotations exist, the description carries the full burden, and it only partially fulfills this.

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, consisting of a single sentence with no superfluous information. It is well-structured for a simple removal operation.

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 sufficient for a basic agent to understand the action, but lacks information about expected outcomes (e.g., success/failure behavior) or error handling. Given its simplicity, it is somewhat complete but could benefit from more detail.

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?

Only the 'project' parameter has a description; 'name' and 'scenarioId' are left implied by context. The tool name and description suggest that 'name' is the dataset name and 'scenarioId' identifies the scenario, but this is not explicitly documented.

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 (remove) and the target (a named scenario-data dataset). It is unambiguous, though it doesn't elaborate on what a 'scenario-data dataset' specifically comprises.

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 like set_scenario_dataset or remove_flow_dataset. The description does not mention any prerequisites or 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?

The description discloses a key behavioral trait: the tool fails if locators are still assigned to the scope. It also implies the prerequisite of unassigning locators. However, it does not mention other side effects or the success behavior, so it is not fully exhaustive.

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

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

The description is two sentences long and contains no redundancy. It efficiently conveys purpose, failure behavior, and a mitigation step.

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