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

With no annotations, the description carries the full behavioral burden. It communicates that the tool is a read operation and discloses the important nuance that returned values reflect Origin's current state, not whatever the caller previously set. This is genuinely useful 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 short and front-loaded: the first sentence states the action and object, and the second provides a concrete motivating use case. Every sentence earns its place with 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 description covers the tool's purpose and when to use it, and an output schema exists to document return values. However, with three parameters and zero schema-level parameter descriptions, the missing guidance on axis and layer semantics leaves the definition incomplete for an agent that needs 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?

Schema description coverage is 0%, and the description only vaguely references 'an axis' without explaining the axis, graph, or layer parameters. It does not clarify valid axis values, what layer means in Origin, or how to identify the target graph. The description fails to compensate for the schema's complete lack of parameter documentation.

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

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

The description opens with a specific verb and resource: 'Read an axis's scale and range as Origin currently holds them.' This clearly identifies it as a getter and distinguishes it from sibling tools like origin_axis_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 explicitly advises using this tool before setting a range, noting that Origin's rescaling may have changed the actual value. This gives clear contextual guidance, though it does not explicitly name the alternative tool or state when not to use it.

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

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

With no annotations provided, the description carries full responsibility and excels: it discloses clamping/rounding of axis ranges, the internal axis swap for horizontal bar charts, and the fact that `matches_request` is a genuine verification. These are non-obvious and valuable behavioral details.

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

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

The description is dense but well organized: purpose first, then parameter behavior, then important caveats. Every sentence contributes useful information without unnecessary 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 complex tool with 8 parameters and no annotations, this description covers the essential guide: scope, real validation behavior, saturation effects, and a subtle internal axis-swapping hazard. It is complete enough for an agent to use 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 0%, so the description must compensate. It adds concrete meaning for `scale` by listing valid names, explains that omitted arguments are untouched, and warns about axis semantics in bar charts. It could go further on `graph`, `layer`, `start`, `end`, and `increment`, but the core parameters are well clarified.

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 an axis's scale, range or title, and read back what Origin holds.' This clearly distinguishes it from read-only siblings like origin_axis_get and from plot-style setters like origin_plot_option_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 gives clear context, such as 'Omitted arguments are left alone' and 'Unlike plot styles, these read back from the same properties Origin draws from.' It does not explicitly list alternative tools or when to prefer them, but the usage context is strong.

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 the handshake-file mechanism, the modal-dialog UI-thread stall, the measured consequence, and the semantic difference between announced and answering. This is far beyond what the schema alone could convey.

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 minimal but front-loads the core purpose and every sentence earns its place. The measured example is arguably extra, but it reinforces why the announced/answering distinction matters for correct usage.

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 simple status check with one optional parameter, and the description covers its key behavioral nuance and parameter semantics. An output schema exists, so the description need not explain the return structure. Nothing critical is missing 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?

The schema gives no description for check_liveness (0% coverage), but the description fully explains it: 'Pass check_liveness=False to skip the request when the answer does not matter.' This adds real meaning beyond the bare boolean type and default 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?

States a specific verb and resource: 'Report where the bridge is, and whether it is actually answering.' The description immediately distinguishes two separate questions ('announced' vs 'answering'), which also helps separate this tool from sibling tools like origin_ping. The core purpose is unmistakable.

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

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

Provides clear context about when the status matters and explicitly instructs when to skip the liveness check: 'Pass check_liveness=False to skip the request when the answer does not matter.' It does not name an alternative tool directly, but the announced-vs-answering distinction gives the agent enough context to select this tool appropriately.

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 disclosure burden. It reveals that Origin may store values without acting on them, that the result only reports the intended write location rather than success, and that expGraph says almost nothing about failure. This is substantial, honest 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 concise and front-loaded with the core purpose. The second paragraph adds valuable caveats without unnecessary padding; 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?

