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

With no annotations, the description carries the behavioral disclosure burden. It discloses the scale_warning behavior, the relative/normalized threshold (peak <= 1.5), and that the channel route is unaffected. This is meaningful behavioral detail beyond the schema, though it stops short of explaining error cases or exact output behavior.

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

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

The description is well-organized and dense without being bloated. The inputs are front-loaded, the alpha mapping is compact, and the scale_warning note is placed at the end where it belongs. Slight cryptic reference to 'CORE-3' costs some clarity, but overall every sentence earns its place.

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

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

The tool has four parameters, no annotations, and no parameter descriptions in the schema, so the description carries a heavy load. It covers the spd route well, including supported input forms and alpha options, but leaves the channels route and channel_type semantics under-specified. The mutual exclusivity of spd vs channels is implied but not explicitly enforced, which could confuse an agent.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain spd formats, alpha values, and the general channel route, which adds real meaning to the opaque schema. However, channel_type is not described at all, and the channel array contents are only vaguely called 'binned route'.

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

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

Description clearly identifies the tool as computing CIE S 026 alpha-opic E/ELR/EDI values and distinguishes the two input routes (spd vs channels). It is not merely a restatement of the name, and the alpha mapping adds specificity. However, it does not explicitly differentiate this from nearby siblings like circadian_metrics or spectral_metrics.

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

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

The description gives important usage constraints: provide spd OR channels, alpha values are mapped 1-5, and omitting alpha returns all five. It implies when to use the exact-spectrum vs binned route, but it does not state when to choose this tool over alternatives or provide exclusions.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It reveals that it 'Runs Radiance if present, else returns the command sequence,' explains the ASE direct-only pass, and details the shading_model handling including the 'undeclared' fallback and lm83_conformant flag. This is substantive transparency about operational behavior, though it omits potential side effects or file modifications.

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

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

The description is dense but well-structured. It leads with the core purpose, then explains parameters in a logical order, front-loading the critical input shapes. While it is lengthy, every sentence adds substantive information. It could be tightened, but it is not redundant or wasteful.

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

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

For a tool with 21 parameters, no annotations, and a complex domain, the description covers the most conceptually difficult inputs and behaviors but leaves gaps. It does not describe the output schema (though an output schema exists), nor does it explain many parameter defaults and their implications. The description is adequate for a user already familiar with the domain but not fully self-contained.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the most complex parameters (channel_scenes, points, sensor_set, occupancy, shading_model) with detailed syntax and defaults. However, it leaves many other parameters (e.g., run, wea, quality, udi_aut, udi_sup, thresholds, timestep_min) unexplained, and the schema itself provides no descriptions. The explanation is helpful but incomplete for the full parameter set.

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

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

The description clearly states the tool's purpose: 'Annual climate-based daylight metrics on the grid: per-point DA/cDA/UDI + spatial sDA/ASE.' It uses specific metric names and indicates the resource (grid). However, it does not explicitly differentiate from close siblings like run_annual or lm83_daylight beyond a passing reference to 'same shape as run_annual,' so it falls short of full clarity.

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

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

The description gives no explicit guidance on when to choose this tool over alternatives. It references run_annual's shape and the sensors tool for sensor_set, but does not state conditions like 'use this instead of run_annual when you need spatial sDA/ASE' or mention exclusions. The usage context is implied by the metric names but not articulated.

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

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

No annotations are provided, so the description carries the full burden. It discloses multiple behavioral traits: the pipeline is 'LONG-RUNNING', R_D is 'RELATIVE only', the tool reads site location from the EPW itself to prevent coordinate convention errors, and it explains the difference between live and emit paths (including required parameters for both). It also details the engine dependency on SMARTSPATH when physical_sky=True, and the default behavior of reconstruction.

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

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

The description is a dense block of text but every sentence carries technical value. It front-loads the core purpose and then systematically covers the pipeline, outputs, and parameter semantics. It could be broken into bullet points for easier parsing, but it is not redundant or padded. Given the tool's complexity (17 parameters), the length is justified, though slightly intimidating.

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

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

For a tool with 17 parameters and a detailed output schema, the description covers all essential aspects: the full computation chain, output structure (faithful/enhanced R_D and RD_cum, divergence), parameter behaviors, prerequisites (points and channel_scenes), and safety note about coordinates. The output schema exists, so return values are presumably documented there, and the description even outlines them. Nothing critical is missing for an agent to call this tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate fully. It does: it explains reconstruction values, timestep_min default and resolution, the points parameter format (inline or .pts path), the physical_sky opt-in and its engine requirement, the run flag's behavior, and the channel_scenes requirement. This adds substantial meaning beyond the raw schema.

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

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

The description opens with a clear statement of purpose: 'Annual light-driven alertness (nvRD R_D) straight from weather (spec §5.1)'. It then details the exact pipeline and output structure, distinguishing it from generic annual simulation tools. The mention of 'SINGLE reference point+view per run' and the reconstruction options further specify scope, making it clear what this tool does and what it does not.

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

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

The description provides constraints (e.g., 'SINGLE reference point+view per run', 'run=False emits the full Daysim+Radiance command plan') but does not explicitly state when to use this tool over siblings like run_annual or nvrd. It implies usage through the detailed pipeline but lacks explicit exclusions or alternative routing, so guidance 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.

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

With no annotations provided, the description carries the full burden and does substantial work: it discloses the backwards-compatibility default ('defaults reproduce prior output'), names the exact model (van Heuklon 1979) and inputs (lat/lon + date) for ozone_mode, states the default 0.65 asymmetry that aerosol_g overrides, and explains the Angstrom-exponent wavelength conversion in aod_anchor_nm. It leaves 'provenance' and any error/validation behavior unexplained, but the core computational behavior is well disclosed.

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

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

Two dense sentences that earn their place, with the core output list front-loaded ahead of the refinements. The 'Opt-in refinements (defaults reproduce prior output):' header efficiently groups the three tuning parameters. Only minor redundancy exists in restating the default 0.65 within aerosol_g's clause, so no meaningful waste.

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

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

An output schema exists, so return-value format need not be explained. Yet the description misses several things an agent needs: the epw input format, the semantics of the required date/time parameters, the meaning of 'provenance' in the output, and any usage-vs-sibling routing. The algorithmic core is solidly covered, but for a 7-parameter scientific tool with zero annotations these gaps keep it from being fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It clearly explains the three optional refinements (ozone_mode, aerosol_g, aod_anchor_nm) with their exact effects. However, it says nothing about the four required parameters—especially epw, whose format (path vs. inline content) is genuinely ambiguous—nor about month/day/hour semantics such as timezone or year context. Covering 3 of 7 parameters at zero schema coverage is partial compensation.

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

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

The description states a clear derived product ('Derived atmospheric state (AOD, PWV, ozone, pressure, albedo, aerosol_g + provenance)') with an explicit output list and a derivation-from-EPW relationship. It distinguishes itself from siblings like spectral_epw by focusing on atmospheric-state quantities rather than spectral conversion, though it never names a sibling directly.

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

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

