Skip to main content
Glama
Sign In
PVsyst CLI MCP

PVsyst CLI MCP

by Anonymousnake
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

pvsyst_create_grid_storage_system

Create a new AC-coupled grid storage variant from an existing PV-only grid design using explicit battery, SOC, load, and efficiency inputs; preview or apply without editing the source.

Instructions

[Loads & Storage] Preview or create a NEW native AC-coupled storage VC from an existing PV-only Grid design. Require explicit workspace loose BTR, series/parallel counts, twelve monthly battery temperatures, cycle/static initial SOW, complete SOC fractions, charger AC-input/battery inverter AC-output kW limits and percent efficiencies. No hardware or climate defaults are inferred. Bind a prepared v1 hourly load record and both current source/normalized CSVs into an explicit MJ snapshot. Enable root self-consumption bit19 and existing native Grid/battery system bits; retain other flags and PV/component/site/weather/geometry fields. Optional allow_grid_export toggles only system no-injection bit27; omission preserves the source setting. This controls export, not grid charging or DC coupling. Creates only one new VC, never edits the source or replaces files. SelfConsumption and WeakGrid use PVAvailable/Immediate. WeakGrid requires a complete explicit availability CSV declaration matching the prepared load year and standard UTC offset, with at least one outage. Bind native pvUnavail/HourlyVal ratio snapshots; SOCDischSelf preserves reserve with grid available and allows discharge toward SOCDischDecl during outages. It is unused as a backup reserve in SelfConsumption. Backend is pvsyst_native_ac_coupled, not hybrid DC battery-port modelling, a new BMS model or a grid-charge tariff controller. Creation does not simulate or certify sizing; verify native E_User, SOC and energy in the matching year/timezone before treating configuration as consumed. Non-ASCII new load/component paths add a disclosed BOM to the NEW VC only.

Input Schema

NameRequiredDescriptionDefault
batteryYes
dry_runNo
projectYes
storageYes
new_variantYes
availabilityNo
source_variantYes
allow_grid_exportNo
load_manifest_nameYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden well: it states no defaults are inferred, describes binding prepared records, enabling flag bits, retaining other flags, creating only one new VC, never editing the source, not simulating, and adding a BOM for non-ASCII paths. It still does not explain dry_run behavior, failure modes, or return values.

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 purpose is front-loaded, but the description is a dense wall of technical jargon with many tightly packed clauses. Much of the content is substantive, yet it could be structured more clearly and would benefit from trimming or bullet-like separation.

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

Completeness3/5

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

This is a complex nine-parameter mutation with no annotations and no output schema, so the description needs to be comprehensive. It provides rich behavioral and nested-field context, but leaves key operational details like dry_run semantics, return behavior, and several top-level parameter meanings under-specified.

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

Parameters3/5

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

Schema description coverage is 0%, and the description compensates for many nested fields by naming series/parallel counts, monthly temperatures, SOW, SOC fractions, power limits, efficiencies, and availability requirements. However, top-level parameters such as project, source_variant, new_variant, dry_run, and load_manifest_name are left mostly implicit.

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

Purpose4/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: preview or create a new native AC-coupled storage VC from an existing PV-only Grid design. It also distinguishes the operation from hybrid DC battery-port modelling and grid-charge tariff control, though it does not explicitly name sibling 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 context is clear: use this for an AC-coupled native storage variant from a PV-only Grid design, with explicit requirements for WeakGrid availability. It includes some exclusions such as not being a hybrid DC model, but it does not name alternative sibling tools or state when to prefer them.

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