The description covers purpose and failure behavior well, and an output schema exists to explain return values. However, with no annotations and zero parameter descriptions, the agent still lacks enough detail about how to correctly specify graph, filename, directory, and width.

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 0%, so the description needed to explain the parameters, but it does not clarify graph, width, filename, or directory semantics. It only hints that filename/directory are the write destination, leaving the agent to infer how to populate the required fields.

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 opening sentence, 'Export a graph to a PNG,' states a specific verb and resource and clearly distinguishes this tool from siblings like origin_plot or origin_graph_info. The added context about verifying style changes reinforces its unique 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 explicitly identifies when to use this tool: it is 'the only way to find out whether a style change did anything.' It does not explicitly list when-not-to-use scenarios or alternative tools, but the 'only way' framing provides strong usage direction.

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

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

With no annotations present, the description carries the full burden, and it discloses a key behavioral trait: writes to group-member plots are refusedassed. It adds meaningful context beyond the schema by explaining the group_mode consequence. It falls short of a 5 because it doesn't mention return shape or explicit side-effect/purity, though the output schema partially covers return 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?

Two tight sentences with the core purpose front-loaded. The second sentence adds a genuinely useful behavioral detail, but the phrase 'with the addresses styling needs' is slightly awkward and could be clearer. Still, no wasted 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?

With an output schema present and only one parameter, the description covers the why-to-use and key behavioral consequence. It is reasonably complete, though the styling-refusal behavior could be elaborated slightly. The primary gap is the undocumented 'graph' parameter format, which affects completeness.

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

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

Schema coverage is 0% and the description does not clarify what the 'graph' parameter should be — name, ID, path, or handle. The tool name implies a graph identifier, but the description adds no format or resolution details beyond the schema, leaving the field ambiguous.

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

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

