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

With no annotations, the description must carry the behavioral disclosure burden. It does mention the return value ('Returns the created object summary') and the optional child behavior, but it does not mention potential side effects, error conditions, or persistence implications. Adequate for a straightforward add operation but lacks depth.

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

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

Two sentences, front-loaded with the action, then the optional behavior, and then the return value. Every word earns its place, no redundancy.

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

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

For an add operation with a rich schema and no output schema, the description covers the core purpose and return. It doesn't mention failure cases explicitly, but those are implied by the schema's uniqueness note and parentName error. Overall, quite complete for the tool's complexity.

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

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

The schema already provides full descriptions for all six parameters (100% coverage). The description only adds context around parentName and the prime/component distinction, which is minimal beyond what the schema's enum and property descriptions already convey. Baseline 3 is appropriate.

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

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

The description clearly states the action ('Add a new object') and the resource ('to a cell'), distinguishing it from sibling tools like list_objects, remove_object, and clone_object. It also mentions the optional child relationship via parentName, which adds 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 context is clear: this tool is for creating new objects. It does not explicitly discuss alternatives or exclusions, but the sibling list makes it obvious when to use add_object versus other object operations. The optional parentName note gives a specific usage scenario.

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 delivers: it discloses fresh unique IDs, collision-safe child renaming, subtree offset semantics, and that all clones collapse into one undo step. It also surfaces error conditions like parentName requiring a component and namePattern containing '{i}'. This is rich behavioral context beyond the schema.

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

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

The description is a single dense paragraph but every clause adds value. It is front-loaded with the main purpose and then systematically covers naming, placements, offsets, and undo behavior. Given the tool's complexity (11 params), the length is justified, though a bulleted structure could improve scannability.

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 thoroughly covers input semantics and behavioral effects, but it does not mention what the call returns (e.g., a list of created names, count of clones, or errors). With no output schema, a brief note on return value would round out the picture. The complexity is high, but the description handles most of the input side exceptionally well.

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

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

Although schema coverage is 100%, the description adds essential meaning: the precedence rules (names wins over namePattern+count), the distinction between startIndex and the 0-based offset multiplier, and the verbatim prompt requirement. These clarifications are not present in the raw schema and are critical for correct invocation.

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 starts with a specific verb+resource: 'Deep-clone one source object into many copies in a single call'. It also explicitly identifies itself as 'the batch counterpart to clone_object', which clearly differentiates it from the most relevant sibling tool.

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

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

It clearly positions this as the batch version of clone_object, implying use when cloning many objects at once. It also explains when to use `names` vs `namePattern`+`count`, and even notes error conditions (e.g., if namePattern lacks '{i}'). It doesn't explicitly state 'use this instead of calling clone_object repeatedly', but the batch counterpart phrasing is strong guidance.

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

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

With no annotations, the description carries the full burden. It discloses write behavior, per-entry nested-write guards, the need for expectedVersion on array/map properties, and confirmTypeChange for shape changes. However, it does not mention response structure, error handling, or atomicity, leaving a minor gap for a mutation tool.

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

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

The description is two sentences of tightly packed information: purpose, use case, entry structure, and guard conditions. No redundancy or filler; every sentence contributes.

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 (array of nested updates) and no output schema, the description covers the essential behavior, use case, and per-entry guards. The schema fully documents the prompt and cellName parameters, so the description need not repeat them. It could mention that it processes all entries in one batch, but the core context is sufficient.

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

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

Schema coverage is 100%, so the schema already documents all parameters and their meanings. The description adds only a slight clarification: 'Each entry specifies an object name and properties to set' and reiterates the guard conditions, which are already in the schema. This provides marginal added value beyond the schema.

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

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

The description clearly states 'Set properties on multiple objects in a single call,' specifying the verb, resource, and scope. It distinguishes from sibling set_property by emphasizing 'multiple objects' and 'mass-editing children of a component,' which uniquely identifies its bulk 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 explicit usage context: 'Useful for mass-editing children of a component (e.g., changing colors).' It also references the same guards as set_property, implying when to use the single-object variant, but does not explicitly state exclusions (e.g., 'for a single object, use set_property').

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 clearly states that the buffer is emptied, which is a destructive action, and the purpose is unambiguous. It does not discuss permissions, side effects, or persistence, but for a debug log clearing tool, the description is transparent enough about the core 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 exactly two sentences, front-loaded with the core action and then providing usage context. Every word earns its place, with no redundancy or irrelevant detail. It is concise and immediately understandable.

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

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

