Skip to main content
Glama
Solitario119

IC-CAP MCP Server

by Solitario119
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

tablevar_get

Retrieve table field values from IC-CAP Transforms and Plots, with disambiguation for same-name conflicts.

Instructions

Get a table field value. Works on any IC-CAP object that has table fields: Transform ('transform_path/Program' for PEL content), Plot ('plot_path/Report Type', 'plot_path/X Data', 'plot_path/Y Data N'), etc. Use tablevar_exists first to verify the field exists. When a path has both a Transform and a Plot with the same name, reads default to the Transform and the result is annotated with conflict=true / resolved_as='Transform' (all common table fields are Transform-exclusive); pass object_type='Plot' to read the Plot side — when any non-Plot object (Transform, Input, or Output) shares the Plot's name, the read runs inside an automatic rename-aside transaction (conflict=true, resolved_as='Plot', via='rename_txn') that restores the original name afterwards. Reading a field the object does not own (e.g. Program on an empty-Function grouping transform, 'Plot 0' on an XY GRAPH) returns ICCAP_FIELD_NOT_APPLICABLE instead of touching the C API; use transform_get_fields / plot_get_fields to introspect first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
eval_varNoEvaluate value: Y=yes, T=yes, N=no (default), F=noN
object_typeNoDisambiguation hint for name conflicts. Unset reads the sole owner (and defaults to the Transform on Transform/Plot conflicts). 'Plot' reads the Plot; on conflict paths this runs inside an automatic rename-aside transaction.
tablevar_pathYesFull path including field name, e.g. '/model/dut/setup/transform_name/Program'

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.3
    • changedInput schema / properties / object_type / description
      Previous value: -"Disambiguation hint for Transform/Plot name conflicts. Unset or 'Transform' reads the Transform (safe default on conflict paths). 'Plot' only succeeds when no conflict exists: with a conflict the C API cannot reach Plot fields and the call fails with ICCAP_FIELD_NOT_APPLICABLE (rename the Plot first to read Plot fields)."New value: +"Disambiguation hint for name conflicts. Unset reads the sole owner (and defaults to the Transform on Transform/Plot conflicts). 'Plot' reads the Plot; on conflict paths this runs inside an automatic rename-aside transaction."
  2. First observedv0.2.2

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses conflict resolution (defaults to Transform, conflict=true / resolved_as='Transform'), the rename-aside transaction with restoration, and the ICCAP_FIELD_NOT_APPLICABLE path instead of touching the C API.

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

Conciseness5/5

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

Front-loaded with the core purpose, then layered details about verification, conflict handling, and error behavior. Despite being long, every sentence carries non-redundant information necessary for correct use of a complex tool.

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

Completeness5/5

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

The description is highly complete for a tool with no output schema and no annotations: it covers when to verify existence, how conflicts resolve, the transaction side effect and restoration, and the not-applicable return behavior. Any remaining expectations about value formats are field-dependent and not reasonably specifiable here.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description adds meaningful context for object_type and tablevar_path by giving concrete path examples and explaining conflict-driven transaction behavior. eval_var is not elaborated beyond the schema, but the description adds enough beyond the bare parameter list to merit a 4.

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

Purpose5/5

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

States a specific verb and resource ('Get a table field value') and clarifies it applies to IC-CAP objects with table fields, including Transform and Plot. The examples and references to introspecting with transform_get_fields / plot_get_fields help distinguish it from sibling tools like tablevar_exists, tablevar_set.

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

Usage Guidelines4/5

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

Clearly advises using tablevar_exists first and using transform_get_fields / plot_get_fields to introspect before reading, which gives concrete usage guidance. It does not explicitly contrast with tablevar_set or object_get_val as alternatives, but the guidance is actionable enough for an agent.

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

Deploy Server

Other Tools