No guidance on when to use this tool versus alternatives such as spectral_sky_from_epw, spectral_epw, or weather. The description explains internal refinements but never states a triggering condition, prerequisite (e.g., valid EPW format), or exclusion such as 'for sky radiance use spectral_sky_from_epw instead.'

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

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

With no annotations, the description carries the full burden and does well: it discloses cloning, building, the fallback when git/cmake are missing, the success output (bin_dir), and the licensing reason for not bundling. It also clarifies that it does not set the environment variable but instructs the user to do so.

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

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

The description is three sentences with no fluff, front-loading the purpose and method, then explaining behavior and licensing. Every sentence adds value and the structure is logical.

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

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

The tool is complex and has an output schema, but the description covers the key outcome (bin_dir) and licensing. However, it omits parameter explanations and usage guidance, making it incomplete for an agent to decide when to use it and how to pass parameters effectively.

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

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

Schema description coverage is 0%, so the description must explain parameters. It only addresses 'run' (executes if true and git+cmake present), leaving 'src_dir' and 'work_dir' completely unexplained. This is a significant gap for an agent to use the tool correctly.

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

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

The description clearly states the verb 'Build' with the specific resource 'Daysim (ds_shortterm + epw2wea)' and the method 'clone master + headless arm64 CMake'. It distinguishes itself from siblings like daysim_status and build_report by being specifically about building Daysim from source.

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

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

The description explains behavior (run=True executes if git+cmake present, otherwise returns command plan) but does not explicitly state when to use this tool versus alternatives like daysim_status. It implies usage when Daysim is not present ('Daysim is NOT bundled') but lacks explicit guidance on alternatives.

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

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

With no annotations, the description must disclose behavioral traits itself. It mentions 'Always runs' but does not explain file overwrite behavior, permission requirements, failure modes, or side effects on other data. The report generation might create or overwrite files, but this is not disclosed. The description is too vague to set accurate agent expectations.

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

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

The description is a single, front-loaded sentence that states the primary action and output path immediately. It is concise and avoids filler. However, it may be too terse given the complexity of the tool and its parameters, but it earns a 4 for efficiency and structure.

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

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

Given the tool's complexity (a free-form brief object, multiple report sections, output file generation) and the absence of annotations, schema descriptions, and an output schema visible here, the description is incomplete. It does not cover the brief's schema, return value, error handling, or prerequisites, leaving an agent under-informed for correct invocation.

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

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

Schema description coverage is 0%, so the description must explain the parameters. It references <work_dir> and <study> in the path template, giving some meaning, but does not explain the 'brief' object structure or its required fields. The default for work_dir is null per the schema, but the description does not clarify how that is handled. Minimal semantic value added.

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

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

The description clearly states the tool renders a study brief into a report file with a specified path and enumerates the report's contents (goal recap, fixture spec, target-vs-achieved table, cross-check, compliance). This is specific and distinguishes it from siblings like save_brief or load_brief, which handle brief persistence rather than report generation.

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

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

There is no guidance on when to use this tool versus alternatives. The phrase 'Always runs' is ambiguous—it might imply no prerequisites or unconditional execution, but it does not clarify selection criteria or when not to use it. No alternatives or exclusions are mentioned.

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

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 that it does not build the scene, requires no binaries, reports defects with a 'fix', and includes a 'skipped' category for unimplemented checks. It does not explicitly state that it is read-only or non-destructive, but the nature of a health-check implies this, and the mentioned behaviors are useful beyond the schema.

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

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

The description is concise and efficiently structured. It front-loads the core purpose and spec date, then lists concrete defect types, then notes the 'skipped' behavior and the cheap-to-run advantage. Every sentence adds distinct value, with no redundancy.

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

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

The description thoroughly covers the tool's purpose and behavior, and since an output schema exists, it need not detail return values. However, with 8 parameters and zero schema coverage, the description does not compensate for the missing parameter documentation. An agent would not know what 'sensors', 'material_map', or 'sidecar' control, which is a notable gap for a tool with this many optional inputs.

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

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

Schema description coverage is 0%, meaning the input schema provides no property descriptions. The description adds essentially no information about the 8 parameters; only 'obj_path' is implied via 'an OBJ scene'. The optional parameters (units, sensors, sidecar, up_axis, material_map, photosensors, electric_lights) are completely unexplained, leaving an agent to guess their purpose.

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

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

The description states a specific verb ('Health-check') and resource ('an OBJ scene'), and clarifies it operates 'without building it', distinguishing it from tools like import_geometry that build scenes. It also enumerates the specific defect categories it catches, making its scope unambiguous.

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

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

The description gives clear context for when to use it: it 'needs no Radiance binaries and builds no scene, so it is cheap to re-run while fixing a model.' It also points to an alternative by noting 'import_geometry embeds the same report as result["health"]'. However, it does not explicitly mention sibling tools like 'validate' or state when to prefer one over the other, so guidance is strong but not fully explicit.

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

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

With no annotations provided, the description fully owns behavioral disclosure. It transparently explains the difference between melanopic_lux and mel_edi, the effect of supplying an SPD (preserving within-bin structure, adding source_mel_der and transport_ratio), and the accuracy trade-offs when SPD is absent (exact for D65, ~1.5% for smooth spectra, up to ~8% high for narrow-band fluorescent). This goes beyond a simple 'computes X' and gives an agent a realistic model of the tool's behavior.

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

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

The description is roughly 200 words, which is on the longer side, but every sentence adds substantive value. It is front-loaded with the core purpose, then explains the output nuances, then the spd behavior. The structure is logical and easy to parse, with clear separation of concerns. No redundant filler.

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

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

Given the tool's complexity and the presence of an output schema, the description is fairly complete. It covers the return format (single dict or list), the key output fields, the spd parameter's semantics and edge cases, and the behavioral differences between the two metric types. The only notable omission is an explanation of channel_type, which is a minor gap given that it has a default and likely represents a mode selector. Overall, an agent has enough to call it correctly.

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

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

Schema coverage is 0%, so the description must compensate. It thoroughly explains the spd parameter: what it is (source spectrum), its allowed forms ('.spd' path, 2-column text, or array), and why it matters (preserves within-bin structure). It also gives a brief hint about channels ('channel irradiances') in the opening line. However, the channel_type parameter is never mentioned, and channels is only indirectly described. Partial compensation for a critical gap.

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

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

The description opens with a clear statement: 'Photopic / melanopic / neuropic equivalent illuminance from channel irradiances.' It specifies the resource (channel irradiances) and the output quantities. While it doesn't explicitly name sibling tools like spectral_metrics or alpha_opic, the domain is distinct enough that the purpose is unambiguous.

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

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

The description provides practical guidance on interpreting results (e.g., 'pass mel_edi to compliance, never melanopic_lux') and explains when the spd parameter should be supplied. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. Usage is implied by the domain but not spelled out.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so well. It clearly states the tool writes a new file, never edits the input, writes to a client-roots-aware work_dir, leaves rad_path untouched, returns an absolute path, and returns {file, rad}. This is strong transparency for a side-effecting file-generation tool.

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

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

The description is compact and information-dense, front-loading the core action and safety guarantee ('writing a NEW file (never edits the input)') before parameter specifics. Every sentence contributes distinct, useful information with minimal redundancy.

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

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

