hcl-mcp

Overview Schema Source Related Servers Discussions Admin

nvrd

Calculate light-driven alerting response over time from spectral irradiance series, returning effective, relative, and cumulative responses per timestep.

Instructions

Light-driven alerting response over time (Amundadottir nvRD).

spectral_series: per-timestep spectral irradiance rows (311 pts 390-700 nm, or 401 pts 380-780) as an inline list, OR a path to a text/CSV file with one row per line. PREFER THE FILE PATH for large/full-resolution series: a big inline array can be truncated over the MCP wire (e.g. 401-pt rows arriving as 367) and then fail the row-length check. Rows must be a SINGLE point+view orientation, in CHRONOLOGICAL order, ideally uniformly spaced at timestep_h. Pre-group multi-orientation/multi-day data and call once per orientation (§9.4 — the source's automatic per-orientation grouping is not reproduced in v1). timestep_h: hours per step. Must be <= 0.3 and yield odd nvRD filter lengths; the model is validated at 0.1 (= 6 min), the recommended value. Other steps raise ValueError. You supply the series (no Daysim). hours: optional explicit per-timestep hour vector for non-uniform spacing; must be monotonically non-decreasing. When omitted, a uniform grid (i*timestep_h) is used. Returns effective_irradiance, relative_response, and cumulative_response per timestep.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`hours`	No
`timestep_h`	No
`spectral_series`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 9, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden. It discloses wire truncation risk for inline arrays, row-length check failures, required single orientation and chronological order, ValueError for invalid timestep_h, and monotonic hour requirements. It also lists all three return outputs. This is exceptional transparency about edge cases and behavior.

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?

The description is long but every sentence carries operational necessity, structured with parameter explanations. It is front-loaded with the purpose and does not contain padding. Slightly more conciseness could be achieved but the detail is justified by complexity.

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?

Given 3 parameters, no annotations, and an output schema not shown but return values described, the description covers input formats, constraints, error conditions, and outputs. An agent has all necessary information to call the tool correctly, including caveats about orientation and file handling.

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

Parameters5/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 fully explain parameters. It does: spectral_series format and file path recommendation, timestep_h constraints and recommended value, hours optional and monotonic. This adds substantial meaning beyond the schema's basic type definitions.

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?

The description clearly states the tool computes 'Light-driven alerting response over time' using the Amundadottir nvRD model, which is a specific verb+resource. It is distinct from siblings like annual_nvrd by focusing on a single time series, but it does not explicitly name alternatives, so differentiation is implied 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 Guidelines3/5

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

The description provides detailed constraints for using this tool (timestep_h <= 0.3, recommended 0.1, chronological order, file path preference) and instructs to pre-group multi-orientation data. However, it never states when to use this tool instead of similar siblings like annual_nvrd or circadian_metrics, so the usage context is implicit but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.