origin_plot

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.