Custom Prompts

Custom prompts are reusable MCP instructions exposed by the N3uron MCP Server. They let an MCP-compatible client start a complete operational workflow from a named prompt instead of requiring the user to write the full diagnostic request each time.

In the AI-Ready PV Demo Project, custom prompts are designed as operator-friendly entry points for common solar O&M tasks such as plant status checks, downtime analysis, poor-performance triage, maintenance planning, and configuration auditing.

Note:

Not all MCP clients support prompt invocation, as some are more focused on tool-oriented functionality.

How custom prompts work

A custom prompt defines a reusable instruction that an MCP-compatible client can invoke. Each prompt includes a name, title, description, and prompt body, and may optionally include arguments when user input or runtime values are required.

Prompt arguments are inserted into the prompt body using the <<argument_name>> placeholder syntax. For example, <<path>> is replaced with the tag path provided by the client, such as /PVSIM/BLUELAKE/PVG001.

Prompt configuration model

Each prompt is configured as a child object under Modules → MCP Server → Prompts.

Available custom prompts

The backup includes 6 enabled custom prompts. Each prompt wraps one operational workflow and, where required, instructs the model to call a specific custom tool.

Prompt arguments

The following table lists the input arguments used by the custom prompts in the backup. Use /PVSIM/BLUELAKE/PVG001 as the plant root path when testing the PV Demo dataset.

Prompt body example

The prompt body defines what the AI model should do, what context or arguments it should consider, and how the answer should be structured. It does not need to specify a particular MCP tool. The model can decide which available tools to use based on the prompt instructions, the available MCP capabilities, and the information required to complete the task.
The following example is based on the find_worst_assets prompt.

Find the worst-performing assets at the solar plant.

Call ops_performance_scan_fleet with path=<<path>>, threshold_pct=<<threshold_pct>>, lookback_days=<<lookback_days>>.

Report worst assets first, plain language. Note if isolated or plant-wide. End with next checks for the field team.

Tip:

A good prompt should define the objective, relevant inputs, expected reasoning, and desired output format. It can let the AI model choose the appropriate tools automatically, or it can specify tool usage when stricter control is required.

Using the prompts

A typical MCP client lists the prompts exposed by the MCP Server, lets the user choose one, collects the required arguments, and sends the resulting prompt instruction to the AI model.

1. Connect an MCP-compatible client to the N3uron MCP Server.

2. Open the client prompt list and select one of the MCP Server prompts, for example check_plant_status.

3. Fill in the required arguments. For instance, /PVSIM/BLUELAKE/PVG001 as the root path.

4. Run the prompt and review the tool-based evidence returned by the AI model.

Recommended workflows

• Daily operations: Start with check_plant_status to get the current health, active alarms, production context, forecast, and immediate next actions.

• Downtime investigation: Use explain_recent_downtime when production stopped or an asset appears offline during daylight conditions.

• Fleet triage: Use find_worst_assets to rank stations or inverters and identify whether the issue is isolated or plant-wide.

• Open-ended troubleshooting: Use investigate_problem when the operator has a natural-language question and is not sure which diagnostic workflow to use. This prompt is different from the others because it includes a question argument in addition to the standard path and lookback_days arguments.

  The path argument defines the tag hierarchy or asset area to investigate. The lookback_days argument defines how much recent history should be reviewed. The question argument contains the operator’s plain-language description of the issue, for example, “Why did production drop yesterday?” The AI model uses this question to determine the most relevant diagnostic approach and returns a structured first diagnosis with the evidence found, the likely interpretation, a confidence level, and the recommended next action.

• Maintenance planning: Use make_maintenance_plan after a performance or alarm review to convert findings into prioritized actions.

• Configuration review: Use audit_configuration to detect missing history, missing descriptions, missing units, bad quality, or stale data.

Customization guidelines

• Use clear argument descriptions: Descriptions should tell users what value to enter and include examples when the expected format is not obvious.

• Reference tools explicitly: When a prompt depends on a specific custom tool, include the tool name and argument mapping in the prompt body.

• Constrain the response format: Ask for a health verdict, ranked list, confidence level, or next action so the output is consistent across clients and users.

• Avoid hidden assumptions: Pass important values through arguments instead of hardcoding site-specific paths, thresholds, or time windows in the prompt body.

Recommendation:

After editing a prompt, test it with a narrow path and a short lookback window before exposing it to operators. Confirm that the model calls the expected tool and that the answer is based on tool evidence, not assumptions.

PV Demo prompt examples

The following prompts are for the PV Demo plant. Each prompt comes in two forms:

• Concrete — full prompt body with all arguments explicit. Reliable and deterministic.

• Ambiguous — natural language only. Tests whether the AI model can infer the correct tool from operator wording.