Given the tool's simplicity (no parameters, no output schema), the description is complete. It not only states what the tool does but also explains the ideal usage context in relation to get_debug_logs, making it self-contained for an agent deciding when to invoke it. The mention of the subsequent log retrieval fills any potential ambiguity.

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

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

The tool has zero parameters, and the baseline for 0-parameter tools is 4. The description does not need to explain parameter meanings, and it does not introduce any confusion. The clear action description aligns with the empty input schema, so the baseline score 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 ('Empty the debug log buffer') with a specific verb and resource. It is easily distinguished from sibling tools like get_debug_logs (retrieves logs) and set_debug_domains (configures domains), and the description adds clarity by framing it as a clearing operation.

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

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

The description explicitly states when to use the tool ('Use before triggering a test action') and explains the rationale ('so the subsequent get_debug_logs call only contains entries from that action'). It does not explicitly state when not to use it or name alternative tools, but the references to get_debug_logs provide clear context for the intended workflow.

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 reveals that the operation creates new IDs, renames children to avoid collisions, and can target an existing component via parentName, which goes beyond the schema. This provides valuable transparency about the operation's side effects and scope.

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

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

The description is two sentences, front-loaded with the core purpose, and avoids redundancy. Every sentence adds value, covering the deep-clone scope and the optional parenting behavior without waste.

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

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

Given the tool's complexity and lack of output schema, the description is largely sufficient. It covers the main behavior, the scope of cloning, and the optional target placement. It does not describe the return value or error conditions, but those are either implied or covered 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?

The input schema already documents all six parameters with 100% coverage, so the baseline is 3. The description adds little parameter-specific meaning beyond what the schema provides, though it does highlight the optional parentName behavior. It does not introduce new syntax or format 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 clearly states the tool deep-clones an object including all children, presets, states, and scripts, and specifies behavior such as generating new unique IDs and renaming children. This distinguishes it from sibling tools like bulk_clone and add_object by emphasizing the deep-cloning aspect.

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

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

The description provides clear context: use this when you need to clone an object deeply into the same or a different cell, optionally as a child component. However, it does not explicitly mention when to prefer this over sibling tools like bulk_clone, nor when not to use it, so it lacks explicit exclusions.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It adds meaningful context about category semantics (e.g., 'concepts' including object variables, message params) and implies a read-only lookup action. However, it does not explicitly state that the tool is read-only, describe return format, or mention any side effects. This is a gap since annotations are absent, but the nature of a reference tool is inferred.

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 consists of two sentences that are densely informative. The first sentence states the purpose; the second lists categories and explains the 'concepts' category. Every phrase contributes essential information, with no redundancy or filler.

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

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

The tool is simple (2 params, no output schema, no annotations). The description together with the schema covers the core usage and category options. It lacks explicit details about the return format (e.g., structured list vs. free text), but for a reference documentation tool this is a minor gap. Given the low complexity, the description is sufficiently complete.

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

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

Schema description coverage is 100%, with both parameters documented in the schema. The description adds slight value by elaborating on certain category meanings (notably 'concepts') and suggesting that 'all' provides a complete syntax reference, which is already in the schema. It does not significantly enhance parameter understanding beyond what the enum descriptions already provide, warranting the baseline score.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Get reference documentation for the Purl DSL scripting language.' It distinguishes itself from sibling tools focused on project/script management by explicitly framing this as a documentation/lookup tool. The mention of queryable categories and 'full syntax reference' further specifies scope.

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

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

The description explains how to use the tool ('Query by category... or get the full syntax reference') and clarifies what the 'concepts' category covers. It does not explicitly say 'use this when you need DSL documentation' or list alternatives, but the purpose is clear enough that an agent would know when to choose this tool over siblings like get_script or validate_script.

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?

Despite lacking annotations, the description fully discloses behavioral traits: sequential application of edits, atomicity ('if any anchor fails... nothing is written'), and loud failure on stale baselines. It also mentions the optional validate flag, adding important context beyond the schema.

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

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

