Aevia

Analyze contributions

lca_analyze_contributions

Break down what drives an impact category. ref is a<N> (analyses a saved assessment's setup) or s<N> (analyses a saved system directly, with no prior assessment needed; method and amount then shape the solve). Returns a b<N> breakdown ref, a separate object from the a<N> it analyses. Modes: by='process' ranks contributing processes (total_amount = per-process total, loop-corrected); by='flow' ranks substance drivers by amount × CF; by='upstream' walks the supply chain. For composed (bill-of-materials) systems only process via an a<N> is available; flow, upstream and an s<N> return 422. The first call per solve prepares the engine in the background (about 3–5 s); later calls on the same solve reuse it. Rows carry p<N>/f<N> refs for further detail.

Input Schema

Name	Required	Description	Default
`by`	No	How to break down the result: rank contributing processes, rank substance flows, or walk the upstream supply-chain tree. Composed (bill-of-materials) systems support process only.	process
`ref`	Yes	`a<N>` — analyse that saved assessment's setup (its system, method and functional unit); `s<N>` — analyse the saved system directly, with NO prior assessment (`method` / `amount` apply only here). List current ones with `lca_get(kind='assessments')` / `lca_get(kind='systems')` — never pass UUIDs.
`depth`	No	Upstream only: maximum depth of the supply-chain walk (1–6).
`top_n`	No	Maximum number of rows to return (default 20).
`amount`	No	`s<N>` only: how many of the system's DECLARED functional units to analyse (N). The solve scales by N x the declared amount, the same way `lca_run_assessment` does. Omit to analyse at the system's declared functional unit (N=1); an explicit value overrides. Ignored with an `a<N>`, which inherits its functional unit — and ignores `amount` entirely — from the saved assessment.
`cutoff`	No	Upstream only: drop nodes contributing less than this fraction of the total impact (0–1, default 0.01).
`method`	No	`s<N>` only: preferred LCIA method — fuzzy-matched (substring) against the methods in the connected database; free text is accepted. Defaults to the same house preference `lca_run_assessment` uses. Ignored with an `a<N>`, which inherits its method from the saved assessment.
`category`	No	Impact category to break down. Defaults to the first category of the method.
`direction`	No	Flow only: which exchange direction to keep — 'input' = substances taken from the environment (resources, land, water intake); 'output' = released to it (emissions like CO₂ to air); 'both' (the default) applies no filter. Most categories are dominated by one direction anyway; narrow mainly for net-balance categories like water consumption, where withdrawals (input) and returns (output) carry opposite signs and would otherwise both rank as top 'drivers' while largely cancelling.	both
`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.
`compartment`	No	Flow only: filter substances to one environmental compartment (medium) — e.g. 'air', 'water', 'soil'. Case-insensitive substring against the compartment path.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 13, 2026

changedInput schema / properties / amount / description

Previous value: -"`system_ref` only: how many of the system's DECLARED functional units to analyse (N). The solve scales by N x the declared amount, the same way `lca_run_assessment` does. Omit to analyse at the system's declared functional unit (N=1); an explicit value overrides. Ignored with `assessment_ref`, which inherits its functional unit — and ignores `amount` entirely — from the saved assessment."New value: +"`s<N>` only: how many of the system's DECLARED functional units to analyse (N). The solve scales by N x the declared amount, the same way `lca_run_assessment` does. Omit to analyse at the system's declared functional unit (N=1); an explicit value overrides. Ignored with an `a<N>`, which inherits its functional unit — and ignores `amount` entirely — from the saved assessment."

removedInput schema / properties / assessment_ref

Removed value: -{
-  "description": "Saved-assessment ref in the form `a<N>` (e.g. `a3`) — analyse the setup this assessment captured (its system, method and functional unit). Mutually exclusive with `system_ref`. List current assessments with `lca_get(kind='assessments')` to pick the right one — never pass UUIDs.",
-  "pattern": "^a\\d+$",
-  "type": "string"
-}

changedInput schema / properties / method / description

Previous value: -"`system_ref` only: preferred LCIA method — fuzzy-matched (substring) against the methods in the connected database; free text is accepted. Defaults to the same house preference `lca_run_assessment` uses. Ignored with `assessment_ref`, which inherits its method from the saved assessment."New value: +"`s<N>` only: preferred LCIA method — fuzzy-matched (substring) against the methods in the connected database; free text is accepted. Defaults to the same house preference `lca_run_assessment` uses. Ignored with an `a<N>`, which inherits its method from the saved assessment."

addedInput schema / properties / ref

Added value: +{
+  "description": "`a<N>` — analyse that saved assessment's setup (its system, method and functional unit); `s<N>` — analyse the saved system directly, with NO prior assessment (`method` / `amount` apply only here). List current ones with `lca_get(kind='assessments')` / `lca_get(kind='systems')` — never pass UUIDs.",
+  "pattern": "^[as]\\d+$",
+  "type": "string"
+}

removedInput schema / properties / source

Removed value: -{
-  "description": "Which kind of target this analysis runs on — set it to match the ref you pass: 'assessment' with `assessment_ref`, 'system' with `system_ref`.",
-  "enum": [
-    "assessment",
-    "system"
-  ],
-  "type": "string"
-}

removedInput schema / properties / system_ref

Removed value: -{
-  "description": "Saved-system ref in the form `s<N>` (e.g. `s1`) — analyse this system directly, with NO prior assessment. Mutually exclusive with `assessment_ref`. List current systems with `lca_get(kind='systems')` — never pass UUIDs.",
-  "pattern": "^s\\d+$",
-  "type": "string"
-}

changedInput schema / required

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

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."

Changed2 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
```

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"
+}

addedInput schema / required
```
Added value: +[
+  "workspace"
+]
```

First observedSep 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare a non-read-only, non-idempotent operation but say nothing about cost or side effects; the description fills that gap by disclosing that the first call per solve prepares the engine in the background (~3–5 s) and later calls reuse it, plus the 422 failure modes. It also notes the returned b<N> is a new object separate from the analysed a<N>. Rich disclosure beyond annotations.

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?

Dense but front-loaded: the core purpose, the ref scheme, and mode behavior come first, with latency and error caveats at the end. Backtick refs compact a lot into one paragraph, though the density borders on cryptic for a first-time reader.

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

Completeness5/5

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

For an 11-parameter tool with no output schema, the description explains the return shape (b<N> breakdown ref, p<N>/f<N> row refs for further detail), all mode-dependent parameter applicability, engine-preparation latency, and error conditions. Nothing essential for a correct invocation is missing.

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%, so baseline is 3, but the description adds real meaning: `ref` `a<N>` vs `s<N>` semantics, that `method`/`amount` only shape an `s<N>` solve, and the per-mode meaning of results (`total_amount` loop-corrected for process, `amount × CF` for flow, supply-chain walk for upstream). Adds value over the schema without fully documenting every param (e.g. depth/top_n/cutoff stay schema-only).

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?

States a specific verb+resource (break down what drives an impact category) and immediately disambiguates from siblings by naming the three modes and the b<N> output object distinct from the a<N> input. An agent can distinguish this from lca_analyze_sensitivity or lca_run_assessment 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 Guidelines4/5

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

Gives explicit when-to-use routing: `a<N>` analyses a saved assessment's setup, `s<N>` analyses a saved system with no prior assessment, and it names lca_get for enumerating refs. It also states when-not (composed systems support only 'process' via `a<N>`; flow/upstream/s<N> return 422). Lacks an explicit comparison to lca_analyze_sensitivity, so 4 rather than 5.

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?