For a 5-parameter tool with no annotations and 0% schema coverage, the description covers the main behavioral contract, output location, return value, and input flexibility. Minor gaps remain around optional parameter defaults (name, work_dir) and the exact structure of channels9, but the description is largely sufficient for an agent to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It gives useful semantics for count ('0=blue,1=green,2=red third of 9 values'), rad_path ('.rad file path or raw .rad text'), and implicitly name/work_dir via '<name>.rad' and 'work_dir'. However, channels9 is only loosely described as a 'channel triplet' and '9 values', leaving some ambiguity about its exact contents and ordering.

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

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

The description opens with a specific verb and resource: 'Inject a channel triplet into a luminaire .rad', and immediately clarifies the key distinction that it writes a NEW file rather than editing the input. This clearly separates it from generic material or radiance writing tools and makes the tool's purpose unambiguous.

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

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

There is no explicit guidance about when to prefer this tool over alternatives, nor any mention of when not to use it. While the description explains mechanics like rad_path accepting file paths or raw text, it does not state a use case or differentiate against sibling tools such as write_material or colored_sky.

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

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

With no annotations provided, the description carries the full burden and does so admirably. It discloses how mode affects execution (spectra runs gendaylit, luminance uses Radiance -C built-in coloring), how hour is interpreted as a wall-clock instant, and the subtle half-hour offset issue. It also notes that diffuse_channels/direct_channels are ignored in luminance mode.

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

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

The description is dense but not wasteful; every sentence adds technical substance. It front-loads the core purpose and modes, then dedicates a focused paragraph to the solar-position gotcha. It could be slightly trimmed but is well-organized.

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

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

For a complex tool with 19 parameters, the description covers the most critical behavioral aspects and the main integration pitfall. The output schema exists, so return values are not needed. Minor omissions like the exact role of channel_type and globl prevent a 5, but overall it is sufficiently complete for correct usage.

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

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

Despite 0% schema description coverage, the description adds meaning to several key parameters: mode, irrad_mode, lon (explicit EAST-positive), hour (wall-clock vs EPW hour-ending), and the sun angle pair. However, it does not explain all 19 parameters (e.g., channel_type, globl, direct, diffuse, work_dir), leaving some to be inferred from context.

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

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

The description opens with a clear verb-resource statement: 'Generate a colored Perez sky+sun Radiance definition.' It then distinguishes itself from the sibling spectral_sky_from_epw by explaining the hour semantics difference, so an agent can tell them apart without inspecting schemas.

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

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

The description gives explicit guidance on when to use the default ephemeris versus passing sun_zenith_deg and sun_azimuth_deg, and it explains the alignment problem with spectral_sky_from_epw, including a concrete example of how to pass geometry verbatim. This is far beyond a generic 'when to use' note.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the mel_edi vs eml precedence (mel_edi wins, eml discarded without warning), the conversion factor (eml = mel_edi * 1.103, so eml is divided by 1.103), the output quantity stamping, and the behavior for en_17037 and ul_24480. This is exceptionally transparent.

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

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

The description is long but well-organized into logical paragraphs (circadian vs electric visual, edge standards). Every sentence contributes necessary information, but it could be tightened slightly (e.g., the conversion explanation is repeated in a few places). Still above average.

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

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

The description covers all parameter groups and explains edge-case return values. With an output schema present, it doesn't need to describe return format. For a 20-parameter tool with zero schema coverage, this is complete enough for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains each parameter group: mel_edi/eml for circadian, em/ugr/uo/ra plus surround/background/wall/ceiling/cylindrical for electric visual, and the task parameter. It also clarifies the conversion factor and precedence, adding meaning far beyond the bare schema.

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

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

The description opens with a clear verb ('check') and resource ('a value against a lighting standard'), then lists the accepted standards. It distinguishes itself from sibling tools like circadian_metrics and spectral_metrics by focusing on compliance checking rather than metric computation or spectral conversion.

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

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

The description explicitly contrasts the circadian path (mel_edi/eml) with the electric visual-task path (en_12464_1), notes which standards return 'n/a' or 'unsupported', and directs users to spectral_metrics for the reverse conversion. It also explains the condition under which en_12464_1 returns 'incomplete' instead of a vacuous pass.

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

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

With no annotations, the description carries the full burden. It discloses that the overcast sky is added internally, that it returns df_per_point plus summary metrics and e_outdoor, and that it can return a command plan when run=false. It also explains the scene_sets structure. This is substantial behavioral context, though it does not mention side effects like file writes or computational cost.

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

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

The description is a single paragraph with a formula and a bullet-like explanation of key inputs and outputs. It is reasonably concise and front-loaded with the definition. However, the bullet for scene_sets and points could be tighter, and the mention of 'command plan' is slightly cryptic.

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

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

Given the high parameter count (11) and no annotations, the description is not complete. It explains the core inputs (scene_sets, points, sensor_set) and the output format, but omits explanation for the other 7 parameters. Even with an output schema, the tool is too complex to rely on defaults without explanation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains scene_sets, points, sensor_set, and run (implicitly), but leaves many parameters (day, hour, month, quality, gnd_refl, work_dir, rad_params) unexplained. The agent must guess their meaning from the schema or defaults, which is inadequate for a tool with 11 parameters.

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

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

The description clearly states the tool computes Daylight Factor per point under the CIE Standard Overcast Sky, with a formula. It is specific about the resource (daylight factor) and scope (per point, overcast sky). However, it does not explicitly distinguish it from sibling tools like annual_daylight or lm83_daylight, though the mention of 'gensky -c' hints at a specific static sky model.

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

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

The description does not provide any guidance on when to use this tool versus alternatives. It does not mention conditions, exclusions, or prerequisites. An agent would have to infer the appropriate use case from the metric definition alone.

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

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

With no annotations provided, the description carries the full burden and does an excellent job: it discloses the confirmation prompt for annual runs, the three return shapes, the weight interpretation (floor-area fraction, sum <= 1.0), and the schedule assumptions. This is far beyond the minimum and leaves no ambiguity about side effects or return values.

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

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

The description is long but information-dense; it front-loads the purpose and then systematically covers modes, weights, return shapes, and the schedule note. No sentence is wasted, but the density makes it a wall of text. It could benefit from bullet points or clearer section separation, but the structure is logical.

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

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

The description covers high-level behavior, return shapes, and the critical weights/schedule semantics. However, it omits explanations for many parameters, and while it references underlying tools (run_grid, run_annual_daylight), the agent cannot safely call this tool without understanding those parameters. An output schema exists, but it lacks descriptions, so the description must do more. It is adequate for an expert but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains mode, points, sensor_set, weights, schedule, and run, and even gives a helper function for weights. However, 21 parameters exist, and many (area, iset, fL_min, fP_min, n_steps, p_rated, quality, work_dir, rad_params, scene_sets, channel_type, control_type, channel_scenes, workbook_compat) are left undocumented. This is a significant gap.

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

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

The description opens with a clear purpose: 'Automated daylight-responsive savings: daylight sim at the reference points -> lighting_controls.' It names the two modes and the underlying functions (run_grid, run_annual_daylight). It is not a tautology, but it doesn't explicitly differentiate from sibling tools like run_grid or annual_daylight, so it misses the highest mark.

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

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