The description is compact and front-loaded with the core purpose. Every sentence adds critical information—mechanics, atomicity, usage distinction, and failure behavior—with no redundancy or filler.

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

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

The tool has 6 parameters and no output schema, but the description covers key behavioral aspects (replaceAll, sequential application, atomicity, validation), alternatives, and edge cases. It is fully sufficient for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics: it explains sequential edit ordering, the uniqueness requirement for 'old', the effect of replaceAll, and the atomic rejection behavior, which goes beyond the schema's field-level 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 begins with a specific verb and resource: 'Edit an existing script via a list of find/replace anchors'. It clearly defines the method (anchored find/replace) and contrasts with update_script, making the tool's unique purpose obvious.

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?

Explicit guidance is provided: 'Use this for targeted changes; use update_script only for full rewrites or brand-new scripts.' It also explains when to use replaceAll and the consequences of stale baselines, giving clear when-to-use and when-not-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, the description carries the transparency burden. It reveals that only entries for currently-enabled domains exist in the buffer and that set_debug_domains must be called beforehand, adding useful behavioral context. It doesn't discuss return format or buffer limits, but the 'Read' verb and parameter schema cover basic expectations.

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

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

The description is three sentences, front-loaded with the action, then a usage example, then a crucial prerequisite. No wasted words.

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

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

The tool is a read-only log fetcher with no required parameters; the description covers the main scenario and prerequisite. The absence of an output schema means return values aren't explained, but the name and filters imply entry contents. Minor gap.

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

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

All 4 parameters are fully described in the schema, so the description adds no additional semantic detail beyond the schema. Baseline of 3 applies per the high schema coverage.

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

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

The description uses the specific verb 'Read' with resource 'recent debug log entries from the running play session,' clearly distinguishing it from sibling tools like clear_debug_logs and set_debug_domains by stating its read-only nature and domain prerequisite.

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

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

Provides a concrete use case ('verifying what the engine saw after a test action') and an explicit prerequisite ('call set_debug_domains first to enable categories'). However, it doesn't explicitly compare with alternatives or state when not to use it, though the read operation is self-evident.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It tells the user what data is returned (all properties, dynamics config, etc.) but does not mention potential side effects, permission requirements, rate limits, or error behavior. It is not misleading but lacks depth beyond listing the content.

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: two sentences, first stating the function and scope, second providing usage context. Every phrase earns its place with no redundancy or filler.

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

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

For a simple read tool with no output schema, the description effectively explains what the returned data includes and when to use it. It is sufficiently complete for an agent to select and invoke the tool, though it could mention error behavior or prerequisites. Given the rich sibling context and schema coverage, this is adequate.

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

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

The schema covers both parameters at 100% coverage, including a useful alias note for 'target' and an explanation for 'cellName'. The description itself adds no parameter-specific information, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('Get') and resource ('a single object'), then enumerates the full scope: 'all properties, dynamics config, states, children, scripts.' This clearly distinguishes it from sibling tools like get_states (states only), get_script (script only), and list_objects (plural list). The 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?

The description provides explicit guidance: 'Use this when you need to inspect or debug a specific object.' This clearly states a primary use case, but it does not mention when not to use it or name alternative tools, so it falls short of a 5.

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

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

With no annotations, the description carries the burden of revealing behavior. It states the tool is a read-only retrieval ('Get') and indicates the return contents, but it does not disclose any potential side effects, performance implications, or what 'live editor' means in terms of state. The coverage is adequate but not rich.

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

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

The description is two concise sentences that front-load the action and resource, then specify return contents. Every word contributes value, and there is no redundant or filler text.

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, zero-parameter tool with no output schema, the description sufficiently covers the purpose and return values. It could elaborate on the exact structure or format of the returned data, but given the low complexity, the description is reasonably complete.

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

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

The tool has zero parameters, so the schema is trivially covered at 100%. The description adds no parameter-specific detail because none exist, which aligns with the baseline of 4 for parameter-less tools.

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

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

The description clearly states the tool gets the 'current Purl project structure from the live editor' and specifies what is returned ('cells, objects, and settings'). This distinguishes it from sibling tools like get_object or get_script, which target specific elements rather than the whole project structure.

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

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

