Skip to main content
Glama

Run impact assessment

lca_run_assessment

Run LCIA on a target and save the result as a durable assessment (a<N>). ref is a saved workspace system (s<N>), or an engine-catalog process (p<N>) or system (e<N>) from engine_search; it is calculated on the database it belongs to. Runs the calculation with the given parameters and returns the impact result; a run that finishes within 45 seconds returns its result directly, and a longer one returns a task_id for lca_get_task_status; the assessment is always saved into the workspace named by workspace, with no separate save step. A catalog e<N> is assessed as a one-off result and not imported as a tracked system (lca_import_system does that). nw_set names one of the method's normalization/weighting sets, applied after the calculation for a single score. lca_analyze_contributions breaks a result down. The assessment_interpretation skill (load_skill) documents what a result means and comparison discipline.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refYesTarget ref: a saved system `s<N>`, or a catalog process `p<N>` / engine system `e<N>` from `engine_search`.
amountNoHow many of the target's DECLARED functional units to assess (N). The calc scales by N x the declared amount, the SAME way for every target kind — a saved `s<N>` (composed, linked, or still mirrored to its remote openLCA copy), an imported `e<N>`, or a catalog process `p<N>`. Omit it to assess exactly one declared functional unit (a catalog `p<N>`/`e<N>` records no declared FU, so its declared amount is 1 reference unit and N is the whole scalar). Must be > 0 and finite.
nw_setNoName of one of the method's normalization/weighting sets (e.g. 'EF 3.0 normalization and weighting set'), applied after the calculation: adds normalized and weighted results and a single score beside the per-category table. Omit for characterized results only; the result lists the sets the method offers.
workspaceYesName 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.
allocationNoAllocation for multi-output processes. Applies to EVERY target kind — a saved `s<N>` (composed or linked) as much as a catalog `p<N>`/`e<N>`. Omit it (or pass `as_declared`) to apply each dataset's OWN declared allocation procedure, resolved per process by openLCA — the same thing openLCA desktop does, and the default here. Naming any other value overrides every dataset in the system, which is a methodological choice you must report.
method_preferenceNoPreferred LCIA method (e.g., 'ReCiPe', 'CML'). Default: ReCiPe 2016.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / engine
      Removed value: -{
      -  "description": "Name of the engine database, as `lca_get(kind='engines')` lists it (case-insensitive). Omitted: this connection's default engine.",
      -  "maxLength": 255,
      -  "minLength": 1,
      -  "type": "string"
      -}
  2. Changed1 schema field changed
    • addedInput schema / properties / nw_set
      Added value: +{
      +  "description": "Name of one of the method's normalization/weighting sets (e.g. 'EF 3.0 normalization and weighting set'), applied after the calculation: adds normalized and weighted results and a single score beside the per-category table. Omit for characterized results only; the result lists the sets the method offers.",
      +  "maxLength": 200,
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • 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."
  4. Changed2 schema fields changed
    • 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
  5. Changed3 schema fields changed
    • addedInput schema / properties / engine
      Added value: +{
      +  "description": "Name of the engine database, as `lca_get(kind='engines')` lists it (case-insensitive). Omitted: this connection's default engine.",
      +  "maxLength": 255,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • 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: -[
      -  "ref"
      -]New value: +[
      +  "workspace",
      +  "ref"
      +]
  6. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses the sync/async split (runs under 45s return the result directly, longer runs return a `task_id` for `lca_get_task_status`) and the persistence semantics (the assessment is always saved into `workspace` with no separate save step). These are the behaviors an agent most needs and none are in the structured fields.

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 the core action and outcome, then the ref taxonomy, then async behavior, then sibling routing — a sensible priority order with no filler. The sentences are long and clause-heavy (semicolon-chained), which costs a little readability.

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 a complex 6-parameter mutation-style tool with no output schema, the description covers the return shape (impact result or `task_id`), persistence, target kinds, and where to go for interpretation via the `assessment_interpretation` skill. Nothing an agent needs to invoke it correctly 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 the baseline is 3, but the description adds real meaning beyond the schema: the ref 'is calculated on the database it belongs to', `nw_set` is applied after the calculation for a single score, and the assessment lands in the named workspace. The `amount` and `allocation` parameters are left to the schema, but the added ref/nw_set semantics justify a bump.

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+outcome: 'Run LCIA on a target and save the result as a durable assessment (`a<N>`)'. It clearly separates this from siblings like `lca_import_system` (one-off vs tracked system) and `lca_analyze_contributions` (breakdown, not run).

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 which ref kinds are valid (`s<N>`, `p<N>`, `e<N>` from `engine_search`) and when to use alternatives: 'a catalog `e<N>` is assessed as a one-off result and not imported as a tracked system (`lca_import_system` does that)' and '`lca_analyze_contributions` breaks a result down'. It even routes agents to `load_skill` for interpretation.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources