Skip to main content
Glama
PVsyst CLI MCP

PVsyst CLI MCP

pvsyst_convert_meteo

Convert staged CSV, MEF, and SIT files into a new MET weather file for PVsyst simulations.

Instructions

[Sites & Weather] Convert a staged CSV + MEF in Meteo and SIT in Sites to a NEW MET.

Input Schema

NameRequiredDescriptionDefault
csv_nameYes
mef_nameYes
met_nameYes
sit_nameYes
log_levelNo
timeshiftNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden and it is a single line. 'NEW MET' implies a new file is written rather than an existing one being overwritten, but nothing is said about whether the source CSV/MEF/SIT are consumed or left intact, whether existing MET files are replaced, or what errors occur if a named input is missing.

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

Conciseness4/5

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

One sentence preceded by a bracketed domain tag, front-loaded and free of padding. Brevity is achieved partly by omitting information, but no sentence is wasted.

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

Completeness2/5

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

This is a multi-file transformation with no annotations, no output schema, and zero parameter documentation, yet the description is one line. An agent could not reliably tell what the resulting MET contains or how timeshift affects the conversion.

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

Parameters2/5

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

Schema description coverage is 0% and all six parameters appear as bare titles. The description only loosely implies the roles of csv_name/mef_name/sit_name/met_name through the sentence; it says nothing about timeshift, which is a meaningful integer offset with default 0, or about log_level.

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?

States a specific verb+resource: convert a staged CSV plus MEF (Meteo) and SIT (Sites) into a new MET file. That is concrete enough to distinguish the transformation from pure read tools like inspect_weather_csv. It stops short of naming which siblings to use instead, so 4 rather than 5.

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 statement of when to use this versus pvsyst_prepare_weather, pvsyst_acquire_weather, or pvsyst_build_monthly_weather, all of which sit in the same weather pipeline. The word 'staged' hints at a prerequisite state but the prerequisite is never spelled out.

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