The description implies the tool is used to fetch the overall project structure, but it does not explicitly state when to use it versus alternatives such as get_object or list_objects. There is no mention of exclusions or comparisons, so guidance is only implied by the description's scope.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the tool 'gets' script code, implying a read-only operation, but it does not mention error behavior when the target is ambiguous, the need for 'cell:' prefix, or what the response format is. The schema covers the cellName requirement, but the description adds no behavioral context.

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

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

The description is a single sentence, front-loaded with the verb 'Get' and the resource 'script code.' Every word earns its place; no filler or redundancy.

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

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

For a tool with only 2 parameters and a clear schema, the description is minimally adequate. It states the core purpose but omits context around ambiguous names and error handling, which are partially covered by the schema. Since there is no output schema, a bit more explanation of return values would improve completeness, but it is not severely lacking.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal meaning beyond the schema, mentioning only 'object or cell' without explaining the target format or the cellName disambiguation logic. The schema already provides detailed parameter semantics.

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

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

Description uses a specific verb+resource pattern: 'Get the script code for an object or cell in the current project.' It clearly indicates the tool returns script code, distinguishing it from sibling tools like get_object or search_scripts, though it doesn't explicitly contrast with read_project_scripts.

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

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

The description gives no guidance on when to use this tool versus alternatives like search_scripts or read_project_scripts. It does not mention prerequisites, limitations, or exclusions. The optional cellName parameter hints at a disambiguation use case, but there is no explicit when/when-not guidance.

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

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

With no annotations, the description carries the full burden. It states the history comes from update_script, is ordered most recent last, and each entry includes timestamp, user prompt, and full code snapshot. This adds meaningful behavioral detail, though it doesn't explicitly confirm read-only behavior or discuss pagination/rate limits.

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

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

Three focused sentences: purpose, use case, and return structure. No wasted words, well 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?

No output schema exists, so the description's explanation of each entry (timestamp, user prompt, full code snapshot) is essential and provided. The tool is a straightforward history lookup, and with 100% schema coverage, the description is complete enough.

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

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

Schema coverage is 100%, so all parameters have descriptions. The tool description adds no extra parameter-specific meaning beyond what the schema already provides, making the baseline 3 appropriate.

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

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

The description clearly states the tool gets the MCP edit history of a specific script, with past versions most recent last. This distinguishes it from sibling tools like get_script (current script) and search_scripts (search).

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 an explicit use case: 'Use this to recover code that was accidentally wiped by a previous edit.' It does not mention exclusions or alternatives, but the context is clear enough to know when it applies.

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

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

With no annotations, the description carries the full burden. It discloses what the operation returns (child list, per-child overrides, reference snapshot, state groups), giving the agent a concrete picture of the response. It also frankly states a limitation (only components). This is strong but not exhaustive—side effects or permissions are not addressed, though "Get" implies read-only.

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

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

The description is three concise sentences: purpose, return payload, and usage constraint. Every sentence adds value with no redundancy or filler.

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

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

For a tool with no output schema and no annotations, the description provides a solid overview: what the tool does, what it returns, and a key limitation. It lacks a detailed return format or examples, but given the simplicity of the operation, it is adequately complete for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, and the schema already documents both parameters (target and cellName). The description adds no extra parameter semantics, so baseline 3 is appropriate.

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

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

The description clearly states a specific verb+resource: "Get presets/states for a component". It lists concrete return contents (child list, preset names, reference snapshot, state groups) and explicitly limits usage to components, distinguishing it from sibling tools like get_object or get_script.

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

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

The description implies when to use it by saying "Only works on components", providing a clear precondition and exclusion for non-components. However, it does not explicitly name alternative tools for non-component state inspection, nor does it state when NOT to use it beyond the component constraint.

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

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

With no annotations provided, the description must carry the burden of behavioral disclosure. It does state what the tool returns (names, types, tags, and key properties) and the scope of its search (project or cell), but it does not explicitly mention whether it is read-only, how pagination works, or any potential side effects. The verb 'List' implies a non-mutating operation, but the description could be more explicit about safe usage and edge cases.

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

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

The description is extremely concise, with exactly two sentences that front-load the main action ('List all objects') and quickly provide the key details (scope and return content). Every word earns its place with no redundancy or fluff.

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

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

