origin-mcp-kimi

by wxxuan2000-gif

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but there is potential confusion among the many plot creation tools (e.g., 'origin_plot' with a 'kind' parameter vs. dedicated 'origin_plot_*' tools) and between 'origin_execute_figure_spec' and 'origin_plan_figure_spec'. Overall, descriptions are clear enough to differentiate.
Naming Consistency5/5
All tools follow a consistent 'origin_verb_noun' pattern (e.g., 'origin_add_calculated_columns', 'origin_plot_scatter'). The naming is uniform and predictable, enhancing usability.
Tool Count3/5
With 63 tools, the server is extensive but covers a complex domain (Origin software). It exceeds the typical 'heavy' threshold (25+), which may be overwhelming, but each tool serves a specific purpose, and the count is reasonable given the breadth of functionality.
Completeness4/5
The tool surface is comprehensive, covering data import, manipulation, multiple plot types, analysis, graph customization, template management, and background tasks. Minor gaps exist, such as no explicit data export tool (other than graph export), but the core workflows are well-covered.
Average 3.1/5 across 63 of 63 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it chooses a route and creates a plot. It discloses no behavioral details such as whether it modifies data, requires user interaction, or how the auto-selection works.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly concise (one sentence) to the point of being insufficient. While it avoids verbosity, it sacrifices necessary information for effective use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (23 parameters, many siblings) and lack of annotations or parameter descriptions, the tool description is severely incomplete. It does not explain what 'choose a chart route' entails or how the output is produced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no meaning to the 23 parameters. The agent cannot infer the role of parameters like path, intent, x_col, or style_mode from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it chooses a chart route and creates a plot, which gives a general sense of the tool's purpose. However, 'chart route' is ambiguous and does not distinguish it from sibling plot tools that also create plots from table data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other plot tools like origin_plot_scatter or origin_plot_line. The description does not specify conditions where auto selection is beneficial or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose what happens if the property is not implemented (error? silent failure?), or any side effects. The action is stated but not its consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it sacrifices meaningful content. It is under-specified rather than efficiently helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no annotations, and no schema descriptions, a one-sentence description is wholly inadequate. The tool’s complexity demands more detail about usage and output (output schema exists but is not referenced).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description does not explain any of the 7 parameters beyond property_name and value. It omits meaning for graph_name, layer_index, plot_index, chart_type, and plot_type_id, leaving the agent without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the verb 'set' and resource 'plot style property', but the phrase 'registry-backed' and 'if it is implemented' are vague. It does not distinguish from sibling tools like 'origin_set_plot_style' or 'origin_format_graph'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The conditional 'if it is implemented' hints at limited applicability but provides no exclusions or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must inform behavioral traits. It only states the basic function, missing details on side effects, required permissions, error conditions, or whether the input range is modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but severely underspecified. It lacks necessary details to be truly concise; instead, it omits important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no schema descriptions, no annotations, and many sibling tools, the one-sentence description is completely inadequate for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only indirectly references two parameters (data_range, template). It does not explain the meaning, format, or defaults of the other six parameters, leaving critical gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a graph from an existing Origin range and template, which is a specific action. However, it does not differentiate from sibling tools like origin_plot or origin_plot_line, which also create graphs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like origin_plot or origin_plot_auto. No when-not-to or prerequisite conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits such as whether it modifies data, requires specific permissions, or has any side effects. With no annotations, the description carries the full burden, but it only says 'Create a plot'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, but it lacks necessary structure and detail. It is too sparse for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (24 parameters, many sibling tools) and no annotations, the description is severely incomplete. It does not provide enough context for an AI agent to select or invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the 24 parameters. It does not explain required fields 'path' and 'intent' or any other parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool creates a plot using chart-atlas intent routing, but 'chart-atlas intent routing' is undefined jargon. It gives a vague sense of purpose without distinguishing from sibling plot tools like origin_plot or origin_plot_auto.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No exclusions or context about 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.
Behavior2/5
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 implies non-blocking queueing but does not disclose whether the task runs asynchronously, what happens on failure, or if there are side effects. This leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks critical details about parameters and behavior. It is not overly verbose, but it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and is a background task, the description should explain what the method is, how parameters influence the task, and what the output represents. It fails to provide this context, making it insufficient 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the tool description does not explain any of the 6 parameters (method, params, host, port, token, timeout). The only hint is 'method' being the bridge method, but no values or usage details are given. The description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (submit) and the resource (Origin bridge method), and specifies it's a queued background task. Among sibling bridge tools, it distinguishes itself as the submission tool, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 bridge tools like origin_bridge_cancel_task or origin_bridge_list_tasks. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It merely states 'Run Origin linear fitting' without explaining whether the operation is destructive, requires specific permissions, modifies the worksheet, or produces output. Key behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is under-specified. The single sentence does not convey essential information about the tool's operation or parameters, making it insufficient for effective use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
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, no annotations, output schema present), the description is severely incomplete. It fails to explain the fitting process, output format, or how parameters like 'options' affect behavior, leaving major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to explain parameter meanings. The description does not reference any of the seven parameters (e.g., worksheet, x_col, y_col), leaving their roles and relationships entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run Origin linear fitting' clearly states the action (Run) and the resource (linear fitting), accurately conveying the tool's purpose. However, it lacks explicit differentiation from sibling tools like origin_nonlinear_fit_structured, which perform similar but distinct operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as origin_nonlinear_fit_structured or origin_run_analysis. The description does not mention prerequisites, context, or exclusions, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'explicit function and parameter hints' but does not disclose any behavioral traits such as side effects (e.g., modifying worksheets), authentication requirements, or error handling. This is insufficient for a fitting tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it sacrifices informative content for brevity. It could be restructured to include key details without significantly increasing length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, no schema descriptions, no annotations), the description is grossly incomplete. It fails to explain return values (despite an output schema), parameter relationships, or typical use cases, leaving an AI agent without sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the 8 parameters. The phrase 'explicit function and parameter hints' vaguely hints at the 'function' and 'initial_params' parameters but provides no concrete details about format, constraints, or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs nonlinear fitting with explicit function and parameter hints, distinguishing it from simpler fitting tools like origin_linear_fit. However, it lacks specificity about what 'explicit function and parameter hints' means in practice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs. alternatives like origin_linear_fit or origin_run_analysis. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'import table data' but does not disclose side effects like graph creation, modification, or data source requirements. Minimal beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise. However, given the tool's complexity (20 parameters), it is somewhat under-specified and could benefit from additional context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 20 parameters, no annotations, and many sibling tools, the description is insufficiently complete. It lacks details on data sourcing, output behavior, and parameter usage, though output schema exists but is not shown.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter explanations. The description adds no meaning to the 20 parameters; it only states the high-level purpose. The agent receives no help understanding parameter roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports table data and creates a box plot, distinguishing it from other plot types like histograms or line plots. However, it could be more specific about the data source (e.g., file vs. existing worksheet).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. There are many sibling plot tools (e.g., origin_plot_histogram, origin_plot_line), but the description does not provide selection criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It only states the basic action without detailing side effects, such as whether the graph is added to an existing worksheet or a new one, what happens on repeated calls, or any data import mechanics. This is insufficient for a tool with 22 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is front-loaded and wastes no words. However, for a tool of this complexity, it is under-specified rather than appropriately concise, sacrificing necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema and high parameter count, the description provides almost no contextual information. It does not explain the import mechanism, graph creation process, return value, or any error conditions. An agent cannot fully understand the tool's behavior from this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and no parameter descriptions in the tool description, the description fails to add meaning beyond the parameter names. Only 'path' is implied by 'import table data'. All other 21 parameters remain unexplained, making it impossible for an agent to know their purpose or valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports table data and creates a column/bar-style graph. It specifies the verb and resource, and the reference to column/bar-style helps distinguish from sibling tools like origin_plot_scatter or origin_plot_line. However, it doesn't explicitly contrast with other plot types or mention any scope limitations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or typical use cases. With many sibling plotting tools, this gap makes it hard for an agent to select the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the responsibility for behavioral transparency. It only mentions importing data and creating a histogram, omitting details like workspace modification, error conditions, or required state (e.g., active worksheet).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence, which is concise but sacrifices necessary detail. It front-loads the core action but lacks structure or additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (20 parameters, many siblings) and lack of output schema explanation (though output schema exists), the description is grossly incomplete. It fails to explain data import sources, parameter roles, or return value, making it insufficient 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no explanation of any of the 20 parameters. The agent receives no help interpreting parameters like 'x_col', 'y_cols', 'delimiter', etc., beyond their names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'create a histogram graph,' specifying the type of plot. However, it does not differentiate from other similar plotting siblings like origin_plot_box or origin_plot_scatter, as it omits the data import aspect which is common to many tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., other plot types) or prerequisites (e.g., data must be in a worksheet). The description merely states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only states the action without any details on side effects, permissions, or behavior. This is insufficient for a tool with 22 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise, but it is overly brief given the tool's complexity. It lacks structure and does not front-load the most critical information (e.g., required path, how to specify data columns).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (22) and many sibling tools, the description is far from complete. It does not explain the input data format, how to select columns, or how this tool differs from other plot tools. The output schema exists but is not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by explaining key parameters like path, x_col, y_cols. It does not. The parameter names in schema provide minimal hints, but the description adds no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb and resource ('Import table data and create a line graph'), but it does not distinguish this tool from sibling tools like origin_plot_line_symbol or origin_plot_scatter, which also create line graphs. The purpose is clear but lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites, context, or when not to use it. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It only mentions importing and creating a graph, but does not disclose side effects, such as whether it modifies existing worksheets, overwrites data, or requires specific permissions. The 22 parameters imply complex behavior not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but too brief for a tool with 22 parameters. It sacrifices completeness for brevity, leaving many aspects unexplained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 22 parameters, 0% schema coverage, and no annotations, the description is highly incomplete. An output schema exists but is not described. The tool's complexity demands a richer description to be usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds no meaning to any of the 22 parameters, many of which relate to data import (e.g., delimiter, encoding, header). It fails to connect the parameters to the import step.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports table data and creates a line+symbol graph. It distinguishes from siblings like origin_plot_line (line only) and origin_plot_scatter (symbols only) by specifying 'line+symbol'. However, it does not clarify what 'table data' refers to (e.g., file or worksheet).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives like origin_plot_line, origin_plot_scatter, or origin_plot_auto. No prerequisites or context provided. The description is too generic to help an agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden but only says it imports and plots. It does not disclose whether it modifies existing graphs, side effects (e.g., overwriting), or what the tool returns. The output schema exists 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single sentence, but it lacks structure for a complex tool. It front-loads the purpose, but does not convey essential parameter info or usage steps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 22 parameters and many sibling plotting tools, the description is severely incomplete. It fails to mention that it can import from various file types, customize axes, or control errors, making it hard for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters but provides none. The one sentence gives no hint about path, columns, or any of the 22 parameters, leaving the agent completely uninformed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports table data and creates a scatter graph, which is a specific verb-resource pair. It distinguishes from sibling plotting tools by specifying 'scatter', but could be more explicit about being the dedicated scatter plot tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like origin_plot or origin_plot_auto. The description does not mention exclusions or preferences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states the basic action (create graph) without revealing effects on data, error conditions, or any side effects. The behavioral context is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single sentence, but it achieves conciseness at the expense of substance. It could be front-loaded with key parameter explanation without exceeding a few sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 20 parameters, an output schema, and a complex task, the description is too minimal. It fails to explain how the tool works, what the output schema indicates, or how parameters interact. The description is incomplete for effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no meaning to any of the 20 parameters. It does not explain what 'plot_type_id' or 'template' represent, nor optional parameters like 'selected_cols' or 'graph_name'. The description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a graph from table data using a Plot Type ID and template, but it does not differentiate from sibling plotting tools like origin_plot or origin_plot_line, which also create graphs from table data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., origin_plot_auto, origin_plot_line). No prerequisites, use cases, or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It does not disclose behavioral traits such as side effects, permissions, error behavior, or output format. The existence of an output schema is not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short but under-specified. It lacks detail needed for effective usage, making it insufficient despite being concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (8 parameters, no annotations, no output schema disclosure), the description is insufficient. It does not explain input data sources, output behavior, or the role of parameters like worksheet, columns, options, etc.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters. It does not explain the meaning or usage of any of the 8 parameters, leaving the agent without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Run' and the resource 'named Origin analysis X-Function' with mechanism 'through LabTalk'. It distinguishes the tool as specific to running predefined analysis functions, but does not explicitly differentiate from siblings like origin_run_labtalk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No when-to-use, when-not-to-use, or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only states the action without mentioning side effects, required graph existence, error handling, or what happens upon success. This is insufficient for a tool with 9 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but at the expense of necessary detail. While not verbose, it fails to include essential information, making it less effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no annotation, many siblings), the description is incomplete. It does not cover prerequisites, return values, parameter relationships, or how it differs from similar tools, leaving significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no meaning about the parameters. It does not explain what each parameter (e.g., worksheet, x_col, y_col) represents or how they interact, leaving the agent to rely solely on parameter names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Add' and the resource 'worksheet X/Y plot to an existing graph layer', clearly identifying the action and target. However, it does not differentiate from sibling tools like origin_plot_scatter or origin_plot, which also add plots, making the purpose less distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as origin_plot or origin_plot_scatter. The description lacks any context about prerequisites, exclusions, or typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits beyond 'browse', such as whether it is read-only, what side effects occur, or permission requirements. The agent has no extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It could be improved by adding bullet points or clarifying the parameter roles.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 optional parameters and an output schema, the description is too brief. It does not specify what the output contains, how to use the parameters effectively, or what constitutes a 'knowledge base' entry. Incomplete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It mentions 'collection and path' but the schema has 'collection', 'topic', and 'version'. There is no explanation of how 'topic' or 'version' relate to a path. This mismatch misleads about the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Browse') and names the resource ('local Origin knowledge base') and mentions parameters ('collection and path'). However, it refers to 'path' while the schema includes 'topic' and 'version', causing slight mismatch. It distinguishes from sibling tools like 'origin_query_knowledge' in name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'origin_query_knowledge'. The description provides no context about which scenarios favor browsing over querying.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'diagnose' which implies read-only, but does not explicitly confirm it is non-destructive, whether authentication is needed, what happens on failure, or any side effects. This lack of transparency is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the key verb and resource. It is efficient and avoids unnecessary words. However, it might be too brief given the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 optional parameters and no annotations or parameter descriptions, the description is insufficient to fully understand the tool's behavior. The presence of an output schema helps a little, but the description does not cover what the tool returns or how parameters affect diagnosis. More context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist. The tool's description does not explain any of the 6 parameters (host, port, token, timeout, status_path, ping_origin). The agent cannot infer what each parameter means or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'diagnose' and names the resource 'Origin bridge' along with aspects (configuration, status file, connectivity). It clearly distinguishes from sibling tools like 'origin_ping' (which is for general connectivity) and 'origin_diagnose_worksheet' (which targets worksheets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites or exclusions. The sibling list includes many tools, and the description does not help an agent decide when to choose 'origin_doctor' over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as read-only nature, side effects, or meaning of 'executable safe setters'. The tool likely reads data, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence without wasted words. It is front-loaded with the core action, but could benefit from structured breakdown of parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two optional parameters with 0% schema coverage, the description should explain how to use them. It does not, and although an output schema exists, the description lacks context about what the report contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides no information about the two optional parameters (chart_type, plot_type_id). It fails to add meaning beyond the schema, leaving users to guess their purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports which style registry entries have executable safe setters. It distinguishes itself from sibling tools like 'origin_set_plot_style' by focusing on coverage rather than setting styles, but does not explicitly contrast with similar tools like 'origin_plot_style_capabilities'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Given siblings include 'origin_plot_style_capabilities', which may be related, the description lacks context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It merely states 'search by keyword' without explaining outcomes, return format, whether it is read-only, or any side effects. Essential behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise in length, but it lacks structure to cover necessary details. It is front-loaded with the core action, but the brevity comes at the cost of completeness. It could be expanded slightly to include parameter context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and an output schema, the description is insufficient. It does not mention what the search returns (despite an output schema existing), how optional parameters affect results, or any limitations. A user would need to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to explain parameters. The description only hints at the 'query' parameter via 'by keyword', but ignores 'collection', 'version', and 'limit'. No meaning is added for these parameters beyond their names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the local Origin knowledge base by keyword. It identifies the verb 'search', resource 'knowledge base', and method 'by keyword'. However, it does not explicitly differentiate from sibling tools like origin_browse_knowledge, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 origin_browse_knowledge. There is no mention of use cases, prerequisites, or how it differs from similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states the tool sets axis properties but does not disclose whether it overwrites existing settings, requires a specific graph state, or has side effects like invalidating other settings. The lack of detail on behavioral traits is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks structure. For a tool with 8 parameters, a bulleted list or more detail would improve usability. It is not wasteful, but it is underspecified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool modifies an existing graph axis and has no annotations, the description is incomplete. It does not mention prerequisites (e.g., a graph must already exist), how layers are identified, or what happens if parameters are omitted. The output schema exists but does not compensate for missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the input schema has no descriptions. The tool description only mentions 'scale, limits, tick step, and title', but there are 8 parameters including graph_name, layer_index, and axis, which are not explained. The description adds minimal semantic value beyond the schema's parameter titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool modifies axis scale, limits, tick step, and title. It distinguishes itself from sibling tools like origin_set_axis_break and origin_format_graph by focusing on axis-specific properties. However, it could be more explicit about modifying an existing graph axis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For instance, it doesn't mention that it should be used after creating a plot, or when to use origin_format_graph instead. The description gives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only says 'list recent tasks' without disclosing behavior like pagination, read-only nature, or what 'recent' means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded with action. However, it could include more detail without becoming verbose; current brevity sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no schema descriptions, no annotations, and an output schema present but unmentioned, the description fails to provide sufficient context for correct tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description does not elaborate on any parameters. Parameter names like host, port, token are left unexplained, so agent lacks semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists recent Origin bridge background tasks, using a specific verb and resource. It distinguishes from siblings like origin_bridge_task_status, though 'recent' is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like origin_bridge_task_status or other sibling tools. The description does not provide context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states 'inspect,' implying a read operation, but fails to mention side effects, error handling, or whether the graph must exist. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no extraneous words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description need not detail return values. However, it lacks parameter semantics and usage guidance, leaving gaps. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter graph_name has no schema description (0% coverage), and the description does not explain its format, purpose, or default behavior. This leaves the agent without crucial context for invoking the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects 'a graph page, its layers, axes, and plots,' using a specific verb and resource. However, it does not differentiate from sibling tools like origin_get_layer_info which inspects a single layer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as origin_get_layer_info or when not to use it. The description lacks any context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'report basic status' without specifying what status means, side effects (e.g., whether it modifies state), or safety profile. The agent cannot infer that this is a safe, idempotent check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but its brevity sacrifices essential information. It is not well-structured; it lacks any breakdown or elaboration. While front-loaded, it is under-specified for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, output schema exists), the description is incomplete. It doesn't explain the parameter or the return value. The output schema may cover returns, but the description fails to clarify behavior, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single boolean parameter 'show' has a default but no description in the schema (0% coverage) and the tool description does not explain its meaning or effect. The agent cannot determine what toggling 'show' does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Connect to Origin/OriginPro and report basic status.' It specifies the resource and a clear outcome, distinguishing it from sibling tools which perform specific operations like plotting or data manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention conditions, prerequisites, or contexts where a ping is appropriate, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It mentions 'validate' and 'return planned operations' but does not disclose side effects, safety, or prerequisites. The agent cannot infer whether calling this tool is safe or has any consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is appropriately front-loaded, though it could benefit from additional context without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, limited parameter description, and existence of an output schema that is not described, the description is incomplete. The agent lacks information on return format, prerequisites, and how this tool fits into a workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single parameter 'spec'. The description adds the term 'declarative FigureSpec' which suggests the expected structure but lacks details on properties or constraints. The parameter is an untyped object with additionalProperties, so the agent has little guidance on how to construct it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates a FigureSpec and returns planned operations, using a specific verb and resource. However, it does not differentiate from siblings like 'origin_execute_figure_spec' which likely executes the spec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling list is extensive, but the description offers no context for selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility for behavioral disclosure. It only states a high-level action without mentioning side effects, permissions, or resource usage. The output schema exists, but the description does not clarify what the output contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. It efficiently conveys the core purpose without unnecessary detail, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, many optional) and the presence of an output schema, the description is too generic. It fails to explain how the parameters relate to 'table shape' or 'column semantics', leaving the agent without enough context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions in the schema. The tool has 15 parameters, but the description only loosely refers to 'table shape, column semantics, and optional intent' without explaining individual parameters like path, intent, x_col, etc. This is insufficient for an agent to correctly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it recommends chart types based on table shape, column semantics, and intent. It uses a specific verb ('recommend') and resource ('chart types'), but does not explicitly differentiate from sibling plotting tools that actually create charts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Given siblings like origin_plot_auto and origin_plot, the description should indicate that this is for recommendation before plotting, but it does not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden for behavioral disclosure. It states execution and optional output capture, but fails to mention potential side effects (e.g., modifying Origin state, destructiveness), error handling, or security implications. The minimal description leaves much unknown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It front-loads the core action and optional output capture. However, it could be slightly expanded to include critical context without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's potential power (executing arbitrary scripts), the description is too sparse. It omits error behavior, return value details (though output schema exists), and usage hints. For a tool with an output schema and simple parameters, more context would aid correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The two parameters (script, capture_log) are hinted at but not fully explained. The description mentions 'script text' and 'optionally return captured output', but does not clarify the format of the script, what capture_log controls (e.g., log vs stdout), or default behavior. This is insufficient for a tool with only two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes LabTalk scripts and can return output. The verb 'Execute' and resource 'LabTalk script text' are specific. However, it does not explicitly distinguish this generic scripting tool from other siblings that perform specific Origin operations, which would warrant a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., origin_run_analysis or other scripting tools). It lacks context about prerequisites, typical use cases, or when not to use it. This is a significant gap for a tool that can run arbitrary scripts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing behavioral traits. It fails to mention whether this is a mutating operation, any side effects, or required permissions. For a tool modifying plot state, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 12 words, efficiently stating the tool's purpose with no unnecessary fluff. It is front-loaded, but could include a bit more context without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, 0% schema coverage, no annotations, and an output schema, the description is insufficient. It omits that graph_name, layer_index, and plot_index are needed to target a specific plot, and provides no details on return value or preconditions. This leaves the agent with significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only lists parameter categories without adding meaningful semantics beyond parameter names. It does not explain valid values, formats (e.g., color as RGB array or string), or constraints, leaving the agent without crucial usage information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool sets line, color, symbol, column/bar gap, and transparency styles on plots, using a specific verb and listing relevant style aspects. It distinguishes from sibling tools like origin_plot (creation) and origin_set_axis (axis settings), though not exhaustively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like origin_set_plot_property or origin_format_graph. The description does not mention prerequisites, such as requiring an existing plot, nor does it provide criteria for choosing among similar styling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether writing appends or overwrites, permissions needed, or side effects like destroying existing data. The output schema exists but is not referenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words, but it lacks necessary detail to be fully useful. It is appropriately sized for the minimal information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, a required output schema, and the complexity of writing rows to a worksheet, the description is insufficient. It fails to explain return values or how parameters interact, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond the schema. It does not explain the purpose of parameters like rows, columns, book_name, sheet_name, start_col, or create, leaving the agent to infer from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Write), the resource (structured rows into Origin worksheet), and mentions the ability to target new or existing worksheets, which differentiates it from read tools like origin_read_worksheet and other write tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives such as origin_import_table or origin_melt_worksheet. There is no mention of prerequisites, exclusions, or specific contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits like safety, idempotency, or potential side effects. It only says 'report,' which implies read-only, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no fluff. It efficiently states the purpose, though it lacks parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the two parameters and an output schema (not shown), the description is too minimal. It does not explain when to set 'show' or 'refresh' or what the output will contain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the 'show' and 'refresh' boolean parameters. With 0% schema description coverage, the description should compensate but fails to add any meaning beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports Origin/originpro versions and runtime feature availability. It is specific and distinguishes from sibling tools which focus on plotting, data manipulation, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives or when not to use it. The description only states what it does, not 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond stating it lists items. It does not clarify whether the operation is read-only, has side effects, or requires any permissions. The description carries the full burden but adds minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. However, it lacks structure for a tool with multiple parameters; a brief listing of parameter groups or hints would be beneficial.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and an output schema, the description should explain how parameters affect the listing (e.g., filtering, pagination). It fails to do so, leaving the tool's behavior ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond the parameter titles. With 7 optional parameters, the lack of any explanation about their usage or filtering behavior makes this dimension severely lacking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'built-in palette names, semantic roles, and source links.' It distinguishes from sibling tools which focus on other functionalities like plotting, data manipulation, or knowledge browsing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention exclusions or prerequisites, leaving the agent to guess the appropriate context for invoking this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states the action and destination. It does not disclose side effects (e.g., creating new workbook), required permissions, size limits, or behavior for edge cases like empty files or unsupported formats. The lack of detail leaves many behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with key information, making it brief. However, it lacks structure such as bullet points or separation of usage and behavior. It could be improved with a slightly more detailed but still concise explanation of parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters, no annotations, and no output schema shown, the description is far from complete. It does not cover common use cases, error handling, or parameter-related guidance. For an import tool, details about encoding, header rows, and data type handling are essential but missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description provides no information about any of the 10 parameters. While parameter names give some hints, they do not explain formatting, usage, or interactions (e.g., how delimiter interacts with TXT files, what encoding options exist). The description fails entirely to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'import' and the resource 'CSV, TSV, TXT, DAT, XLS, or XLSX file' into a 'new Origin worksheet'. It distinguishes from siblings like origin_read_worksheet which reads existing worksheets, and origin_write_worksheet which writes to existing worksheets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when importing a file into a new worksheet, but it does not explicitly state when not to use it or compare to alternatives. It mentions 'new' worksheet, which suggests a constraint, but no further guidance on prerequisites or conflicts with other import-like tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. The description indicates a read operation (non-destructive) but fails to disclose behavior such as authorization requirements, return format details, or what happens if the worksheet is empty or missing. The burden falls entirely on the description, which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Efficient but could benefit from a brief list or separation of key points. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters (none required), no annotations, and an existing output schema (but not described), the description is too minimal. It does not explain the output format or the meaning of 'window' (row range), which is critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 only mentions 'a window' but does not explain parameters like 'book_name', 'sheet_name', 'start_row', 'max_rows', or 'columns'. The schema property names are self-explanatory, but the description adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'worksheet data', specifying 'a window' as the scope. It distinguishes from the sibling 'origin_write_worksheet' and other data manipulation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'origin_diagnose_worksheet' or 'origin_get_graph_info'. The description only states what it does, not when it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It explains the formula syntax but does not mention whether the operation is destructive, reversible, or requires specific permissions. The impact of invalid formulas or cross-sheet references is omitted, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with four sentences, each adding value. The purpose is front-loaded in the first sentence, and the remaining sentences explain the key detail about formula syntax. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and main parameter well but lacks details on error behavior, return values, and full parameter descriptions for book_name and sheet_name. Given that an output schema exists (though not described), the description is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 explains the 'columns' parameter structure and formula syntax, and hints at 'book_name' and 'sheet_name' usage. However, it does not fully describe these optional parameters or their default behavior, providing only partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: adding worksheet columns from LabTalk formulas in batch. The verb 'add' and resource 'worksheet columns' are specific. However, it does not distinguish from sibling tools like origin_write_worksheet or origin_filter_rows, so it loses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description focuses on syntax details rather than usage context. It does not mention when not to use or prerequisites, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It fails to mention important details such as whether the tool overwrites existing files (despite an overwrite parameter), how it resolves conflicts when both active and named graphs are specified, or supported file formats. This lack of transparency hinders correct agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core functionality without extraneous words. It is front-loaded and efficient, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is incomplete for a 3-parameter tool. It does not explain behavior on file conflicts, supported formats, or error handling. Given many sibling tools, more contextual completeness would help an agent choose correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should provide parameter details, but it only mentions 'active or named' graph. It does not explain the 'path' parameter (e.g., file extension, absolute/relative), 'graph_name' behavior (null exports active), or 'overwrite' semantics. Significant gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Export the active or named Origin graph to an image/PDF file,' specifying the verb (export), resource (Origin graph), and output format (image/PDF). This clearly defines the tool's purpose and distinguishes it from sibling tools like origin_view_graph or origin_get_graph_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor does it mention prerequisites or context. It simply states what the tool does without usage recommendations or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates that the tool can operate in-place or write to a new sheet via output_book/output_sheet. However, it does not explicitly state that in-place modification is the default, nor does it describe side effects, data type handling, or error conditions. With no annotations, more detail is needed for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loads the purpose. The list of strategies is presented clearly. It is concise but could be better structured with bullet points or sections for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is incomplete for a tool with 7 parameters and no annotations. It does not explain the role of book_name and sheet_name, the default behavior (in-place vs new sheet), or the format of the columns parameter. Missing these details hinders correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to three parameters: strategy lists allowed values, columns explains scope, and output_book/output_sheet indicate new sheet creation. However, book_name and sheet_name are not explained, and the value parameter is only implied for the 'value' strategy. Given 0% schema description coverage, the description partially compensates but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Handle missing worksheet values' which clearly indicates the tool's domain. It then enumerates strategies, making the purpose specific and distinct from siblings like filter_rows or drop_duplicates. However, 'handle' is somewhat generic, and a more precise verb like 'fill or remove' would improve clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, scenarios, or tool selection criteria. The strategies are listed, but no advice is given on choosing among them or comparing with similar tools like origin_drop_duplicates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It only states the tool lists controls, omitting details like pagination, performance, or side effects. The minimal description leaves important behavioral aspects unknown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that front-loads the action and resource. No unnecessary words, and the structure efficiently communicates the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 documented elsewhere. However, the description does not explain the output's structure or provide enough context for an agent to decide when to use this tool among many similar siblings. It is minimally complete given the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds conceptual meaning by mapping the three parameters to filtering criteria. However, it lacks details on valid values (e.g., what chart types or term formats are acceptable). Baseline reduced due to low coverage but description provides some semantic mapping.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies verb 'List' and resource 'semantic plot style controls', with three filtering criteria (chart type, Plot Type ID, term). This clearly identifies the tool's function and distinguishes it from sibling plotting tools that create or modify plots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'origin_plot_style_setter_coverage' or 'origin_set_plot_style'. The description does not specify prerequisites or contexts where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the burden. It only states two actions but does not disclose side effects, prerequisites, or what 'mark for cancellation' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words, but it combines two actions with 'or' which could be clearer if separated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with no description and an output schema not explained, the description is insufficient for an agent to fully understand usage and return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain the purpose of host, port, token, or timeout. Only task_id is obvious from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Cancel' and the resource 'Origin bridge task', and specifies the two states (queued or running). It differentiates from sibling tools like origin_bridge_list_tasks and origin_bridge_submit_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage from the action of cancellation, but no explicit when-to-use or when-not-to-use, and no mention of alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description is the sole source. It does not disclose behavioral traits such as whether the tool modifies the active graph, whether rescale affects all axes, or potential side effects. The description is minimal and assumes domain knowledge.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 13 words with no redundancy. Front-loads the verb and key objects, efficiently conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 6 optional parameters and an output schema, the description fails to explain context (e.g., tool modifies existing graph, prerequisites like active graph). Lacks information about default behavior and return values, which is critical given the low schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It maps to 5 of 6 parameters: 'graph long name' (graph_name), 'axis labels' (x_label, y_label), 'legend visibility' (show_legend), 'optional rescale' (rescale). However, it omits the 'title' parameter and does not clarify that all parameters are optional with null defaults. Partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'graph' with specific properties (long name, axis labels, legend visibility, rescale). It distinguishes from sibling tools like origin_plot (creates graphs) and origin_set_axis (sets axis properties).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not specify prerequisites (e.g., graph must exist) or exclusions (e.g., use origin_set_axis for axis properties). The description implies use for formatting, but lacks context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. 'Inspect' implies read-only behavior, but no explicit declaration of side effects, permissions, or performance characteristics is given. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It fits within a short summary and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks parameter explanations and behavioral details. For a simple 2-parameter tool with 0% schema coverage, it is minimally complete but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 explain the parameters graph_name or layer_index. The agent must rely solely on schema names and defaults, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Inspect' with resource 'one graph layer' and specifies scope 'its axes and plots', clearly distinguishing it from sibling tools like origin_get_graph_info (whole graph) and origin_set_axis (modification).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions or context, leaving the agent to infer from the sibling list, which is external.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially compensates by noting that unsupported features are reported in the plan instead of being guessed. However, it lacks details on side effects (e.g., whether it modifies existing figures), authentication needs, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core action and follow with a key behavioral detail. Every sentence serves a purpose without extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the 'spec' object parameter and the existence of an output schema, the description does not set expectations for the output or provide enough context for the spec structure. While output schema exists, the description should still hint at what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage, and the description does not explain the 'spec' object structure or the 'dry_run' parameter. It only implies that 'spec' is a declarative figure configuration, which adds minimal value beyond the parameter names from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a declarative FigureSpec and specifies it supports worksheet-backed single-panel and grid multi-panel figures with common plot types. This distinguishes it from sibling plotting tools that target specific chart types or direct plotting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like origin_plot or origin_plot_line. It does not mention when to prefer this declarative approach or any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It discloses that the default behavior is in-place modification and how to write to a new sheet. However, it lacks details on irreversibility, permissions, or error handling. The description adequately covers the mutating aspect but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: first states purpose, second explains subset, third explains keep and output options. It is front-loaded and free of unnecessary words, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality and key parameters, but leaves out source sheet parameters (book_name, sheet_name) and does not mention return value (though an output schema exists). For a data manipulation tool, it is moderately complete but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description compensates partially. It explains subset (default all columns), keep options, and output_book/output_sheet usage. However, it does not describe book_name or sheet_name parameters (source sheet), and the exact format for subset (e.g., list of column names/indexes) is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it removes duplicate worksheet rows. The purpose is specific and distinct from sibling tools like origin_filter_rows (which filters rows by criteria) or origin_melt_worksheet. However, it does not explicitly differentiate from all siblings, but the verb 'drop_duplicates' is self-explanatory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains parameter usage: subset limits columns, keep options (first/last/none), and output_book/output_sheet for new output instead of in-place. It does not provide explicit guidance on when to use this tool vs alternatives like origin_filter_rows for other filtering needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behavior: overwrites source worksheet if no output is specified, otherwise writes to new sheet. Explains condition joining via combine. No annotations provided, so description carries burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that effectively convey the tool's purpose and key parameters. Front-loaded with main action. Could be slightly more structured but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains core behavior and output options, but lacks explanation of source worksheet parameters and does not mention error scenarios or return value. Output schema exists so return details are covered, but the missing parameter explanation reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% so description should explain all parameters. It explains conditions and combine format, and output_book/sheet, but completely omits explaining book_name and sheet_name (the source worksheet identifiers). This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it filters rows from a worksheet based on conditions. Provides specific condition format and operators. Although it doesn't explicitly distinguish from siblings like drop_duplicates, the description is sufficiently specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains condition format and when to use output_book/sheet to avoid overwriting. However, it does not provide guidance on when to use this tool vs other row manipulation tools (e.g., drop_duplicates, fill_missing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the option to write to a new sheet vs. in-place, but does not clarify whether the original worksheet is modified when no output is specified. Missing details on error handling, permissions, or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, covering the main concepts efficiently. It is front-loaded with the core operation first. However, it could be more structured (e.g., separate sections for required vs. optional parameters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (2 required) and an output schema, the description covers the pivot operation but leaves ambiguity about source worksheet specification (book_name, sheet_name vs. output_book/output_sheet). Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains index, columns, values, aggfunc (listing options), and output_book/output_sheet. However, it does not explain book_name and sheet_name parameters, and the values parameter's behavior when null or omitted is unclear. Schema coverage is 0%, so description adds some value but not for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reshapes long data into a wide pivot table, explaining index, columns, values, and aggfunc. However, it does not explicitly distinguish from sibling tools like melt or transpose, though the purpose is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating pivot tables but provides no explicit guidance on when to use this tool versus alternatives (e.g., melt for inverse operation). No when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description states the tool imports table data and creates a graph, implying it opens Origin and may export if export_path is set, but it does not disclose potential side effects, required permissions, or performance characteristics. The statement 'Both lists are required' is a useful constraint but overall transparency is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus a list of plot types) and front-loads the core action. However, it could be better structured by grouping parameters or using bullet points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 21 parameters and an output schema (not shown), but the description covers only three parameters. It fails to explain the data import parameters (path, delimiter, header, etc.) and the return value. For a complex tool, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. However, it only explains y1_cols, y2_cols, and plot_type, leaving 18 other parameters (e.g., path, x_col, book_name, delimiter) undocumented. The description adds minimal meaning beyond the schema for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports table data and creates a double-Y graph, specifying that y1_cols map to left Y axis and y2_cols to right Y axis. It also lists valid plot_type values. This distinguishes it from single-Y siblings like origin_plot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that both y1_cols and y2_cols are required and lists plot_type options, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., origin_plot for single Y). No when-not-to-use or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool reads data (status, result, logs) and implies no side effects, but does not mention what happens if the task does not exist, authentication requirements, or network behavior. Basic transparency but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's function without any fluff. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks explanation of crucial connection parameters (host, port, token, timeout) and does not mention error handling or behavior when the task is not found. Despite having an output schema, the agent is left guessing about setup and failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions task_id, include_logs, log_limit, and include_result, but fails to explain host, port, token, and timeout parameters, which are likely for connection/authentication. These missing semantics hinder correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads status, result, or logs for an Origin bridge background task. It distinguishes this tool from siblings like origin_bridge_cancel_task, origin_bridge_submit_task, and origin_bridge_list_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used to check task progress by reading status/result/logs, but it does not explicitly state when to use it vs alternatives like origin_bridge_list_tasks or origin_bridge_cancel_task. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description indicates it is a read-only, ordered list operation. It lacks details on potential limitations, permissions, or side effects, but is adequate for a simple retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema that covers return values, the description is sufficiently complete for the tool's simplicity. Could mention that it returns all templates without filtering, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds no parameter info, but per guidelines, a baseline of 4 is appropriate when no parameters are present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists saved user templates in reverse chronological order. However, it does not explicitly distinguish from sibling tools like origin_search_templates, which may have similar functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as origin_search_templates or other template-related tools. An agent has no context on why to choose this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses the two modes (release only vs close Origin) and the default behavior. However, it omits side effects (e.g., impact on running tasks, token invalidation) and does not explain the timeout parameter. The description adds value beyond the schema but lacks comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (three sentences) and front-loaded with the primary action. Every sentence adds value, though it could be slightly more structured (e.g., list parameters). No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters with no schema descriptions, no annotations, and an output schema not shown, the description is incomplete. It fails to document most parameters, does not mention the return value or side effects, and lacks guidance on prerequisites (e.g., is the bridge running?). The tool's complexity (many optional connection params) demands more completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in input schema), so the description must compensate. It only explains the close_origin parameter and implies release_origin via the default behavior. The other four parameters (host, port, token, timeout) are not described, leaving their semantics unclear. This is a significant gap for a 6-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stops the Origin GUI bridge from serving requests, distinguishing between releasing the connection (default) and force-closing Origin. This is a specific verb+resource action, and among sibling bridge tools (e.g., origin_bridge_cancel_task), it uniquely addresses shutdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the default behavior (release without close) and the optional close_origin parameter for force-close. It implies this is the tool to use for shutdown, but does not explicitly mention when not to use it or provide alternatives. However, given the sibling names, the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It mentions listing but does not disclose side effects, permissions, rate limits, or that it is read-only. The behavior is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. It is effectively front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema, the description is mostly complete. However, it uses 'common' which may imply incompleteness, and could clarify that the output structure is defined in the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, giving a baseline of 4. The description adds meaning beyond the empty schema by stating what is listed—function names and parameters—which is the tool's sole purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact action ('List') and resource ('common Origin nonlinear fit function names and parameters'), clearly distinguishing it from sibling tools like origin_linear_fit or origin_nonlinear_fit_structured which perform fits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention related tools or contexts where listing fit functions is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It explains the effect (hides a range) but does not mention whether the operation is destructive, reversible, or requires specific permissions. The description lacks clarity on side effects or state changes beyond the break.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the purpose and explains key parameters. It is reasonably concise but could be more compact by combining sentences. No redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers most parameters and the core functionality, but it omits explanation of graph_name and layer_index, which are important for targeting the correct graph. It also does not mention the existence of an output schema (which is present) or any prerequisites. Given the tool's complexity (8 parameters), the description is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema itself has 0% description coverage, but the description compensates by explaining 6 of 8 parameters (break_from, break_to, axis, position, post_break_increment, enabled) with additional context (e.g., position as percent of axis length). However, graph_name and layer_index are not mentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds or removes an axis break on a graph axis. It specifies the action ('Add or remove') and the resource ('axis break on a graph axis'), distinguishing it from sibling tools like origin_set_axis which set axis properties without breaking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding or removing axis breaks but does not explicitly state when to use this tool over alternatives (e.g., origin_set_axis). No guidance on when not to use it or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: it does not redraw the graph, renames specific file types (.otpu/.json/.png) and updates the index. It also reveals the return format for failure cases ('renamed: false' with a reason). This provides adequate transparency for a simple rename operation, though the success return is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point: one sentence for the main purpose, followed by a concise technical note on file operations and return format. Every sentence adds value without redundancy. It is front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 params, output schema exists), the description covers the essential aspects: purpose, affected files, and failure return. It lacks details on success return and prerequisites (e.g., template must exist), but it is largely complete for an agent to understand the operation's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no additional meaning beyond the property names. It does not explain that 'old_name' must be the current template name or that 'new_name' must be unique and valid. For a tool with only two parameters, the description should at least clarify these constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renames a user template, specifying the resource ('saved user template') and the key behavior ('without redrawing the graph'). It distinguishes from sibling tools like 'origin_delete_template' or 'origin_update_template_metadata' by focusing on renaming with a specific non-redraw effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the purpose is clear, it does not mention when to choose rename over other template operations, nor does it indicate constraints like the template must exist or not be in use. The description implicitly suggests usage for renaming but lacks comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses transposition mechanics, label_column effect, and in-place vs new sheet behavior. However, with no annotations, it omits error handling, data type constraints, or uniqueness requirements for label_column. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences followed by explanatory details. Every sentence adds value, no redundancy, and front-loaded with main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers transposition behavior and output options, but lacks detail on constraints (e.g., unique label_column), data type handling, or differentiation from similar sibling tools. Output schema exists, so return details are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, description adds meaning for label_column and output_book/sheet, but does not explain book_name or sheet_name. Partial improvement over schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Transpose a worksheet so rows become columns' with specific verb and resource. It further explains the role of label_column and output options, distinguishing it from siblings like origin_melt_worksheet and origin_pivot_worksheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage through description of behavior and output options, but no explicit when-to-use or when-not-to-use guidance compared to sibling tools. Lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions that by default the worksheet is modified in place, but provides option for new sheet. It does not explicitly warn about destructive nature (overwriting original data) or other side effects like ignoring unsupported data types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences and efficiently conveys the main purpose and key parameters. It could be more structured (e.g., separate sections for parameters and behavior) but is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no schema coverage and no annotations, the description covers the essential transformation and output options but lacks details like default behavior when value_vars is null, handling of non-numeric columns, and the exact role of book_name/sheet_name as input identifiers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains id_vars and value_vars roles, and the output parameters, but does not clarify the default values for var_name and value_name, nor the difference between book_name/sheet_name vs output_book/output_sheet.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reshapes wide data into long format (unpivot), and explains the roles of id_vars and value_vars. This is specific and distinguishes it from the sibling 'origin_pivot_worksheet' which does the opposite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the core transformation and the optional output parameters for writing to a new sheet, implying when to use vs. in-place modification. However, it does not explicitly state when to choose this tool over alternatives like pivot_worksheet or other transformation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description conveys key behavioral traits: placement as percentages, zoom capability via x_start/x_end/y_start/y_end, and auto-scaling. It adds context beyond basic purpose but does not cover prerequisites or effects on the original graph.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear front-loaded purpose sentence followed by two sentences of essential details. Every sentence adds value, no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, no annotations, and no output schema details visible, the description covers the core workflow but omits prerequisites (e.g., graph must exist), error handling, and the return value (though output schema exists). It is adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 explains the roles of left, top, width, height, worksheet, x_col, y_cols, and the zoom parameters, but does not describe graph_name or plot_type. This provides moderate but incomplete semantic enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds an inset (small embedded layer) to an existing graph, with specific verb 'add' and resource 'inset'. It distinguishes from siblings like origin_add_plot_to_graph by specifying it's an embedded sub-layer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for adding a magnified detail view or a small embedded plot, and explains zooming options. However, it does not explicitly state when to use this tool versus alternatives like origin_add_plot_to_graph or the various origin_plot_* tools, nor does it mention 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.
Behavior4/5
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 deletion scope, index removal, and failure behavior (returns deleted: false with reason not_found). Could mention permanence, but the verb 'delete' implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and zero unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description adequately covers the deletion scope and error case. However, it omits the success return value (likely deleted: true), which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter description coverage, and the description does not add any parameter-specific meaning. It does not explain the format, case-sensitivity, or source of the template name, leaving ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'saved user template', specifying exactly what files are deleted (.otpu/.json/.png) and the effect (drop from index). This distinguishes it from sibling tools like rename_template or save_graph_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use or avoid this tool, nor does it mention alternatives. It implies usage for deleting templates, but lacks guidance on prerequisites (e.g., template existence) or caution about irreversibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the tool is a parameterized entry point and lists valid kinds, but does not disclose side effects, auth requirements, or error behavior. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states purpose, second gives usage context, third lists kinds and references. Concise, front-loaded, but the list of kinds is long and could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description doesn't explain return values. It covers kind but not other parameters. For a tool with 7 params, it lacks completeness in parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to explain parameters. It only adds meaning for 'kind' by listing valid values; other 6 parameters (path, selected_cols, graph_name, title, export_path, style_mode) are unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a table-based plot selected by 'kind'. It lists many plot kinds and distinguishes itself from dedicated sibling tools like origin_plot_line and origin_plot_scatter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (compact profile, generic entry) and when not to (use dedicated tools for line/scatter/column/histogram/box, use origin_plot_matrix_id for matrix-range plots), specifying alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It explains the storage location and basic function but does not mention side effects (e.g., overwriting existing templates), permissions, or whether the graph remains unchanged. The 'overwrite' parameter is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. The first sentence states purpose, and the second paragraph adds relevant usage details. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters and an output schema, the description could be more complete. It explains the main workflow but leaves out important parameters like 'graph_name' and 'overwrite'. It also does not differentiate from similar siblings like origin_update_template_metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must explain parameters. It mentions 'plot_types', 'roles', and 'n_columns' for search metadata, and 'name' as required. However, it omits 'graph_name', 'description', 'tags', and 'overwrite', which are not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: saving a finished graph as a reusable template. It explains how to reuse it later and provides context on metadata. This distinguishes it from siblings like search, delete, or update metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context: how to reuse the template in plotting tools and how to populate metadata for searchability. However, it does not explicitly state when not to use this tool or contrast it with siblings like origin_update_template_metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses ranking criteria, return structure (score, match_reasons), and empty list behavior. However, it does not address permissions, side effects (though likely none), or detailed behavior like whether it modifies state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences covering purpose, ranking, return format, and empty case. Front-loaded with key action. Slightly redundant but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 optional parameters, no schema descriptions, and an output schema (not shown), the description explains return values (score, match_reasons) and emptiness. It could elaborate on how to apply the template, but the sibling tools fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds meaning by linking parameters to ranking criteria: 'plot type' (plot_type), 'data shape' (n_columns inferred), 'tags' (tags), 'keywords' (query). However, limit is not explained, and query format is not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the user template library for matching templates, ranks them, and returns scores. It specifies the context ('before plotting') and distinguishes from siblings like origin_list_user_templates and origin_save_graph_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this before plotting to reuse a matching style', providing clear usage context. However, it does not explicitly mention when not to use it or provide alternatives, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the tool's behavior: it reports per-column stats and structured issues at three severity levels (error, warning, info), explains the high_missing_threshold parameter, and clarifies the 'passed' flag. The tool is likely read-only, and the description transparently describes its diagnostic output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 covered. However, the description omits explanations for three of four input parameters (book_name, sheet_name, columns), which is a significant gap for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It only describes one parameter (high_missing_threshold) explicitly. The other three parameters (book_name, sheet_name, columns) are not described, leaving their meaning and usage unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check worksheet data quality before plotting or analysis.' It details the specific reports (per-column dtype, missing count/fraction, unique count) and structured issues, which distinguishes it from other tools like origin_read_worksheet or origin_plot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used before plotting or analysis, but does not explicitly state when not to use it or provide alternatives. The context is clear, but exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers partial update behavior, no file modification, and a specific failure return (updated: false, not_found). Adds value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the purpose and behavior, with no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers update behavior, failure case, and relationship to sibling tools. Lacks explicit success return details, but output schema is present, so not critical. Adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description mentions example fields (tags, description, matching hints) and partial update behavior. However, it does not detail all six parameters (e.g., plot_types, roles, n_columns), leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it edits a saved template's searchable metadata, using the verb 'Edit' and specifying the resource. It distinguishes from siblings like 'rename_template' and 'delete_template' by noting no file modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises using this tool to fix tags, description, or matching hints without re-saving, and implies not for renaming or deletion. Omitted fields are left untouched, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the concatenation behavior, axis effect, and output behavior (overwrite vs new sheet). However, it does not mention potential side effects, data type alignment issues, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with no wasted words. Uses technical terms succinctly (SQL UNION ALL) and front-loaded structure: verb first, then parameters and options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, reducing the need to explain return values. The description covers all six parameters, axis behavior, and output writing. Slight gaps remain about default behavior of axis and handling of invalid inputs, but overall adequate for a moderately complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description adds substantial meaning: it explains 'others' as a list of book/sheet objects, axis options with SQL UNION ALL analogy, and output parameters for avoiding overwrite. This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool concatenates worksheets, specifies the primary worksheet and others, and explains two axis options. It distinguishes from siblings like origin_merge_worksheets by detailing specific behavior (rows vs columns stacking).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides guidance on when to use rows vs columns and mentions output options to avoid overwriting. However, it does not explicitly advise against using this tool when other concatenation or merge tools might be more appropriate, nor does it list prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses that the left worksheet is overwritten by default unless output_book/output_sheet are provided, which is a key behavioral trait. However, it does not mention error handling, permissions, or side effects beyond overwriting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs with clear structure: purpose first, then left/right, keys, how, and output. Every sentence adds value without redundancy. It is front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a database-style merge with 10 parameters, the description covers all essential aspects: source worksheets, key options, join types, and output behavior. It is sufficient for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains all major parameters: left worksheet (book_name/sheet_name), right worksheet (right_book/right_sheet), key specification (on, left_on, right_on), join type (how), and output location (output_book/output_sheet). It adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a database-style merge of two worksheets on key columns, using specific verbs and resources. It distinguishes itself from sibling tools like origin_concat_worksheets by specifying the join operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to specify keys (on or left_on/right_on), the default behavior when omitted, and the how parameter options. It provides clear context for use, though it does not explicitly state when not to use it or list alternatives beyond the implicit contrast with concat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the full lifecycle: renders to temporary PNG, returns as image content block with text summary, deletes temp file. It also explains the side effect of max_width controlling token costs. Since no annotations exist, this is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: first sentence states purpose, second contrasts with sibling, third gives usage, fourth explains a parameter, fifth notes a prerequisite. No wasted sentences; each adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the return value (image content block + text summary) and the temporary file deletion. It covers behavior, parameters, usage, and constraints, making the tool's context complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly explains 'max_width' purpose: bounds pixel width to keep image and token cost small. 'graph_name' is implied by the tool's purpose but not detailed further. With 0% schema coverage, the description adds significant meaning, though graph_name could be clearer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool renders an Origin graph as an image for the model to see, distinguishing it from the sibling tool 'origin_export_graph' by noting it leaves no file behind. The verb 'render' and resource 'graph' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use it to visually verify a plot and iterate on it.' It also contrasts with 'origin_export_graph' and notes the requirement for a vision-capable client, indicating when not to use (if client lacks vision). The context of iteration is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![origin-mcp-kimi MCP server](https://glama.ai/mcp/servers/wxxuan2000-gif/origin-mcp-kimi/badges/card.svg)](https://glama.ai/mcp/servers/wxxuan2000-gif/origin-mcp-kimi)

Score Badge

Copy to your README.md:

[![origin-mcp-kimi MCP server](https://glama.ai/mcp/servers/wxxuan2000-gif/origin-mcp-kimi/badges/score.svg)](https://glama.ai/mcp/servers/wxxuan2000-gif/origin-mcp-kimi)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wxxuan2000-gif/origin-mcp-kimi'

If you have feedback or need assistance with the MCP directory API, please join our Discord server