Skip to main content
Glama
Solitario119

IC-CAP MCP Server

by Solitario119
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

tablevar_set

Set the value of an existing table field in IC-CAP projects, with validation to prevent false successes on Transform or Plot conflicts.

Instructions

Set an existing table field; this tool cannot create fields. Use tablevar_exists first. On Transform/Plot name-conflict paths, writes default to the Transform (result annotated with conflict=true); pass object_type='Plot' to write the Plot side — on conflict paths this runs inside an automatic rename-aside transaction (necessary because a direct write on a conflict path silently targets the non-Plot object and reports success). Plot writes are validated against the plot's actual field set first: writing a field the current Report Type does not own (e.g. 'Plot 0' on an XY GRAPH, which STFV would accept while writing nothing) returns ICCAP_FIELD_NOT_APPLICABLE listing the available fields — never a false success. Transform-side writes are validated the same way against the Function type.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueYesValue to set
object_typeNoDisambiguation hint. Unset writes the sole owner (and defaults to the Transform on Transform/Plot conflicts). 'Plot' writes the Plot; on conflict paths this runs inside an automatic rename-aside transaction.
tablevar_pathYesFull path including field name

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. Unset or 'Transform' writes the Transform (safe default on conflict paths). 'Plot' only succeeds without a name conflict; with a conflict the C API cannot reach Plot fields."New value: +"Disambiguation hint. Unset writes the sole owner (and defaults to the Transform on Transform/Plot conflicts). 'Plot' writes the Plot; on conflict paths this runs inside an automatic rename-aside transaction."
  2. First observedv0.2.2

TDQS

A4.6/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 handles it excellently. It discloses silent-targeting risk on conflict paths, the automatic rename-aside transaction, validation against the actual field set, the ICCAP_FIELD_NOT_APPLICABLE error behavior, and the promise of 'never a false success.' This is unusually transparent 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.

Conciseness4/5

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

The description is longer than average, but every sentence earns its place given the genuinely complex conflict and validation behavior. It is front-loaded with the core purpose and prerequisite, then proceeds logically through conflict handling and validation. Slight redundancy between the schema's object_type text and the description is the only minor inefficiency.

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?

For a mutation tool with no output schema and no annotations, the description is remarkably complete. It covers prerequisites, conflict behavior, side effects, validation semantics, and an error code with the available-fields listing. An agent has enough context to invoke the tool correctly and to interpret non-obvious outcomes. The only minor absence is a general return-format statement, but the description's conflict=true annotation reference partially covers results.

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, but the description adds real value beyond the schema. It clarifies that tablevar_path must reference an existing field, deepens the meaning of object_type by explaining conflict-path write targeting, and explains why the 'Plot' option requires the rename-aside transaction. Only 'value' receives no additional semantic detail, which is acceptable.

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

Purpose5/5

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

The opening sentence 'Set an existing table field; this tool cannot create fields' states a specific verb, resource, and constraint. It clearly differentiates from sibling tools like tablevar_get and tablevar_exists, and the explicit 'cannot create fields' removes ambiguity against creation-style tools.

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

Usage Guidelines4/5

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

The description gives explicit, actionable guidance: 'Use tablevar_exists first' names the required prerequisite. It also explains exactly when to pass object_type='Plot' versus defaulting to Transform on conflict paths, which is strong usage direction. It stops short of contrasting against all possible set-like siblings, but that is not essential here.

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