When to use each

Use concrete prompts for repeatable production workflows. Use ambiguous prompts to evaluate model quality — they reveal whether the model can route correctly from natural operator language without explicit instructions.

P-01 — Check Plant Status

Concrete

Get the current status of the BLUELAKE solar plant.

Call ops_summary_daily with:
  path = /PVSIM/BLUELAKE/PVG001
  include_forecast = false
  plant_kpi_group = KPI_VG
  active_energy_day_tag = ACTIVE_ENERGY_DAY
  performance_ratio_tag = PERFORMANCE_RATIO
  capacity_factor_tag = CAPACITY_FACTOR
  active_power_total_tag = ACTIVE_POWER_TOTAL
  nominal_power_tag = NOMINAL_POWER
  irradiance_path = /PVSIM/BLUELAKE/PVG001/WST/POA_IRRADIANCE

Status: healthy / warning / critical. Summarize alarms, production, and top next actions. Plain language.

Ambiguous

How is the BLUELAKE plant doing today?

P-02 — Audit Configuration

Concrete

Audit configuration quality at the BLUELAKE solar plant.

Call system_audit_node with:
  path = /PVSIM/BLUELAKE/PVG001
  max_backup_age_hours = 24

Start with overall health (healthy or not). List problems: missing history, missing descriptions, missing units, bad realtime quality. For each: what is wrong, why it matters, what to fix.

Ambiguous

Are there any configuration problems at the BLUELAKE plant?

P-03 — Explain Recent Downtime

Concrete

Explain recent downtime at the BLUELAKE solar plant.

Call ops_downtime_summarize with:
  path = /PVSIM/BLUELAKE/PVG001
  lookback_days = 7
  granularity = station
  station_group_regex = ^PST_\d+$
  inverter_group_regex = ^INV\d+$
  active_energy_tag = ACTIVE_ENERGY
  active_power_tag = ACTIVE_POWER
  irradiance_path = /PVSIM/BLUELAKE/PVG001/WST/POA_IRRADIANCE
  irradiance_threshold = 50
  zero_power_threshold_kw = 0.5

Report: what stopped, when, which assets affected, likely cause, what to check next.

Ambiguous

Has anything stopped or gone offline at BLUELAKE in the last week?

P-04 — Find Worst Assets

Concrete

Find the worst-performing assets at the BLUELAKE solar plant.

Call ops_performance_scan_fleet with:
  path = /PVSIM/BLUELAKE/PVG001
  threshold_pct = 10
  lookback_days = 7
  station_group_regex = ^PST_\d+$
  inverter_group_regex = ^INV\d+$
  active_energy_tag = ACTIVE_ENERGY

Report worst assets first, plain language. Note if isolated or plant-wide. End with next checks for the field team.

Ambiguous

Which inverters or stations are underperforming at BLUELAKE?

P-05 — Investigate Problem

Concrete

Investigate: Why is PST_03 underperforming?

BLUELAKE plant — use these values directly:
  path = /PVSIM/BLUELAKE/PVG001
  lookback_days = 7
  station_group_regex = ^PST_\d+$
  inverter_group_regex = ^INV\d+$
  active_energy_tag = ACTIVE_ENERGY
  active_power_tag = ACTIVE_POWER
  irradiance_path = /PVSIM/BLUELAKE/PVG001/WST/POA_IRRADIANCE

Choose the right tool and pass the matching extra params:
- Downtime / stopped / offline → ops_downtime_summarize (also: irradiance_threshold=50, zero_power_threshold_kw=0.5, granularity=station)
- Alarms / faults / trips → ops_alarm_analyze_patterns
- Low output / underperformance → ops_performance_scan_fleet (also: threshold_pct=10)
- Current status / overview → ops_summary_daily

What seems to be happening: <diagnosis>
Why: <tool evidence only>
Confidence: High / Medium / Low
Best next action: <one action>

Ambiguous

Why is PST_03 underperforming at BLUELAKE?

P-06 — Make Maintenance Plan

Concrete

Build a maintenance plan for the BLUELAKE solar plant.

Call ops_maintenance_recommend with these exact arguments (numeric values are numbers, not strings):
  path = /PVSIM/BLUELAKE/PVG001
  lookback_days = 7
  threshold_pct = 10
  min_priority = 1
  cluster_window_minutes = 60
  station_group_regex = ^PST_\d+$
  inverter_group_regex = ^INV\d+$
  active_energy_tag = ACTIVE_ENERGY

Format:
1. Asset / Problem / Why it matters / What to do

If no actionable result, say so directly.

Ambiguous

What maintenance does the BLUELAKE plant need this week?

Further details can be found in the MCP Server Prompts.