For a simple list tool with one optional parameter and no output schema, the description provides adequate context. It specifies what the tool does, the optional filter, and what is returned. However, it omits any mention of pagination or performance characteristics, which could be relevant for a 'list all objects' operation, preventing a perfect score.

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

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

The schema already provides a 100% description coverage for the only parameter (cellName) with an explanation of its purpose ('Optional: filter to objects in this cell (by label)'). The description's phrase 'or a specific cell' aligns with this parameter but adds no new semantic details beyond what the schema already states. According to the rubric, a baseline of 3 is appropriate when schema coverage is high and no additional parameter context is needed.

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

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

The description clearly states the tool's function with a specific verb ('List all objects') and resource ('in the current project or a specific cell'), and it distinguishes itself from siblings like get_object (which retrieves a single object) and get_project (which likely returns project metadata). The scope (project or cell) and returned data (names, types, tags, key properties) are explicitly defined.

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

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

The description provides clear context for when to use the tool: when you need a list of objects in a project or a specific cell. It does not explicitly name alternatives or state when not to use it, but the mention of the optional cellName parameter gives usage context. However, there is no direct comparison to related tools like get_object or search_scripts, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It discloses no-op behavior when already at the requested parent, error conditions for invalid parent or self-move, and the special 'top' value. This is strong behavioral transparency for a mutation tool.

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

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

Three sentences, front-loaded with the tool's purpose, and no filler. Every sentence adds relevant behavioral or usage detail, making it highly concise and well-structured.

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

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

Given the mutation nature and 4-param schema with full descriptions, the description covers key behaviors (no-op, errors, scope) adequately. It omits return values, but since no output schema exists, this is not a significant gap. The tool is conceptually simple and well-explained.

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 baseline is 3. The description reiterates newParent semantics (e.g., 'top' vs component name) but adds no new parameter details beyond what the schema already states. It provides marginal reinforcement, not additional meaning.

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

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

The description opens with a specific verb+resource: 'Reparent an existing object within the same cell,' clearly distinguishing it from sibling tools like add_object, remove_object, and clone_object. It also explains the two distinct modes (hoist to top vs move into named component), reinforcing 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 clearly scopes usage to 'within the same cell' and explicitly covers both use cases (newParent='top' or component name). It doesn't name alternative tools, but the context is clear enough for an agent to decide when this tool is appropriate.

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

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

With no annotations, the description carries the full burden. It discloses key behavioral traits: 'Additive — only the target array is touched; siblings and unrelated entries stay intact' and 'Errors if the target isn't an array.' This goes beyond a simple purpose statement, though it does not discuss permissions or return format, which is acceptable for a simple mutation tool.

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

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

The description is three sentences, front-loaded with the primary action, followed by behavioral transparency and usage guidance. Every sentence earns its place; there is no repetition of schema details or filler. It is concise and well-structured.

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

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

Given the tool's moderate complexity (6 params) and lack of annotations or output schema, the description covers the essential context: purpose, side effects, error condition, and relationship to a sibling tool. It does not explain return values or the prompt-collapse behavior, but those are documented in the schema. Overall, the description is sufficiently complete for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds general context about nested paths and array-shaped properties, but does not add specific parameter-level meaning beyond what the schema already provides. The schema fully documents all six parameters, so the description's contribution here is minimal but not absent.

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: 'Append a value to an array at a nested path.' This precisely identifies the action and target, and differentiates from siblings by explicitly recommending this tool over set_property for additive array appends. It leaves no ambiguity about what the tool does.

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

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

The description provides explicit guidance: 'Use this instead of set_property for adding items to a DATA prime's value (or any other array-shaped property).' This names a specific alternative and the condition under which this tool should be chosen. The 'additive' qualifier and error condition ('Errors if the target isn't an array') further clarify when it is appropriate.

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

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