The description clearly explains when to use each mode (point_in_time vs annual) and the run=False behavior. It also provides a note about schedule assumptions for annual mode. However, it does not explicitly state when not to use this tool or name direct alternatives beyond the underlying functions, so it falls short of a 5.

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

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

With no annotations, the description carries full burden. It discloses that no subprocess runs except a best-effort version probe, and notes Daysim is built from source locally (never bundled). These are meaningful behavioral traits beyond what a schema could express.

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

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

Two sentences plus a return line. Purpose is front-loaded, and the alternative is stated in a compact conditional. No filler or redundancy.

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

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

The output schema covers return fields, so description needn't repeat them. It adds essential context about environment variable usage, source-built nature, and the fallback to build_daysim. For a status tool, this is complete enough; error behavior is implied by the 'found' field.

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

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

The tool has zero parameters, so schema coverage is 100% vacuously. The description adds no parameter details, but none are needed. Baseline for 0 params is 4.

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

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

The description clearly states 'Report Daysim availability' with specific executables (ds_shortterm + epw2wea) and the mechanism (HCL_DAYSIM_BIN or PATH). It distinguishes from siblings like build_daysim (which builds) and radiance_status (which reports a different tool).

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

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

It explicitly mentions 'use build_daysim if missing', providing a conditional alternative. While it doesn't compare to radiance_status or other status tools, the context makes the intended use obvious. The alternative guidance is clear and actionable.

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

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

With no annotations provided, the description carries the full burden and delivers richly: it discloses the default timestep satisfying the nvRD step guard, the site-location default derived from the EPW LOCATION line, the DAYSIM coordinate convention (WEST-positive longitude, time_zone in degrees = -15 × UTC offset), and the fallback behavior when Daysim is absent (returns command plan + written .hea). This is substantial behavioral disclosure.

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

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

The description is dense but information-efficient, front-loading the core pipeline and putting the most critical caveat (coordinate convention) in the middle where the override discussion lives. Every sentence adds value; it could benefit from minor structuring but is far from bloated.

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

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

An output schema exists, so return values are already covered. For a 9-parameter, Daysim-integrated pipeline tool with zero annotations, the description explains defaults, conventions, and fallback behavior well. Remaining gaps are the unexplained solar_time and run parameters, which keep it from a 5.

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

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

Schema description coverage is 0%, so the description must compensate. It explains epw, work_dir, timestep_min (default 6), and the coordinate overrides with their DAYSIM convention. However, solar_time and run (a boolean) are never mentioned, leaving two of nine parameters semantically unexplained. Coverage is good but incomplete.

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

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

The description opens with a specific transformation chain 'EPW -> sub-hourly broadband .wea via Daysim (epw2wea -> .hea -> ds_shortterm)', naming the exact input, output, and pipeline. This clearly distinguishes it from weather-related siblings like weather, import_weather, spectral_epw, and atmosphere_from_epw, all of which do different things.

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

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

The description tells the agent the normal invocation ('normally you only pass the epw + work_dir') and conditions the override parameters on explicit intent ('Pass explicit latitude/longitude/time_zone/site_elevation only to override'). It does not explicitly name alternative tools or state when not to use it, but the default-vs-override guidance is clear context.

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

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

No annotations are provided, so the description carries the full burden. 'Look up' implies a read-only operation, but the description does not explicitly state non-destructiveness, authorization requirements, or any side effects. It also doesn't disclose the return format or pagination behavior, leaving agents without crucial behavioral context.

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

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

The description is extremely concise and front-loaded with the core purpose. The topic list is a compact addition. No wasted words, though it is so brief that it might under-specify, which slightly lowers the score from a perfect 5.

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

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

Given the tool's simplicity (one optional parameter) and the presence of an output schema, the description could be minimal. However, it doesn't mention any prerequisites, disambiguation from the 'reference' sibling, or edge cases. For a lookup tool with many siblings, more context would be expected to ensure correct selection.

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

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

Schema coverage is 0%, but the description compensates by explicitly enumerating the valid topics: bins, coefficients, caveats, overview. This gives the agent concrete guidance on parameter values beyond the raw schema, which only declares a default.

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

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

The description clearly states the verb 'look up' and the resource 'HCL reference content', and lists specific topics. However, it does not differentiate from the sibling tool 'reference', which likely serves a similar purpose, so it loses a point for not addressing sibling distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives. There is no mention of exclusions or when to prefer another tool, such as the sibling 'reference'. This is a significant gap for a tool with many siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose a key behavioral trait: 'Runs Radiance if present, else returns the commands.' This explains the conditional execution and whether it mutates or returns commands. However, it does not mention side effects like file creation, permissions, or the nature of the output beyond returning commands, which is incomplete for a rendering and analysis tool.

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

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

The description is concise at two sentences with the main purpose front-loaded. The delegation detail is somewhat implementation-specific but not excessive. There is no wasted phrasing, and it gets to the core function quickly.

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

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

Given the tool has 11 parameters (1 required) and no parameter descriptions, the description is far from complete. It does not explain the output format (even though an output schema exists, it is not referenced), the meaning of UGR/DGP/glare sources, or how to interpret the returned commands vs actual execution. The conditional behavior is mentioned but not elaborated. An agent would struggle to call this correctly without additional info.

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

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

Schema description coverage is 0%, so the description must compensate by explaining parameters. It only hints at 'daylight and/or electric_lights' which maps to the electric_lights parameter, but it does not explain scene_sets (the only required parameter), glare_params, rad_params, quality, or others. This is a significant gap; the description adds almost no semantic value for parameters.

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

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

The description clearly states the tool renders a fisheye image and runs evalglare to compute UGR/DGP/glare sources. It uses specific verbs ('Render', 'run') and names the resource (fisheye, evalglare). It distinguishes itself from siblings like run_image by noting it delegates with glare=True, implying a specialized glare analysis tool, though it does not explicitly name alternatives.

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

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

The description implies the tool is for glare analysis and mentions it delegates to run_image, but it does not explicitly state when to use this tool versus alternatives like run_image or other analysis tools. There is no mention of exclusions or conditions beyond the delegation, so usage guidance is only implied.

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

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

With no annotations provided, the description fully carries the behavioral burden. It discloses that transmissivity is always larger, gives a numeric example, explains the internal transmittance-squared term, and even warns about the load-bearing float|list annotation and the DEF-1 error. This is far beyond what annotations would normally cover.

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

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

The description is dense but every sentence adds critical value: purpose, definition, usage rule, alternatives with consequence, and an annotation note. It is front-loaded with the core purpose and uses clear formatting (bold 'USE THIS ONLY') to guide the agent. No wasted words.

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

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

For a tool with one parameter, an output schema (which presumably covers return type), and no annotations, the description covers everything an agent needs: what it does, when to use it, when not to, why, and even a technical caveat about schema generation. It is fully self-sufficient.

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

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 the parameter. It does: 'transmittance' is defined as the datasheet number (Tvis) in the 0-1 range, accepts a number or list, and the conversion logic is detailed. The single parameter is completely documented.

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

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

