Skip to main content
Glama
PVsyst CLI MCP

PVsyst CLI MCP

pvsyst_simulate_template

Preflight or run a template-based full-year PVsyst grid simulation without the GUI, validating inputs first and returning energy, reports, and manifests without overwriting existing files.

Instructions

[Simulation] Preflight or execute one template-to-full-year grid simulation without GUI. Supply an existing valid PRJ/VC, loose text PAN/OND, workspace SIT/MET, tilt, year and a NEW project filename. Missing inputs return field-specific issues. Native MET root date declarations are checked before creating the working project; generic-1990, absent or unreadable dates remain disclosed, not inferred from filenames. Scope: completely checked single subarray/fixed plane, no active shading/layout, PRCorrTemp=False; retain template counts unless capacity is explicitly supplied. capacity plans integer series/strings/inverters against declared design voltages, currents, temperatures, IEC/UL module voltage rating and maximum DC:AC ratio. Require independent unshared 8.1.0/8.1.6, one repeatable inverter/MPPT/string branch, full hardware MPPT population and crystalline PAN at STC; mode/topology stays intact. Design envelope/source are required, not guessed from raw temperature coefficients. No native temperature-model reproduction, hardware selection or design certification. Optional weather_manifest_name binds prepare_weather provenance to the requested year/SIT/MET, explicitly loads native weather, and compares hourly GHI/DHI/Tamb; changed files stop before writes. Conversion/rounding concerns remain needs_review. dry_run=true (default) writes nothing and consumes no simulation execution. dry_run=false copies/configures the project, runs Jan 1 through Dec 31 hourly, validates native context/complete year, and returns energy, standard PR, IL_Pmax, warnings, CSV/PDF/SFI and a persisted JSON manifest with reverse recovery steps. Existing project/output files are never overwritten. Failure retains the original template and working files/backups/manifest; no automatic retry or destructive cleanup. status is blocked/ready/completed/needs_review/failed; inspect it, not just MCP is_error. Extreme IL_Pmax versus STC reference energy triggers a disclosed review heuristic, not a claim of native physical validation or an automatic model repair. Year is 1969..2068 due to two-digit native CSV dates. Restart host for this tool. azimuth overrides the template plane azimuth in -180..180 degrees (zero south, west positive); losses accepts only LIDLoss, PMismMPP and ModuleQualityLoss on the subarray plus UFactor on the whole main array. Template fields left unspecified keep their saved values, and the returned configuration_summary discloses the requested angles and losses; no loss is fitted, inferred or defaulted. Optional report_pages is a nonempty list of native page names (for example ["summary", "losses"]); omit it for the default complete report. Invalid pages stop in preflight, and the request/manifest records the selection. Explicit tracking + tracking_variant selects an existing verified native8.1.6 UnlimTracking template flow instead: omit tilt/azimuth/capacity/losses; exact source PAN/OND database references and equipment counts stay inherited. This branch requires explicit positive nominal_dc_power_kw and printable tracking_power_source; these are declarations cross-checked against native PR, not guessed from names/cached sizing. Loose workspace/builtin model shadows stop; database internals are not inspected or snapshotted. Only CLI8.1.6rev49278, and completed consumption retains needs_review. Reuses create_tracking_variant to create a NEW VC in the isolated clone, then the same yearly native load/report/ context/integrity checks plus finite actual columns and GlobShd. No type conversion, arbitrary geometry or other tracker families. native_consumption_verified becomes true only after validated completion, not engineering certification. Its recovery is review/manual archive of the entire new clone/VC/outputs; no stale per-file undo, automatic retry/resume, deletion or repeat on an existing project/output.

Input Schema

NameRequiredDescriptionDefault
tiltNo
yearNo
lossesNo
azimuthNo
dry_runNo
variantNo
capacityNo
met_nameNo
ond_nameNo
pan_nameNo
trackingNo
site_nameNo
new_projectNo
report_pagesNo
template_projectNo
tracking_variantNo
nominal_dc_power_kwNo
tracking_power_sourceNo
weather_manifest_nameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does most of it: dry_run writes nothing, execution copies/configures the project, runs Jan 1–Dec 31 hourly, validates native context, returns energy/PR/IL_Pmax/warnings/CSV/PDF/SFI plus a persisted manifest, never overwrites existing files, and retains originals on failure. It omits some operational detail an agent might want, such as expected runtime or concurrency limits, and a few preflight checks are only implied by 'field-specific issues.'

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

Conciseness2/5

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

The purpose is front-loaded, but the body is a dense multi-hundred-word block of run-on semicolon sentences mixing scope, prerequisites, parameter semantics, failure behavior, and recovery in no clear hierarchy. Almost every clause carries real information, yet the lack of structure makes it hard to scan; a short bulleted or sectioned layout would preserve content with far better readability.

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 19-parameter, no-output-schema, no-annotation simulation tool, the description supplies what's missing: status semantics (blocked/ready/completed/needs_review/failed, inspect status not is_error), failure and recovery behavior, overwrite policy, host-restart requirement, and the tracking-branch variant of the flow. Nothing essential to calling it safely appears absent.

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 description coverage is 0%, so the description must compensate and largely does: it explains azimuth (-180..180, zero south, west positive), accepted loss keys and their array targets, report_pages semantics and default, tracking branch requirements (nominal_dc_power_kw, tracking_power_source, omit tilt/azimuth/capacity/losses), weather_manifest_name provenance binding, and the year range 1969..2068. It leaves several string parameters (site_name, met_name, pan_name, ond_name, variant, template_project) unexplained beyond their names.

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?

Opens with a specific verb+resource: 'Preflight or execute one template-to-full-year grid simulation without GUI,' and the scope sentences (single subarray/fixed plane, no shading/layout, PRCorrTemp=False) sharpen what kind of simulation. It does not name a sibling to distinguish from pvsyst_run_simulation or pvsyst_simulate_design, so differentiation is inferred from the template-based flow rather than stated.

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?

Explicitly states when to preflight (dry_run=true, the default) versus execute (dry_run=false), with detailed prerequisites: independent unshared 8.1.0/8.1.6, repeatable inverter/MPPT/string branch, full MPPT population, crystalline PAN at STC, required design envelope. Exclusions are equally explicit: no native temperature-model reproduction, no hardware selection, no design certification, no active shading/layout, no automatic retry or destructive cleanup.

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