With no annotations, the description carries the burden. It discloses return format (flat array of {target, scriptName, code, lineCount}), sort order (scene-order), empty-skip behavior, soft byte cap, truncation marker, and refinement options. However, there is a discrepancy: description states default 50000 for the soft cap while the schema says maxBytes default 200000, which could confuse an agent. This minor inconsistency prevents a perfect score.

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 fairly concise and front-loaded with the main purpose. It packs a lot of useful detail into three sentences, but the default cap discrepancy and slight overloading (mentioning both 50000 and truncation) could be streamlined. Still, each sentence yields high value.

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, sort order, truncation behavior, and usage scenarios. It is nearly complete, but the default cap mismatch with the schema and the omission of explicit target default (though schema has it) leave minor gaps. Overall, it is well-developed for a complex tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds some context about when to use refinements (e.g., 'refine via cellName or targets') and mentions the default skip-empty behavior, but it largely echoes the schema's parameter descriptions. It does not add significant new 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 opens with a specific verb and resource: 'Dump every script in the project (cell scripts + object scripts, all tabs) in one call.' It clearly differentiates from search_scripts by stating when to use this tool (whole-project audits, refactors, finding wired places) versus when to use search_scripts (only matching lines).

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?

Explicit usage guidance is provided: 'Use this for whole-project audits, refactors, or "find every place X is wired" questions where you need the surrounding code, not just matching lines (use search_scripts when you only need matching lines).' It also suggests refining via cellName or targets, giving clear context for when to use alternatives.

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

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

With no annotations, the description carries the full burden and does disclose a key behavioral trait: removing a component also removes its children. However, it does not mention other relevant aspects such as whether removal is permanent, if there are any safety checks, or what happens to references. The disclosed cascade behavior is useful but the overall transparency is minimal.

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

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

The description is two short sentences with no filler. The first sentence states the core action, and the second adds an important exception, making it highly efficient and easy to scan.

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

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

Given the tool's simplicity, full schema parameter coverage, and lack of an output schema, the description adequately covers the core functionality and the cascade behavior. It could mention edge cases like object-not-found behavior, but that is not essential for selecting and invoking 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 input schema already provides complete descriptions for all three parameters, so the description does not need to add parameter details. The phrase 'from a cell' loosely aligns with the 'cellName' parameter but adds no new semantic value beyond what the schema already states. Baseline 3 applies due to full schema coverage.

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

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

The description uses a specific verb ('Remove') and resource ('an object from a cell'), clearly distinguishing it from sibling tools like add_object, clone_object, and move_object. It also adds a meaningful qualifier about component children, ensuring the scope is unambiguous.

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

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

The description implies usage when an object needs to be removed, but it does not explicitly state when to prefer this over alternatives or mention any exclusions or prerequisites. The 'from a cell' context provides some guidance, but there is no direct comparison to sibling tools.

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

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

With no annotations, the description carries the full burden. It discloses important behavioral traits: array element shifting, map entry deletion, and error on non-existent path (no silent no-ops). This goes well beyond the schema and provides clear expectations for a mutating operation.

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

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

The description is two sentences, front-loaded with the main purpose, and every sentence adds value. It is concise without unnecessary detail.

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

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

The tool has no output schema or annotations, but the description explains core behavior and error conditions well. However, it omits details about the return value on success and any undo/versioning implications, which would be useful given the mutation context.

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

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

Schema coverage is 100%, so all parameters are documented in the schema. The description adds minor context about path behavior (e.g., bracket index) but does not significantly enhance parameter semantics beyond what the schema already provides.

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

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

The description clearly states the tool removes a single value at a given path, with explicit behavior for arrays (shift elements) and maps (delete keyed entry). This distinguishes it from sibling tools like set_value_at_path, which sets rather than removes.

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

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

The description implies the tool is for removing values but does not explicitly mention when to use it over alternatives or provide exclusions. It lacks direct comparison to set_value_at_path or push_value, so usage context is only implied.

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

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

With no annotations provided, the description carries the full burden. It discloses the return structure, contextLines behavior with default and cap, and case sensitivity option. It does not mention potential performance issues or what happens when no matches are found, but core behavior is 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?

Three sentences, front-loaded with purpose, followed by return format and usage guidance. Every sentence earns its place with no redundancy or fluff.

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

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

For a search tool with no output schema, it provides a complete picture: scope (all scripts including templates), return fields, contextLines option, and case sensitivity. It also gives usage context, making it sufficient for an agent to decide when and how to invoke the tool.

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

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