The description opens with a precise verb and resource ('Convert glazing transmittance to Radiance transmissivity') and immediately clarifies the conceptual difference between Tvis and transmissivity, distinguishing it from any conversion that might be assumed. It also explicitly names the siblings (write_material, import_geometry) that should NOT use this tool, making its role unambiguous.

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

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

The description gives an explicit 'USE THIS ONLY' condition (hand-writing a Radiance glass primitive) and provides a clear negative: do not pre-convert for write_material or import_geometry, with a concrete consequence (9% error). It names alternatives and explains why they take raw Tvis, leaving no room for misapplication.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the output but does not mention side effects, error handling, whether the operation is read-only, or limitations (e.g., invalid IES handling). It does not contradict any annotations (none exist), but it falls short of disclosing key behavioral traits.

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

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

The description is concise, with two sentences that front-load the primary purpose and output list, followed by a clear parameter explanation. There is no wasted wording; every sentence adds value.

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

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

Given that an output schema exists (indicated as true), the description need not detail return values beyond the enumerated fields, which it already lists. It also explains the input parameter format. However, it omits any mention of error conditions or prerequisites, and lacks sibling differentiation, which slightly reduces completeness.

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

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

The schema has 0% description coverage, so the description must compensate. It explains the parameter 'ies' as 'raw IES text or a file path', which adds meaningful semantics beyond the bare string type. This clarifies the accepted input formats, making the tool more usable.

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

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

The description clearly states the verb 'parse' and the resource 'IESNA LM-63 luminaire', and enumerates the specific fields returned (rated lumens, watts, efficacy, max candela + location, beam/field angles, zonal flux down/up, LOR). This is specific and distinguishes the tool from siblings like ies_to_radiance (which converts to radiance) or validate (which checks validity).

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

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

The description gives no guidance on when to use this tool versus alternatives such as ies_to_radiance or validate. There is no mention of prerequisites, exclusions, or recommended scenarios. The only implied usage is when a photometric report is needed, but no explicit when/when-not guidance is provided.

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

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

With no annotations, the description carries the full behavioral burden. It explains that user scaling (multiplier * maintenance_factor) is separate from ies2rad's internal candela/ballast/pfactor application, and that execution is conditional on Radiance presence. These are valuable behavioral details.

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

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

The description is two concise sentences, front-loaded with the core action and a focused note on scaling behavior. Every sentence adds value with no redundancy.

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

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

Despite an output schema, the description leaves most parameter semantics and operational details (e.g., placement structure, default behaviors, output format) unexplained. For an 11-parameter tool, this is a significant gap that an agent must resolve by trial or external knowledge.

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

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

Only multiplier and maintenance_factor are explained through the scaling note; the other nine parameters (ies, run, lamp, color, units, work_dir, placement, out_prefix, units_divisor) are left undocumented. With 0% schema coverage, the description fails to compensate adequately.

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

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

The description states a specific conversion action: converting an IES luminaire to a Radiance .rad via ies2rad, with optional xform placement. It is clear and distinct from siblings like ies_analyze, though it does not explicitly name alternatives.

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

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

The description implies use for IES-to-Radiance conversion but does not contrast with other tools. It does provide a conditional execution note (runs ies2rad if Radiance is present, else returns commands), which guides expectations but not tool selection.

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

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

Annotations are absent, so the description carries the full burden, and it delivers: unmapped groups 'hard-fail', dry_run 'return[s] a discovery payload ... without binding materials or running Radiance', strict raises GeometryHealthError on error-severity findings, and it explicitly flags the subtle interaction that 'strict has NO effect when dry_run=True'. It also discloses conditional keys appearing only when requested, the manifest sidecar write, and live-validation for annotate. This is exceptional disclosure, including an edge-case interaction most tools omit.

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

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

The description is long, but the length is earned given 16 params, 0% schema coverage, and no annotations. The core purpose is front-loaded, parameters are grouped under a 'v2/v3' section, and return/conditional keys are clearly enumerated. The material_map specification is a dense run-on paragraph that is harder to parse than the rest, but every sentence carries information; no filler.

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

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

Output schema exists and the description still details returns (geometry_set, material_sets, apertures, manifest, conditional keys), which is thorough. But for a 16-param tool it leaves run, work_dir, and channel_type completely unexplained, and it gives no guidance for distinguishing from closely-related siblings like check_geometry or preview_scene. Those gaps keep it from being complete despite the strong behavioral and parameter coverage.

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

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

Schema coverage is 0%, so the description must compensate, and it does heavily: it adds enum-like values (units: mm|cm|m|ft; up_axis: Y|Z), fully specifies material_map's keying and every type-dict (plastic/glass/ground/context/luminaire/floor), and explains north_angle_deg (applied as -rz(-north)), sidecar precedence ('explicit kwargs always win'), and defaults for eye_heights/workplane_h/spacing. The gap: three params — run, work_dir, and channel_type — are never mentioned, leaving their semantics entirely unexplained in both schema and description.

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

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

Opens with a specific verb+resource+destination: 'Import a Wavefront .obj room into a per-channel Radiance scene (obj2rad -> xform)'. This is unmistakable against siblings like run_grid/run_image (simulation runners), check_geometry, and preview_scene. The derived-sensor outputs (grid_points/observer_sets) could be mistaken for the workplane_grid/observer_points siblings, but the description clearly frames these as outputs of this import tool rather than the tool's purpose.

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

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

Gives strong pipeline context: returned scene_sets are 'to compose into run_grid / run_annual', luminaire payload is 'drop-in ... for run_grid/run_image', and ground_albedo is meant to 'feed to spectral_sky_from_epw'. It also explains dry_run's discovery role. However, it never explicitly states when NOT to use it or names an alternative for a given condition, so the when-vs-other guidance is implicit through workflow positioning rather than direct exclusion.

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

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

With no annotations provided, the description must disclose behavior itself. It reveals that the tool returns a summary (wea_summary) rather than full arrays, explaining the response budget constraint, and mentions that the subset .wea is written to disk. This is meaningful behavioral context beyond the schema, though it does not address auth, reversibility, or side effects beyond file creation.

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

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

The description is concise, consisting of two short paragraphs. The primary purpose is stated upfront, followed by important behavioral details. It avoids unnecessary fluff and front-loads the key information, though it could be slightly tighter by merging the two paragraphs.

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

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

The tool has an output schema and the description summarizes the return value (wea_summary contents). It also covers the main use cases and limitations (response budget). For a tool with four optional parameters and a straightforward purpose, the description is largely complete, though edge cases and error handling are not mentioned.

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

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

The schema description coverage is 0%, so the description must compensate. It explains the purpose of period and subset_out, but does not mention wea_path or timestep_min. The description adds value for two of four parameters, leaving the others to be inferred from names and defaults. This is partial compensation for the coverage gap.

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

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

The description clearly states the tool's purpose: ingest a .wea file and/or decompose an analysis period into HOY and wea line numbers. It uses specific verbs (ingest, decompose) and identifies the resource (.wea). However, it does not explicitly contrast with sibling tools like weather or generate_subhourly_wea, so the differentiation is implicit.

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

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

