The origin-mcp server lets AI assistants programmatically control Origin/OriginPro on Windows for data handling, visualization, analysis, and application management.
Connectivity & Bridge Management
Ping Origin, query capabilities, and diagnose bridge configuration
Start/stop the bridge, submit background tasks, monitor/cancel/list task status
Data Import & Worksheet Management
Import CSV, TSV, TXT, DAT, XLS, and XLSX files into worksheets (with options for headers, encoding, delimiters, and missing values)
Read and write data to/from new or existing worksheets
Plotting & Visualization
Create 2D plots: line, scatter, line+symbol, column/bar, histogram, box plots
Create graphs from files or existing Origin data ranges using Plot Type IDs or templates
Auto-select the best chart type (origin_plot_auto) or get chart recommendations based on data shape and intent
Add plots to existing graph layers
Graph Customization & Export
Inspect graph pages, layers, axes, and plots
Set axis scale, limits, tick steps, and titles; format titles, labels, and legends
Style plots: line style/width, color, symbol kind/size, transparency; apply preset styles (e.g., "Nature-style")
Export graphs as images or PDFs
Analysis
Run Origin X-Functions: fitting, smoothing, integration, peak finding, descriptive statistics, interpolation, normalization, t-tests, FFT/IFFT, and correlation
Execute arbitrary LabTalk scripts directly inside Origin
Knowledge Base
Browse and search the local Origin documentation by collection and keyword
Controls Origin/OriginPro on Windows for importing data, editing worksheets, creating and refining graphs, running analyses, exporting figures, and managing the Origin application lifecycle.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@origin-mcp Import sample_data.csv and plot column A vs B as a line graph"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
origin-mcp is a local Model Context Protocol (MCP) server that lets AI
assistants control Origin/OriginPro on Windows. An authenticated local bridge
runs inside Origin so automation stays on its UI thread. The project is still
in testing; real-workflow feedback and contributions are welcome.
Import, edit, transform, and export worksheet, matrix, image, and connector data.
Create and refine 2D, 3D, contour, statistical, and specialized plots.
Run fitting, signal processing, statistics, Peak Analyzer, and batch workflows.
Manage projects, folders, Notes, templates, analysis operations, and graph layouts.
Build publication figures with reusable templates, palettes, and an optional Nature-style preset.
Related MCP server: OriginLab MCP Server
You need Windows, a licensed Origin/OriginPro installation, and Python 3.10+ for the MCP server. Origin 2026/2026b is the current target family; the bridge uses the Python bundled with Origin.
Install the MCP server:
pip install origin-mcpAdd the MCP server to your client (use the absolute python.exe path if
python points to another environment):
{
"mcpServers": {
"origin": {
"command": "python",
"args": ["-m", "origin_mcp"]
}
}
}Install the Origin Start/Stop Apps, follow the short registration guide, then click Origin MCP Bridge Start once per Origin session:
origin-mcp install-origin-app --forceVerify the bridge and live Origin connection:
origin-mcp status
origin-mcp doctor --ping-originBoth diagnostic commands support --json. For manual bridge startup or
troubleshooting, see the bridge guide.
To let an AI agent install and configure origin-mcp, send it this instruction:
Fetch and follow https://raw.githubusercontent.com/Ge-Shun/origin-mcp/main/docs/agentic/origin-mcp-bootstrap.md end to end.
From a checkout, install with pip install -e . and run the full local gate:
python scripts/dev_check.py --testsThe bridge listens only on 127.0.0.1 and authenticates local requests by
default with a per-session token. Treat the token as a credential, keep its
handshake file in a user-private directory, and avoid
ORIGIN_MCP_BRIDGE_NO_AUTH unless every local process is trusted. Set
ORIGIN_MCP_ALLOWED_ROOTS to restrict which files tools may access.
MIT. See LICENSE.
Cancel a queued Origin bridge task or mark a running task for cancellation.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Optional Origin bridge host override. Normally omit to use configured localhost. | |
| port | No | Optional Origin bridge TCP port override. Normally omit to use the handshake value. | |
| token | No | Optional bridge authentication token override. Normally omit to use the handshake. | |
| task_id | Yes | Background task identifier returned by origin_bridge_submit_task. | |
| timeout | No | Bridge request timeout in seconds; null uses the configured default. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It only says 'cancel' or 'mark for cancellation' without detailing side effects, whether cancellation is immediate, or what happens to the task state. This lacks depth for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and covers both queued and running scenarios. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and high schema coverage, the description is adequate but minimal. It could mention prerequisites (e.g., task must exist) or error states, but the current text suffices for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description adds minimal value by linking task_id to origin_bridge_submit_task, but does not enhance understanding of host, port, token, or timeout beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels or marks for cancellation an Origin bridge task, using specific verbs 'Cancel' and 'mark'. It distinguishes from sibling tools like origin_bridge_submit_task and origin_bridge_task_status by focusing on cancellation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description distinguishes between queued and running tasks, providing some context. However, it does not explicitly state when to use this tool versus alternatives (e.g., checking status first via origin_bridge_task_status) or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent Origin bridge background tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Optional Origin bridge host override. Normally omit to use configured localhost. | |
| port | No | Optional Origin bridge TCP port override. Normally omit to use the handshake value. | |
| limit | No | Maximum number of matching or recent records to return. | |
| token | No | Optional bridge authentication token override. Normally omit to use the handshake. | |
| timeout | No | Bridge request timeout in seconds; null uses the configured default. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states it lists recent tasks. Does not disclose side effects, authentication requirements, or pagination behavior. Returns an output schema, but behavioral details are minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise and front-loaded with the action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with full schema coverage and an output schema, the description is complete enough. It provides the necessary context for an agent to understand its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The tool description adds no additional meaning beyond stating the list operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recent Origin bridge background tasks, which is specific and distinguishes it from sibling tools like cancel, submit, and status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., origin_bridge_task_status for a single task, origin_bridge_submit_task to create). Lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask the Origin GUI bridge to stop serving requests.
By default this releases the Origin automation connection without closing
Origin itself. Set close_origin=True to force-close Origin as part of
shutdown.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Optional Origin bridge host override. Normally omit to use configured localhost. | |
| port | No | Optional Origin bridge TCP port override. Normally omit to use the handshake value. | |
| token | No | Optional bridge authentication token override. Normally omit to use the handshake. | |
| timeout | No | Bridge request timeout in seconds; null uses the configured default. | |
| close_origin | No | Whether bridge shutdown should also force-close the Origin application. | |
| release_origin | No | Whether bridge shutdown should release its Origin automation connection. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It accurately describes that the tool releases the automation connection by default and can force-close Origin when close_origin=True. This covers the key behavioral aspects, though it omits details about error handling or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences with no superfluous information. It front-loads the main action and provides additional detail in the second sentence, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (all optional) and an output schema, the description adequately covers the essential behavior and the key parameter (close_origin). It does not explain return values, but the output schema likely handles that. The description is complete enough for an agent to understand the tool's core functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so the baseline is 3. The description adds some context beyond the schema by explaining the default behavior for close_origin and the release action, but it does not substantially enrich the parameter meanings beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to ask the Origin GUI bridge to stop serving requests. It uses specific verbs ('stop serving') and distinguishes itself from sibling tools like origin_bridge_submit_task or origin_bridge_list_tasks, which are clearly different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the default behavior and how to force-close Origin via close_origin=True, but it does not explicitly state when to use this tool instead of alternatives, nor does it provide exclusions or prerequisites. Usage guidance is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a supported Origin bridge method as a queued background task.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Optional Origin bridge host override. Normally omit to use configured localhost. | |
| port | No | Optional Origin bridge TCP port override. Normally omit to use the handshake value. | |
| token | No | Optional bridge authentication token override. Normally omit to use the handshake. | |
| method | Yes | Allowlisted Origin bridge method to run as a background task. | |
| params | No | Keyword arguments passed to the selected allowlisted bridge method. | |
| timeout | No | Bridge request timeout in seconds; null uses the configured default. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only hints at asynchronous execution ('queued background task') but does not disclose side effects, authentication requirements, error handling, or whether it is destructive. This is insufficient for a task submission tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It efficiently conveys the core action, though it could benefit from slightly more structure (e.g., front-loading key constraints).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite output schema existing, the description lacks important context: valid methods, task lifecycle, error handling, and how to retrieve results. Given the complexity (6 parameters, no annotations), more complete context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with adequate parameter descriptions. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('submit') and resource ('supported Origin bridge method') and indicates the result is a 'queued background task', distinguishing it from sibling tools like cancel or list tasks. However, it could be more explicit about the nature of 'Origin bridge' and the queuing behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., submitting directly). There are no prerequisites, error conditions, or mentions of other bridge task management tools among the listed siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read status, result, or optional recent logs for an Origin bridge background task.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Optional Origin bridge host override. Normally omit to use configured localhost. | |
| port | No | Optional Origin bridge TCP port override. Normally omit to use the handshake value. | |
| token | No | Optional bridge authentication token override. Normally omit to use the handshake. | |
| task_id | Yes | Background task identifier returned by origin_bridge_submit_task. | |
| timeout | No | Bridge request timeout in seconds; null uses the configured default. | |
| log_limit | No | Maximum number of recent background-task log records to return. | |
| include_logs | No | Whether to include recent background-task log records in the response. | |
| include_result | No | Whether to include a completed background task's result payload. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'Read' suggesting non-destructive behavior, but does not disclose potential behaviors like error handling, blocking nature, or prerequisites. The description is too brief to convey behavioral traits beyond the basic read action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. The key information is front-loaded. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and an output schema, the description is minimal. It does not explain parameter interdependencies (e.g., log_limit effect when include_logs is false) or scenarios. However, the presence of an output schema reduces the need to describe return values, keeping the score at a mid level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description does not add new meaning beyond what the schema already provides for each parameter. It mentions 'status, result, or optional recent logs' which aligns with include_result and include_logs, but the schema covers those details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' and clearly identifies the resource as 'status, result, or optional recent logs for an Origin bridge background task'. It effectively distinguishes from sibling tools like origin_bridge_cancel_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.
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. It does not mention prerequisites (e.g., after submitting a task) or when not to use it. The description implies checking task status 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.
List knowledge collections or browse one collection by slash-delimited path.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Slash-delimited entry path within the collection, for example analysis/workflow. Omit to list the collection's immediate children. | |
| version | No | Optional Origin documentation version filter, such as 2026b. | |
| collection | No | Knowledge collection. Omit to list collections; allowed names are in the schema. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 indicates read-only behavior ('List' and 'browse') but does not disclose edge cases (e.g., invalid path) or failure modes. Acceptable for a listing tool but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 10-word sentence that immediately conveys the purpose without wasted words. It is front-loaded with the primary action and succinctly covers both listing and browsing modes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high schema coverage and the presence of an output schema, the description sufficiently explains the tool's core functionality. It could mention result format or pagination, but the output schema likely covers that. Minor omission but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with each parameter having a descriptive comment. The tool description adds context about slash-delimited paths, but the schema already explains the 'topic' parameter similarly. Baseline 3 is appropriate as the description adds marginal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists knowledge collections or browses a collection by slash-delimited path. It uses a specific verb ('List' and 'browse') and resource ('knowledge collections'), and implicitly distinguishes from sibling tools like origin_query_knowledge which queries content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: omit collection to list collections, provide collection to browse. However, it does not explicitly state when not to use the tool or mention alternatives among siblings, leaving some ambiguity for complex scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report runtime capabilities; set show only to change Origin visibility.
| Name | Required | Description | Default |
|---|---|---|---|
| show | No | Whether Origin should be visible after connecting or querying capabilities. | |
| refresh | No | Whether to bypass cached capability data and query Origin again. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the full burden of behavioral disclosure. It discloses that setting 'show' changes Origin visibility, implying a side effect beyond reporting. However, it omits details about read-only nature, output format, or other potential impacts, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 12 words. Every word contributes meaning, with no redundancy or fluff. It efficiently conveys the primary purpose and a key behavioral note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), return values are covered. The description covers the core purpose and one parameter effect, but lacks context about typical usage, relationship to siblings, and what 'runtime capabilities' entails. It is minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described in schema), so baseline is 3. The description adds value for 'show' by explaining its effect on Origin visibility, but provides no extra context for 'refresh'. Overall, the addition is marginal but positive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports runtime capabilities, with a specific verb ('report') and resource ('runtime capabilities'). It also notes a secondary effect of the 'show' parameter. While it doesn't explicitly differentiate from sibling tools, the unique purpose is implied by the name and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs. alternatives. There is no mention of prerequisites, typical use cases, or conditions under which this tool is preferred over sibling tools like 'origin_ping' or 'origin_query_knowledge'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check worksheet data quality before plotting or analysis.
Reports per-column dtype, missing count/fraction, and unique count, plus structured issues: empty_worksheet and all_null_column (error), high_missing and duplicate_columns (warning), non_numeric_column and constant_column (info). high_missing_threshold is the missing fraction (0-1) that triggers a high_missing warning. "passed" is false when any error-severity issue is found.
| Name | Required | Description | Default |
|---|---|---|---|
| columns | No | Column names or zero-based column indexes selected for this operation. | |
| book_name | No | Origin workbook name. Omit to use the active workbook or the tool default. | |
| sheet_name | No | Origin worksheet name. Omit to use the active sheet or the tool default. | |
| high_missing_threshold | No | Missing-value fraction from 0 through 1 that triggers a high_missing warning. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses expected outputs: column stats, issue list with severities, and 'passed' flag. It details threshold behavior and issue triggers, though it could mention read-only nature explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a front-loaded purpose statement. Every sentence adds information—no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description adequately covers behavior and expected results. It could mention that the tool is read-only, but overall it is complete for a diagnostic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds value by explaining high_missing_threshold range and the meaning of 'passed' false, going beyond the schema's basic parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks worksheet data quality before plotting or analysis, listing specific reports (dtype, missing, unique) and issue types. This distinguishes it from sibling tools like origin_read_worksheet and origin_plot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use 'before plotting or analysis', providing clear context. However, it does not mention when not to use or list alternatives, though no sibling tool has similar purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diagnose Origin bridge configuration, status file, and connectivity.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Optional Origin bridge host override. Normally omit to use configured localhost. | |
| port | No | Optional Origin bridge TCP port override. Normally omit to use the handshake value. | |
| token | No | Optional bridge authentication token override. Normally omit to use the handshake. | |
| timeout | No | Bridge request timeout in seconds; null uses the configured default. | |
| ping_origin | No | Whether diagnostics should also make a live request to Origin. | |
| status_path | No | Optional bridge status-file path override used by diagnostics. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions diagnosing connectivity but does not specify whether the tool makes live requests (though ping_origin parameter hints at this), requires authentication, or is read-only. The behavioral traits are under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence of 8 words, front-loading the purpose with no extraneous detail. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 optional parameters and an output schema, the description is quite minimal. It does not explain the output format or the optional behavior like ping_origin. While output schema reduces burden, the tool's overall diagnostic flow is not fully conveyed, leaving gaps for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description. The tool description adds no additional meaning beyond listing the areas (configuration, status file, connectivity), which maps to parameters. Baseline 3 is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Diagnose' and clearly identifies the resource as 'Origin bridge configuration, status file, and connectivity'. This distinguishes it from sibling tools like origin_ping (simple ping) and origin_bridge_* (task management), providing a clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies diagnostic use through the name 'doctor' and the listed areas, but it does not explicitly state when to use this tool versus alternatives like origin_ping or other bridge tools. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a declarative FigureSpec.
The current executor supports worksheet-backed single-panel and grid multi-panel figures with common plot types. Unsupported features are reported in the plan instead of being guessed.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | Declarative FigureSpec describing data, layout, plots, style, export, and QA. | |
| dry_run | No | Validate and plan the operation without changing the Origin project. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 mentions supported features and that unsupported ones are reported in the plan, but lacks details on side effects (e.g., project modification), blocking behavior, or error handling. For a complex tool, this 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with purpose, and avoids redundancy. It earns its place, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the input schema (nested objects, many options), the description is too sparse. It does not explain the tool's lifecycle, return values (though output schema exists), or how it integrates with other tools like origin_plan_figure_spec. More guidance would significantly improve usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes both parameters adequately (spec as 'Declarative FigureSpec...', dry_run as validation without changes). The description adds minimal semantic value beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes a declarative FigureSpec, distinguishing it from planning tools like origin_plan_figure_spec. The verb 'execute' combined with the resource 'FigureSpec' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use cases for generating figures from specs, but does not explicitly state when to use this tool over siblings like origin_plan_figure_spec or origin_export_graph. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the active or named Origin graph to an image/PDF file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Filesystem path consumed or produced by this tool; see the tool description. | |
| width | No | Export width in pixels; zero preserves Origin's default export width. | |
| overwrite | No | Whether an existing output file may be replaced. | |
| graph_name | No | Origin graph page name. Omit to use the active graph or create a new page. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It does not disclose behavioral details such as what happens if the file exists (handled by overwrite parameter but not described), how file format is determined, or the effect on the Origin graph. The mention of 'create a new page' for graph_name is in the schema but not in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information. Very concise, though it could incorporate more usage guidance or behavioral context without losing brevity. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered. The description lacks context on the export process, file format handling, and interaction with the active graph. Adequate for a simple tool but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The description does not add additional meaning beyond the schema; it merely restates the overall purpose. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (Export), resource (Origin graph), and output format (image/PDF). It distinguishes from siblings like origin_view_graph (viewing) and origin_format_graph (formatting). The verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for exporting graphs to files but provides no explicit guidance on when to use this tool vs alternatives (e.g., origin_format_graph for in-memory formatting) or when not to use it. 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.
Set graph long name, axis labels, legend visibility, and optional rescale.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Optional graph page long name. | |
| rescale | No | Whether to rescale graph axes after formatting. | |
| x_label | No | Optional X axis title. | |
| y_label | No | Optional Y axis title. | |
| graph_name | No | Optional graph page name. | |
| show_legend | No | Set legend visibility when provided. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits, but it only lists what can be set. It doesn't explain side effects (e.g., rescale behavior), whether it modifies in-place, or if the graph must be active. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Could be slightly more structured but appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complexity is moderate (6 params, output schema present), but description is minimal. No mention of return value, no guidance on when rescale is needed, and no explanation of formatting effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds a summary grouping of parameters but no new constraints or interdependencies beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets graph long name, axis labels, legend visibility, and optional rescale. It distinguishes from sibling tools like origin_export_graph or origin_plot by focusing on formatting an existing graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mention of prerequisites (e.g., graph must exist) or context like 'use after plotting'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a graph page, its layers, axes, and plots.
| Name | Required | Description | Default |
|---|---|---|---|
| graph_name | No | Origin graph page name. Omit to use the active graph or create a new page. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full burden. It only states 'Inspect', implying read-only, but does not disclose potential creation of a new page when graph_name is omitted (as hinted in the parameter description). This omission reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly stating the purpose without any extraneous words. It is optimally concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema present), the description is adequate but misses contextual details like default behavior (active graph vs. new page) and what the output contains. The parameter description fills some gaps, but the tool description alone is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The tool description adds no further meaning beyond what the schema already provides for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Inspect') and identifies the resource ('graph page, its layers, axes, and plots'), clearly distinguishing it from siblings like origin_view_graph (view) and origin_export_graph (export).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., origin_view_graph for rendering, origin_browse_knowledge for knowledge queries). The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import a CSV, TSV, TXT, DAT, XLS, or XLSX file into a new Origin worksheet.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to a CSV, TSV, TXT, DAT, XLS, or XLSX file. | |
| nrows | No | Maximum number of data rows to read. | |
| header | No | Zero-based row number to use as column names. | |
| encoding | No | Optional text file encoding. | |
| skiprows | No | Rows to skip while reading. | |
| book_name | No | Optional Origin workbook name. | |
| delimiter | No | Delimiter for text files. If omitted, CSV/TSV defaults or auto-detection are used. | |
| na_values | No | Additional missing value markers. | |
| sheet_name | No | Optional Origin worksheet name. | |
| excel_sheet | No | Excel sheet name or zero-based index. Ignored for text files. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It states the tool imports into a 'new' worksheet, yet parameters like book_name and sheet_name suggest existing workbooks/worksheets can be specified, creating ambiguity. No mention of side effects, file existence requirements, error handling, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and object, with no extraneous words. It efficiently communicates the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no annotations, but with an output schema), the description is insufficiently complete. It omits any mention of return values, error conditions, behavior when files or sheets don't exist, or the relationship between parameters like book_name and the 'new' worksheet claim.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 10 parameters with descriptions (100% schema coverage), so the description adds no extra parameter-level meaning. Baseline 3 is appropriate; the description lists file types which partially reinforces the path parameter but does not deepen understanding of other parameters like encoding or na_values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: importing specific file formats (CSV, TSV, etc.) into a new Origin worksheet. It uses a specific verb ('Import') and resource ('Origin worksheet'), effectively distinguishing it from sibling tools like origin_read_worksheet or origin_write_worksheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for importing external data files into a new worksheet but provides no explicit guidance on when to use this tool versus alternatives, such as origin_read_worksheet for reading existing data or origin_write_worksheet for writing data. No when-not or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to Origin/OriginPro and report basic status.
| Name | Required | Description | Default |
|---|---|---|---|
| show | No | Whether Origin should be visible after connecting or querying capabilities. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behaviors. It mentions connecting and reporting status, but does not specify what status includes or side effects (e.g., making Origin visible via 'show' parameter). Adequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient sentence with no wasted words, but could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool, full schema coverage, and existence of an output schema, the description is largely complete. Only missing details about the status report format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the tool description does not add extra meaning beyond the schema's parameter description. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool connects to Origin/OriginPro and reports basic status, which is a distinct purpose from sibling tools that perform specific operations like task management or plotting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, but the purpose is straightforward and implies use for connectivity checks before other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a declarative FigureSpec and return the planned Origin operations.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | Declarative FigureSpec describing data, layout, plots, style, export, and QA. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose important behavioral traits: side effects (none, but not stated), resource requirements, or error handling. The word 'validate' 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but may be too brief for a tool with a complex input schema. It earns its place but lacks structured detail like bullet points or sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the FigureSpec and the absence of annotations, the description is incomplete. It does not explain the return format (planned operations), validation behavior, or potential errors. An output schema exists but its content is not leveraged.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds only generic phrasing ('Declarative FigureSpec describing data, layout, plots, style, export, and QA'), which adds minimal insight beyond the schema field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a FigureSpec and returns planned Origin operations, distinguishing it from execution-oriented siblings like origin_execute_figure_spec. The verb 'validate' and noun 'FigureSpec' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., execute vs plan), no prerequisites or conditions for use. The description provides no when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a table-based plot selected by kind.
A single parameterized entry point for common table plots and the Plot Type
ID routes that each also have a dedicated origin_plot_* tool. For the
common line/scatter/line_symbol/column routes, selected_cols uses the
first column as X and the remaining columns as Y. A one-column selection is
treated as Y-only. Matrix-range plots still use origin_plot_matrix_id.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Table plot kind. The schema lists every compact-route kind supported by this tool. | |
| path | Yes | Filesystem path consumed or produced by this tool; see the tool description. | |
| title | No | Optional Origin page long name or graph title. | |
| graph_name | No | Origin graph page name. Omit to use the active graph or create a new page. | |
| style_mode | No | Graph styling policy: origin_default preserves the Origin template; nature applies the origin-mcp scientific preset. | origin_default |
| export_path | No | Optional output path for exporting the created graph. | |
| selected_cols | No | Column names or zero-based indexes to include in the plot. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses how selected_cols maps columns (first as X, rest as Y, one-column as Y-only), but does not address potential side effects like overwriting existing graphs, permissions, or rate limits. Moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with six sentences, front-loading the core purpose, and each sentence provides necessary context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 params, 2 required, many kinds) and presence of output schema, the description covers key usage aspects and behavioral details. Minor gap: no mention of whether plots are created on new or existing graphs (addressed partially in graph_name param).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds significant value beyond schema by explaining how selected_cols interprets column order (X vs Y), which is not detailed in the parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a table-based plot selected by kind, uses specific verb 'Create' and resource 'table-based plot', and distinguishes itself from sibling tools like dedicated origin_plot_* tools and matrix plot routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool vs dedicated origin_plot_* tools (single parameterized entry point) and mentions that matrix-range plots still use origin_plot_matrix_id, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect table columns, select a suitable chart route, and create the plot.
Provide intent when the desired comparison or relationship is known.
Otherwise the router uses column types, cardinality, and selected X/Y/Z or
error columns. Use origin_recommend_chart first when no graph should be
created yet.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to a CSV, TSV, TXT, DAT, XLS, or XLSX file. | |
| nrows | No | Maximum number of data rows to read. | |
| title | No | Optional graph page long name. | |
| x_col | No | Column name or zero-based index to use as X. Defaults to the first column. | |
| z_col | No | Optional Z column for contour/XYZ plots. | |
| header | No | Zero-based row number to use as column names. | |
| intent | No | Optional natural-language chart intent used to guide automatic routing. | |
| y_cols | No | Column names or zero-based indexes to plot as Y. Defaults to all non-X columns. | |
| x_label | No | Optional X axis title. | |
| y_label | No | Optional Y axis title. | |
| encoding | No | Optional text file encoding. | |
| skiprows | No | Rows to skip while reading. | |
| book_name | No | Optional Origin workbook name. | |
| delimiter | No | Delimiter for text files. If omitted, CSV/TSV defaults or auto-detection are used. | |
| na_values | No | Additional missing value markers. | |
| graph_name | No | Optional Origin graph page name. | |
| sheet_name | No | Optional Origin worksheet name. | |
| style_mode | No | Graph styling policy. origin_default/template/theme/none preserve Origin template defaults; nature applies origin-mcp styling after plotting. | origin_default |
| excel_sheet | No | Excel sheet name or zero-based index. Ignored for text files. | |
| export_path | No | Optional graph export path. | |
| x_error_col | No | Optional X error column. | |
| y_error_col | No | Optional Y error column. | |
| palette_name | No | Optional registered color palette name used by the selected style mode. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool inspects columns, selects chart route, creates plot, and uses intent or column properties. However, it does not mention potential side effects (e.g., modifying workbook), permissions, or failure cases. Adequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, then usage guidance. No unnecessary words. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 23 parameters and output schema present, the description covers core behavior and usage. It lacks details on error handling or return values, but output schema likely covers that. Good overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. The description adds marginal value: explains intent role and default for y_cols. Baseline 3 is appropriate since schema already documents parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Inspect table columns, select a suitable chart route, and create the plot.' It names specific verb+resource (inspect, select, create) and distinguishes sibling tool origin_recommend_chart by advising to use it first when no graph should be created.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use origin_recommend_chart first when no graph should be created yet.' Also explains when to provide intent parameter and how the router works. Provides clear context for using this tool vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the local Origin knowledge base by keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of matching or recent records to return. | |
| query | Yes | Keyword query matched against local knowledge titles, summaries, and bodies. | |
| version | No | Optional Origin documentation version filter, such as 2026b. | |
| collection | No | Optional knowledge collection filter; allowed names are in the schema. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral disclosure. It does not mention that results may include recent records if no match, order, pagination, or whether the search is case-sensitive. Critical behavioral details from schema (like default limit) are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose concisely. It is appropriately sized for a simple tool but could benefit from additional detail without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of 4 parameters and an output schema, the description is too minimal. It does not explain search semantics, result ordering, or filtering behavior, which are important for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-documented. The description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Search the local Origin knowledge base by keyword,' which clearly identifies the action (search), resource (local knowledge base), and method (by keyword). However, it does not differentiate this tool from the sibling 'origin_browse_knowledge', which likely serves a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'origin_browse_knowledge' or other search tools. The description lacks context on prerequisites, use cases, or 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.
Read a window of Origin worksheet data as structured rows.
| Name | Required | Description | Default |
|---|---|---|---|
| columns | No | Column names or zero-based column indexes selected for this operation. | |
| max_rows | No | Maximum number of worksheet rows to return. | |
| book_name | No | Origin workbook name. Omit to use the active workbook or the tool default. | |
| start_row | No | Zero-based worksheet row at which reading begins. | |
| sheet_name | No | Origin worksheet name. Omit to use the active sheet or the tool default. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions 'read' but does not clarify idempotency, side effects, or access requirements. The description is too brief for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, front-loaded. Could be slightly more descriptive about the return format, but efficiency is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and an output schema, the description is too minimal. It does not explain 'structured rows', row limits, or behavior when parameters are omitted. More context needed for a data-reading tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with full parameter descriptions. The description adds no additional meaning beyond schema; baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and resource ('Origin worksheet data as structured rows'), clearly distinguishing it from siblings like origin_write_worksheet and origin_diagnose_worksheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives; lacks context for when not to use or prerequisites. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend chart types from table shape, column semantics, and optional intent.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to a CSV, TSV, TXT, DAT, XLS, or XLSX file. | |
| nrows | No | Maximum number of data rows to read. | |
| x_col | No | Column name or zero-based index to use as X. Defaults to the first column. | |
| z_col | No | Optional Z column for contour/XYZ plots. | |
| header | No | Zero-based row number to use as column names. | |
| intent | No | Optional natural-language chart intent used to guide automatic routing. | |
| y_cols | No | Column names or zero-based indexes to plot as Y. Defaults to all non-X columns. | |
| encoding | No | Optional text file encoding. | |
| skiprows | No | Rows to skip while reading. | |
| delimiter | No | Delimiter for text files. If omitted, CSV/TSV defaults or auto-detection are used. | |
| na_values | No | Additional missing value markers. | |
| excel_sheet | No | Excel sheet name or zero-based index. Ignored for text files. | |
| x_error_col | No | Optional X error column. | |
| y_error_col | No | Optional Y error column. | |
| max_recommendations | No | Maximum number of ranked chart recommendations to return. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but does not disclose behavioral traits like what happens when data cannot be read, how recommendations are ranked, or error handling. It only gives a high-level overview.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core action. It could be slightly more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 15 parameters, no annotations, and an output schema, the description is too minimal. It does not explain the recommendation logic, output format, or how to interpret results, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description hints at some parameters (table shape, column semantics, intent) but adds little beyond the schema's parameter names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool recommends chart types based on table shape, column semantics, and optional intent. It uses a specific verb ('recommend') and resource ('chart types'), differentiating from sibling tools like origin_plot which actually plot data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as origin_plot_auto or origin_plan_figure_spec. It does not mention prerequisites, exclusions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a supported Origin analysis and return structured metrics or output rows.
Use include_output=True with output_sheet for analyses that create a
worksheet. The analysis schema lists canonical names; aliases remain
accepted for backward compatibility.
| Name | Required | Description | Default |
|---|---|---|---|
| x_col | No | Optional X column. | |
| y_col | No | Optional Y column. | |
| options | No | Analysis-specific options. Examples: polynomial_fit uses order; smooth uses method and points; peak_find uses direction, threshold, and smooth_points; t-tests use tail and alpha; fft/ifft use window and sampling_interval. Set recalculate to none/0, auto/1, or manual/2 to create a recalculating Origin operation. | |
| analysis | Yes | Canonical analysis name. Supported values are listed in the schema; common choices include linear_fit, polynomial_fit, smooth, peak_find, fft, and correlation. | |
| worksheet | No | Worksheet range or book/sheet reference. | |
| output_sheet | No | Optional output sheet/name hint. | |
| include_output | No | Read output worksheet rows back into the response when possible. | |
| output_max_rows | No | Maximum rows to read from an output worksheet. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that include_output=True is for analyses creating worksheets and mentions backward compatibility for aliases. However, it does not explain key behaviors such as synchronous vs asynchronous execution, data mutation, permissions, or error handling, which are important for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, then a key usage note, then clarification about schema naming. Every sentence serves a purpose without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 8 parameters, an output schema, and the existence of sibling tools, the description covers the main purpose and key usage pattern. It could be more complete by explaining the return format or prerequisites, but the output schema likely fills some gaps. Overall, it is adequate for a tool with good schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with each parameter described. The description adds significant value by providing concrete examples for the options parameter (e.g., polynomial_fit uses order, smooth uses method and points) and explaining the recalculate sub-option. This extra context helps the agent understand how to set analysis-specific parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a supported Origin analysis and returns structured metrics or output rows. It provides specific details about using include_output with output_sheet for worksheet-creating analyses, and distinguishes this tool from siblings by focusing on analysis execution versus other operations like plotting or reading worksheets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives guidance on when to use include_output=True with output_sheet, and mentions that aliases are accepted for backward compatibility. However, it does not explicitly state when not to use this tool or provide alternatives from the sibling list, leaving some ambiguity about best practices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute LabTalk script text inside Origin and optionally return captured output.
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | LabTalk script text to execute inside the connected Origin application. | |
| capture_log | No | Whether to capture and return LabTalk output produced by the script. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits such as side effects, requirements, or limitations, but it only states the basic function and optional output capture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence that is front-loaded with the key action and resource, containing no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema exists to explain return values, the description lacks context on prerequisites, error handling, or when to prefer this over sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters; the tool description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it executes LabTalk script text and optionally returns output, clearly distinguishing it from siblings like origin_run_analysis which runs analysis routines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines provided; does not state when to use this tool versus alternatives like origin_run_analysis or origin_plot.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render an Origin graph and return it as an image the model can see.
Unlike origin_export_graph this leaves no file behind: the graph is
rendered to a temporary PNG, returned as an image content block alongside a
small text summary, and the temp file is deleted. Use it to visually verify
a plot and iterate on it. max_width bounds the rendered pixel width to
keep the returned image (and its token cost) small. Requires a
vision-capable client to be useful.
| Name | Required | Description | Default |
|---|---|---|---|
| max_width | No | Maximum rendered image width in pixels. | |
| graph_name | No | Origin graph page name. Omit to use the active graph or create a new page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes rendering to temp PNG, returning as image content block with text summary, and deleting temp file. Mentions max_width bounds token cost. No annotations provided, so description carries the burden well. Could explicitly state read-only behavior, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. Front-loaded with purpose. Student if additional details needed, but highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return format (image + text summary). Covers parameters, behavior, and distinction from sibling. Minor missing details about summary content but adequate for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds meaningful context: max_width limits pixel width for token cost, graph_name usage (active graph or new page). Exceeds baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Render an Origin graph and return it as an image the model can see.' It uses a specific verb-resource pair and distinguishes itself from sibling origin_export_graph by noting no file is left behind.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use it to visually verify a plot and iterate on it.' Contrasts with export_graph to guide selection. Mentions vision-capable client requirement. Doesn't list all alternatives, but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write structured rows into a new or existing Origin worksheet.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | Rows to write, as objects keyed by column name or arrays matching columns. | |
| create | No | Whether to create the target Origin object when it does not already exist. | |
| columns | No | Column names for object rows. For array rows, these names define the array order. | |
| book_name | No | Origin workbook name. Omit to use the active workbook or the tool default. | |
| start_col | No | Column name or zero-based column index at which writing begins. | |
| sheet_name | No | Origin worksheet name. Omit to use the active sheet or the tool default. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 only states the basic operation, omitting key details like whether data is appended or overwritten, error handling, required permissions, or what happens when the worksheet doesn't exist (though a 'create' parameter exists, its behavior is not explained in the description). This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence with no extraneous words. It is concise and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values need not be explained. However, the description lacks behavioral context (e.g., overwrite vs. append) and does not mention the tool's interaction with active sheets/workbooks, leaving the agent uncertain about side effects. It is minimally adequate but incomplete for safe autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema; it merely restates 'structured rows' without clarifying the interplay between 'rows', 'columns', and 'start_col' or the implications of 'create'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Write structured rows') and the resource ('into a new or existing Origin worksheet'), using a specific verb+resource pattern that distinguishes it from sibling tools like origin_read_worksheet or origin_diagnose_worksheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. Sibling tools like origin_read_worksheet or origin_diagnose_worksheet appear in the list, but no differentiation is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.3origin_bridge_cancel_task5 fields changedInput schema / properties / host / descriptionAdded value: +"Optional Origin bridge host override. Normally omit to use configured localhost."Input schema / properties / port / descriptionAdded value: +"Optional Origin bridge TCP port override. Normally omit to use the handshake value."Input schema / properties / task_id / descriptionAdded value: +"Background task identifier returned by origin_bridge_submit_task."Input schema / properties / timeout / descriptionAdded value: +"Bridge request timeout in seconds; null uses the configured default."Input schema / properties / token / descriptionAdded value: +"Optional bridge authentication token override. Normally omit to use the handshake."origin_bridge_list_tasks5 fields changedInput schema / properties / host / descriptionAdded value: +"Optional Origin bridge host override. Normally omit to use configured localhost."Input schema / properties / limit / descriptionAdded value: +"Maximum number of matching or recent records to return."Input schema / properties / port / descriptionAdded value: +"Optional Origin bridge TCP port override. Normally omit to use the handshake value."Input schema / properties / timeout / descriptionAdded value: +"Bridge request timeout in seconds; null uses the configured default."Input schema / properties / token / descriptionAdded value: +"Optional bridge authentication token override. Normally omit to use the handshake."origin_bridge_shutdown6 fields changedInput schema / properties / close_origin / descriptionAdded value: +"Whether bridge shutdown should also force-close the Origin application."Input schema / properties / host / descriptionAdded value: +"Optional Origin bridge host override. Normally omit to use configured localhost."Input schema / properties / port / descriptionAdded value: +"Optional Origin bridge TCP port override. Normally omit to use the handshake value."Input schema / properties / release_origin / descriptionAdded value: +"Whether bridge shutdown should release its Origin automation connection."Input schema / properties / timeout / descriptionAdded value: +"Bridge request timeout in seconds; null uses the configured default."Input schema / properties / token / descriptionAdded value: +"Optional bridge authentication token override. Normally omit to use the handshake."origin_bridge_submit_task6 fields changedInput schema / properties / host / descriptionAdded value: +"Optional Origin bridge host override. Normally omit to use configured localhost."Input schema / properties / method / descriptionAdded value: +"Allowlisted Origin bridge method to run as a background task."Input schema / properties / params / descriptionAdded value: +"Keyword arguments passed to the selected allowlisted bridge method."Input schema / properties / port / descriptionAdded value: +"Optional Origin bridge TCP port override. Normally omit to use the handshake value."Input schema / properties / timeout / descriptionAdded value: +"Bridge request timeout in seconds; null uses the configured default."Input schema / properties / token / descriptionAdded value: +"Optional bridge authentication token override. Normally omit to use the handshake."origin_bridge_task_status8 fields changedInput schema / properties / host / descriptionAdded value: +"Optional Origin bridge host override. Normally omit to use configured localhost."Input schema / properties / include_logs / descriptionAdded value: +"Whether to include recent background-task log records in the response."Input schema / properties / include_result / descriptionAdded value: +"Whether to include a completed background task's result payload."Input schema / properties / log_limit / descriptionAdded value: +"Maximum number of recent background-task log records to return."Input schema / properties / port / descriptionAdded value: +"Optional Origin bridge TCP port override. Normally omit to use the handshake value."Input schema / properties / task_id / descriptionAdded value: +"Background task identifier returned by origin_bridge_submit_task."Input schema / properties / timeout / descriptionAdded value: +"Bridge request timeout in seconds; null uses the configured default."Input schema / properties / token / descriptionAdded value: +"Optional bridge authentication token override. Normally omit to use the handshake."origin_browse_knowledge4 fields changedInput schema / properties / collection / descriptionAdded value: +"Knowledge collection. Omit to list collections; allowed names are in the schema."Input schema / properties / collection / enumAdded value: +[
+ "labtalk",
+ "mcp_tools",
+ "official_docs",
+ "python_api",
+ "reference"
+]Input schema / properties / topic / descriptionAdded value: +"Slash-delimited entry path within the collection, for example analysis/workflow. Omit to list the collection's immediate children."Input schema / properties / version / descriptionAdded value: +"Optional Origin documentation version filter, such as 2026b."origin_capabilities2 fields changedInput schema / properties / refresh / descriptionAdded value: +"Whether to bypass cached capability data and query Origin again."Input schema / properties / show / descriptionAdded value: +"Whether Origin should be visible after connecting or querying capabilities."origin_diagnose_worksheet6 fields changedInput schema / properties / book_name / descriptionAdded value: +"Origin workbook name. Omit to use the active workbook or the tool default."Input schema / properties / columns / descriptionAdded value: +"Column names or zero-based column indexes selected for this operation."Input schema / properties / high_missing_threshold / descriptionAdded value: +"Missing-value fraction from 0 through 1 that triggers a high_missing warning."Input schema / properties / high_missing_threshold / maximumAdded value: +1Input schema / properties / high_missing_threshold / minimumAdded value: +0Input schema / properties / sheet_name / descriptionAdded value: +"Origin worksheet name. Omit to use the active sheet or the tool default."origin_doctor6 fields changedInput schema / properties / host / descriptionAdded value: +"Optional Origin bridge host override. Normally omit to use configured localhost."Input schema / properties / ping_origin / descriptionAdded value: +"Whether diagnostics should also make a live request to Origin."Input schema / properties / port / descriptionAdded value: +"Optional Origin bridge TCP port override. Normally omit to use the handshake value."Input schema / properties / status_path / descriptionAdded value: +"Optional bridge status-file path override used by diagnostics."Input schema / properties / timeout / descriptionAdded value: +"Bridge request timeout in seconds; null uses the configured default."Input schema / properties / token / descriptionAdded value: +"Optional bridge authentication token override. Normally omit to use the handshake."origin_execute_figure_spec7 fields changedInput schema / $defsAdded value: +{
+ "FigureAnnotationSpec": {
+ "properties": {
+ "frame": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Frame"
+ },
+ "id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Id"
+ },
+ "layer": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Layer"
+ },
+ "location": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Location"
+ },
+ "orientation": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Orientation"
+ },
+ "style": {
+ "additionalProperties": true,
+ "title": "Style",
+ "type": "object"
+ },
+ "text": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Text"
+ },
+ "type": {
+ "title": "Type",
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Value"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "title": "FigureAnnotationSpec",
+ "type": "object"
+ },
+ "FigureAxisBreakSpec": {
+ "properties": {
+ "enabled": {
+ "default": true,
+ "title": "Enabled",
+ "type": "boolean"
+ },
+ "end": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Value immediately after the break.",
+ "title": "End"
+ },
+ "position": {
+ "anyOf": [
+ {
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Break position as an axis percentage.",
+ "title": "Position"
+ },
+ "post_break_increment": {
+ "anyOf": [
+ {
+ "exclusiveMinimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Major tick increment after the break.",
+ "title": "Post Break Increment"
+ },
+ "start": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Value immediately before the break.",
+ "title": "Start"
+ }
+ },
+ "title": "FigureAxisBreakSpec",
+ "type": "object"
+ },
+ "FigureAxisSpec": {
+ "properties": {
+ "breaks": {
+ "description": "Optional axis break. The current executor supports one break per axis.",
+ "items": {
+ "$ref": "#/$defs/FigureAxisBreakSpec"
+ },
+ "maxItems": 1,
+ "title": "Breaks",
+ "type": "array"
+ },
+ "limits": {
+ "anyOf": [
+ {
+ "const": "auto",
+ "type": "string"
+ },
+ {
+ "items": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": "auto",
+ "title": "Limits"
+ },
+ "scale": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Scale"
+ },
+ "step": {
+ "anyOf": [
+ {
+ "exclusiveMinimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Step"
+ },
+ "title": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Title"
+ }
+ },
+ "title": "FigureAxisSpec",
+ "type": "object"
+ },
+ "FigureDataSpec": {
+ "properties": {
+ "delimiter": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Delimiter"
+ },
+ "encoding": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Encoding"
+ },
+ "excel_sheet": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": 0,
+ "title": "Excel Sheet"
+ },
+ "format": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "csv/tsv/txt/dat/xlsx/xls/xlsm.",
+ "title": "Format"
+ },
+ "header": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": 0,
+ "title": "Header"
+ },
+ "id": {
+ "description": "Dataset id referenced by layers and plots.",
+ "title": "Id",
+ "type": "string"
+ },
+ "na_values": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Na Values"
+ },
+ "nrows": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Nrows"
+ },
+ "object": {
+ "default": "worksheet",
+ "enum": [
+ "worksheet",
+ "matrix",
+ "xyz"
+ ],
+ "title": "Object",
+ "type": "string"
+ },
+ "roles": {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "items": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ }
+ ]
+ },
+ "type": "array"
+ }
+ ]
+ },
+ "description": "Semantic column roles such as x, y, z, group, error, err_low, err_high.",
+ "title": "Roles",
+ "type": "object"
+ },
+ "skiprows": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "items": {
+ "type": "integer"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Skiprows"
+ },
+ "source": {
+ "description": "Source data file path.",
+ "format": "path",
+ "title": "Source",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "source"
+ ],
+ "title": "FigureDataSpec",
+ "type": "object"
+ },
+ "FigureExportFormatSpec": {
+ "properties": {
+ "enabled": {
+ "default": false,
+ "title": "Enabled",
+ "type": "boolean"
+ },
+ "path": {
+ "anyOf": [
+ {
+ "format": "path",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Path"
+ },
+ "width_px": {
+ "anyOf": [
+ {
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Width Px"
+ }
+ },
+ "title": "FigureExportFormatSpec",
+ "type": "object"
+ },
+ "FigureExportSpec": {
+ "properties": {
+ "dir_figures": {
+ "anyOf": [
+ {
+ "format": "path",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Dir Figures"
+ },
+ "dir_opju": {
+ "anyOf": [
+ {
+ "format": "path",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Dir Opju"
+ },
+ "pdf": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/FigureExportFormatSpec"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Pdf"
+ },
+ "png": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/FigureExportFormatSpec"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Png"
+ },
+ "qa": {
+ "additionalProperties": true,
+ "title": "Qa",
+ "type": "object"
+ },
+ "save_clean_data": {
+ "default": false,
+ "title": "Save Clean Data",
+ "type": "boolean"
+ },
+ "svg": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/FigureExportFormatSpec"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Svg"
+ },
+ "tiff": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/FigureExportFormatSpec"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Tiff"
+ }
+ },
+ "title": "FigureExportSpec",
+ "type": "object"
+ },
+ "FigureLayerSpec": {
+ "properties": {
+ "data_ref": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Data Ref"
+ },
+ "frame": {
+ "additionalProperties": {
+ "type": "boolean"
+ },
+ "title": "Frame",
+ "type": "object"
+ },
+ "grid_cell": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "integer"
+ },
+ "maxItems": 2,
+ "minItems": 2,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Grid Cell"
+ },
+ "grid_span": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "integer"
+ },
+ "maxItems": 2,
+ "minItems": 2,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Grid Span"
+ },
+ "id": {
+ "description": "Layer/panel id.",
+ "title": "Id",
+ "type": "string"
+ },
+ "page": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Page"
+ },
+ "panel_tag": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Panel Tag"
+ },
+ "position": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "description": "Absolute layer geometry for position_mode='absolute': left, top, width, height as page percentages.",
+ "title": "Position",
+ "type": "object"
+ },
+ "position_mode": {
+ "default": "grid",
+ "enum": [
+ "grid",
+ "absolute"
+ ],
+ "title": "Position Mode",
+ "type": "string"
+ },
+ "title": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Title"
+ },
+ "x": {
+ "$ref": "#/$defs/FigureAxisSpec"
+ },
+ "y": {
+ "$ref": "#/$defs/FigureAxisSpec"
+ },
+ "z": {
+ "$ref": "#/$defs/FigureAxisSpec"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "title": "FigureLayerSpec",
+ "type": "object"
+ },
+ "FigureMeta": {
+ "properties": {
+ "id": {
+ "description": "Stable figure identifier.",
+ "title": "Id",
+ "type": "string"
+ },
+ "title": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional figure title/long name.",
+ "title": "Title"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "title": "FigureMeta",
+ "type": "object"
+ },
+ "FigurePageSpec": {
+ "properties": {
+ "id": {
+ "default": "page_main",
+ "title": "Id",
+ "type": "string"
+ },
+ "layout": {
+ "default": "single",
+ "enum": [
+ "single",
+ "grid",
+ "custom",
+ "inset",
+ "dual_y"
+ ],
+ "title": "Layout",
+ "type": "string"
+ },
+ "margins_mm": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Margins Mm"
+ },
+ "panel_spacing_mm": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Panel Spacing Mm"
+ },
+ "size_mm": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "number"
+ },
+ "maxItems": 2,
+ "minItems": 2,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Size Mm"
+ }
+ },
+ "title": "FigurePageSpec",
+ "type": "object"
+ },
+ "FigurePlotSpec": {
+ "properties": {
+ "data_ref": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Data Ref"
+ },
+ "group_style": {
+ "additionalProperties": true,
+ "title": "Group Style",
+ "type": "object"
+ },
+ "id": {
+ "description": "Plot primitive id.",
+ "title": "Id",
+ "type": "string"
+ },
+ "layer": {
+ "title": "Layer",
+ "type": "string"
+ },
+ "map": {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "items": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ }
+ ]
+ },
+ "type": "array"
+ }
+ ]
+ },
+ "description": "Visual channel mapping such as x, y, z, group, error.",
+ "title": "Map",
+ "type": "object"
+ },
+ "style": {
+ "additionalProperties": true,
+ "title": "Style",
+ "type": "object"
+ },
+ "type": {
+ "description": "line/scatter/line_symbol/column/histogram/box/contour/heatmap.",
+ "title": "Type",
+ "type": "string"
+ },
+ "uncertainty": {
+ "additionalProperties": true,
+ "title": "Uncertainty",
+ "type": "object"
+ }
+ },
+ "required": [
+ "id",
+ "layer",
+ "type"
+ ],
+ "title": "FigurePlotSpec",
+ "type": "object"
+ },
+ "FigureRuntimeSpec": {
+ "properties": {
+ "new_project": {
+ "default": false,
+ "description": "Start a fresh Origin project first.",
+ "title": "New Project",
+ "type": "boolean"
+ },
+ "project_path": {
+ "anyOf": [
+ {
+ "format": "path",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional OPJU/OPJ save path.",
+ "title": "Project Path"
+ },
+ "save_project": {
+ "default": false,
+ "description": "Save the Origin project after export.",
+ "title": "Save Project",
+ "type": "boolean"
+ },
+ "show_origin": {
+ "default": true,
+ "description": "Whether Origin should be visible.",
+ "title": "Show Origin",
+ "type": "boolean"
+ }
+ },
+ "title": "FigureRuntimeSpec",
+ "type": "object"
+ },
+ "FigureSpec": {
+ "properties": {
+ "annotations": {
+ "items": {
+ "$ref": "#/$defs/FigureAnnotationSpec"
+ },
+ "title": "Annotations",
+ "type": "array"
+ },
+ "data": {
+ "items": {
+ "$ref": "#/$defs/FigureDataSpec"
+ },
+ "title": "Data",
+ "type": "array"
+ },
+ "export": {
+ "$ref": "#/$defs/FigureExportSpec"
+ },
+ "figure": {
+ "$ref": "#/$defs/FigureMeta"
+ },
+ "layers": {
+ "items": {
+ "$ref": "#/$defs/FigureLayerSpec"
+ },
+ "title": "Layers",
+ "type": "array"
+ },
+ "page": {
+ "$ref": "#/$defs/FigurePageSpec"
+ },
+ "plots": {
+ "items": {
+ "$ref": "#/$defs/FigurePlotSpec"
+ },
+ "title": "Plots",
+ "type": "array"
+ },
+ "runtime": {
+ "$ref": "#/$defs/FigureRuntimeSpec"
+ },
+ "style": {
+ "$ref": "#/$defs/FigureStyleSpec"
+ }
+ },
+ "required": [
+ "figure"
+ ],
+ "title": "FigureSpec",
+ "type": "object"
+ },
+ "FigureStyleSpec": {
+ "properties": {
+ "annotation_font_size": {
+ "anyOf": [
+ {
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Annotation Font Size"
+ },
+ "font_family": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Font Family"
+ },
+ "palette_name": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Palette Name"
+ },
+ "palette_role": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Palette Role"
+ },
+ "template": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Template"
+ },
+ "theme": {
+ "default": "origin_default",
+ "enum": [
+ "origin_default",
+ "template",
+ "theme",
+ "none",
+ "nature"
+ ],
+ "title": "Theme",
+ "type": "string"
+ }
+ },
+ "title": "FigureStyleSpec",
+ "type": "object"
+ }
+}Input schema / properties / dry_run / descriptionAdded value: +"Validate and plan the operation without changing the Origin project."Input schema / properties / spec / $refAdded value: +"#/$defs/FigureSpec"Input schema / properties / spec / additionalPropertiesRemoved value: -trueInput schema / properties / spec / descriptionAdded value: +"Declarative FigureSpec describing data, layout, plots, style, export, and QA."Input schema / properties / spec / titleRemoved value: -"Spec"Input schema / properties / spec / typeRemoved value: -"object"origin_export_graph4 fields changedInput schema / properties / graph_name / descriptionAdded value: +"Origin graph page name. Omit to use the active graph or create a new page."Input schema / properties / overwrite / descriptionAdded value: +"Whether an existing output file may be replaced."Input schema / properties / path / descriptionAdded value: +"Filesystem path consumed or produced by this tool; see the tool description."Input schema / properties / width / descriptionAdded value: +"Export width in pixels; zero preserves Origin's default export width."origin_format_graph6 fields changedInput schema / properties / graph_name / descriptionAdded value: +"Optional graph page name."Input schema / properties / rescale / descriptionAdded value: +"Whether to rescale graph axes after formatting."Input schema / properties / show_legend / descriptionAdded value: +"Set legend visibility when provided."Input schema / properties / title / descriptionAdded value: +"Optional graph page long name."Input schema / properties / x_label / descriptionAdded value: +"Optional X axis title."Input schema / properties / y_label / descriptionAdded value: +"Optional Y axis title."origin_get_graph_info1 field changedInput schema / properties / graph_name / descriptionAdded value: +"Origin graph page name. Omit to use the active graph or create a new page."origin_import_table12 fields changedInput schema / properties / book_name / descriptionAdded value: +"Optional Origin workbook name."Input schema / properties / delimiter / descriptionAdded value: +"Delimiter for text files. If omitted, CSV/TSV defaults or auto-detection are used."Input schema / properties / encoding / descriptionAdded value: +"Optional text file encoding."Input schema / properties / excel_sheet / descriptionAdded value: +"Excel sheet name or zero-based index. Ignored for text files."Input schema / properties / header / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / header / descriptionAdded value: +"Zero-based row number to use as column names."Input schema / properties / na_values / descriptionAdded value: +"Additional missing value markers."Input schema / properties / nrows / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / nrows / descriptionAdded value: +"Maximum number of data rows to read."Input schema / properties / path / descriptionAdded value: +"Absolute path to a CSV, TSV, TXT, DAT, XLS, or XLSX file."Input schema / properties / sheet_name / descriptionAdded value: +"Optional Origin worksheet name."Input schema / properties / skiprows / descriptionAdded value: +"Rows to skip while reading."origin_ping1 field changedInput schema / properties / show / descriptionAdded value: +"Whether Origin should be visible after connecting or querying capabilities."origin_plan_figure_spec6 fields changedInput schema / $defsAdded value: +{
+ "FigureAnnotationSpec": {
+ "properties": {
+ "frame": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Frame"
+ },
+ "id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Id"
+ },
+ "layer": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Layer"
+ },
+ "location": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Location"
+ },
+ "orientation": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Orientation"
+ },
+ "style": {
+ "additionalProperties": true,
+ "title": "Style",
+ "type": "object"
+ },
+ "text": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Text"
+ },
+ "type": {
+ "title": "Type",
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Value"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "title": "FigureAnnotationSpec",
+ "type": "object"
+ },
+ "FigureAxisBreakSpec": {
+ "properties": {
+ "enabled": {
+ "default": true,
+ "title": "Enabled",
+ "type": "boolean"
+ },
+ "end": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Value immediately after the break.",
+ "title": "End"
+ },
+ "position": {
+ "anyOf": [
+ {
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Break position as an axis percentage.",
+ "title": "Position"
+ },
+ "post_break_increment": {
+ "anyOf": [
+ {
+ "exclusiveMinimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Major tick increment after the break.",
+ "title": "Post Break Increment"
+ },
+ "start": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Value immediately before the break.",
+ "title": "Start"
+ }
+ },
+ "title": "FigureAxisBreakSpec",
+ "type": "object"
+ },
+ "FigureAxisSpec": {
+ "properties": {
+ "breaks": {
+ "description": "Optional axis break. The current executor supports one break per axis.",
+ "items": {
+ "$ref": "#/$defs/FigureAxisBreakSpec"
+ },
+ "maxItems": 1,
+ "title": "Breaks",
+ "type": "array"
+ },
+ "limits": {
+ "anyOf": [
+ {
+ "const": "auto",
+ "type": "string"
+ },
+ {
+ "items": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": "auto",
+ "title": "Limits"
+ },
+ "scale": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Scale"
+ },
+ "step": {
+ "anyOf": [
+ {
+ "exclusiveMinimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Step"
+ },
+ "title": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Title"
+ }
+ },
+ "title": "FigureAxisSpec",
+ "type": "object"
+ },
+ "FigureDataSpec": {
+ "properties": {
+ "delimiter": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Delimiter"
+ },
+ "encoding": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Encoding"
+ },
+ "excel_sheet": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": 0,
+ "title": "Excel Sheet"
+ },
+ "format": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "csv/tsv/txt/dat/xlsx/xls/xlsm.",
+ "title": "Format"
+ },
+ "header": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": 0,
+ "title": "Header"
+ },
+ "id": {
+ "description": "Dataset id referenced by layers and plots.",
+ "title": "Id",
+ "type": "string"
+ },
+ "na_values": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Na Values"
+ },
+ "nrows": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Nrows"
+ },
+ "object": {
+ "default": "worksheet",
+ "enum": [
+ "worksheet",
+ "matrix",
+ "xyz"
+ ],
+ "title": "Object",
+ "type": "string"
+ },
+ "roles": {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "items": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ }
+ ]
+ },
+ "type": "array"
+ }
+ ]
+ },
+ "description": "Semantic column roles such as x, y, z, group, error, err_low, err_high.",
+ "title": "Roles",
+ "type": "object"
+ },
+ "skiprows": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "items": {
+ "type": "integer"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Skiprows"
+ },
+ "source": {
+ "description": "Source data file path.",
+ "format": "path",
+ "title": "Source",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "source"
+ ],
+ "title": "FigureDataSpec",
+ "type": "object"
+ },
+ "FigureExportFormatSpec": {
+ "properties": {
+ "enabled": {
+ "default": false,
+ "title": "Enabled",
+ "type": "boolean"
+ },
+ "path": {
+ "anyOf": [
+ {
+ "format": "path",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Path"
+ },
+ "width_px": {
+ "anyOf": [
+ {
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Width Px"
+ }
+ },
+ "title": "FigureExportFormatSpec",
+ "type": "object"
+ },
+ "FigureExportSpec": {
+ "properties": {
+ "dir_figures": {
+ "anyOf": [
+ {
+ "format": "path",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Dir Figures"
+ },
+ "dir_opju": {
+ "anyOf": [
+ {
+ "format": "path",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Dir Opju"
+ },
+ "pdf": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/FigureExportFormatSpec"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Pdf"
+ },
+ "png": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/FigureExportFormatSpec"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Png"
+ },
+ "qa": {
+ "additionalProperties": true,
+ "title": "Qa",
+ "type": "object"
+ },
+ "save_clean_data": {
+ "default": false,
+ "title": "Save Clean Data",
+ "type": "boolean"
+ },
+ "svg": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/FigureExportFormatSpec"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Svg"
+ },
+ "tiff": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/FigureExportFormatSpec"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Tiff"
+ }
+ },
+ "title": "FigureExportSpec",
+ "type": "object"
+ },
+ "FigureLayerSpec": {
+ "properties": {
+ "data_ref": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Data Ref"
+ },
+ "frame": {
+ "additionalProperties": {
+ "type": "boolean"
+ },
+ "title": "Frame",
+ "type": "object"
+ },
+ "grid_cell": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "integer"
+ },
+ "maxItems": 2,
+ "minItems": 2,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Grid Cell"
+ },
+ "grid_span": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "integer"
+ },
+ "maxItems": 2,
+ "minItems": 2,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Grid Span"
+ },
+ "id": {
+ "description": "Layer/panel id.",
+ "title": "Id",
+ "type": "string"
+ },
+ "page": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Page"
+ },
+ "panel_tag": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Panel Tag"
+ },
+ "position": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "description": "Absolute layer geometry for position_mode='absolute': left, top, width, height as page percentages.",
+ "title": "Position",
+ "type": "object"
+ },
+ "position_mode": {
+ "default": "grid",
+ "enum": [
+ "grid",
+ "absolute"
+ ],
+ "title": "Position Mode",
+ "type": "string"
+ },
+ "title": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Title"
+ },
+ "x": {
+ "$ref": "#/$defs/FigureAxisSpec"
+ },
+ "y": {
+ "$ref": "#/$defs/FigureAxisSpec"
+ },
+ "z": {
+ "$ref": "#/$defs/FigureAxisSpec"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "title": "FigureLayerSpec",
+ "type": "object"
+ },
+ "FigureMeta": {
+ "properties": {
+ "id": {
+ "description": "Stable figure identifier.",
+ "title": "Id",
+ "type": "string"
+ },
+ "title": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional figure title/long name.",
+ "title": "Title"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "title": "FigureMeta",
+ "type": "object"
+ },
+ "FigurePageSpec": {
+ "properties": {
+ "id": {
+ "default": "page_main",
+ "title": "Id",
+ "type": "string"
+ },
+ "layout": {
+ "default": "single",
+ "enum": [
+ "single",
+ "grid",
+ "custom",
+ "inset",
+ "dual_y"
+ ],
+ "title": "Layout",
+ "type": "string"
+ },
+ "margins_mm": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Margins Mm"
+ },
+ "panel_spacing_mm": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Panel Spacing Mm"
+ },
+ "size_mm": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "number"
+ },
+ "maxItems": 2,
+ "minItems": 2,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Size Mm"
+ }
+ },
+ "title": "FigurePageSpec",
+ "type": "object"
+ },
+ "FigurePlotSpec": {
+ "properties": {
+ "data_ref": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Data Ref"
+ },
+ "group_style": {
+ "additionalProperties": true,
+ "title": "Group Style",
+ "type": "object"
+ },
+ "id": {
+ "description": "Plot primitive id.",
+ "title": "Id",
+ "type": "string"
+ },
+ "layer": {
+ "title": "Layer",
+ "type": "string"
+ },
+ "map": {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "items": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ }
+ ]
+ },
+ "type": "array"
+ }
+ ]
+ },
+ "description": "Visual channel mapping such as x, y, z, group, error.",
+ "title": "Map",
+ "type": "object"
+ },
+ "style": {
+ "additionalProperties": true,
+ "title": "Style",
+ "type": "object"
+ },
+ "type": {
+ "description": "line/scatter/line_symbol/column/histogram/box/contour/heatmap.",
+ "title": "Type",
+ "type": "string"
+ },
+ "uncertainty": {
+ "additionalProperties": true,
+ "title": "Uncertainty",
+ "type": "object"
+ }
+ },
+ "required": [
+ "id",
+ "layer",
+ "type"
+ ],
+ "title": "FigurePlotSpec",
+ "type": "object"
+ },
+ "FigureRuntimeSpec": {
+ "properties": {
+ "new_project": {
+ "default": false,
+ "description": "Start a fresh Origin project first.",
+ "title": "New Project",
+ "type": "boolean"
+ },
+ "project_path": {
+ "anyOf": [
+ {
+ "format": "path",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional OPJU/OPJ save path.",
+ "title": "Project Path"
+ },
+ "save_project": {
+ "default": false,
+ "description": "Save the Origin project after export.",
+ "title": "Save Project",
+ "type": "boolean"
+ },
+ "show_origin": {
+ "default": true,
+ "description": "Whether Origin should be visible.",
+ "title": "Show Origin",
+ "type": "boolean"
+ }
+ },
+ "title": "FigureRuntimeSpec",
+ "type": "object"
+ },
+ "FigureSpec": {
+ "properties": {
+ "annotations": {
+ "items": {
+ "$ref": "#/$defs/FigureAnnotationSpec"
+ },
+ "title": "Annotations",
+ "type": "array"
+ },
+ "data": {
+ "items": {
+ "$ref": "#/$defs/FigureDataSpec"
+ },
+ "title": "Data",
+ "type": "array"
+ },
+ "export": {
+ "$ref": "#/$defs/FigureExportSpec"
+ },
+ "figure": {
+ "$ref": "#/$defs/FigureMeta"
+ },
+ "layers": {
+ "items": {
+ "$ref": "#/$defs/FigureLayerSpec"
+ },
+ "title": "Layers",
+ "type": "array"
+ },
+ "page": {
+ "$ref": "#/$defs/FigurePageSpec"
+ },
+ "plots": {
+ "items": {
+ "$ref": "#/$defs/FigurePlotSpec"
+ },
+ "title": "Plots",
+ "type": "array"
+ },
+ "runtime": {
+ "$ref": "#/$defs/FigureRuntimeSpec"
+ },
+ "style": {
+ "$ref": "#/$defs/FigureStyleSpec"
+ }
+ },
+ "required": [
+ "figure"
+ ],
+ "title": "FigureSpec",
+ "type": "object"
+ },
+ "FigureStyleSpec": {
+ "properties": {
+ "annotation_font_size": {
+ "anyOf": [
+ {
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Annotation Font Size"
+ },
+ "font_family": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Font Family"
+ },
+ "palette_name": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Palette Name"
+ },
+ "palette_role": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Palette Role"
+ },
+ "template": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Template"
+ },
+ "theme": {
+ "default": "origin_default",
+ "enum": [
+ "origin_default",
+ "template",
+ "theme",
+ "none",
+ "nature"
+ ],
+ "title": "Theme",
+ "type": "string"
+ }
+ },
+ "title": "FigureStyleSpec",
+ "type": "object"
+ }
+}Input schema / properties / spec / $refAdded value: +"#/$defs/FigureSpec"Input schema / properties / spec / additionalPropertiesRemoved value: -trueInput schema / properties / spec / descriptionAdded value: +"Declarative FigureSpec describing data, layout, plots, style, export, and QA."Input schema / properties / spec / titleRemoved value: -"Spec"Input schema / properties / spec / typeRemoved value: -"object"origin_plot9 fields changedInput schema / properties / export_path / descriptionAdded value: +"Optional output path for exporting the created graph."Input schema / properties / graph_name / descriptionAdded value: +"Origin graph page name. Omit to use the active graph or create a new page."Input schema / properties / kind / descriptionAdded value: +"Table plot kind. The schema lists every compact-route kind supported by this tool."Input schema / properties / kind / enumAdded value: +[
+ "area",
+ "bar",
+ "bars_3d",
+ "box",
+ "bubble",
+ "bubble_color_mapped",
+ "candlestick",
+ "color_mapped",
+ "column",
+ "column_stack",
+ "dendrogram",
+ "errorbar_3d",
+ "fill_area",
+ "floating_bar",
+ "high_low_close",
+ "histogram",
+ "line",
+ "line_symbol",
+ "pie",
+ "polar_xr_ytheta",
+ "ribbon_3d",
+ "scatter",
+ "smith",
+ "stack_area",
+ "stack_bar",
+ "ternary",
+ "ternary_contour",
+ "vector_3d",
+ "vector_xyam",
+ "vector_xyxy",
+ "waterfall"
+]Input schema / properties / path / descriptionAdded value: +"Filesystem path consumed or produced by this tool; see the tool description."Input schema / properties / selected_cols / descriptionAdded value: +"Column names or zero-based indexes to include in the plot."Input schema / properties / style_mode / descriptionAdded value: +"Graph styling policy: origin_default preserves the Origin template; nature applies the origin-mcp scientific preset."Input schema / properties / style_mode / enumAdded value: +[
+ "origin_default",
+ "template",
+ "theme",
+ "none",
+ "nature"
+]Input schema / properties / title / descriptionAdded value: +"Optional Origin page long name or graph title."origin_plot_auto26 fields changedInput schema / properties / book_name / descriptionAdded value: +"Optional Origin workbook name."Input schema / properties / delimiter / descriptionAdded value: +"Delimiter for text files. If omitted, CSV/TSV defaults or auto-detection are used."Input schema / properties / encoding / descriptionAdded value: +"Optional text file encoding."Input schema / properties / excel_sheet / descriptionAdded value: +"Excel sheet name or zero-based index. Ignored for text files."Input schema / properties / export_path / descriptionAdded value: +"Optional graph export path."Input schema / properties / graph_name / descriptionAdded value: +"Optional Origin graph page name."Input schema / properties / header / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / header / descriptionAdded value: +"Zero-based row number to use as column names."Input schema / properties / intent / descriptionAdded value: +"Optional natural-language chart intent used to guide automatic routing."Input schema / properties / na_values / descriptionAdded value: +"Additional missing value markers."Input schema / properties / nrows / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / nrows / descriptionAdded value: +"Maximum number of data rows to read."Input schema / properties / palette_name / descriptionAdded value: +"Optional registered color palette name used by the selected style mode."Input schema / properties / path / descriptionAdded value: +"Absolute path to a CSV, TSV, TXT, DAT, XLS, or XLSX file."Input schema / properties / sheet_name / descriptionAdded value: +"Optional Origin worksheet name."Input schema / properties / skiprows / descriptionAdded value: +"Rows to skip while reading."Input schema / properties / style_mode / descriptionAdded value: +"Graph styling policy. origin_default/template/theme/none preserve Origin template defaults; nature applies origin-mcp styling after plotting."Input schema / properties / style_mode / enumAdded value: +[
+ "origin_default",
+ "template",
+ "theme",
+ "none",
+ "nature"
+]Input schema / properties / title / descriptionAdded value: +"Optional graph page long name."Input schema / properties / x_col / descriptionAdded value: +"Column name or zero-based index to use as X. Defaults to the first column."Input schema / properties / x_error_col / descriptionAdded value: +"Optional X error column."Input schema / properties / x_label / descriptionAdded value: +"Optional X axis title."Input schema / properties / y_cols / descriptionAdded value: +"Column names or zero-based indexes to plot as Y. Defaults to all non-X columns."Input schema / properties / y_error_col / descriptionAdded value: +"Optional Y error column."Input schema / properties / y_label / descriptionAdded value: +"Optional Y axis title."Input schema / properties / z_col / descriptionAdded value: +"Optional Z column for contour/XYZ plots."origin_query_knowledge7 fields changedInput schema / properties / collection / descriptionAdded value: +"Optional knowledge collection filter; allowed names are in the schema."Input schema / properties / collection / enumAdded value: +[
+ "labtalk",
+ "mcp_tools",
+ "official_docs",
+ "python_api",
+ "reference"
+]Input schema / properties / limit / descriptionAdded value: +"Maximum number of matching or recent records to return."Input schema / properties / limit / maximumAdded value: +100Input schema / properties / limit / minimumAdded value: +1Input schema / properties / query / descriptionAdded value: +"Keyword query matched against local knowledge titles, summaries, and bodies."Input schema / properties / version / descriptionAdded value: +"Optional Origin documentation version filter, such as 2026b."origin_read_worksheet5 fields changedInput schema / properties / book_name / descriptionAdded value: +"Origin workbook name. Omit to use the active workbook or the tool default."Input schema / properties / columns / descriptionAdded value: +"Column names or zero-based column indexes selected for this operation."Input schema / properties / max_rows / descriptionAdded value: +"Maximum number of worksheet rows to return."Input schema / properties / sheet_name / descriptionAdded value: +"Origin worksheet name. Omit to use the active sheet or the tool default."Input schema / properties / start_row / descriptionAdded value: +"Zero-based worksheet row at which reading begins."origin_recommend_chart19 fields changedInput schema / properties / delimiter / descriptionAdded value: +"Delimiter for text files. If omitted, CSV/TSV defaults or auto-detection are used."Input schema / properties / encoding / descriptionAdded value: +"Optional text file encoding."Input schema / properties / excel_sheet / descriptionAdded value: +"Excel sheet name or zero-based index. Ignored for text files."Input schema / properties / header / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / header / descriptionAdded value: +"Zero-based row number to use as column names."Input schema / properties / intent / descriptionAdded value: +"Optional natural-language chart intent used to guide automatic routing."Input schema / properties / max_recommendations / descriptionAdded value: +"Maximum number of ranked chart recommendations to return."Input schema / properties / max_recommendations / maximumAdded value: +20Input schema / properties / max_recommendations / minimumAdded value: +1Input schema / properties / na_values / descriptionAdded value: +"Additional missing value markers."Input schema / properties / nrows / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / nrows / descriptionAdded value: +"Maximum number of data rows to read."Input schema / properties / path / descriptionAdded value: +"Absolute path to a CSV, TSV, TXT, DAT, XLS, or XLSX file."Input schema / properties / skiprows / descriptionAdded value: +"Rows to skip while reading."Input schema / properties / x_col / descriptionAdded value: +"Column name or zero-based index to use as X. Defaults to the first column."Input schema / properties / x_error_col / descriptionAdded value: +"Optional X error column."Input schema / properties / y_cols / descriptionAdded value: +"Column names or zero-based indexes to plot as Y. Defaults to all non-X columns."Input schema / properties / y_error_col / descriptionAdded value: +"Optional Y error column."Input schema / properties / z_col / descriptionAdded value: +"Optional Z column for contour/XYZ plots."origin_run_analysis11 fields changedInput schema / properties / analysis / descriptionAdded value: +"Canonical analysis name. Supported values are listed in the schema; common choices include linear_fit, polynomial_fit, smooth, peak_find, fft, and correlation."Input schema / properties / analysis / enumAdded value: +[
+ "correlation",
+ "descriptive_stats",
+ "differentiate",
+ "fft",
+ "ifft",
+ "integrate",
+ "interpolate",
+ "linear_fit",
+ "nonlinear_fit",
+ "normalize",
+ "peak_find",
+ "polynomial_fit",
+ "smooth",
+ "ttest_one_sample",
+ "ttest_paired",
+ "ttest_two_sample"
+]Input schema / properties / include_output / descriptionAdded value: +"Read output worksheet rows back into the response when possible."Input schema / properties / options / descriptionAdded value: +"Analysis-specific options. Examples: polynomial_fit uses order; smooth uses method and points; peak_find uses direction, threshold, and smooth_points; t-tests use tail and alpha; fft/ifft use window and sampling_interval. Set recalculate to none/0, auto/1, or manual/2 to create a recalculating Origin operation."Input schema / properties / output_max_rows / descriptionAdded value: +"Maximum rows to read from an output worksheet."Input schema / properties / output_max_rows / maximumAdded value: +10000Input schema / properties / output_max_rows / minimumAdded value: +1Input schema / properties / output_sheet / descriptionAdded value: +"Optional output sheet/name hint."Input schema / properties / worksheet / descriptionAdded value: +"Worksheet range or book/sheet reference."Input schema / properties / x_col / descriptionAdded value: +"Optional X column."Input schema / properties / y_col / descriptionAdded value: +"Optional Y column."origin_run_labtalk2 fields changedInput schema / properties / capture_log / descriptionAdded value: +"Whether to capture and return LabTalk output produced by the script."Input schema / properties / script / descriptionAdded value: +"LabTalk script text to execute inside the connected Origin application."origin_view_graph2 fields changedInput schema / properties / graph_name / descriptionAdded value: +"Origin graph page name. Omit to use the active graph or create a new page."Input schema / properties / max_width / descriptionAdded value: +"Maximum rendered image width in pixels."origin_write_worksheet6 fields changedInput schema / properties / book_name / descriptionAdded value: +"Origin workbook name. Omit to use the active workbook or the tool default."Input schema / properties / columns / descriptionAdded value: +"Column names for object rows. For array rows, these names define the array order."Input schema / properties / create / descriptionAdded value: +"Whether to create the target Origin object when it does not already exist."Input schema / properties / rows / descriptionAdded value: +"Rows to write, as objects keyed by column name or arrays matching columns."Input schema / properties / sheet_name / descriptionAdded value: +"Origin worksheet name. Omit to use the active sheet or the tool default."Input schema / properties / start_col / descriptionAdded value: +"Column name or zero-based column index at which writing begins."v0.1.2origin_add_plot_to_graphorigin_bridge_shutdown1 field changedInput schema / properties / close_originAdded value: +{
+ "default": false,
+ "title": "Close Origin",
+ "type": "boolean"
+}origin_bridge_task_status3 fields changedInput schema / properties / include_logsAdded value: +{
+ "default": false,
+ "title": "Include Logs",
+ "type": "boolean"
+}Input schema / properties / include_resultAdded value: +{
+ "default": true,
+ "title": "Include Result",
+ "type": "boolean"
+}Input schema / properties / log_limitAdded value: +{
+ "default": 20,
+ "title": "Log Limit",
+ "type": "integer"
+}origin_capabilities3 fields changedInput schema / properties / show / anyOfAdded value: +[
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / show / defaultPrevious value: -falseNew value: +nullInput schema / properties / show / typeRemoved value: -"boolean"origin_diagnose_worksheetorigin_execute_figure_specorigin_export_graph1 field changedInput schema / properties / widthAdded value: +{
+ "default": 0,
+ "title": "Width",
+ "type": "integer"
+}origin_get_layer_infoorigin_plan_figure_specorigin_plotorigin_plot_auto1 field changedInput schema / properties / palette_nameAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Palette Name"
+}origin_plot_boxorigin_plot_chart_atlasorigin_plot_columnorigin_plot_from_rangeorigin_plot_histogramorigin_plot_lineorigin_plot_line_symbolorigin_plot_scatterorigin_plot_table_idorigin_set_axisorigin_set_plot_styleorigin_view_graphorigin_add_calculated_columnorigin_add_graph_labelorigin_add_reference_lineorigin_append_tableorigin_apply_image_panel_styleorigin_apply_nature_styleorigin_apply_publication_styleorigin_arrange_layersorigin_batch_plot_from_templateorigin_bridge_cancel_taskorigin_bridge_list_tasksorigin_bridge_shutdownorigin_bridge_submit_taskorigin_bridge_task_statusorigin_browse_knowledgeorigin_change_plot_dataorigin_change_plot_typeorigin_chart_atlas_routeorigin_clear_worksheetorigin_delete_columnsorigin_delete_objectorigin_descriptive_statsorigin_detachorigin_diagnose_graphorigin_differentiateorigin_doctororigin_export_all_graphsorigin_export_previeworigin_export_worksheet_csvorigin_force_quitorigin_format_legendorigin_get_cell_valueorigin_get_default_plot_configorigin_get_worksheet_infoorigin_import_csvorigin_import_excelorigin_import_fileorigin_inspect_exportorigin_integrateorigin_linear_fitorigin_list_fit_functionsorigin_list_graph_templatesorigin_list_projectorigin_new_projectorigin_nonlinear_fitorigin_nonlinear_fit_structuredorigin_open_projectorigin_peak_findorigin_plot_3d_barsorigin_plot_3d_errorbarorigin_plot_3d_ribbonorigin_plot_3d_scatterorigin_plot_3d_surfaceorigin_plot_3d_vectororigin_plot_areaorigin_plot_autoorigin_plot_barorigin_plot_bubbleorigin_plot_bubble_color_mappedorigin_plot_candlestickorigin_plot_chart_atlas1 field changedInput schema / properties / style_mode / defaultPrevious value: -"nature"New value: +"origin_default"origin_plot_color_mappedorigin_plot_column_stackorigin_plot_contourorigin_plot_dendrogramorigin_plot_errorbarorigin_plot_fill_areaorigin_plot_floating_barorigin_plot_heatmaporigin_plot_high_low_closeorigin_plot_imageorigin_plot_matrix_3d_scatterorigin_plot_matrix_3d_surfaceorigin_plot_matrix_contourorigin_plot_matrix_heatmaporigin_plot_matrix_idorigin_plot_pieorigin_plot_polarorigin_plot_polar_xr_ythetaorigin_plot_smithorigin_plot_stack_areaorigin_plot_stack_barorigin_plot_ternaryorigin_plot_ternary_contourorigin_plot_type_coverageorigin_plot_vector_xyamorigin_plot_vector_xyxyorigin_plot_waterfallorigin_polynomial_fitorigin_query_knowledgeorigin_quitorigin_recommend_chartorigin_releaseorigin_remove_plot_from_graphorigin_rename_objectorigin_run_labtalk1 field changedInput schema / properties / capture_logAdded value: +{
+ "default": true,
+ "title": "Capture Log",
+ "type": "boolean"
+}origin_run_plot_matrixorigin_save_projectorigin_set_cell_valueorigin_set_column_designationsorigin_set_column_labelsorigin_set_graph_pageorigin_smoothorigin_sort_worksheetv0.1.0origin_add_calculated_columnorigin_add_graph_labelorigin_add_plot_to_graphorigin_add_reference_lineorigin_append_tableorigin_apply_image_panel_styleorigin_apply_nature_styleorigin_apply_publication_styleorigin_arrange_layersorigin_batch_plot_from_templateorigin_capabilitiesorigin_change_plot_dataorigin_change_plot_typeorigin_chart_atlas_routeorigin_clear_worksheetorigin_delete_columnsorigin_delete_objectorigin_descriptive_statsorigin_detachorigin_diagnose_graphorigin_differentiateorigin_export_all_graphsorigin_export_graphorigin_export_previeworigin_export_worksheet_csvorigin_force_quitorigin_format_graphorigin_format_legendorigin_get_cell_valueorigin_get_default_plot_configorigin_get_graph_infoorigin_get_layer_infoorigin_get_worksheet_infoorigin_import_csvorigin_import_excelorigin_import_fileorigin_import_tableorigin_inspect_exportorigin_integrateorigin_linear_fitorigin_list_fit_functionsorigin_list_graph_templatesorigin_list_projectorigin_new_projectorigin_nonlinear_fitorigin_nonlinear_fit_structuredorigin_open_projectorigin_peak_findorigin_pingorigin_plot_3d_barsorigin_plot_3d_errorbarorigin_plot_3d_ribbonorigin_plot_3d_scatterorigin_plot_3d_surfaceorigin_plot_3d_vectororigin_plot_areaorigin_plot_barorigin_plot_boxorigin_plot_bubbleorigin_plot_bubble_color_mappedorigin_plot_candlestickorigin_plot_chart_atlasorigin_plot_color_mappedorigin_plot_columnorigin_plot_column_stackorigin_plot_contourorigin_plot_dendrogramorigin_plot_errorbarorigin_plot_fill_areaorigin_plot_floating_barorigin_plot_from_rangeorigin_plot_heatmaporigin_plot_high_low_closeorigin_plot_histogramorigin_plot_imageorigin_plot_lineorigin_plot_line_symbolorigin_plot_matrix_3d_scatterorigin_plot_matrix_3d_surfaceorigin_plot_matrix_contourorigin_plot_matrix_heatmaporigin_plot_matrix_idorigin_plot_pieorigin_plot_polarorigin_plot_polar_xr_ythetaorigin_plot_scatterorigin_plot_smithorigin_plot_stack_areaorigin_plot_stack_barorigin_plot_table_idorigin_plot_ternaryorigin_plot_ternary_contourorigin_plot_type_coverageorigin_plot_vector_xyamorigin_plot_vector_xyxyorigin_plot_waterfallorigin_polynomial_fitorigin_quitorigin_read_worksheetorigin_releaseorigin_remove_plot_from_graphorigin_rename_objectorigin_run_analysisorigin_run_labtalkorigin_run_plot_matrixorigin_save_projectorigin_set_axisorigin_set_cell_valueorigin_set_column_designationsorigin_set_column_labelsorigin_set_graph_pageorigin_set_plot_styleorigin_smoothorigin_sort_worksheetorigin_write_worksheetEach tool has a clearly distinct purpose, with names and descriptions that prevent ambiguity. Even closely related tools like origin_plot and origin_plot_auto have well-delineated roles.
All tools follow the consistent pattern 'origin_verb_noun' in snake_case, making the naming predictable and easy to understand.
25 tools is on the higher side, but the scope of the Origin server (graphing, analysis, bridge tasks, knowledge) justifies the count. Some consolidation of plotting tools could be considered, but each serves a distinct function.
The tool surface covers major domains (import, worksheet read/write, plotting, analysis, knowledge, bridge tasks) but lacks some lifecycle operations (e.g., update/delete for worksheets) and analysis is only via a single generic tool.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Open, inspect, filter, edit and convert xlsx and csv files from your AI chat. Processing is local.
AI access to Quadratic spreadsheets: open files, run Python/SQL, query connected databases.
Connect AI assistants to Google Sheets through controlled tools for reading and updating rows.
Operate Obriym CRM from your AI assistant: leads, deals, orders, catalog, stock, marketplaces.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Ge-Shun/origin-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
