Uindow

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that names are trimmed and truncated to 64 characters, that a 10th agent will fail due to the 9-agent maximum, and that it returns a unique index 1-9. This is transparent about key side effects, though it could have mentioned error behavior for invalid names (already covered by 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?

Four compact, information-dense sentences. The purpose is stated first, followed by the limit, name behavior, a pointer to agent_list, and the return value. Every sentence earns its place; no filler or repetition.

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

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

For a one-parameter create tool with no output schema, the description fully covers the return value (index), the agent limit, name handling rules, and how to discover existing agents. This is sufficient for an agent to call it correctly and understand the result. Minor extras like error cases are already implied by the 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?

The input schema already describes agentName as a string between 3 and 64 characters after trimming (100% coverage). The description adds behavioral detail that the name is trimmed and truncated to 64 characters, clarifying what happens to longer inputs, and explains the return value (index), which is not in the schema. This adds meaningful context beyond the schema.

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

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

States the exact operation ('Create agent') and resource, and adds specific constraints (max 9 agents, name trimming/truncation). It distinguishes itself from siblings like agent_update, agent_delete, and agent_list by being the creation operation, so an agent can easily route to 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 points to agent_list for fetching existing agents and indexes, implying you should check before creating to avoid exceeding the 9-agent limit. It discloses the limit and failure condition. However, it does not explicitly name alternatives for modification (agent_update) or deletion (agent_delete), leaving some routing to inference.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It returns True/false but does not disclose that deletion is likely irreversible, whether it can delete a running agent, or what side effects may occur. The destructive nature is implied by the name and verb but not elaborated.

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

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

The description is short and front-loaded with the core action. The first line 'Delete agent' is somewhat redundant with the tool name and the following sentence, but overall it is compact and free of filler.

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

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

For a one-parameter destructive tool, the description covers the essential call sequence and return value. Missing context includes whether deletion is permanent and how it interacts with a running agent, which matters for an agent deciding whether to invoke 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 schema already documents 'index' as a one-based agent index, so coverage is complete. The description adds useful meaning by directing the user to agent_list to obtain valid indexes, which helps the agent understand where the parameter value comes from.

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 'Delete' and the resource 'agent', and adds 'from the list' to define the scope. This distinguishes it from sibling operations like agent_stop, agent_start, or agent_update, since removal is a unique action among the 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 gives a concrete prerequisite: use agent_list to fetch available agents and their indexes. However, it does not explicitly state when not to use this tool or mention alternatives such as agent_stop for merely stopping an agent, so the when-to-use guidance is partial.

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 does so thoroughly. It discloses that code runs outside the browser, has no access to DOM APIs, can only use plain JavaScript plus the $ object, and behaves like regular user actions. It also explains that all code blocks are already asynchronous, preventing a common misuse.

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 long but almost every sentence carries necessary safety, environment, or usage information. It is front-loaded with the core action and return behavior. It loses a point for slight redundancy in mentioning app_docs multiple times, but overall the length is justified by the tool's complexity.

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 code-execution tool with no output schema and no annotations, the description covers the execution environment, prerequisites, required companion tools, return behavior, and explicit failure-prevention rules. The agent has enough context to call it correctly and safely.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds useful enrichment by showing return syntax, referencing $ methods via app_docs, and telling the agent to use agent_list to resolve the index parameter. This is meaningful but not essential since the schema already defines both parameters clearly.

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 'Execute code in an agent' and immediately clarifies 'Execute asynchronous JavaScript code in the agent and forward the returned value.' This is a specific verb+resource statement that clearly distinguishes the tool from sibling lifecycle tools like agent_start, agent_stop, and agent_status.

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

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

The description gives explicit preconditions: the agent must first be stopped using agent_status and agent_stop, app_docs must be used twice before running, and async IIFEs must never be used. It also directs the agent to agent_list for indexes and app_docs for $ method discovery, providing concrete how-to-use context.

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

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

With no annotations provided, the description carries the behavioral burden and adds useful context: agents have unique indices 1-9, the index identifies the agent for commands, and the list reflects current execution state. It implies a read-only list operation without explicitly stating side-effect absence.

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

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

The description is well-structured and front-loaded, but it is slightly redundant: 'List agents', 'Get the list of agents', and 'Returns: List of agents' all convey the same core message. Still, it is compact and readable.

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

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

For a zero-parameter tool with an output schema, the description covers everything an agent needs: what the list contains, how indices work, and two explicit use cases. No critical contextual information is 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 tool has zero parameters, so the baseline is 4; there is nothing for the description to add beyond what the schema already shows. The description appropriately focuses on output semantics instead.

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

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

The description states a specific verb and resource: list agents that can perform tasks on this machine. It distinguishes itself from sibling create/update/delete/status tools by emphasizing the list/index mapping purpose.

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 concrete usage contexts: mapping a user-referenced agent name to its index and checking whether an agent is executing a task. It does not explicitly mention alternatives or when not to use it, but the intended use is clearly implied.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses that logs are consumed incrementally (since the last call), that logs appear in `content` and NOT in `structuredContent`, that structuredContent holds a status object with three possible values, and it recommends a polling loop. These non-obvious traits are exactly what would otherwise cause misinvocation.

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 long but every segment carries load: core purpose, log format with a concrete example, the response-location warning, the polling recommendation, and sibling routing. The final 'Returns: Agent status object' line is mildly redundant with the structuredContent paragraph, which 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 one-parameter tool with no annotations and an uncomplicated input schema, this is complete: it covers what is returned, exactly where in the response to find each part, the format of each log line, the status value space, and a recommended invocation loop. Nothing an agent needs to call it correctly or interpret the result is 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?

Schema coverage is 100% and the single parameter `index` is already documented in the schema as 'One-based agent index.' The description adds only indirect guidance by pointing to agent_list to 'fetch all available agents and their indexes,' so it meets the baseline but does not meaningfully extend the schema's 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?

Opens with a specific verb+resource ('Get agent logs') and immediately clarifies the distinctive scope: 'Output agent logs generated since the last agent_logs tool call.' It also distinguishes itself from siblings by documenting where logs appear and by pointing to agent_status for status-only retrieval.

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

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

Provides explicit routing to alternatives: agent_status for the status object without logs, agent_list for fetching indexes, and agent_start/agent_stop for lifecycle. It also gives a concrete call pattern: 'call agent_logs in a loop until the returned status is stopped or paused.' No when-to-use ambiguity remains.

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 behavioral transparency burden. It discloses the population precondition, explains that outputs declared via src_output_* are rendered as form elements, and states the return shape. It stops short of describing empty-result or invalid-index behavior, but it is substantially 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 core purpose and every paragraph contributes useful guidance or pointers. There is minor redundancy between 'Get latest results' and 'Fetch the results from the most recent call', but overall the size is appropriate for the information conveyed.

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

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

For a single-parameter read tool, the description covers the result source, population conditions, how to obtain the index, where to find SDK usage details, and what is returned. Edge cases such as what happens if there is no recent call or the index is invalid are not covered, but a supplied output schema helps complete the contract.

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

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

The schema already documents index as a one-based agent index, which gives a baseline of 3. The description adds value by pointing to agent_list as the source of available agents and their indexes, giving the caller a concrete way to obtain a valid parameter value, though it does not explicitly tie the index to the agent whose results are fetched.

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 ('Fetch') and resource ('results from the most recent call to either agent_start or agent_execute'), which clearly distinguishes it from logging, status, and output-setter siblings. The first sentence gives an immediate and accurate summary.

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?

Gives clear preconditions: results exist only when SDK methods like ioOutput/ioSave are invoked correctly. It also directs the caller to agent_list for valid indexes and app_docs for SDK method details. However, it does not explicitly mention when not to use this tool or name alternatives such as src_output_get.

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 transparency burden. It discloses the return format, concurrency behavior, and that no file output setup is needed. It does not mention failure modes or what happens if no page is loaded, but the read-only nature of a screenshot is reasonably 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 multi-line but each part earns its place, covering format, alternatives, preparation, and return structure. The opening 'Grab agent screenshot' is slightly redundant with the next sentence, preventing 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?

Despite having no output schema, the description fully specifies the return object shape. It also explains how to get the required index and when to use the text-viewport sibling tool. For a single-parameter screenshot tool, this is complete.

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

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

The schema already documents index as 'One-based agent index', and coverage is 100%. The description adds value by telling the agent to use agent_list to fetch available agents and their indexes, which clarifies where the parameter value comes from.

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

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

The description states a specific verb and resource: 'Capture a PNG screenshot of the current web page directly as a Base64-encoded string.' It also distinguishes itself from agent_viewport by noting that tool provides a text version, so an agent can 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?

The description explicitly routes the agent: use agent_list to obtain agent indexes, and use agent_viewport instead if the model does not support images. It also adds practical context like 'No need to set up a file output' and that it works during another task.

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

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

No annotations are present, so the description carries the full behavioral burden. It makes clear the operation is a fetch, describes the returned data, and discloses the 5000-row cap for table inputs. It does not explicitly state that no settings are modified, but 'get' and 'fetch' strongly communicate read-only 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 concise and well-structured, front-loading the core resource before adding useful context. The 'Get settings' opener is a slight redundancy with the tool name, but every other sentence adds value: SDK usage, Settings tab behavior, index discovery, and the table-input row limit.

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 one required parameter, full schema coverage, and an output schema present, the description provides everything an agent needs to call the tool correctly. It explains what the tool returns, how to find the required index, and an important row-limit behavior. No critical prerequisite or side-effect behavior is 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 already documents `index` as 'One-based agent index' with 100% coverage. The description adds practical meaning by telling the agent to use `agent_list` to discover valid agent indexes, which is exactly the missing link for choosing a correct parameter value.

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

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

The description clearly states that the tool fetches the input configurations used by the `$.ioInput*()` SDK methods and returns all input keys with their current values. This is a specific read operation on agent settings, clearly distinct from the sibling `agent_settings_set` and from the `src_input_*` tools. The short 'Get settings' opener is redundant, but the following sentence anchors the exact resource and action.

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 'Use this tool to get all input keys and their current values' and gives context: these inputs are rendered in the Settings tab and used when starting the agent with `agent_start`. It also sends the agent to `agent_list` to fetch available agents and indexes, which is useful prerequisite guidance. It does not explicitly say 'use agent_settings_set to change values,' but the read-versus-write contrast is clear from context.

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

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

With no annotations, the description carries the behavioral burden and does a solid job: it defines how booleans/ints/strings become lists via isList, requires absolute file paths for files, describes table values as row objects keyed by columns, and states the return shape. It doesn't discuss error behavior or persistence, but the update semantics and return behavior are sufficiently 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 core action, uses a compact bullet list for type mappings, groups related tool calls in a short paragraph, and ends with a one-line return summary. There are no wasted or redundant sentences.

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 three-parameter tool with full schema coverage and an output schema present, the description supplies the necessary lookup workflow (agents, indexes, keys, type inspection), exact value formats, and return behavior. It could additionally state failure behavior on type mismatch or invalid index, but an agent has enough to make a correct first call.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value beyond the raw schema: it maps each semantic input type to its JSON representation, explains list handling when isList is true, and specifies absolute paths and row-object structure. The key and index semantics remain in the schema, but the value semantics are substantially enriched.

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

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

The description clearly identifies the action (Update settings / Set the value of an input), the resource (an input declared via the src_input_set_* tools), and the key behavior that the value type is resolved from the input's own definition. It does not explicitly contrast itself with sibling tools such as agent_settings_get or src_input_set_bool/int/string, so sibling differentiation is incomplete but the core purpose is unambiguous.

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

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

It gives actionable usage guidance: fetch agent indexes with agent_list, fetch input keys with src_keys_list, inspect declared types with src_input_get, and then pass the natural value. This is clear context for how to invoke the tool correctly, though it does not state when to prefer agent_settings_set over the type-specific src_input_set_* siblings.

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 so admirably. It discloses the exact return semantics (`True` if started from stopped/paused, `false` if already running), implying partial idempotency, and mentions prerequisites like setting inputs and reviewing source code via related tools. It also explains the purpose of the source code for permanence and transferability.

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

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

The description is well-structured: starts with the core action, explains the rationale, names the alternative, lists related tools in a logical flow, and ends with return behavior. Every sentence adds essential information without redundancy, making it appropriately sized 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?

For a tool with one parameter, no annotations, and no output schema, the description covers all necessary aspects: action, return value, prerequisites, related tools, and the purpose of the source code. It provides a complete guide for an agent to invoke the tool correctly and understand its behavior.

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% as the single parameter `index` is described as 'One-based agent index'. The description adds value by pointing to `agent_list` to fetch available indexes, helping the agent understand how to obtain the correct value. This extra context raises the score above the baseline 3.

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

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

The description clearly states the verb 'start' and the resource 'agent', and specifies that it runs the source code defined by `src_*` tools. It explicitly differentiates from `agent_execute` by noting that `agent_execute` is for executing SDK methods on the fly without saving, 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?

It explicitly names `agent_execute` as the alternative for on-the-fly execution and provides a full workflow of related tools: `agent_list` for indexes, `agent_status`/`agent_logs` for progress, `src_export` for review, `agent_settings_set` for inputs, and `agent_results_get` for outputs. 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 provided, the description bears the full burden of behavioral disclosure. It mentions that the tool returns a status object and checks execution state, but does not describe side effects, permissions, rate limits, or any specific behavioral traits beyond that. The description adds little beyond what the name and input schema already imply.

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 moderately concise. The first sentence 'Get agent status' is partially redundant with the second 'Check whether the agent is currently executing a task,' but the subsequent tool recommendations are useful and well-structured. The overall length is reasonable, and the most relevant information (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?

Given the tool's simplicity (one required parameter) and the existence of an output schema, the description is largely complete. It provides context for related tools and the purpose of the status check. It does not mention error handling or invalid index behavior, but the low complexity and available output schema reduce the need for exhaustive 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?

Schema description coverage is 100% for the single parameter `index`, which is documented as a one-based agent index. The description does not elaborate on the parameter, but it does point to `agent_list` for obtaining indexes, which is helpful context. Since the schema fully describes the parameter, the description adds marginal value, aligning with the baseline of 3.

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

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

The description states a clear verb and resource: 'Get agent status' and further clarifies the specific purpose: 'Check whether the agent is currently executing a task.' This distinguishes it from sibling tools like `app_status` and `agent_logs`, since it focuses on execution state rather than general logs or app status.

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

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

The description provides guidance on related tools: it tells the agent to use `agent_logs` for status plus logs, `agent_list` to find indexes, and `agent_start`/`agent_stop` for lifecycle actions. It implicitly suggests `agent_status` for a quick execution-state check. However, it does not explicitly state when to choose this tool over `agent_logs` for status-only needs, leaving some inference required.

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 behavior burden. It explicitly discloses the return value ('True' if stopped, 'false' if already stopped) and the effect (returns control). It does not cover side effects like resource cleanup or permission needs, but for a control action this is reasonably transparent. The disclosed return behavior adds real value beyond the schema, so a 4 is justified.

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 well-structured: a clear purpose statement, a usage hint, and a return-value note. Every sentence earns its place, and the most important information (stop agent) is front-loaded. There is no wasted text, so a 5 is warranted.

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, the description covers the purpose, how to get the parameter, and the return behavior. It does not mention potential error conditions or effects on running tasks, but for such a tool this is adequate. Given the low complexity and good schema coverage, a 4 is reasonable.

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 full coverage for the single parameter with 'One-based agent index'. The description adds value by directing the agent to `agent_list` to fetch valid indexes, which clarifies how to determine the correct value. Since schema coverage is 100% and the description enriches the context, a 4 is appropriate.

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

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

The description clearly states the action ('Stop agent') and the resource (the agent), and explains what it accomplishes ('return control back to the user or AI assistant'). It is distinct from siblings like agent_delete or agent_start, though it does not explicitly call out the difference. This is clear but lacks explicit sibling differentiation, so a 4 is appropriate.

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 guidance: 'Use the `agent_list` tool to fetch all available agents and their indexes,' which tells the agent how to obtain the required index. However, it does not state when to use this tool versus alternatives (e.g., agent_delete) or any exclusions. It gives one piece of context but not a full usage policy, so a 3 is fair.

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

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

No annotations are provided, so the description must disclose behavioral traits. It mentions that the name is trimmed and truncated to 64 characters, which is a behavioral constraint. It also states returns True on success. However, it does not discuss side effects such as whether the update is persistent, whether it overwrites other agent properties, or any permission requirements. Given the mutation nature and lack of annotations, this is a moderate disclosure.

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

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

The description is very concise: three short paragraphs plus a return line. The first line 'Update agent' is redundant with the title, but the second paragraph adds crucial behavioral constraints. The usage hint is front-loaded after the core description. It wastes no words, though the title-like first line is slightly repetitive.

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 two fully documented parameters and no output schema, the description provides enough to call it correctly: the purpose, the origin of the index, and the return type. It lacks details on error cases or whether the update is idempotent, but given the low complexity and full schema coverage, it is nearly complete. The only significant omission is mention of any prerequisites or side effects beyond the name change.

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

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

Schema coverage is 100%, so the schema already describes both parameters. The description adds that the name is trimmed and truncated to 64 characters, which elaborates on the agentName parameter beyond the schema (schema says between 3 and 64 characters after trimming). This adds some semantic value, but the `index` parameter is only described as 'One-based agent index' in the schema, which the description does not enhance. Since schema covers the basics, a baseline 3 is appropriate with slight credit for the trimming/truncation detail.

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

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

The description clearly states it updates an agent's name, which is specific. It distinguishes from siblings like agent_create and agent_delete, but does not explicitly name them as alternatives. The verb 'Update' and resource 'agent' are clear, but the scope (only name) is highlighted, giving good differentiation from other agent tools like agent_start or agent_settings_set.

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 advises using `agent_list` to fetch available agents and their indexes, which is a useful usage pointer. It implicitly indicates when to use this tool (when you need to rename an agent) but does not explicitly state when not to use it or mention alternatives. The reference to agent_list is a clear guide for obtaining the required `index` parameter, which aids correct invocation.

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

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

With no annotations provided, the description carries the behavioral disclosure burden and does so well. It discloses that the first entry is a synthetic `<viewport>` entry, explains the coordinate system and scroll values, and states that remaining entries are ordered by 'how likely they are to be worth acting on rather than by document position.' It stops short of explicitly confirming the tool is read-only or has no side effects, hence a 4 rather than 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 organized and front-loaded with the core purpose, but it is somewhat long and contains redundancy: the trailing 'Returns:' line repeats the opening sentence. There is also a grammatical issue in 'Use the `agent_execute` tool to with `$.do*` methods' that slightly harms clarity.

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

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

Given the tool has an output schema and 100% parameter schema coverage, the description goes beyond minimum completeness: it explains the synthetic viewport entry, coordinate relativity, scroll semantics, ordering, and how to obtain the required `index`. An agent has all the context it needs to invoke this tool correctly and know what to expect.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not explain `index` or `maxResults` directly, but it does point to `agent_list` for fetching valid indexes, which adds a little context. The maxResults behavior is already fully 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 opens with a clear verb and resource: 'Get a structured list of the HTML elements currently visible in the agent's viewport.' It explicitly distinguishes itself from the sibling `agent_screenshot` by calling itself a 'lightweight, text-based alternative... for text-only AI models,' so an agent can tell them apart without opening the schema.

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

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

The description gives strong usage context: it positions the tool for text-only AI models, names `agent_screenshot` as the non-text alternative, and recommends `agent_execute` for deeper DOM inspection and `agent_list` for finding agent indexes. It does not explicitly say 'do not use this for...', but the alternatives are clear enough.

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

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

With no annotations, the description carries the transparency burden. It discloses return format (Markdown), list vs. search behavior, result sorting by prefix match, and that full argument details and code examples are returned. It stops short of stating no side effects, but for a read-only lookup tool the disclosure is solid.

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?

Front-loaded with a one-line purpose and a strong warning, then organized into usage, return, and behavioral details. Slight redundancy in the final 'Returns' sentence and the somewhat opaque 'Uindow modules' phrase keep it from a perfect 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?

Given no output schema and no annotations, the description covers return format, list-vs-search behavior, sorting, and a clear pre-call workflow. It is largely complete for a tool with two optional parameters, though the exact structure of the returned documentation is not fully spelled out.

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

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

Schema coverage is 100%, so baseline is 3. The description adds real value beyond the schema by explaining what the query should contain (the exact method/property about to be used) and how matching works (sorted by match to beginning of paragraph), complementing the schema's syntax-only details.

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

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

The description states a clear purpose: query SDK documentation to get full argument details and code examples for dollar-sign ($) object properties/methods, or list them. It doesn't explicitly contrast itself with sibling tools, but its resource and function are distinctive enough to avoid obvious 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?

It gives explicit, actionable guidance: never guess arguments and always call app_docs with the target method or property as the query before using it. It also ties usage to `agent_execute` and `src_code_set`, making when-to-use highly concrete.

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

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

No annotations are provided, so the description carries full behavioral burden. It discloses idempotent behavior (false when already running), download-on-demand side effects, and the return signals. It could mention failure modes such as download/launch errors, but for a zero-argument tool it is sufficiently 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 succinct and well-structured: a one-line summary, conditional behavior, and a returns line. Minor redundancy and the repeated 'Uindow' typo prevent a perfect score, but there is no wasted 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 no-parameter tool without an output schema, the description explains what happens, when it returns false, and what it returns on success. It lacks explicit failure/exception information, but overall it provides enough context 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 tool has zero parameters, so there is no parameter schema burden for the description to compensate for. The description adds no parameter details, but none are needed; baseline 4 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?

States a specific verb ('Start', 'launch') and resource ('application'), and clearly communicates the action: launch the Uindow app and return true/false. It is easy to distinguish from sibling lifecycle tools like app_stop and app_status.

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

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

Gives useful conditional usage context: if already running, return false; otherwise download dependencies and launch. However, it does not explicitly mention alternatives such as app_status for checking state before calling, so usage 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?

With no annotations, the description carries the full burden of behavioral disclosure. It communicates a read-only check and return type, but it is internally inconsistent: it says 'Check whether Uindow was installed and started' while the return line defines true only by whether the app was started. This leaves the role of installation status in the result unclear, which is a transparency gap.

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

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

The description is short, front-loaded with the tool's purpose, and clearly separates the return semantics in its own line. The typo 'Uindow' and slight redundancy between the heading and first sentence are minor issues, but the overall structure is appropriately concise.

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

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

Because there is no output schema, the description must fully explain the meaning of the returned boolean. It fails to do so consistently: 'installed and started' suggests two conditions, while the return definition mentions only 'started.' The tool is callable (no arguments), but the agent cannot confidently interpret what false means.

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 parameter-level semantics are not applicable. The baseline of 4 applies, and the description adds useful information about the boolean return value, which is sufficient in this 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 identifies a status-check operation with a specific verb and resource: 'Get application status' and 'Check whether Uindow was installed and started.' This distinguishes it from sibling tools like app_start and app_stop. However, the ambiguity between 'installed and started' and the return-condition 'if the app was started' slightly weakens the precision.

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

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

The intended use as a status/readiness check is implied by the name and description, and it naturally contrasts with the app_start/app_stop siblings. However, no explicit guidance is given about when to prefer this tool over alternatives, and no when-not-to-use conditions are stated.

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

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

With no annotations provided, the description carries the full burden and does it well: it discloses the quit signal, graceful exit wait, the already-stopped edge case, and the failure case where the signal cannot be delivered. The typo 'Uindow' is a minor flaw but does not obscure the 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 reasonably concise and front-loads the core purpose. The final 'Returns' sentence somewhat repeats the preceding conditional explanation, but the overall structure is clear and scannable.

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

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

Given no parameters, no annotations, and no output schema, the description fully explains the return value and edge cases. An agent knows exactly what to expect when calling this tool: true on successful graceful stop, false if already stopped or signal delivery fails.

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. There is no parameter information to add, and the description appropriately focuses on behavior and return semantics instead.

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

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

The description clearly states the tool stops an application, followed by concrete behavioral details about how it does so and what it returns. This distinguishes it from sibling tools like app_start and app_status by naming the specific action and outcome.

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

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

The intended use is implied through the verb 'stop' and the sibling tool set, but the description does not explicitly say when to prefer this over alternatives or provide exclusions. It gives useful edge-case behavior but no direct usage guidance or routing.

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 behavioral load: 'Fetch' implies a read-only operation, and returning a 'Sourceâwhat code object' is disclosed. It also adds useful behavior beyond the name by warning that returned code may contain $ methods requiring app_docs lookup.

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

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

The description is compact and front-loaded with the core purpose, followed by four concrete steps. The 'Module' line is slightly redundant with the first sentence, but it doesn't bloat, and every other 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?

For a 3-tool param fetch with an output schema present, this description covers all needed operations: what it fetches, how to obtain all input values, and how to interpret a possible issue in the returned code. There's the agent needs to call it correctly, and missing edge-case behavior is minor in comparison.

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

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

The schema already documents all three parameters at 100% coverage, so the baseline is 3. The description adds meaning by explaining how to discover valid values: agent_state for the index, src_keys_list rooms with section names for the key. That is helpful signal the schema alone doesn't provide.

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

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

The description uses a specific verb ('Fetch') and resource ('source code') and scopes it to 'FSM state, or function', which is clear and domain-specific. It doesn't explicitly contrast itself with siblings such as src_code_set or src_key_list, but the resource is distinct enough to avoid 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?

Provides an explicit usage sequence: use agent_list for indexes, src_keys_list for section-specific keys, and app_docs for dollar-sign methods. This gives clear context for how to call the tool correctly, though it does not spell out exclusions or 'when to use this instead of a sibling like src_code_set.'

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it warns against async IIFEs, explains FSM start and transition behavior, discloses 64-state and 128-function limits, clarifies that function return values do not trigger transitions, and notes that the returned key is sanitized and uniqueness-checked.

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 long but well-organized with section headings and a prominent warning. There is minor redundancy between 'Module: set state or function code' and the following sentence, and the list of companion tools adds some length, but most sentences carry meaningful operational detail for a tool with this complexity.

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 code-writing tool with no annotations, the description is highly complete: it covers both section variants, key constraints, maximum counts, async behavior, argument passing, return-value semantics, and even points to relevant docs, samples, and listing tools. It also states the return value ('Updated state or function'), which is sufficient given that an 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?

Even though schema coverage is 100%, the description adds significant meaning beyond the schema: it explains the behavioral difference between the two section enum values, gives concrete return-object syntax for state transitions, demonstrates $.fn calls with argument arrays, and clarifies that code blocks are already asynchronous. This enriches the code and section parameters well beyond their schema descriptions.

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

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

The description opens with a specific verb-resource pair: 'Set the source code' for either an FSM state or a function. It clearly distinguishes this tool from code-getting and key-management siblings and identifies the two relevant sections (srcStateMachine, srcFunctions).

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 strong contextual guidance: when editing FSM state code vs function code, how to trigger state transitions, and how functions are invoked via $.fn. It also directs the agent to agent_list, src_keys_list, app_docs, and src_sample for prerequisite or supplementary information, though it does not explicitly name src_code_get as the alternative for reading code.

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 behavioral burden. It clearly discloses that the result is a YAML string and guarantees the returned object always contains srcStateMachine, srcFunctions, srcInputs, and srcOutputs. It does not discuss error behavior or permissions, but for a read-only export operation this is sufficient.

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 uses bullets to organize related tools and practical instructions. The opening 'Module: get source (yaml)' and final 'Returns' line are somewhat redundant, but each substantive 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?

Although there is no output schema, the description compensates by specifying the YAML return format and guaranteed object keys. It also explains how to obtain the index, which tools to use for editing, and the file extension for save requests. For a low-complexity one-parameter getter, nothing essential is 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?

Schema coverage is 100%: the index parameter is already described as a one-based agent index. The description adds practical value by directing the agent to use agent_list to fetch all available agents and their indexes, which goes beyond the schema alone.

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

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

The description states a specific verb and resource: 'Export the agent's source as a YAML string.' It also enumerates the exact keys of the returned object, making the tool's scope unmistakable and clearly distinguishing it from the src_code_*, src_input_*, and src_output_* editors.

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 explicit routing guidance: edit srcStateMachine/srcFunctions with src_code_* tools, edit srcInputs/srcOutputs with src_input_*/src_output_* tools, use agent_list to resolve indexes, and use src_sample for structural understanding. It stops short of contrasting src_export with sibling read tools like src_code_get or src_input_get, so it is not a full 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, the description carries the responsibility for behavior. 'Fetch' and 'Returns: Input definition' clearly indicate this is a read operation, which is the most important behavior. However, it does not mention side-effects, error behavior, or what happens if an invalid index or key is supplied.

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

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

The description is short and front-loads the core action before giving parameter-discovery instructions. The 'Module: get input' line is a little redundant, but it does not add meaningful noise.

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

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

For a simple two-parameter read operation, the description is sufficiently complete: it says what is fetched, what is returned, and how to discover valid parameter values. It does not detail the return structure, but that gap is minor for this tool's 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 schema already documents both parameters at 100% coverage, so the baseline is a 3. The description adds value by explaining where to get the parameter values: agent_list for indexes and src_keys_list for input keys. This goes beyond the bare schema definitions.

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 says 'Fetch the definition for this input', which gives a specific verb and resource. It is easily distinguishable from the setter tools and src_code_get because it is a read-style fetch for input definitions, though it could more explicitly reference the key/index parameters.

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 explicit prerequisite guidance, telling the agent to use agent_list to obtain agent indexes and src_keys_list with section *srcInputs* to obtain keys. It does not name alternatives explicitly, but the fetch-versus-set distinction is implied strongly enough.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses that an existing key will be converted, that false boolean inputs hide dependent inputs, and that the returned key is sanitized and uniqueness-checked. It does not detail every side effect, but the key behavioral traits are covered.

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

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

The description is organized with a clear core definition, behavioral notes, workflow guidance, and a returns line. It is slightly padded with generic advice like using src_sample, but the structure is logical and the critical 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 four-parameter schema and output schema, the description is largely complete: it explains conversion semantics, dependency behavior, key uniqueness, and related tools. It stops short of providing a concrete example, but an agent can likely invoke this tool correctly from the provided information.

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 four parameters are already described in the schema, so the baseline is 3. The description adds meaningful context beyond the schema by explaining that key is sanitized and checked for uniqueness, and by pointing to agent_list for resolving index values.

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

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

The description clearly states the verb and resource: 'set boolean input' / 'Define a boolean input.' It distinguishes this from sibling tools like src_input_set_int and src_input_set_string by emphasizing the boolean type and its UI-control behavior.

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 useful context about when a boolean input is relevant, including its dependency-hiding behavior and configurability via agent_settings_set. It doesn't explicitly contrast with non-boolean input setters, but the surrounding workflow hints and sibling names make the intended usage 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 behavioral burden. It discloses a key side effect (existing inputs with the same key are changed to files inputs) and warns that the returned key is sanitized. It also notes that value setting happens through agent_settings_set, clarifying what this tool does not do.

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

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

The description is well-structured and front-loaded with the tool's purpose. It includes practical usage steps, though the reference to src_sample for learning FSM/IO interaction is somewhat tangential to actually invoking this tool.

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

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

Given the presence of a rich output schema and full parameter descriptions, the description appropriately focuses on behavior, workflow, and side effects. It covers the update behavior, key sanitization, and related tools, which is sufficient for an agent to call this tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3 even without additional parameter details. The description adds some context about the key's sanitization and uniqueness, but it does not explain individual parameter meaning beyond the schema.

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

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

The description clearly states the tool defines a *files* input and even describes its update semantics: if an input with the same key exists, it will be converted to a files input. This distinguishes it from the sibling input-set tools (e.g., src_input_set_bool) because the type is explicit.

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

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

The description provides clear workflow context: fetch agents with agent_list, list existing input keys with src_keys_list, set values with agent_settings_set, and then use agent_start. It does not explicitly contrast with alternative src_input_set_* tools, but the 'files' type makes the intended use apparent.

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 states that if an input with the given key exists, it 'will be changed to an *integer* input with these properties', which is an important overwrite behavior. It also discloses that the key returned is sanitized and unique, and that the tool returns an input definition. This gives agents enough transparency to anticipate side effects, though it doesn't mention permissions or state requirements.

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 longer than strictly needed, with multiple 'Use ...' tool directives that could be seen as slightly repetitive. However, it is structured: the purpose is front-loaded, followed by behavioral notes, a list of related tools, and the return type. Every sentence has a purpose, but the cross-tool references add verbosity. It is organized but not exceptionally concise.

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

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

Given the tool's complexity (10 parameters, 3 required) and the presence of an output schema (though not shown), the description provides substantial context: it clarifies behavior on existing keys, key sanitization, required index lookup, and the overall workflow involving agent_settings_set and agent_start. It also mentions the return value. This is quite complete for an agent to use the tool correctly, though it omits error handling or edge cases.

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

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

The input schema has 100% description coverage, so all 10 parameters are already well-documented. The description adds minimal parameter semantics beyond the schema; it references the 'key' parameter indirectly by advising to use the returned key, but does not elaborate on any parameter meanings. This meets the baseline for high schema coverage, but adds little extra value.

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

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

The description opens with 'Module: set integer input' and explains it defines an integer input that can be configured manually or via agent_settings_set. This is a specific verb+resource, and the emphasis on 'integer' clearly differentiates it from sibling tools like src_input_set_bool or src_input_set_string. It also states the behavior when an existing key is present, further clarifying the tool's exact purpose.

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

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

The description gives concrete prerequisites and related tools: it instructs using agent_list to fetch agent indexes, src_keys_list to get input keys, agent_settings_set to set values, and agent_start to start the agent. It also clarifies that the returned key must be used because it is sanitized and unique. While it doesn't explicitly call out alternatives, the integer specificity implies when this tool should be chosen.

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

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

With no annotations, the description carries the transparency burden. It discloses mutation semantics (existing key becomes a string input), key sanitation and uniqueness via the returned key property, and states the return value. It does not discuss side effects on existing configured values, but the core behavioral traits are covered.

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

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

The description is front-loaded with the main purpose and then provides a compact sequence of related tool calls. The "Use src_sample..." sentence is somewhat generic, but the overall structure is clear and not bloated for a tool with this complexity.

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 10-parameter tool with no annotations, the description covers the essential surrounding workflow: discovering agents and keys, setting the input value, and using the returned sanitized key. It also states the return shape. It does not explain all edge cases, but it is sufficiently complete 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 already describes all 10 parameters at 100% coverage, so the baseline is 3. The description adds meaningful parameter-level guidance by warning that the returned key must be used because the key is sanitized and checked for uniqueness, and by telling the agent how to obtain valid agent indexes.

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

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

The description uses a specific verb and resource: "Define a *string* input". It clearly distinguishes this tool from sibling input-type tools by emphasizing the string type and by explaining that an existing input with the same key will be changed to a string input.

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 preconditions and workflow: use agent_list to find indexes, src_keys_list to see existing keys, and agent_settings_set to set values before agent_start. It does not explicitly name sibling alternatives like src_input_set_int, but the string-specific purpose and related-tool guidance make the intended usage 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 behavioral burden and does it well: it discloses that existing keys are overwritten to become table inputs, that there is a maximum of 6 input tables, and that the returned key is sanitized and uniqueness-checked. It could mention persistence or failure modes, but the core side effects are clearly communicated.

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 somewhat long, opening with the near-tautological 'Module: set table input'. Several sentences provide useful workflow guidance, but the `src_sample` reference is more generic than tool-specific. It is structured and ends with the return value, yet could be tightened.

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, related tools, configuration approaches, mutation behavior, limits, and the return value. Given that an output schema exists and there are no annotations, this is a fairly complete definition. It would be more complete with explicit guidance on when to prefer other input-setting siblings, but nothing critical is 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?

Input schema description coverage is 100%, so the schema already documents all parameters. The description adds one important semantic detail about the `key` parameter ('You must always use the returned *key* property'), but it does not substantially expand meaning for the remaining parameters. Thus 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 operation with a specific verb and resource: 'Define a *table* input'. It also clarifies the update behavior ('If an input with this key exists, it will be changed to a *table* input'), which makes the tool's purpose concrete. It does not explicitly call out sibling tools like src_input_set_bool or src_input_set_string, but the table-input resource is specific enough to distinguish 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?

The description gives strong usage context, including configuring the input manually or via `agent_settings_set`, obtaining agent indexes via `agent_list`, and listing existing keys via `src_keys_list`. It lacks explicit when-not-to-use wording or direct alternatives for other input types, so it does not fully reach level 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?

No annotations are provided, so the description carries the burden. It states the operation is destructive ('Delete this item'), requires safety checks before calling, and specifies the return value (true if found/removed, false otherwise). It could mention irreversibility and permission requirements, but the protective guidance gives a strong picture of the tool's 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 well structured: a short action statement, a safety precondition, bulleted section-specific rules, and a compact return-value explanation. It is a bit redundant at the start ('Module: delete item' and 'Delete this item'), but overall every remaining part contributes meaning.

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

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

For a destructive deletion tool with no output schema and no annotations, the description is essentially complete. It covers the action, the prerequisite safety check, section-specific conditions, how to enumerate valid inputs, and the return behavior. An agent could invoke it correctly and know what to expect.

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 fulldocuments coverage for all three parameters, so baseline is 3. The description adds value by telling the agent how to find valid values: use agent_list for agent indexes and src_keys_list for available keys per section. This operational guidance goes beyond the schema.

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

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

The description states a concrete action ('Delete this item') and identifies the resource as a key within a module section, which distinguishes it from sibling tools like src_keys_update and src_keys_reorder. However, it does not explicitly name or contrast those sibling tools, so it falls just short of a 5.

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

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

It gives clear usage context: delete only after verifying the item is no longer referenced, and it explains the per-section checks needed before deleting. It does not explicitly say when to prefer this tool over other src_keys tools, but the prerequisites make the appropriate usage unambiguous.

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

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

No annotations are present, so the description carries the behavioral burden. It clearly states this is a listing operation returning keys, and adds useful behavioral details for each module section — including FSM state execution and how keys are consumed. It does not claim any mutations, and its 'Returns: List of keys' line reinforces a side-effect-free read.

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 more detailed than necessary but each bullet and code reference earns its place by clarifying the four section kinds. The structure is front-loaded with the primary purpose and then uses bullets for well-organized detail. It is not bloated, though the last two related-tool sentences slightly stretch beyond direct 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?

For a two-parameter tool with a fully self-describing schema and an output schema, the description covers everything needed: what the tool returns, how to determine the index, what each section means, and related tools when broader context is needed. An agent should be able to invoke it correctly without further probing.

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

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

Schema coverage is 100%, so the schema already defines the required parameters. The description goes beyond that by tying each allowed section value to its meaning for the module (states, functions, inputs, outputs) and directs the agent to agent_list for resolving the one-based index. This is meaningful added value over the raw schema.

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

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

The description opens with a clear specific verb+resource: 'Get a list of all keys defined in a module section.' It enumerates the four section types and their meanings, so the agent knows exactly what kind of keys are returned. This is strongly differentiated from sibling tools like src_keys_update, src_keys_reorder, and src_keys_delete by the verb 'list.'

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

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

The description gives concrete context for using the tool: use agent_list to find agent indexes and src_export to get the full module source instead. It does not explicitly say 'when not to use,' but it sets clear expectations through these related-tool pointers. This is enough for an agent to decide when src_keys_list is the right call.

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 behavioral impact: for `srcInputs` and `srcOutputs`, reordering affects UI element order; for `srcStateMachine`, it affects execution order; for `srcFunctions`, it is only for debugging. It also states the return value ('Updated list of keys'). It does not mention persistence, permissions, or potential failures, but for a reorder operation the described effects are sufficiently transparent. This is above the 'minimal viable' level, so 4.

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

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

The description is well-structured: it opens with the core purpose, uses bullet points to explain per-section effects, lists companion tool commands, and ends with the return type. Every sentence conveys necessary information without redundancy. It is concise yet comprehensive, earning 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?

The description fully equips the agent: it explains the impact per section, provides steps to obtain required inputs (agent list, keys list, source export), and states the return value. An output schema exists, so the description need not detail the return format. The tool is simple (3 params, one enum) and the description covers all necessary context for correct invocation. This is complete for its purpose.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds contextual meaning to the `section` parameter (explaining the role of each section) but does not elaborate on the `keys` array format or the `index` beyond schema. Since high schema coverage lowers the burden, the description adds marginal extra value. This aligns with the baseline of 3.

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

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

The description clearly states the tool's purpose: 'Reorder the items in a module *section*.' It specifies the verb (reorder) and resource (items in a section) and provides per-section context. However, it does not explicitly differentiate from the sibling `src_keys_update`—while the name implies reorder vs. update, the description does not directly say 'use this for ordering, not for changing values.' Thus it stops short of full sibling differentiation, fitting a 4.

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

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

The description gives clear context for when to use the tool: it explains the impact for each section type (state machine, functions, inputs, outputs) and suggests companion tools (`agent_list`, `src_keys_list`, `src_export`) to gather necessary information. However, it does not explicitly state when *not* to use this tool (e.g., when updating key values instead of order) or mention alternatives like `src_keys_update`. This is 'clear context, no exclusions,' so a 4 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 must disclose behavioral traits, and it does: changing the key requires manually checking and updating references in the exported source code. This warns the agent about a critical side effect and the need to follow up with edits. It does not describe error behavior or constraints beyond the schema, but the manual-reference advice is a valuable behavioral disclosure.

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 reasonably concise and front-loaded with the core action, then prerequisites and a return note. A little redundancy exists because src_export is mentioned both in the reference-check instruction and again as a separate use instruction, but this does not prevent comprehension.

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 4 required parameters, the description covers the preconditions, the key action, and a potential side effect. It explains what to do before calling and what to expect as a result. Some missing details would be error handling or behavior if the old key doesn't exist, but the use flow is sufficiently complete for invocation.

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

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

The input schema already covers all four parameters with descriptions, so baseline value is 3. The description adds useful guidance on how to obtain valid values by using agent_list and src_keys_list with the corresponding section, going beyond schema text.

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 changes an item's key to improve source code readability. It uses a specific verb and resource, and the operation is distinct from sibling tools like src_keys_delete and src_keys_reorder, though it does not explicitly name or contrast those alternatives.

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 explicit prerequisite steps: fetch agents with agent_list, list items with src_keys_list, and review source with src_export before updating references. It provides clear context for correct usage, though it does not explicitly state when not to use this tool compared to other key-related tools.

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

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

No annotations are present, so the description must bear the behavioral transparency burden. 'Fetch' and 'Returns: Output definition' sufficiently indicate a read-only retrieval, but the description does not disclose behavior for missing keys, invalid indexes, or other error conditions. It provides the core return value but little else.

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 explanation is compact and meaningfully front-loaded: true purpose appears in the second sentence. The leading "Module: get output" line is redundant with tool name and minor waste, but the rest of the text is purposeful.

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 this is a 2-parameter getter with an output schema present, the description is sufficiently complete: it identifies the operation, tells how to obtain both args, and names the return shape. It would be more robust if it called out invalid key or index behavior, but the overall is strong.

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

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

The schema already fully documents both parameters, so the description does not need to restate their meanings. It adds meaningful value by explaining how to resolve valid parameter values using "agent_list" and "src_keys_list

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

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

The description states a specific verb and resource: 'Fetch the definition for this output.' It also ends with 'Returns: Output definition,' which reinforces what the tool produces. This clearly distinguishes it from the src_output_set_* and src_input_get* sibling tools.

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

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

The description gives actionable usage guidance by telling the agent to use 'agent_list' to get agent indexes and 'src_keys_list' with section '*src Outputs*' to get output keys. It does not explicitly state when to avoid this tool in favor of another, but the **discovery workflow is specific and unambiguous.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It reveals upsert-like behavior (existing key changed to a boolean output), key sanitization/uniqueness, and the need to use the returned key. It does not cover error cases or permissions, but it is substantially 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 well-organized and front-loaded with the core purpose, then prerequisites. The 'Module: set boolean output' heading is redundant with the tool name, but the remaining sentences each add useful information.

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

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

Together with a full output schema and complete parameter descriptions, the text covers output behavior, key sanitization, viewing options, and prerequisite tools. It lacks a concrete example and explicit alternative selection guidance, but nothing critical is missing for invoking this tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description reinforces the importance of the returned key but adds no new parameter-level semantics beyond what the schema provides.

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

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

The description states a specific verb and resource: 'set boolean output' or 'Define a boolean output'. It clearly distinguishes this from sibling output setters by specifying the boolean type and its rendering as green or red dots.

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

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

The description gives clear context: outputs are viewable in the Results tab or via agent_results_get, and it points to agent_list for agent indexes and src_keys_list for output keys. It does not explicitly contrast with src_output_set_int/string/files/table, so it stops 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 the full burden of behavioral disclosure. It reveals that an existing output with the same key will be changed, that the returned key is sanitized and uniqueness-checked, that visibility can be toggled, and that the tool returns an output definition. It does not discuss auth or error behavior, but the core side effects are 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 moderately sized and front-loaded with the core purpose, then adds useful operational guidance. Some redundancy exists, such as mentioning the Results tab twice and including several doc-pointer sentences, but each sentence contributes meaningful context 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?

Given the tool has 8 parameters, no annotations, and an output schema, the description covers the essential behavioral and operational context: when to use it, key uniqueness, visibility control, and where to find supporting information. It is sufficiently complete for correct invocation, though it omits edge-case details like validation failures or storage limits.

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

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

Schema description coverage is 100%, so the baseline is 3 even though the description adds little parameter-specific detail. The description does reinforce the importance of the returned key and mentions the `visible` option, but the schema already documents all parameters adequately.

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

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

The description opens with a specific verb and resource: 'Define a *files* output', and immediately distinguishes it from other output types by connecting it to `$.ioSave*` SDK methods and the Results tab. This clearly identifies the tool's role among many sibling output setter tools.

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

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

The description provides practical context for when to use this tool: when defining files outputs or when working with `$.ioSave*` SDK methods. It also explains overwrite behavior for existing keys and references supporting tools like `agent_list` and `src_keys_list`, though it does not explicitly contrast it with alternative output setter 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 provided, the description carries the full burden of behavioral disclosure. It usefully documents that an existing key will be overwritten, that the returned key is sanitized and unique, and how integer outputs are rendered. This is solid transparency for a mutation tool, though it doesn't cover permissions or other side effects.

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

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

The description is well-structured and front-loaded with the core purpose. It includes distinct paragraphs for behavior, rendering, and supporting tools. The 'Module:' prefix and the brief 'Returns: Output definition' line are slightly redundant given the tool name and output schema, but they don't create meaningful bloat.

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

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

Given the presence of an output schema and fully documented parameters, the description covers the essential non-schema context: overwrite behavior, sanitized key usage, rendering, and companion tools. It is complete enough for an agent to call the tool correctly, except for minor specifics like invalid index handling.

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

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

The input schema has 100% parameter description coverage, so the description doesn't need to repeat property meanings. The description does add some operational context around the index and key parameters by pointing to agent_list and src_keys_list. That is helpful but not extensive enough to move far beyond the schema-supported baseline.

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

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

The description uses a specific verb-resource pair ('Define an integer output') and clearly distinguishes this tool from sibling output setters by stating the integer type and its line-graph rendering. It also explains how the output can be observed, so an agent can select this tool without opening sibling schemas.

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

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

The description gives clear context for when to use this tool: when an integer output needs to be defined for the Results tab or agent_results_get. It also provides concrete preparatory steps with agent_list and src_keys_list. However, it does not explicitly name alternatives or state when not to use this tool.

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

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

With no annotations, the description carries the behavioral burden. It discloses the side-effect that an existing output with the same key will be changed, and it emphasizes key sanitization/uniqueness plus the need to use the returned key. It does not cover permissions or broader side effects, but the core mutation behavior is explicit.

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 definition and key behavioral warning, then dedicated helper-tool references. The 'Use the...' sentences are purposeful and not padding; only the redundant 'Module: set string output' header adds minor noise.

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 6-parameter mutating tool with no annotations, the description covers the action, overwrite semantics, return-key requirement, and discovery workflow. The output schema presumably covers the return value and the input schema covers parameters, so the remaining gaps are mostly explicit alternatives and side-effect scope, which are minor here.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some context around the key parameter (sanitized, returned, uniqueness-checked) but leaves min, max, desc, name, and index semantics to the schema, which already documents them adequately.

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 tool defines a *string* output and distinguishes it from sibling output setters by type. It also specifies how the output can be viewed (Results tab or agent_results_get) and notes the overwrite-if-key-exists behavior, so an agent can tell this apart from other src_output_set_* 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 clear context: use this to set a string output, and it points to prerequisite discovery steps like agent_list and src_keys_list. However, it does not explicitly contrast with src_output_set_bool/int/files/table or state when not to use this tool, so it stops short of full alternative routing.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses that the tool mutates/overwrites outputs with the same key, enforces a maximum of 6 table outputs, sanitizes the key, and produces an interactive table visible in Results or via agent_results_get. This is strong transparency for a mutating tool, though it does not cover failure modes or permission requirements.

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 definition and is reasonably organized. However, it contains some redundancy ('Module: set table output' restates the tool name, and the Results-tab rendering is mentioned twice) and a generic tip about src_sample that is more background than invocation guidance.

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

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

The tool is moderately complex with 5 parameters and no annotations, but the description covers key behavioral aspects: overwrite behavior, uniqueness/sanitization, the 6-table limit, and how to discover valid agent indexes and output keys. The output schema exists, so the return format does not need explanation. Missing error handling details are minor given the constraints already in the 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 coverage is 100%, so the baseline is 3. The description adds extra value by explaining how to obtain the index via agent_list, how to list existing output keys via src_keys_list, and why the returned key must be used. This goes beyond the raw schema and helps an agent fill parameters correctly.

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

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

The description clearly states the action ('Define a *table* output') and the resource, and explains how the output is viewed and that existing outputs with the same key are changed. It is clear but does not explicitly contrast it with sibling output-set tools like src_output_set_bool or src_output_set_files, so it earns a 4 rather than a 5.

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

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

The description gives practical context: use agent_list to find the correct index, use src_keys_list to see existing output keys, and returns a sanitized key that must be used. It does not provide explicit when-not-to-use guidance or name alternatives, but the context is clear enough for selecting this tool for table outputs.

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 explaining behavior. It discloses that the tool returns YAML, that the result is always an object with specific keys (`srcStateMachine`, `srcFunctions`, `srcInputs`, `srcOutputs`), and that it illustrates FSM interactions and `$.args` usage. It does not explicitly state side effects, but for a sample-retrieval tool with zero parameters the behavioral surface is minimal and well 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 well structured and front-loaded with the primary purpose. It is moderately detailed but every paragraph serves a distinct role: what is returned, what the sample demonstrates, and which sibling tools to use. Minor redundancy exists between the opening ('YAML format') and the final 'Returns' line, but it remains scannable and efficient.

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

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

For a zero-parameter, no-output-schema tool, the description is complete: it explains the return format (YAML), the guaranteed top-level structure (four keys), the pedagogical purpose, and how to proceed with related tools. An agent has enough information to invoke the tool and understand its result without 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 tool has zero parameters, and the schema shows an empty properties object with `additionalProperties: false`, so parameter meaning is trivially complete. The description's mention of `$.args` refers to content inside the returned sample, not to invocation parameters, so it does not confuse parameter semantics.

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

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

The description states a specific verb and resource: 'Get a fully functional Uindow module in YAML format.' It also clarifies the tool's role as a sample provider and distinguishes it from authoring tools by saying 'Use the other src_* tools to author your own automation.' This makes it easy for an agent to know exactly what this tool returns and how it differs 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 gives explicit routing guidance: use `app_docs` for dollar-sign ($) methods in the returned code, and use the other `src_*` tools to author automation. This tells the agent when to use this tool versus alternatives, satisfying the usage-guidelines requirement.

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