The description states a specific action (list) and resource (a graph's layers and plots), and notes it also carries styling addresses. This distinguishes it from sibling tools like origin_plot_option_get (targeted option retrieval) and origin_axis_get (axis outcomes), so an agent can clearly differentiate it.

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

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

Explicitly instructs to 'check here before trying to style one', providing a concrete when-to-use directive tied to the refusal behavior. This is actionable guidance that tells the agent to call this tool before attempting write operations, clearly distinguishing it from write-oriented 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 it delivers: it explains that `returned` only means parsed/dispatched, not that anything happened; it discloses that scripts stop at the first bad expression and the last captured line indicates progress; and it warns that Origin's own error text cannot be captured. It also explains the Python refusal with the in-flight-command reason.

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 relative to the complexity of an escape-hatch tool, and every sentence contributes: purpose, use preference, return-value meaning, failure behavior, and a critical limitation. The first line is a clear summary, and the details are front-loaded in order of importance.

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 use guidance, result interpretation, error behavior, and refused script types, which is strong for a general-purpose tool. The one notable gap is explicit handling of the `capture_output` parameter, especially since the schema provides no explanation for it.

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

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

The schema has 0% description coverage, so the description must compensate. It adds meaningful semantics for `script` by explaining execution behavior, failure mode, and Python restriction. However, it never explicitly describes `capture_output` or how it affects the returned result, so the compensation is incomplete.

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: 'Run a LabTalk script inside Origin and return what it printed.' It also positions itself as 'the escape hatch' and tells the agent to prefer dedicated tools, which distinguishes it from the many sibling tools without needing to open their 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?

It explicitly says to 'prefer a dedicated tool where one exists' because this tool 'cannot check its own work,' giving clear when-to-use versus when-not-to-use guidance. It also states that Python-starting scripts are refused and why, which further constrains appropriate usage.

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

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

With no annotations, the description must disclose behavioral traits. It clearly indicates the operation is a mutation (adds a layer) and explains the return index's importance due to the graph possibly already having layers. However, it does not mention potential failure modes, permissions, or side effects beyond the addition. The key behavioral insight about the index is valuable, but the description could be more thorough.

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

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

The description is two sentences with no wasted words. The first sentence states the action and return value; the second provides rationale and context. It is well-structured and front-loads the essential information, though it could be slightly improved by adding parameter context.

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

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

The tool is simple, but the description omits critical context such as what the 'graph' parameter represents, any preconditions (e.g., graph must exist), and error behavior. While the return-index explanation is useful, the description lacks sufficient guidance for an agent to use the tool correctly without additional assumptions.

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 0%, and the description does not elaborate on the 'graph' parameter. It only says 'to a graph,' which is vague and doesn't explain what format or identifier the string should take. Given the single parameter, the description should clarify how to specify the graph, but it fails to do so, leaving the agent to infer from context.

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

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

The description clearly states the action: 'Add a layer (a panel) to a graph' and explicitly mentions the return value 'report which index it got.' The verb and resource are specific, and the description differentiates from siblings by focusing on layer addition, even if not naming alternatives. It is slightly less explicit than a 5 because it doesn't explicitly contrast with 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?

No guidance is provided on when to use this tool versus alternatives. The description explains why the index return matters but does not mention any conditions, preconditions, or alternative tools. An agent receives no context about when to invoke this tool over other layer-related operations.

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

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

With no annotations provided, the description must carry the full behavioral burden. It does disclose an important behavior: a grid too small is refused because it would omit a layer. However, it does not state whether the operation is destructive, whether it returns a success/error object, or what the resulting grid layout implies for existing layers. Partial but not complete.

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, with the primary action front-loaded and a relevant constraint in the second sentence. Every sentence contributes; there is no fluff. Slightly reduces score because it does not hint at parameter meaning, but the structure itself is clean.

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 three required parameters with zero schema documentation, and no output schema details provided to the agent, the description is insufficient. It does not explain how rows/columns map to the grid, what the 'graph' identifier refers to, or the tool's effect on existing layers. The single constraint is helpful but overall the agent lacks enough context 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?

The schema descriptions are absent (0% coverage), and the tool description provides no meaning for 'rows', 'columns', or 'graph'. An agent cannot infer likely data types (graph is presumably a reference, rows/columns positive integers), units, or acceptable ranges. This is a significant gap that prevents correct invocation without external knowledge.

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 (lay out) and the resource (a graph's layers) as a grid of panels. It distinguishes the tool from siblings that export, create, or set graph properties, though it does not explicitly name alternatives. The exclusion of the 'too small' case adds specificity, 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?

There is no guidance on when to use this tool versus other graph manipulation tools like origin_plot, origin_layer_add, or origin_axis_set. The description does not mention common scenarios, prerequisites (e.g., graph exists), or exclusions. A single sentence about the refusal condition hints at a constraint but does not help an agent choose this tool over 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?

No annotations are provided, so the description carries the full burden. It explains that the legend is generated from plots and that calling after plot changes refreshes it, which is useful behavioral context. However, it does not explicitly state that the rebuilt legend overwrites any existing legend, though this is implied by 'rebuild'.

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, comprising two sentences with no unnecessary fluff. It efficiently conveys the core action, the rationale, and the key parameter 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?

Given the tool's simplicity and the absence of an output schema, the description adequately covers what an agent needs to know: what it does, when to call it, and the meaning of the main parameter. There are no related legend tools among siblings, so no confusion arises.

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

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

The schema provides no descriptions for parameters, and the description only explains the 'position' parameter's allowed values. The meanings of 'graph', 'layer', and 'show' are not explicitly described, though they may be inferred from typical Origin usage. This leaves some ambiguity for an agent.

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

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

Clearly states the tool's purpose: to rebuild a layer's legend, with optional placement or hiding. The description distinguishes it from siblings by focusing on legend management, which no other tool handles.

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

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

Explicitly advises calling this after adding plots, which is the primary use case. It also implies the legend is derived from current plots, giving a clear when-to-use signal, even though there is no alternative legend tool to contrast with.

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

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

Annotations are absent, so the description carries the full burden. Where the description explains that the tool 'answers even when originpro is broken', a behavioral trait that is non-obvious from the name and critical for failure-recovery reasoning. The ping semantics also imply a non-destructive read, though the description does not state explicitly that it has a side effects (minor for a 0-param heartbeat 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?

Two sentences, no filler. The core operation is front-loaded in the first sentence, and the second sentence adds a high-value behavioral criterion (works when originpro is broken) that justifies the entire purpose. Nothing earned 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 0-parameter tool with an output schema, the description is largely sufficient: it says what the tool does, what it reports, and when it works. The remaining gap is selection clarity — an agent could hesitate between origin_ping and origin_bridge_status because the description never distinguishes them or routes to one over the other.

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 per the rubric the baseline is 4. The description needs no parameter-level detail; the far-end report is the only input/output relevant information, and the tool is invocable with no arguments.

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

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

The description gives a specific verb+resource ('Check the bridge is reachable') and states what the tool reports ('report what is on the far end'), making the plumbing immediate. It does not explicitly distinguish itself from the origin_bridge_status sibling, though 'Answers even when originpro is broken' hints at the differentiation without naming 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?

Usage context is only implied: the line 'which is when it matters most' signals that this tool is valuable during failure scenarios, so an agent can infer it is the right choice when Origin is broken. There is no explicit when-to-use or when-not-to-use guidance relative to origin_bridge_status or the other origin_* 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?

Since no annotations exist, the description must carry full weight. It discloses important behavioral details: the new layer is not the active one (so graph and layer must be used), plots_in_layer is read back from Origin, plot_type accepts names or numeric IDs, and columns can be indexes or short names. This is thorough, though error conditions and side effects are not addressed, which is acceptable for a plotting 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 organized into clear paragraphs, each addressing a distinct aspect: core purpose, the graph parameter workflow, plot_type flexibility, column input format, and return-value usage. It is efficient for the amount of information conveyed, neither overly verbose nor cryptic.

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 (7 parameters, 0% schema coverage), the description is quite complete. It explains the return values (graph and layer), when to use them, multi-panel construction, and parameter nuances. The only omissions are explicit details on 'book' and 'sheet' semantics, but these are inferable and the output schema likely covers return fields. Overall, the description equips an agent to call the tool correctly.

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

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

Schema description coverage is 0%, so the description must explain parameters. It covers x, y, graph, group, and plot_type in detail (e.g., columns as indexes or short names, grouping behavior, plot_type flexibility). However, 'book' and 'sheet' are not explicitly described; their meaning is only implied by context. This is a minor gap but overall the description adds significant semantic value beyond the bare 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 the core operation clearly: 'Plot worksheet columns into a graph layer, and return the graph and layer.' It uses a specific verb ('plot'), a resource ('worksheet columns'), and a target ('graph layer'). This is easily distinguished from siblings like origin_plot_option_set or origin_layer_add, which have different purposes.

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 for both new graphs and adding panels to existing ones, mentioning the multi-panel workflow with origin_layers_arrange. It clarifies the graph parameter behavior but does not explicitly contrast this tool with alternatives (e.g., when to use origin_plot vs. origin_layer_add). The usage context is strong, though explicit exclusions are absent.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It clearly states the operation is a read ('Read') and gives concrete examples of options and their semantics. It also warns about the risk of using invalid options. However, it doesn't describe potential side effects (none expected), error cases, or return format, but the output schema covers the return. Overall adequate.

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

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

Two sentences, front-loaded with the core purpose, then a crucial usage hint about option names and the companion tool. No fluff, highly efficient.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that 'option' is a LabTalk token, gives examples, warns about invalid names, and directs to origin_set_options. It doesn't explain return format, but an output schema exists. The parameter semantics for graph/plot/layer are left implicit, though likely inferable from the context of Origin data plots. Overall quite complete but not exhaustive.

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 has no descriptions (coverage 0%), so the description must compensate. It explains the 'option' parameter well, giving examples and warning about guessabilityemanding reference to origin_set_options. However, it does not explain the semantics of 'graph', 'plot', and 'layer' parameters, leaving the agent to infer they refer to plot identification. Some compensation, but incomplete.

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 reads a LabTalk set option from a data plot, with a specific verb ('Read') and resource ('data plot'). It differentiates from sibling origin_plot_option_set by focusing on read versus set, and names the companion tool origin_set_options for discovering valid options. This makes the purpose unambiguous and distinct.

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

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

The description explicitly instructs to use origin_set_options to find option namesaine a non-obvious set, and warns that invented options are accepted but ineffective. This provides clear when-to-use and when-not-to-use guidance, effectively distinguishing this read tool from its set counterpart.

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 does this exceptionally well: it explains that readback reports whether Origin stored the value, warns that Origin stores unrecognized options so a matching readback is necessary but not sufficient evidence, tells the caller to render the graph to confirm visible changes, and discloses that group writes are refused because of misleading readbacks. This is far beyond generic 'sets a value' language.

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 and then adds three dense, high-value caveats: readback semantics, readback_means caution, and group refusal. Every sentence earns its place; no filler or repetition. Despite three paragraphs, the total length is appropriate for the behavioral nuance it needs to convey.

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

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

Even though an output schema exists and rich behavioral caveats are provided, the input side remains under-specified. With no parameter descriptions, no enums, and no examples, the description does not give an agent enough grounding to confidently construct valid calls. The behavioral warnings are excellent, but they do not compensate for the missing parameter semantics.

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 0%, so the description must compensate, but it does not explain the meaning or accepted formats of graph, layer, plot, option, or value. It references a 'LabTalk set option' and a 'plot inside a group,' but gives no examples or enumeration of valid option names, value ranges, or how to address plots in groups. The agent is left to guess the exact parameter values it should supply.

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 object: 'Set one LabTalk `set` option on a data plot, and read it back.' This clearly identifies the tool as a setter for plot options and distinguishes it from the sibling getter origin_plot_option_get. It also communicates the unusual read-back behavior, so there is no confusion about what the tool accomplishes.

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 a clear raison d'être: set one plot option and read back the result. It also gives an explicit when-not condition: writing to a plot inside a group is refused. It does not name sibling alternatives directly, but the setter/getter pairing with origin_plot_option_get is strongly implied by the tool names and the action described.

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 this is a lookup operation (not a mutation), warns about the risk of guessing, and explains the `verified` field as indicating whether an option has been tested against a real Origin. This goes beyond a simple 'searches options' statement and sets accurate expectations about reliability. It doesn't contradict any annotations (since none exist).

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, with the purpose stated first, followed by contextual warnings and a useful note about the `verified` field. Every sentence contributes value; there is no filler. It could potentially add a line about parameter usage, but the current length is appropriate.

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

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

The tool has an output schema, so return values are presumably documented there. With only two optional parameters and no required ones, the missing parameter semantics are the main gap. The description covers purpose, usage context, and reliability, but leaves parameter details unexplained. For a lookup tool with this complexity, the description is moderately complete but not fully self-sufficient.

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

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

The schema has zero description coverage, so the description must compensate for the parameters. It does not explain `limit` or `search` at all. While the names are somewhat self-explanatory, the description doesn't specify how `search` matches (e.g., by control name, option value, or what the option controls). The description says 'look up ... by what they control,' implying search matches by the thing it controls, but this is not explicit. This is a significant gap given 0% 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 states exactly what the tool does: 'Look up LabTalk `set` options by what they control.' It names the resource (LabTalk set options) and the action (look up), and the added context about unguessable names clearly distinguishes this from sibling tools like origin_plot_option_get/set, which deal with plot options rather than general set options.

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 advises using this tool instead of guessing option names, which is practical usage guidance. It also explains the consequence of guessing (Origin accepts and ignores plausible names). It doesn't explicitly name alternative tools, but the sibling set includes plot option tools which are clearly different in scope. The guidance is clear and context-rich, though it could have been more explicit about when not to use it.

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

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

There are no annotations, so the description carries the behavioral burden. It usefully discloses that the tool does not read worksheet contents and returns descriptive metadata only. It stops short of stating behavior on missing worksheets or confirming the absence of 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?

Two sentences with no filler; the core purpose is front-loaded and the active-worksheet note is placed second. Every clause earns its place.

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

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

The output schema covers return structure, so the description need not explain it. With only two optional parameters, the active-worksheet behavior is stated, and the metadata scope is explicit, making the definition complete for this simple tool.

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

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

The schema has no parameter descriptions, but the description adds key semantics: omitting both arguments targets the active worksheet. The titles 'Book' and 'Sheet' plus the tool's context make the remaining mapping reasonably clear.

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: 'Describe a worksheet' with concrete metadata delivered (size, column names, formats). The qualifier 'without reading it' distinguishes it from the sibling origin_worksheet_read, making its purpose unambiguous.

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

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

It gives a practical invocation rule: omit both arguments to target the active worksheet. It doesn't explicitly name alternatives or when-not-to-use conditions, but the 'without reading it' contrast implies the read sibling would be used when cell data is needed.

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

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

With no annotations provided, the description carries the full burden and does so exceptionally. It discloses that an unreadable portion causes refusal rather than silent truncation (because a truncated answer looks like a short worksheet), that row counts are returned separately to avoid ambiguity, and that dates come back as Julian day numbers. These are subtle, high-risk behaviors an agent must know to use the tool safely.

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, then layers behavioral caveats in order of importance. Every sentence earns its place—the refusal rule, the window guidance, the row-count separation, and the Julian-date warning are all substantive. It is slightly longer than strictly necessary but has no 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?

For a 5-parameter tool with no annotations and 0% schema description coverage, the description covers the non-obvious semantics thoroughly. An output schema exists, so return values do not need explanation. The only minor gap is explicit guidance on what 'book' and 'sheet' refer to, but those are reasonably inferable from the tool family.

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 0%, so the description must compensate. It adds real meaning for start_row and max_rows by explaining the windowing idiom and the semantic consequences of the no-truncation rule. book, sheet, and columns are left to the schema, but they are self-explanatory enough that the marginal value of explaining them is low. Coverage of the riskiest parameters is good.

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 ('Read worksheet columns as lists') and the native format Origin holds them in. This clearly distinguishes it from siblings like origin_worksheet_info (metadata) and origin_worksheet_write, though it does not explicitly name them.

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

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

The description gives explicit guidance on when to use start_row/max_rows to take a deliberate window, and advises reading rows_in_sheet and rows_after_window. It also warns about date/time columns coming back as Julian numbers and defers conversion choices. What it lacks is explicit exclusion of alternatives among siblings, but the usage direction is strong.

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

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

With no annotations, the description carries the burden and adds meaningful behavioral context: format is deliberately not inferred, guessing can quietly corrupt columns, and dates must be Julian day numbers. It does not state overwrite/append behavior, but the key data-integrity warning is valuable.

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 every sentence earning its place: the core write action, the column schema, the rationale for explicit formats, and the date encoding requirement. 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?

It covers the complex column format semantics and date behavior sufficiently, but it omits target-worksheet semantics (book/sheet) and start_col placement, and does not clarify whether writing replaces or appends columns. For a 4-parameter tool with no annotations, this is a minimum-viable description.

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 0%, so the description must compensate. It thoroughly explains the 'columns' element shape and valid format values, but says nothing about 'book', 'sheet', or 'start_col', leaving those parameters reliant on their names and defaults.

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

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

The description opens with a specific action and resource: 'Write columns into a worksheet.' It also provides concrete column structure and format strings, making the tool's role unmistakable and clearly distinct from worksheet read/info 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?

No explicit when-to-use or when-not-to-use guidance is provided, and no sibling alternatives are named. The description implies writing use but does not distinguish it from origin_set_options or origin_worksheet_read for an agent deciding between tools.

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