The schema covers 100% of parameters, so baseline is 3. The description adds value by explaining the practical benefit of contextLines ('usually enough to skip a follow-up get_script call') and reiterates the scope of the search, going beyond simple schema repetition.

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 'Search every script in the project... for a substring' with a specific verb, resource, and scope, clearly distinguishing it from siblings like get_script or read_project_scripts. It also specifies the output format ('target/scriptName/lineNumber/line'), 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 says 'Use this whenever you need to answer "where is X used..." before making changes', giving a clear when-to-use directive. It also mentions skipping a follow-up get_script call, providing a practical alternative comparison.

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

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

With no annotations provided, the description carries full burden. It discloses that the operation replaces the current set, explains the empty-array behavior to disable all, and lists valid domains. It does not cover error handling or return values, but for this simple tool the core behavioral traits are well disclosed.

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

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

The description is two sentences, front-loaded with the primary action and followed by essential details on replacement and valid domains. No filler or redundant 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?

This is a low-complexity tool with one parameter. The description covers the action, the replacement behavior, the empty-array edge case, and the valid domain enumeration, making it self-sufficient for an agent to invoke it correctly.

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

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

The schema has a single parameter with a brief description, but the tool description adds a comprehensive list of valid domain names, which the schema lacks. This significantly enhances parameter understanding and correct usage.

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

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

The description clearly states 'Enable a specific set of debug chips on the running play session' with a specific verb and resource. It also distinguishes from sibling tools like clear_debug_logs by focusing on domain configuration and mentions the replacement 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 clear context for use: configuring debug domains on a live session. It does not explicitly name alternative tools or state when not to use, but the replacement semantics and valid domain list imply the intended 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 full disclosure burden and succeeds admirably. It reveals merge semantics, the required version guard for array/map properties, the type-change confirmation requirement, and instructs to read get_object first for _versions. This is rich, actionable behavioral context far exceeding typical tool descriptions.

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

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

The description is a single, well-organized paragraph that fronts the core purpose, follows with example use cases, and ends with critical guard behavior. No filler or redundancy; every clause 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 complex mutation tool with no output schema, the description covers the full action cycle: what it does, when to use it, what guards apply, and the prerequisite read call. This is sufficient for an agent to invoke it correctly, especially with the rich schema parameter descriptions.

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

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

Schema description coverage is 100% with already-detailed parameter docs, so the baseline is 3. The description adds complementary context by explaining the `_versions` source and the merge operation that `properties` performs, which ties parameters to the overall flow without duplicating 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 opens with a specific verb+resource ('Set properties on an object') and enumerates concrete use cases (position, size, visibility, tags, content, dynamics), making its purpose unmistakable. It distinguishes itself from sibling mutation tools by focusing on object property updates rather than cells, scripts, or bulk operations.

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

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

Provides a clear list of when to use ('Use for position, size, visibility, tags, content, dynamics settings'), giving concrete context. Does not explicitly name alternative tools for exclusions (e.g., bulk_set_property for bulk), but the intended scope is 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 provided, the description carries the full burden of disclosing behavioral traits. It usefully reveals that intermediate objects/arrays are auto-created and that siblings remain intact, which are important behaviors. Yet it omits other crucial traits such as the undo/history behavior, version-precondition handling, or permission requirements. The schema's parameter descriptions cover some of these, but the description itself adds only partial transparency.

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

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

The description is two sentences long, front-loaded with the primary action, and packs in the essential use-case distinction without any filler. Every sentence earns its place.

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

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

Given the rich schema (100% coverage) and the fact that this is a mutation tool without an output schema, the description covers purpose and key behavior well. It falters only slightly by not describing return values or failure modes, but the detailed parameter documentation compensates for most of the needed context.

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

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

Schema description coverage is 100%, so each parameter is already well-documented (e.g., path format, prompt verbatim rule, expectedVersion precondition). The description does not add any new parameter semantics; its reference to 'given path' merely mirrors the schema. A baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Set a single nested value at the given path.' It clearly defines the operation and explicitly distinguishes it from the sibling tool set_property, making the tool's purpose unmistakable.

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

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

It provides explicit guidance to prefer this over set_property when changing a single deep-nested field in a DATA prime's value. However, it stops short of describing when not to use it or naming other alternatives like push_value or bulk_set_property, so it's clear but not exhaustive.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action 'Set cell-level properties' without revealing whether properties are merged or replaced, whether validation occurs, or any undo behavior. The prompt parameter description in the schema mentions undo collapsing, but the tool description itself does not communicate this.

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

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