The description provides guidance on using period + subset_out to get the needed rows, which helps with parameter usage. However, it does not explicitly state when to choose this tool over alternatives or provide conditions for when not to use it. The context is clear but lacks explicit routing guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses the calculation behavior, the output fields for both modes, the role of weights, and the effect of workbook_compat. It does not mention error handling or edge cases, but for a pure calculator this is less critical. The mention of verification and regression adds transparency.

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

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

The description is dense and information-rich, with a clear lead statement about the tool's purpose and modes. It uses colons and examples to structure information efficiently. While it is longer than a typical description, every sentence carries meaningful information, and the structure makes it scannable.

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

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

The tool is complex with 12 parameters and no output schema provided. The description covers the primary usage modes and output fields, but it does not explain all parameters or provide units or defaults beyond what is in the schema (which is minimal). Given the complexity and lack of schema coverage, more detail would be needed for full completeness, but the description is adequate for the main use cases.

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

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

With 0% schema coverage, the description must explain parameters. It explains itot_per_point, itot_series, weights, control_type, and workbook_compat, but omits area, iset, fL_min, fP_min, n_steps, p_rated, and schedule. Some may be inferable from context (e.g., area is needed for annual mode), but several remain unexplained. The description adds value for the key parameters but does not fully compensate for the schema gap.

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

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

The description clearly states the tool is a 'Daylight-responsive lighting-control calculator' with a specific reference (EnergyPlus §7.3.5) and verification. It distinguishes itself from siblings by being a calculation tool, not a status or validation tool. The purpose is unambiguous and specific.

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

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

The description provides explicit usage modes: point-in-time and annual/series, with instructions on which inputs to pass for each. It explains the meaning of 'weights' and 'control_type' and mentions 'workbook_compat' for regression. However, it does not explicitly state when to use this tool over alternatives like lm83_daylight or annual_daylight, though the mode-specific instructions give strong contextual guidance.

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

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

With no annotations, the description carries the full burden. It discloses that LED models are illustrative and not measured (referencing spec 5.7), and states the return behavior when a name is given (SPD + metadata). It does not explicitly state it is read-only, but that is implied by a list/fetch operation. The data-quality caveat adds valuable context beyond the schema.

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

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

Two sentences, front-loaded with the primary action, then the list of names and the behavioral distinction. No wasted words; every sentence earns its place.

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

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

The tool has an output schema (per context signals), so return structure is already covered. The description covers the optional parameter semantics, the data-quality caveat, and the two usage modes. For a simple list/get tool, this is complete for an agent to invoke correctly.

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

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

The schema only defines a nullable string 'name' with no description (0% coverage). The description explains that omitting it lists all presets, while providing it fetches that specific preset's SPD and metadata. This fully clarifies the parameter's effect, adding meaning that the schema lacks.

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

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

States a specific action (list/fetch) on illuminant presets, enumerates the exact preset names, and clarifies it covers CIE standards plus illustrative LED models. This distinguishes it from the sibling 'presets' tool by its focus on illuminant presets, making the purpose unambiguous.

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

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

Explicitly describes two usage modes: call with no name to list all presets, or provide a name to fetch a specific preset's SPD and metadata. It lists the valid names and the illustrative caveat. It does not explicitly contrast with the sibling 'presets' tool, but the self-contained instructions are sufficient for an agent to decide when to use it.

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

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

With no annotations, the description carries the full burden. It discloses the conformance flag is always false, the bias from missing frame occlusion, the blind default (5% not 20%), and the area pooling dilution effect. It also explains the three-phase engine and blind trigger behavior. All critical behavioral traits are covered.

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

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

The description is long but each sentence earns its place. It is organized into clear paragraphs by parameter group, front-loads the core purpose and sibling distinction, then dives into details. There is no fluff or repetition; every sentence adds critical information.

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

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

Given the complexity (19 params, no schema descriptions, complex standard compliance), the description covers all needed aspects: engine method, parameter semantics, defaults, constraints, output structure (metrics, conditions, conformance flag), and limitations. The presence of an output schema helps, but the description provides the required behavioral and usage context fully.

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

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

Schema description coverage is 0%, so the description must explain every parameter. It does: obj_path, material_map (including glazing mapping requirements), units/up_axis/north_angle_deg (with consequences of wrong values), points/sensor_set, areas (with constraints and fallback), blind (including subtypes and defaults), window_groups, and declared_no_blinds. Each parameter's purpose and constraints are described in detail.

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

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

The description clearly states the tool computes IES LM-83-12 sDA/ASE with mandatory blinds, and explicitly contrasts it with annual_daylight, which computes arithmetic sDA/ASE on the scene's existing shading. This distinguishes the tool from its sibling and specifies the exact resource and verb.

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

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

The description explicitly says 'Unlike annual_daylight...' and explains when to use this tool vs. the sibling. It also gives conditions for using areas, blinds, window_groups, and declared_no_blinds, and warns about pooling facades and area size limits. This is explicit when/when-not guidance.

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

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

Discloses a key behavioral trait: returns an empty skeleton if no brief exists, and implies state persistence. With no annotations provided, the description carries the burden and does so adequately, though it doesn't mention side effects or authentication.

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

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

Two sentences with no wasted words, front-loading the main action and the key behavior. The structure is efficient and easy to parse.

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

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

Covers usage context and the empty skeleton case, and the output schema handles return format. However, the lack of parameter explanations means the tool is not fully usable without external knowledge, making it only partially complete.

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

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

The description adds no information about the 'study' or 'work_dir' parameters. With schema description coverage at 0%, the agent gets no guidance on what values to pass, leaving a significant gap.

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

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

The description clearly states the action ('Load a study brief') and the resource (a brief), and adds the nuance of returning an empty skeleton when none exists. This makes it unambiguous and distinct from the sibling 'save_brief'.

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

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

Explicitly instructs to call at journey start to resume where left off, providing clear when-to-use guidance. It also implies the behavior when no brief exists, which helps the agent decide to call it.

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

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.

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.

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.

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.

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.

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.

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does well: it discloses the non-obvious clip_to_footprint behavior (does NOT move observers, only warns), the material_map OR sidecar requirement, the fallback chain, and the return payload. This goes well beyond what the schema conveys.

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

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

The description is information-dense with the purpose front-loaded and every sentence carrying meaning. It loses a point for structural jumbling — the return statement and 'material_map OR sidecar required' are awkwardly dropped mid-paragraph rather than cleanly separated — but there is no fluff.

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

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

For a complex 17-param tool with 0% schema coverage and no annotations, the description covers the core algorithm, fallbacks, bypass, and key behavioral caveats. An output schema exists so return values are partially covered. The main gaps are the six unexplained parameters and the absence of error behavior, leaving the agent to guess at units, sweep_n, and coordinate conventions.

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

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

Schema coverage is 0%, so the description must compensate. It meaningfully explains workstations (with exact format), eye_height (floor-top+eye_height), direction_fallback (in {window, azimuth, sweep}), position_fallback, clip_to_footprint, and the material_map/sidecar requirement. But it leaves several params unexplained (units, up_axis, sweep_n, north_angle_deg, fallback_azimuth, work_dir), so compensation is partial for a 17-parameter tool.

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

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

