Skip to main content
Glama
Solitario119

IC-CAP MCP Server

by Solitario119
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

transform_create

Create an IC-CAP Transform with its function type and program content in one call, supporting PythonLocal, PEL, Equation, built-in extraction, and Optimize types.

Instructions

Create a Transform and optionally set its Function type and Program content in one call.

ORDERING: Transforms may be created before or after setup_import_mdm — both orders are supported (live-verified 2026-09-02). Engineer PEL programs conventionally start with an UPDATE_AUTO line, which makes the transform auto-execute on creation; with data already imported, that execution runs against real data.

TRANSFORM TYPES AND THEIR SYNTAX REQUIREMENTS:

  1. PythonLocal - Python script. Use transform_type='PythonLocal', program=''. Example: transform_create(transform_type='PythonLocal', program='print("hello")')

  2. PEL/Program - IC-CAP PEL script. Use transform_type='PEL', program=''. WARNING: PEL uses return statement to output data. Direct assignment like beta = ic/ib causes parse error "Direct assignment to the data set beta is not allowed. Use the RETURN statement." Correct: return ic/ib. WRONG: beta = ic/ib. Example: transform_create(transform_type='PEL', program='return ic/ib')

  3. Equation - Simple mathematical expression. Use transform_type='Equation' (or check funcdict for available types). Equations are evaluated directly; no return statement is needed. Note: IC-CAP requires lowercase 'equation' as function type; the handler auto-maps 'Equation' to 'equation'. Equation content is stored in the 'Input' field (NOT 'Program'); the handler handles this automatically. Example: transform_create(transform_type='Equation', program='ic/ib')

  4. Built-in - IC-CAP built-in extraction functions (e.g. BJTDC_is_nf, BJTDC_fwd_gummel, PNCAPsimu, RBBcalc). Use transform_type=''. Function is set automatically. Built-in transforms require table fields to be filled (data references to other setups/transforms). Inspect the transform's table fields with tablevar_get and consult the installed IC-CAP documentation for required fields. Example: transform_create(transform_type='BJTDC_is_nf') Then fill table fields: tablevar_set('/path/to/transform/Forward VC', 'fearly/vc')

  5. Optimize - Optimization transform. Use transform_type='Optimize'. Configure it with optimizer_setup or with transform_set_optim_field for individual fields. Example: transform_create(transform_type='Optimize') Then: optimizer_setup(transform_path='/path/to/optimize', ...)

Malformed transform types, programs, or fields can leave IC-CAP unresponsive. Always verify the created transform with transform_get_function.

Creating a Transform onto a name a Plot already uses creates a name conflict: the result then carries a warning (the Transform is never auto-renamed), and Plot-side field access afterwards requires object_type='Plot'. Prefer distinct names for new objects.

Consult the IC-CAP documentation installed with your licensed software for model- and version-specific transform fields.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
programNoProgram script content. For PEL: MUST use 'return' statement, NOT direct assignment. For PythonLocal: standard Python code. For Equation: mathematical expression without return.
functionNoLegacy alias for program parameter
overwriteNoDelete and replace an existing Transform only when explicitly enabled
transform_pathYesTransform path, e.g. '/model/dut/setup/my_transform'
transform_typeNoFunction type: 'PythonLocal', 'PEL', 'Optimize', 'Equation', or built-in name (e.g. 'BJTDC_is_nf', 'PNCAPsimu'). Check funcdict via transform_get_funcdict for available types.
allow_without_checkpointNoProceed only if an automatic pre-overwrite save fails; use with care

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.2

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses hazards ('Malformed transform types, programs, or fields can leave IC-CAP unresponsive'), syntax pitfalls (PEL return statement requirement with exact error text), automatic behaviors (Equation auto-mapping and Input field storage), and name-conflict side effects including the warning and object_type requirement.

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

Conciseness5/5

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

The description is long but every section earns its place: a front-loaded purpose, ordering note, type-by-type syntax with warnings, and follow-up verification. Headings and examples make it scannable, and there is no filler or repetition.

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

Completeness4/5

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

The description is highly complete for a complex tool with no output schema: it covers ordering, type syntax, side effects, and hazards. The only gap is that it never explicitly states the return value or success indication, though it mentions 'the result then carries a warning' in the name-conflict case. A brief return-value note would make it fully self-contained.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema. It explains program semantics for each transform_type, gives examples for PythonLocal, PEL, Equation, Built-in, and Optimize, and clarifies the function alias. This far exceeds the schema's short property descriptions.

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

Purpose5/5

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

The opening sentence states a specific verb and resource: 'Create a Transform and optionally set its Function type and Program content in one call.' This clearly distinguishes it from related tools like transform_set_function by emphasizing combined creation and configuration. The subsequent type sections reinforce this purpose with concrete examples.

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

Usage Guidelines5/5

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

The description provides rich when-to-use guidance: ordering relative to setup_import_mdm, per-type parameter requirements, and explicit alternatives such as 'Configure it with optimizer_setup or with transform_set_optim_field' and 'Inspect the transform's table fields with tablevar_get.' It also recommends verification with transform_get_function, covering both usage and follow-up.

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