Skip to main content
Glama
Sign In
PVsyst CLI MCP

PVsyst CLI MCP

by Anonymousnake
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

pvsyst_update_component

Edit allowlisted component text fields with automatic backup; dry runs return diffs and SHA checks reject stale writes. Use to safely update PVsyst workspace components.

Instructions

[Components] Edit allowlisted text fields in one workspace component with automatic backup. dry_run returns a diff and candidate SHA without writes. Pass the inspected expected_sha256 to reject stale edits. PAN ISC/Isc and MuISC/muISC are aliases for root physical fields; edits retain the file's spelling and reject duplicate aliases. curve_updates accepts OND Version=8.1.6 single-voltage Converter/ProfilPIO Mode=1 points in watts, or BTR Version=8.1.6 AGM/Gel CapaCourant/Capa_DischRate Mode=1 points as [discharge hours, capacity relative to C10]. BTR requires positive points, increasing X, nondecreasing Y, coverage of 100h and C100/C10 in [1.15,1.45]. Supply the complete table of 4..256 points; X >= 1e-9 and X gaps >= 1e-8. Count changes require point_count_editable from inspection and synchronize NPtsMax/NPtsEff/Point_N rows. Curves require expected_sha256; pass updates={} for curve-only edits. Automatic curves require explicit use_file_curve=true alongside points to clear the root automatic-profile bit. For BTR, this opt-in renames the supplied Capa_DischRate block to CLI's CapaCourant; all other tags and Flags are preserved. Use the current path from inspection. Three-voltage OND, other BTR curves and legacy PAN are read-only. commercial_updates edits/adds the Version=8.1.6 commercial form fields returned by inspection, including dimensions in metres and weight in kg. PAN Width/Height also update LargApp/LongApp when present; absent legacy root dimensions are not added to GUI-format files. Identity changes synchronize a tab-separated root Comment. remarks replaces up to five lines ([] clears); PAN's fifth line may encode functional options. These operations require expected_sha256 and share the preview/backup. Seller prices, flags and model fitting are separate from this form. curve_csv alternatively accepts one path-to-CSV-text entry; never combine it with curve_updates. Header: input_watts,output_watts for OND or discharge_hours,relative_capacity for BTR. Use comma-separated decimal numbers with decimal dots, 4..256 point rows and at most 64 KiB of UTF-8 text. The same curve guards, preview and backup apply. No file is read from a caller-supplied path; supply the CSV contents. Physical behavior requires simulation; derived scalars are not refitted. A no-op returns changed=false without creating a backup.

Input Schema

NameRequiredDescriptionDefault
dry_runNo
remarksNo
updatesYes
filenameYes
curve_csvNo
curve_updatesNo
component_typeYes
use_file_curveNo
expected_sha256No
commercial_updatesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/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 backup behavior, dry-run previewing, stale-edit rejection, alias handling, curve validation rules, read-only exclusions, and no-op behavior. It also clarifies that no caller-supplied file path is read for CSV mode.

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

Conciseness3/5

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

The description front-loads the main purpose, but it is a dense wall of technical text with no headings or bullets, making it hard to scan. Much of the detail is justified by the complex tool, but the structure could be clearer.

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?

For a 10-parameter mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is largely complete on behavior and validation. The main omissions are component_type valid values and fuller success-return semantics beyond dry_run and no-op cases.

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 0%, so the description must compensate, and it does extensively for dry_run, curve_updates, curve_csv, commercial_updates, remarks, use_file_curve, and expected_sha256. However, it does not define allowed component_type values and only partially enumerates the allowlisted keys for the central updates object.

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 states a specific verb and resource: editing allowlisted text fields in one workspace component, with automatic backup. It distinguishes this from adjacent operations such as seller prices, flags, and model fitting, and it identifies read-only component classes.

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 substantial when-to-use guidance: dry_run for diffs without writes, expected_sha256 to reject stale edits, curve_updates versus curve_csv, updates={} for curve-only edits, and when use_file_curve is required. It also marks several cases as read-only, though it does not explicitly name sibling tools to use instead.

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