The description states a specific purpose: generating workstation eye-point observers (with gaze vectors) from an OBJ room. It clearly distinguishes itself from sibling tools like workplane_grid, photosensors, and sensors by describing the pairing of seat to screen objects and the eye/gaze computation. The verb and resource are specific and unambiguous.

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

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

The description implies when to use it — when workstation eye-point observers and glare views are needed — and details the auto-detection/fallback/bypass logic. However, it never explicitly names alternatives or states when NOT to use it, leaving differentiation from the many related geometry tools (workplane_grid, sensors, photosensors) implicit rather than explicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses the core behavior: dominant facade detection, zone building, sensor placement at sensor_fraction, mount orientation details, return format, .pts file writing, and required inputs. It does not cover failure modes or edge cases, but it is substantially transparent about what the tool does.

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

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

The description is dense but efficient: front-loaded with the tool's purpose, then algorithmic steps, geometry details, outputs, and requirements. Every sentence conveys essential information with no filler.

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

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

For a complex geometric tool, the description covers the main workflow, output format, mount behavior, and required inputs. It even references methodology.md for deeper detail. It is not fully complete because several optional parameters are not explained, but it is adequate for a typical default call.

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

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

Schema description coverage is 0%, so the description must explain parameters, and it does for key ones: zone_rule, depth_factors, sensor_fraction, mount, workplane_h, material_map/sidecar, and the .pts output. However, it leaves several parameters unexplained (units, up_axis, task_height, north_angle_deg, work_dir), which is a meaningful gap for a 14-parameter tool.

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

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

The description is clear that this tool generates daylight-dimming photosensor points from an OBJ room: it locates, builds, and places sensors and returns point coordinates. It does not explicitly distinguish itself from sibling tools like 'sensors' or 'workplane_grid', but the specific algorithm and daylight-dimming context make the purpose sufficiently clear.

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

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

The description provides solid context: it applies to an OBJ room with a glazed facade, and it states that material_map OR sidecar is required to identify floor and glazing. It does not explicitly say when to choose this tool over alternatives, but the technical context and prerequisites give clear enough usage direction.

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

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

No annotations are provided, so the description carries the full burden. It discloses that some presets are illustrative (not measured, see spec 5.7) and that a named fetch returns SPD + metadata. This covers the key behavioral aspects for a list/fetch tool, though it doesn't mention side effects (likely none) or rate limits.

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

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

Two sentences, front-loaded with purpose, and every clause earns its place. The name enumeration is compact and the spec reference is useful without being verbose.

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

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

Given the simple list/fetch behavior and the presence of an output schema, the description covers the essential context: available presets, the illustrative flag, and the return format. It doesn't describe behavior when no name is given (implied as listing all), but that's minor.

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

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

Schema coverage is 0%, but the description compensates fully by enumerating all valid preset names (D65, D50, A, FL1..FL12, LED models) and explaining the effect of providing the 'name' parameter. This is exactly the semantic detail an agent needs beyond the bare schema.

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

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

The description clearly states the tool lists illuminant presets or fetches one by name, which is a specific verb+resource. It distinguishes from generic preset tools by specifying 'illuminant presets', though it doesn't explicitly contrast with the sibling 'list_presets' or 'quality_presets'.

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

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

The description implies usage: use it to list or fetch illuminant presets. It doesn't explicitly state when to prefer this over alternatives like 'list_presets' or provide exclusions. The context is clear but no alternative routing is given.

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

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

No annotations are provided, so the description must carry the full burden. It discloses that it's diagnostic only, that material_map or sidecar is required, that layers left None are omitted, and that point layers can be .pts paths or inline rows. It does not mention potential side effects like file writes, but for a preview tool this is acceptable and the required precondition is clear.

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

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

The description is dense but front-loaded with the core purpose, then explains key parameters in compact phrasing. Every sentence adds value, and there is no fluff. It is appropriately sized for the complexity, though it could benefit from a clearer breakdown of parameters.

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

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

Given 13 parameters and 0% schema coverage, the description covers the most critical aspects: render modes, point layer formats, and the material_map/sidecar requirement. It leaves some parameters (units, north_angle_deg) unexplained, but the tool's core usage is clear. An agent can likely invoke it correctly for basic previews.

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

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

Schema description coverage is 0%, so the description must compensate. It explains render options, point layers (grid_pts, observer_pts, photosensor_pts), and the material_map/sidecar requirement. However, it does not explain units, up_axis, north_angle_deg, work_dir, write_prefix, or luminaire_groups, leaving those parameters ambiguous.

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

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

The description clearly states a specific verb (preview) and resource (room with sensor overlays) and specifies the output (matplotlib PNG, plan + 3D). It also distinguishes itself from photometric renders by explicitly saying 'not a photometric render', which helps differentiate from rendering tools like run_image and run_grid.

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

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

The description provides clear context for when to use it: it's a diagnostic preview, not a final render, and it requires material_map OR sidecar. It does not name specific alternative tools, but the purpose is distinct enough and the 'not a photometric render' note implies it should not be used for final rendering.

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

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

With no annotations, the description carries full responsibility, and it excels. It discloses that omitting 'rad_params' inherits a preview-grade default and quantifies the accuracy impact with a concrete example (sDA 77.78% vs 100%). It explains the behavior of calling with no argument versus a level, and it lists each level with its exact -ab value and caveats. No hidden behavior is omitted.

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

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

The description is long but every sentence earns its place. It front-loads the purpose, explains why ambient quality matters, lists levels with concise caveats, and ends with usage instructions. The structure is logical and scannable, with no fluff or repetition.

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

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

The description covers everything an agent needs: what the tool does, the trade-off it addresses, all valid inputs, the output behavior (table vs single level), and how to integrate with simulation tools. Given the tool's simplicity (one optional parameter) and the presence of an output schema, this is complete. The agent can confidently invoke it without additional context.

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

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

The schema only defines a single optional 'level' parameter with no description or enum, so schema coverage is effectively 0%. The description fully compensates by enumerating the valid values (low, medium, high, extra_high) and explaining what each does. It also clarifies the null/omitted case, making the parameter's meaning completely clear.

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

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

The description opens with a precise purpose: 'Ambient-quality presets: pick the accuracy/runtime trade-off up front, by name.' It clearly distinguishes this tool from siblings like 'presets' and 'list_presets' by focusing specifically on ambient-quality levels for Radiance. The description immediately tells the agent what the tool is for and what it returns.

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

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

The description gives explicit guidance on when to use each level: low for geometry checks, medium for drafts, high for reportable results, extra_high for validation. It also explains how to call it with or without an argument and how to pass the level to simulation tools. While it doesn't explicitly state alternatives, the level list and integration instructions provide complete context for selection.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It conveys that this is a read-only 'Report' operation, lists the availability-related fields, and explains the practical consequence of availability (execution vs returning commands). This is strong coverage for a simple status tool.

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

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

Two sentences, no wasted words, and the core purpose is front-loaded. The first sentence states exactly what is reported; the second sentence gives the actionable use case.

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

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

For a zero-parameter status tool with an output schema, the description is complete. It tells the agent what the tool reports, why it matters, and how to interpret the result in relation to Radiance tool execution.

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

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

