Skip to main content
Glama
PVsyst CLI MCP

PVsyst CLI MCP

pvsyst_run_house_task

Runs an AI-authored residential PV project through PVsyst using a bound northern-site template, verifies mesh and PV regions, then performs annual simulation with guarded artifacts.

Instructions

[Simulation] Deliver one AI-authored residential project through existing native entries. Source must be the existing bounded fixed PV-only northern-site template, with identical bound workspace SIT/MET in PRJ/VC. Hardware/counts/angles/losses, source engineering defaults and weather remain inherited and disclosed, never sized or guessed. AI supplies a complete mesh house and one/two placed PV regions in spec; all module counts/source-PAN metadata and native8.1.6CN/DPI96 boundaries remain. Two source orientations require one explicitly named region per orientation1/2, the same PAN/OND, anchor azimuth zero and distinct source planes. Native table properties assign each plane and place its declared coordinates; SHD exports, saved VC and actual GUI reload verify every mesh/region before the annual run. Optional spec.shading_mode=module_layout invokes the native detailed electrical layout path for two landscape zero-spacing, single-string groups and exports ShdElec. Omitting it preserves the original request/checkpoint representation. Optional spec.scene_import_method="native" routes the SAME supported two-fixed-table recipe through the existing headless native importer (no GUI/INI/clipboard) and records the new variant as STORED-only: stored_geometry_verified (and stored_module_layout_verified for module_layout) may be true, while imported/native_geometry_verified/native_reload_verified and native_consumption_verified stay false until the normal CLI simulation consumes that VC. Omitting it keeps the original GUI import route and request/checkpoint shape; unsupported recipes stop with a concrete issue before writing and there is no silent GUI fallback. Preview writes nothing/does not activate or launch GUI; cold execution requires dry_run=false and confirm=true, configured DataPath and NO preexisting native GUI. It exclusively creates a working PRJ/VC0, PVC2 and SFI, opens one owned GUI, imports/ associates/checks/shading-tables/SavesAs one NEW native variant, then normally closes only its actual Popen. Unknown dialogs/unsaved-work questions are not dismissed. A NEW CLI process reloads the saved variant, recomputes native shading and generates the explicit full-year CSV/PDF. Completeness/context/finite columns/GlobShd and source preservation are checked using existing result validators; no replacement PV model. File creation, native save and simulation-consumption remain distinct checkpoints. Results/_house_task.json records the exact request and guarded files; existing artifacts are never overwritten/deleted. Resume requires the IDENTICAL spec and explicit resume=true; no checkpoint PID grants ownership. Partial unverified native saves need inspection, not blind reimport. A failed run keeps its outputs: explicit retry_simulation=true chooses NEW attempt names, without rebuilding the saved scene. A completed retry-free resume revalidates artifacts and runs no new GUI/simulation. Status/phase/issues matter, not just MCP is_error; any unexpected stop retains evidence. Process coordination is one server/workspace RLock, not a global desktop/task service.

Input Schema

NameRequiredDescriptionDefault
specYes
resumeNo
confirmNo
dry_runNo
retry_simulationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/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 substantial work: it enumerates the artifacts created (working PRJ/VC0, PVC2, SFI, one new native variant), the GUI lifecycle (opens one owned GUI, closes only its actual Popen), non-overwrite semantics for existing artifacts, the file/native-save/simulation-consumption checkpoint separation, and the stored_geometry_verified vs. native_consumption_verified flag semantics. Verbosity and unexplained internal jargon ('native8.1.6CN/DPI96 boundaries') keep it from being fully transparent despite the breadth of disclosure.

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?

A single dense paragraph crammed with domain jargon and capitalized internal steps; the most actionable constraints (preview, confirm, resume) sit in the back half behind opaque setup prose. Bullets or a short front-loaded summary would help an agent parse this substantially faster.

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?

Given a destructive, multi-checkpoint GUI/simulation orchestrator with no annotations and no output schema, the description covers side effects, resumption and retry well, but never states the return value/status shape beyond a JSON checkpoint file path, gives no cost/timing expectation, and offers no sibling routing.

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%, so the description must carry parameter meaning; it does explain dry_run, confirm, resume, retry_simulation, spec.shading_mode=module_layout and spec.scene_import_method="native" with real behavioral consequences. But spec.year, spec.report_pages, spec.module_geometry and the NamedPVTablesLayout vs. PlacedPVTableLayout choice are only glancingly covered, leaving several parameters documented nowhere.

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 opening sentence ('Deliver one AI-authored residential project through existing native entries') is vague — 'deliver' and 'entries' don't identify the operation, and the actual action (create a new project/variant from a bounded source template, build a mesh house + placed PV regions, run the annual simulation) only emerges scattered through later clauses. The constraint 'Source must be the existing bounded fixed PV-only northern-site template' partially scopes it, but there is no explicit differentiation from close siblings like pvsyst_run_sourced_house_task or pvsyst_create_house_pv_scene.

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?

Strong conditional guidance: preview writes nothing, cold execution requires dry_run=false and confirm=true with a configured DataPath and no preexisting native GUI; resume requires the IDENTICAL spec plus resume=true; a failed run needs retry_simulation=true, which selects new attempt names. What it lacks is routing against the similar sibling tools, so the agent knows this vs. a sourced house task is left to inference.

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