Skip to main content
Glama
Solitario119

IC-CAP MCP Server

by Solitario119
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

plot_setup

Creates and configures IC-CAP plots in one call, supporting all report types. Automatically resolves name conflicts and validates field mapping per plot type.

Instructions

Create and fully configure a Plot in one call, never creating a name conflict. Supports all IC-CAP report types: XY GRAPH, SMITH PLOT, POLAR PLOT, RI GRAPH, SCATTER PLOT, HISTOGRAM, CDF PLOT, MULTI PLOT. Field mapping is live-verified per type: XY GRAPH traces go to 'Y Data 0..7' + '# of Traces'; SMITH/POLAR/RI use 'Sweep Data' + 'Smith/Polar/RI Data 0..7'; SCATTER PLOT takes a single 'Y Data' (only y_data[0] is used); HISTOGRAM/CDF PLOT take a single 'Data-set' (pass data_set, or y_data[0]); MULTI PLOT takes sub-plot names in y_data -> 'Plot 0..N' + '# of Plots' (set 'Orientation' afterwards via tablevar_set). Conflict guard: when a Transform/Input/Output already uses the requested name, the Plot is auto-suffixed '_plot' ('_plot2', ... on collision) and the response reports name_adjusted/final_name. Reconfiguring an existing conflicted Plot (overwrite=true) writes fields through a rename-aside transaction.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
headerNoOptional plot header text
x_dataNoX-axis or sweep data source name. Maps to 'X Data' (XY/SCATTER) or 'Sweep Data' (SMITH/POLAR/RI)
y_dataNoTrace data source names. Maps to 'Y Data 0..N' (XY), 'Smith/Polar/RI Data 0..N', single 'Y Data' (SCATTER, only first item used), or 'Data-set' (HISTOGRAM/CDF, first item used when data_set is omitted)
data_setNoData-set source for HISTOGRAM / CDF PLOT. Optional; falls back to y_data[0].
overwriteNoDelete and replace an existing Plot only when explicitly enabled
plot_pathYesPlot path, e.g. '/model/dut/setup/my_plot'
curve_dataNoCurve data source for parameterized plots (SMITH/POLAR/RI/XY). Optional.
object_typeNoReserved; plot_setup always creates a Plot. Omit or pass 'Plot'.
report_typeNoReport type: XY GRAPH (default), SMITH PLOT, POLAR PLOT, RI GRAPH, SCATTER PLOT, HISTOGRAM, CDF PLOTXY GRAPH
x_axis_typeNoX axis: LINEAR (default), LOG10, dB. Only used by XY GRAPH and SCATTER PLOT.LINEAR
y_axis_typeNoY axis: LINEAR (default), LOG10, dB. Only used by XY GRAPH and SCATTER PLOT.LINEAR
allow_without_checkpointNoProceed only if an automatic pre-overwrite save fails; use with care

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.2.3
    • addedInput schema / properties / data_set
      Added value: +{
+  "description": "Data-set source for HISTOGRAM / CDF PLOT. Optional; falls back to y_data[0].",
+  "type": "string"
+}
    • changedInput schema / properties / object_type / description
      Previous value: -"Set to 'Plot' when a Transform with the same name exists, to avoid IC-CAP hang."New value: +"Reserved; plot_setup always creates a Plot. Omit or pass 'Plot'."
    • changedInput schema / properties / y_data / description
      Previous value: -"Trace data source names. Maps to 'Y Data' (XY/SCATTER), 'Smith Data' (SMITH), 'Polar Data' (POLAR), 'RI Data' (RI)"New value: +"Trace data source names. Maps to 'Y Data 0..N' (XY), 'Smith/Polar/RI Data 0..N', single 'Y Data' (SCATTER, only first item used), or 'Data-set' (HISTOGRAM/CDF, first item used when data_set is omitted)"
  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, the description carries full responsibility, and it excels: it discloses the conflict-avoidance auto-suffixing, the overwrite=true rename-aside transaction, and the per-type live-verified field mapping. It also implicitly communicates that the tool can delete existing plots when overwrite is enabled, via the parameter description, but the main description adds significant behavioral context.

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

Conciseness4/5

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

The description is dense but well-organized, front-loading the core purpose before diving into type-specific mappings. It avoids redundancy and every sentence contributes to the agent's understanding. While it is long, the complexity of the tool justifies the detail.

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 tool with 12 parameters and no output schema, the description covers all major facets: supported report types, field mappings, conflict resolution, overwrite semantics, and response details (name_adjusted/final_name). It leaves no critical ambiguity for an agent deciding whether and how to call it.

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

Parameters4/5

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

The schema already provides 100% coverage for all 12 parameters, so the baseline is 3. The description adds substantial value by explaining how parameters like y_data map differently per report type and how data_set falls back to y_data[0], which is not fully captured in the schema. This enriches the semantics beyond the schema alone.

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

Purpose5/5

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

The description opens with a specific verb phrase 'Create and fully configure a Plot' and immediately adds the unique guarantee 'never creating a name conflict', which clearly distinguishes this tool from siblings like plot_get_fields or plot_display. It enumerates all supported report types, making its scope unambiguous.

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 clearly states what the tool does and its scope (all report types, live-verified field mapping), but it does not explicitly name alternative tools or conditions under which to choose a different tool. However, its role as the one-call setup tool is implied, and the conflict-guard behavior suggests when it should be preferred over object_create.

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