The tool has zero parameters, so there is no parameter burden for the description to carry. The baseline of 4 applies, and the description adds useful context by naming the output fields and their role.

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

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

The description states a specific verb ('Report') and resource ('Radiance availability') and enumerates the exact fields included. It clearly distinguishes this from sibling tools like daysim_status by focusing on Radiance, and even references run_grid as an example.

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

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

The description explicitly tells the agent when to use this tool: to check whether Radiance tools will execute or return commands. It gives clear context without naming an alternative tool, so it earns a 4 rather than a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does state that the tool is deterministic and always runs, and it lists the return items. However, it does not mention potential side effects, error conditions, or prerequisites (e.g., whether geometry must be imported first). This is partial but not comprehensive for a complex sizing tool.

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

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

The description is concise, with three sentences that front-load the core purpose and then list outputs and a key parameter. It is well-structured and does not waste words, though the pointer to an external doc adds a minor dependency.

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

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

Given the tool's complexity (16 parameters, no annotations, no schema descriptions), the description is insufficient for an agent to call it correctly. It lacks parameter semantics, usage conditions, and behavioral details such as required inputs or error handling. The external reference to workflow F is not self-contained, and the agent would likely need to consult external docs to use it effectively.

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

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

The schema has 0% description coverage for its 16 parameters, so the description must compensate. It only explains the 'distribution' parameter (direct|direct_indirect|indirect) and hints at 'mel-DER circadian' relating to target_mel_edi. The vast majority of parameters (e.g., rho_wall, maintenance_factor, target_efficacy_lm_w) are not explained at all, leaving the agent to guess their meaning and units.

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

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

The description clearly states it performs fixture sizing using a combined lumen method and circadian solve, and lists the outputs (flux, count, layout, CCT band, energy, caveats). It is specific enough to distinguish from sibling tools like circadian_metrics or spd_to_channels, though it does not explicitly name an alternative. The purpose is unambiguous.

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

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

There is no explicit guidance on when to use this tool versus alternatives. The phrase 'See operating-guide.md workflow F' points to external documentation but does not describe conditions or trade-offs. The description does not mention when to use this over, say, presets or compliance, leaving the agent to infer usage context.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It openly states the return value ('Returns the spectrum + the flat-vs-reference and neutral-vs-colored-sun divergence (always surfaced)') and explains key behavioral differences between methods and sun spectral models. It does not mention side effects or error conditions, but as a reconstruction tool it is likely read-only and the description sufficiently conveys its operational behavior.

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

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

The description is a single dense paragraph but well-structured with semicolons separating the method, sun_spectral, dseries_sky, sun_spd, and return behavior. It front-loads the core purpose and then details options. There is no fluff, but it is lengthy; still, every sentence contributes essential information for correct invocation.

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

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

Given the tool's complexity (10 parameters, 2 required), the description covers the most decision-relevant parameters and the return contract. An output schema exists, which likely details the exact return structure, so the description need not repeat that. It omits a few parameters, but the essential information for selecting the method and understanding the output is present. Slight gaps remain for edge-case parameters like channel_type and solar_zenith, but overall it is sufficiently complete for an agent to call correctly in most scenarios.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the meaning of method, sun_spectral, dseries_sky (and its dependence on sky_cct), and sun_spd as an override. It does not explicitly cover sky_spd, channel_type, or solar_zenith, but these are either inferable from context or secondary. The description adds significant semantic value beyond the bare schema, though not exhaustive.

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

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

The description starts with a specific action: 'Reconstruct a 401-value 380-780 nm @1 nm per-nm spectrum from sky+sun channel sets'. It clearly identifies the verb, the resource, and the source data, distinguishing it from sibling tools like spd_to_channels (conversion) or spectral_metrics (analysis). It also references the spec section, adding precision.

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

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

The description explains the two methods ('faithful' reproduces legacy 2.0, 'reference' re-integrates to channel bin totals) and the sun_spectral options, giving clear context on what each does. However, it does not explicitly state when to prefer one over the other or exclude alternatives among siblings. There is no 'when not to use' guidance, but the tool's purpose is distinct enough that usage is largely self-evident.

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

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

No annotations are provided, so the description carries the full burden. It states 'look up' implying a read operation, but does not disclose side effects, error behavior, or output format. The description is minimal and leaves the agent to infer safety 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.

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

The description is a single sentence that front-loads the purpose and lists the valid topics. It is concise and free of filler, though it could be slightly more structured with bullet points, but as a string it is efficient.

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

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

Given the tool's simplicity (one optional parameter, output schema exists), the description is fairly complete. It specifies the valid topics, and the output schema presumably defines the return structure. The main gap is the lack of guidance on edge cases or alternatives, but for a straightforward lookup this is adequate.

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

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

Although schema coverage is 0%, the description compensates by enumerating the allowed values for 'topic' (bins | coefficients | caveats | overview), which is more informative than the schema's bare string type with a default. It tells the agent exactly what inputs are valid.

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

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

The description clearly states the action (look up) and the resource (HCL reference content), and even lists specific topics (bins, coefficients, caveats, overview). It is specific and unambiguous, though it does not explicitly differentiate from the sibling 'get_reference', which might overlap.

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

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

No guidance is provided on when to use this tool versus alternatives. The description implies that it is for retrieving HCL reference content, but does not mention when not to use it, prerequisites, or how it relates to siblings like 'get_reference' or 'list_presets'.

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

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

With no annotations, the description carries the full burden. It discloses key behaviors: it runs Radiance if present, otherwise returns the exact command sequence; it automatically writes inline points to a .pts file; and it subsets the .wea when period is given. These are meaningful behavioral details beyond the schema, though it does not cover error handling or performance.

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

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

The description is well-structured: a concise purpose line, then dedicated sections for channel_scenes, points, and period, followed by a single execution note. It is front-loaded with the purpose and packs significant detail without being verbose. The use of line breaks aids readability.

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

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

The description covers the core inputs and the execution behavior, and references dependencies like import_geometry and run_grid. However, given the tool's complexity (11 params, simulation, no annotations), it omits explanations for several parameters and does not describe the output format, although an output schema exists. It is adequate but not exhaustive.

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

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

The schema has 0% description coverage, so the description must compensate. It thoroughly explains channel_scenes (including the single-geometry note), points (inline vs .pts with auto-writing), and period (analysis window and subsetting). However, it leaves many other parameters (wea, run, quality, work_dir, rad_params, channel_type, timestep_min, dosimetry_threshold) undocumented, relying solely on their names. It covers the most complex required inputs but not all.

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

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

The opening line clearly states the tool's function: 'Annual 2-phase DDS HCL simulation (per channel) -> annual mel-EDI + circadian dosimetry.' This is a specific verb+resource combination that distinguishes it from siblings like run_grid or run_image, which likely focus on standard daylight or rendering. The description also clarifies the per-channel scope and output metrics.

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

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

The description does not explicitly state when to use this tool versus alternatives such as run_grid or annual_daylight. It implies it is for HCL-specific annual simulation, but provides no exclusions or alternative routing. The final note about Radiance presence is behavioral, not usage guidance.

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