Skip to main content
Glama
Sign In
PVsyst CLI MCP

PVsyst CLI MCP

by Anonymousnake
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

pvsyst_get_variant_parameters

Reads stored parameters for a PVsyst project variant—orientations, subarray losses, system settings, power controls, P50/P90, and generator/shading state—to verify native inputs without editing them.

Instructions

[Projects & Variants] Inspect orientations, including native SummerTilt/WinterTilt (degrees), WinterMonths (raw month bitmask) and UsesTiltAver. Seasonal FieldTilt=0 is not the effective seasonal angle; these fields are read-only here, not a mode editor. Inspect owning subarray LIDLoss/PMismMPP percent, raw PQualityModU/I/P and Flags, variant_name from the header only (null if absent/duplicate there; late-root name ambiguity is not validated), utf8_bom (raw UTF-8 names do not prove BOM-less native decoding), main_array UFactor (W/m2/K)/Flags/Flags2, main_array.soiling, native grid_limit, auxiliaries, horizon, inverter_temperature and power_factor state, power_controls (verified PF/grid combinations), p50_p90 (existing native result-template parameters), and standalone generator settings/thresholds. Unsupported system forms report an issue; system_parameters exposes unique owning SystemType/Flags/TempShift/TempFixed/ TanPhi/PLimGrid/LimGrSeparLoss as raw text; missing or duplicate fields are omitted. Native temperature fields use degC; TanPhi is not a computed PF, and PLimGrid units depend on the native mode (kW or kVA). Nested owning object fields are excluded; this does not widen write support. Read-only transformers, system_unavailability, peak_shaving and shading_scene expose stored native layers, outage periods, strategy and scene declarations. Active shading_scene.pv_bindings additionally exposes one/two native8.1.6 PVCollada PV-table declarations: raw automatic labels/creation counters, stored orientation IDs, module counts and native DOrigine metres (NOT house/PVCollada coordinates). Cross-checks ordinary fixed-plane references, three angle fields and per-plane saved module totals. stored_consistent means these declarations agree, not source geometry/identity, circuit topology or native consumption verified. Unsupported/malformed records retain the scene's active declaration and report an issue, never an empty/verified scene. Generic meshes are not decoded. These are not computed electrical quantities or dispatch. Ageing reports its stored template fields; IAM includes native FresnelSmooth/UserProfile point tables without evaluating them. A broader readable P50 root state does not widen writing.

Input Schema

NameRequiredDescriptionDefault
projectYes
variantYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.6/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 behavioral burden and does so extensively: it clarifies read-only status, raw vs computed fields, omitted/malformed fields, unsupported system forms, units such as degC and W/m2/K, and that stored_consistent does not imply verified geometry. It lacks prerequisites and auth needs, but exposes substantial operational caveats.

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 description is a dense, semicolon-heavy block with no front-loaded summary and long tangential field enumerations. It is information-rich but poorly structured and likely to obscure the main purpose.

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?

With no output schema, the description usefully enumerates many returned fields and caveats, which is valuable for a complex inspection tool. However, it omits input parameter semantics and lacks a concise high-level orientation, leaving clear gaps.

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

Parameters1/5

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

Schema description coverage is 0% and both required parameters (project and variant) are completely undocumented in the description. The description adds no meaning about identifier formats, expected values, or selection rules for these inputs.

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

Purpose3/5

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

The description says 'Inspect orientations...' and then enumerates many variant parameter fields, so the resource is identifiable, but there is no single concise statement of overall purpose. It distinguishes from write tools only obliquely with 'read-only here, not a mode editor' and 'does not widen write support'.

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

Usage Guidelines2/5

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

There is no explicit when-to-use or when-not-to-use guidance, and no sibling tool is named as an alternative. The mention of read-only behavior implies inspection rather than editing, but an agent must infer the selection criteria.

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