Aevia

Analyze sensitivity

lca_analyze_sensitivity

Quantify which inputs drive a system's result, and by how much. Target: a saved assessment via assessment_ref (a<N>). Composed (bill-of-materials) systems are analysed exactly and instantly; engine-backed tornado uses one cached contribution solve, and engine sweep/scenarios re-solve openLCA param:<name> parameters. Every result states its nature, source and limits. Modes: tornado ranks each variable's ±variation_pct swing; sweep walks one variable over [range_min, range_max] (reference_ref/threshold give a break-even); scenarios compares named overrides (id → multiplier, 1.0 = baseline). Variable ids come from a default tornado run, or a unique name fragment is resolved server-side (an ambiguous or unmatched one returns the valid ids). member:<slug> = composed member; driver:<slug> = engine driver; param:<name> = engine parameter (sweepable); system:amount scales a whole composed system. Returns a durable v<N>, separate from the a<N> it analyses.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mode`	No	Analysis type.	tornado
`steps`	No	Sweep: number of points.
`category`	No	Impact category to analyse. Defaults to the method's first.
`variable`	No	Sweep: the single variable to walk — a composed `member:<slug>` id (analytic), an engine `param:<name>` id (openLCA dataset parameter — re-solves the model, deferred), a unique name fragment (resolved server-side), or `system:amount` (scale the whole system: service-life / replacement-count). An engine `driver:<slug>` is NOT sweepable (tornado only) — use `param:<name>` instead. Unresolvable → 422 with the valid list.
`range_max`	No	Sweep: upper multiplier.
`range_min`	No	Sweep: lower multiplier.
`scenarios`	No	Scenarios: named override sets vs the same baseline, e.g. [{name: 'worst case', overrides: {'member:steel': 1.5}}]. Keys are composed `member:<slug>` / `system:amount` ids (analytic) OR, for an engine target, engine `param:<name>` ids (re-solves the model, deferred) — name fragments resolve server-side either way, but a scenario set may not MIX driver/member and param keys. An unresolvable key 422s.
`threshold`	No	Sweep: break-even vs a fixed value. Mutually exclusive with `reference_ref`.
`variables`	No	Variables to rank: composed `member:<slug>` ids, engine `driver:<slug>` ids, OR unique name fragments (resolved server-side; a default tornado's rows list every id). Naming ONLY engine `param:<name>` knobs instead re-solves the model under those parameters (deferred) rather than ranking drivers — mixing `driver:`/`param:` ids in one call 422s. Omit for all (composed members, or the E1 driver tornado). `system:amount` is NOT valid here (use sweep/scenarios).
`workspace`	Yes	Name of the workspace to work in, as `lca_get(kind='workspaces')` lists it (backticks optional). Named on every call: several conversations can share one connection, and each names its own workspace. The connection's default is often an empty sandbox rather than the user's work.
`reference_ref`	No	Sweep: break-even vs another assessment's total (`a<N>`). Mutually exclusive with `threshold`.
`variation_pct`	No	Tornado: perturb each variable by ±this percent.
`assessment_ref`	Yes	Saved-assessment ref in the form `a<N>` (e.g. `a3`) — study the setup this composed assessment captured. List current assessments with `lca_get(kind='assessments')` — never pass UUIDs.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 28, 2026

changedInput schema / properties / workspace / description

Previous value: -"Name of the workspace to work in, as `lca_get(kind='workspaces')` lists it (backticks optional). Named on every call: several conversations can share one connection, and each names its own workspace."New value: +"Name of the workspace to work in, as `lca_get(kind='workspaces')` lists it (backticks optional). Named on every call: several conversations can share one connection, and each names its own workspace. The connection's default is often an empty sandbox rather than the user's work."

Changed4 schema fields changedSep 27, 2026
- changedInput schema / $schema
```
Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
```
- removedInput schema / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / scenarios / items / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / scenarios / items / properties / overrides / propertyNames
```
Added value: +{
+  "type": "string"
+}
```

Changed2 schema fields changedSep 24, 2026

addedInput schema / properties / workspace

Added value: +{
+  "description": "Name of the workspace to work in, as `lca_get(kind='workspaces')` lists it (backticks optional). Named on every call: several conversations can share one connection, and each names its own workspace.",
+  "maxLength": 255,
+  "minLength": 1,
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "assessment_ref"
-]New value: +[
+  "workspace",
+  "assessment_ref"
+]

First observedSep 23, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations declare non-read-only, non-destructive, non-idempotent; the description is consistent with these and adds real context: composed systems are 'exact and instantly' while engine targets 're-solve' and are deferred, and 'Every result states its nature, source and limits'. It also discloses that a durable v<N> is created alongside the analysed a<N>.

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

Conciseness4/5

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

Front-loaded with purpose and target, then proceeds mode-by-mode with the id-syntax legend last. Dense but telegraphese makes it slightly harder to scan; nearly every clause carries operational information, so little is wasted.

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

Completeness4/5

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

No output schema exists, and the description partially compensates by telling the agent what comes back (a durable v<N>, plus stated nature/source/limits). With 13 params fully documented in the schema, this is close to complete for a complex multi-mode tool.

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

Parameters4/5

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

Schema coverage is 100%, but the description adds meaning the schema does not: the distinction between composed/analytic vs engine/deferred targets, mutual exclusivity (threshold vs reference_ref), server-side fragment resolution, and the 422-with-valid-ids failure path for unresolvable variables. This is more than restating the schema.

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

Purpose5/5

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

Opens with a specific verb+resource: 'Quantify which inputs drive a system's result, and by how much,' which is distinct from the sibling lca_analyze_contributions and lca_compare_assessments. The three modes are named and their scope stated, so an agent can route without opening the schema.

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

Usage Guidelines5/5

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

Explicitly states when to use each mode (tornado ranks, sweep walks one variable with break-even, scenarios compares overrides) and names the exact alternatives to avoid: driver:<slug> is 'tornado only — use param:<name> instead', and system:amount 'is NOT valid here (use sweep/scenarios)'. Error behavior and id-resolution fallbacks are also documented.

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

All Aevia tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?