The description is a single, front-loaded sentence that efficiently communicates the core purpose with zero wasted words. Every word contributes to understanding the tool's function, making it appropriately concise and structured.

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

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

Despite a rich schema (100% coverage) and nested properties, the description omits important context such as the undo-history behavior tied to the prompt parameter, the distinction from sibling set_property tools, and any output or error semantics. For a mutation tool with an unusual prompt requirement, the description is too minimal to be fully self-contained.

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

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

Schema coverage is 100% with clear descriptions for all three parameters, so the baseline is 3. The description adds a few property examples (gravity, wind, windAngle) that are already reflected in the schema's example payload, providing minimal additional value beyond the structured 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 'Set cell-level properties like gravity, wind, windAngle, size, or label' clearly identifies the action (set) and resource (cell-level properties), with concrete examples. It does not explicitly differentiate from sibling tools like set_property or bulk_set_property, so it misses the top score for sibling distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives such as set_property or bulk_set_property. It does not mention prerequisites, exclusions, or any specific context, leaving the agent without direction on choosing this tool.

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

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

No annotations are provided, so the description must carry the transparency burden. It warns that update_script would 'silently overwrite' stale baselines and explains how expectedVersion makes failures loud, which covers the main risk. It doesn't disclose return values or permission requirements, but the core behavioral trait (full replacement) is clearly stated.

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?

Three sentences, each earning its place: first states the action, second gives the primary use case and alternative, third advises a safety mechanism. The structure is front-loaded and avoids redundancy.

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

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

For a tool with 7 params and no output schema, the description covers the key decision points: when to use, when to avoid, and how to prevent data loss. It lacks explicit mention of return values, but the schema and sibling context (e.g., get_script for version) fill the gap. Overall it is sufficiently complete for an agent to choose and safely invoke the tool.

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

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

Input schema covers 100% of parameters with rich descriptions, so the baseline is 3. The description adds context around expectedVersion ('stale write fails loudly') and reiterates the danger of overwriting, reinforcing schema meaning. It doesn't introduce new parameter info, but the existing schema descriptions are already strong.

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 'Full-replace a script: writes the supplied code as the new content,' which precisely names the verb and resource. It also distinguishes itself from edit_script by stating it is for genuine rewrites or new slots, not incremental edits.

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 prescribes when to use ('genuine rewrites or to create a new script slot') and when not to ('For incremental edits... prefer edit_script'), and gives safety guidance for full-replace (pass expectedVersion). This is clear, actionable direction with an alternative.

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 transparently explains outcomes: 'Returns detailed error messages with line/column numbers, or confirms valid syntax with a summary of detected events and actions.' This goes beyond the simple verb 'validate' by detailing what happens on success and failure. It does not explicitly state that the operation is non-destructive, but the nature of validation implies it, and the return behavior covers the key aspects.

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

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

The description is two sentences long, front-loaded with the primary action, and every sentence adds value. The first sentence states the core function; the second explains the two possible outcomes, including error details. No wasted words 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?

The tool is simple with only one parameter, and the description fully covers its purpose and behavior. There is no output schema, but the description explains what will be returned in both success and error cases. It also specifies the use of the 'full parser', which is important context for users concerned about validation thoroughness. The description is complete for this tool's complexity.

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

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

The input schema already documents the only parameter ('code') with a clear description, giving 100% schema coverage. The tool description does not add extra meaning about the parameter, but it does not need to because the schema is sufficient. This aligns with the baseline of 3 for high schema coverage.

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

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

The description clearly states the tool's purpose: 'Validate Purl DSL script syntax using the full parser.' This provides a specific verb and resource, distinguishing it from sibling tools like get_script or update_script, which are for retrieval or modification. The addition of 'full parser' and return behavior further clarifies its distinct role.

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 makes the usage context obvious: it is for validating Purl DSL script syntax. While it does not explicitly name alternatives or exclusions, the uniqueness of the task (no other sibling tool validates scripts) makes the intended use clear. No explicit 'when not to use' guidance is provided, but the context is unambiguous.

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