Aevia LCA Modeler

AI-powered life cycle assessment and modelling: connect to LCA databases, build product systems, run life cycle assessments and analyze the results.

CommunityOnlineNo sign-inGlobalFreeRead-only

What it can do

  • Engine Search: Search the LCA database this session is bound to. `kind` scopes to processes, systems, flows, or `all` (all three in parallel). `query='*'` (or an empty string) enumerates everything of
  • Engine Get: Detail for a ref minted by `engine_search` or `engine_list_methods` — an object in the connected engine database. Polymorphic on the prefix: `p<N>` → process, `e<N>` → engine product syste
  • Engine List Methods: Inspect LCIA methods. Without `ref`, lists the available methods, each with an `m<N>` ref. With `ref` (`m<N>`), returns that method's impact categories; `include_factors=true` add

What data it sees

Do you need an account

No: the server works without sign-in

AI-powered life cycle assessment and modelling: connect to LCA databases, build product systems, run life cycle assessments and analyze the results.

How to connect

How to connect Aevia LCA Modeler to Claude

The server address to paste into Claude settings:

https://aevia-lca-modeler.run.tools

  1. Open Claude (claude.ai or the desktop app).
  2. Go to Settings → Connectors.
  3. Click Add custom connector.
  4. Paste the server address copied below into Remote MCP server URL and click Add.
  5. In a chat, click + → Connectors and switch the new connector on.

Custom connectors are available on Free, Pro, Max, Team and Enterprise plans (Free is limited to one). On Team and Enterprise an organization Owner adds the connector first under Organization settings → Connectors.

Authorization

After you click Add, a sign-in window for the service opens. Sign in with your own account and approve access. Claude never sees your password.

How to connect Aevia LCA Modeler to ChatGPT

The server address to paste into ChatGPT settings:

https://aevia-lca-modeler.run.tools

  1. Open ChatGPT in a browser (chatgpt.com). A Plus, Pro, Business, Enterprise or Edu plan is required.
  2. Turn on developer mode once: Settings → Apps → Advanced settings → Developer mode.
  3. Open Settings → Connectors and click Create.
  4. Fill in the form: Name (anything), Description (one line about what the service does), MCP server URL (copy it below).
  5. Under Authentication choose OAuth if the service requires sign-in, otherwise None. Click Create.
  6. In a new chat open + → Apps/Connectors and enable the connector.

OpenAI has renamed this section before (Connectors → Apps/Plugins). If the label differs, search settings for "developer mode". On Business/Enterprise workspaces an admin must allow custom connectors first.

Authorization

On first use ChatGPT opens the service's sign-in window. Sign in and approve access.

How to connect Aevia LCA Modeler to Cursor

The server address to paste into Cursor settings:

https://aevia-lca-modeler.run.tools

Fastest: click Open in Cursor below and confirm the prompt.

Manually:

  1. In Cursor open Settings → Cursor Settings → MCP and click Add new global MCP server.
  2. Paste the JSON copied below into ~/.cursor/mcp.json (per project: .cursor/mcp.json in the repo root).
  3. Save the file. The server appears in the MCP list; authorize it there if asked.

Authorization

If the service needs sign-in, an authorize button appears next to the server in the MCP list.

Server tool list (20)

Raw names from tools/list. Only developers need these.

engine_searchSearch the LCA database this session is bound to. `kind` scopes to processes, systems, flows, or `all` (all three in parallel). `query='*'` (or an empty string) enumerates everything of the given `kind` — e.g. `kind='system', query='*'` lists every product system in the database (one page of `limit`, plus the true total). With `kind='flow'`, `flow_type` (`elementary` / `product` / `waste`) filters the results; with `kind='process'`, `process_type` (`unit_process` / `system_process`) does. Returns typed refs (`p1`, `e1`, `f1`; a system hit is an `e<N>` engine-catalog ref, not a workspace `s<N>`) that stay valid for the session and are accepted by `engine_get` and `lca_run_assessment`. `scope_ref` (any engine ref such as `p3`/`e1`/`m2` from an earlier result) searches the database that ref came from instead of the session's current one, for comparing across databases; refs minted that way stay bound to that database.
engine_getDetail for a ref minted by `engine_search` or `engine_list_methods` — an object in the connected engine database. Polymorphic on the prefix: `p<N>` → process, `e<N>` → engine product system, `f<N>` → flow, `m<N>` → LCIA method. A workspace `s<N>` is a different object, read with `lca_get(ref='s<N>')`; this tool rejects it. Process detail defaults to a summary of both sides (top 20 each, ranked by share of magnitude per unit); `section='inputs'|'outputs'` with `offset` pages one side, and `limit` (max 100) sizes the page. Every heading states the true total, and a follow-up call hint is included whenever rows remain. `include_providers=true` on a flow ref lists the processes that produce it. A process's exchange rows and reference product carry `f<N>` refs, which the compose and edit tools accept directly.
engine_list_methodsInspect LCIA methods. Without `ref`, lists the available methods, each with an `m<N>` ref. With `ref` (`m<N>`), returns that method's impact categories; `include_factors=true` adds the characterization factors per category, which is rarely needed. When listing, `scope_ref` (any engine ref such as `p3`/`e1`/`m2`) lists the methods of the database that ref came from instead of the session's current one.
lca_getPolymorphic read of objects saved in the session's workspace. Takes exactly one of `ref` (one object's detail) or `kind` (a list). Refs: `s<N>` → product system (live openLCA structure), `a<N>` → saved assessment (full impact results), `c<N>` → saved comparison (full matrix). An `s<N>` read also states the system's kind and the edit tool it takes; `form='authored'` returns it in the authored shape the compose and edit tools accept. Kinds: 'systems' / 'assessments' / 'comparisons' return paginated lists of this workspace, with optional filters (`query`, `system_ref`, `method`, `assessment_status`, `include_stale`); 'workspaces' / 'engines' list the workspaces and engine databases available, by name, marking the current one. Workspace refs are short handles with no UUID equivalent, so UUIDs are not accepted; current contents can be listed with `kind='systems' | 'assessments' | 'comparisons'`.
lca_run_assessmentRun 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`. Runs the calculation with the given parameters and returns the impact result; the assessment is always saved into the session's 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). `lca_analyze_contributions` breaks a result down.
lca_compare_assessmentsSave a comparison across 2–8 saved assessments. Each target is an `a<N>` ref (listable with `lca_get(kind='assessments')`); every `lca_run_assessment` call already saves one, so there is no separate save step. Two preconditions are enforced (400): all targets share one LCIA method, and all declare the same functional unit — comparing 1 kg against 1 unit is refused unless `allow_mismatched_fu` is set. Differences in allocation, database or provider linking are not refused; they are returned as equivalence warnings alongside the result. The comparison is saved into the session's workspace and returned as `primary_ref` (`c<N>`), which holds the full matrix. The matrix does not rank the targets; it reports each impact category separately.
lca_analyze_contributionsBreak down what drives an impact category. Takes exactly one target: `assessment_ref` (`a<N>`) analyses a saved assessment's setup, or `system_ref` (`s<N>`) analyses a saved system directly, with no prior assessment needed. `source` must match the target; with `system_ref`, `method` and `amount` 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 `assessment_ref` is available; `flow`, `upstream` and `system_ref` 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.
lca_analyze_sensitivityQuantify 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.
lca_compose_assemblyBuild a new product system as a bill of quantities — existing database processes and the amount of each — in one call. Structure only; no LCIA runs. The assembled product is the functional unit, and each member is linked to its own full upstream when assessed, so the total is a cradle-to-gate figure with a per-material breakdown. Takes `inputs` (flat) or `stages` (a DAG of life-cycle stages), not both. The system is validated against the database; if valid it is saved and `system_ref` is returned for `lca_run_assessment`. If invalid, the response lists `errors[]`, `missing_required[]` and `warnings[]` and nothing is saved; a corrected call carries the complete system. `dry_run: true` validates without saving. A tool error, rather than an invalid result, means the engine is unavailable. Members are `p<N>` refs; UUIDs are not accepted. `lca_compose_linked` builds explicit supply edges instead. The `product_system_authoring` skill (`load_skill`) documents build order and common failures.
lca_compose_linkedBuild a new product system as an explicit process network — every member process and every supply edge between them — in one call. Structure only; no LCIA runs. It controls which process supplies which flow to which; for a list of materials and quantities, `lca_compose_assembly` is simpler. `ref_process_ref` is the functional unit's process and also appears in `member_process_refs`. The system is validated against the database; if valid it is saved and `system_ref` is returned for `lca_run_assessment`. If invalid, the response lists `errors[]`, `missing_required[]` and `warnings[]` and nothing is saved; a corrected call carries the complete system. `dry_run: true` validates without saving. A tool error, rather than an invalid result, means the engine is unavailable. Takes `p<N>`/`f<N>` refs; UUIDs are not accepted. Requires a writable engine of the user's own; a member the engine cannot reach blocks the build. The `product_system_authoring` skill (`load_skill`) documents build order and common failures.
lca_import_systemImport an engine-catalog product system (an `e<N>` ref from `engine_search`) into the current workspace as a saved system, returning a stable `s<N>`. Captures the system's full definition server-side (no need to read its graph) and mirrors it — the copy tracks the engine original for drift and is immediately assessable (`lca_run_assessment s<N>`) and comparable. Idempotent: re-importing the same engine system returns the existing `s<N>`. Only accepts `e<N>` (engine systems) — a workspace `s<N>` is already imported, and a process `p<N>` is not a system. To RESTRUCTURE it: read `lca_get(ref='s<N>', form='authored')`, then either targeted `lca_edit_linked` ops (`add_link`/`remove_link`/`rewire_link`/`replace_provider`/`set_target_amount`/`set_title` — a new version of the same `s<N>`) or `lca_compose_linked` (a new `s<M>` from the restructured topology). The mirror stays fully assessable/comparable. On this rail `lca_edit_linked` also needs the `base_version_seq` `lca_get` reports.
lca_edit_assemblyPatch a saved composed (bill-of-materials) system (`s<N>`). Ops: `replace_provider` (swap a member everywhere it is used), `set_target_amount` (rescale the functional unit), `set_title` (rename), `add_member` / `remove_member`, `set_member_amount` (rescale an existing member), `add_stage` / `remove_stage` (grow or shrink the stage DAG, e.g. an amortization layer; it must stay acyclic with one sink). `mode` (default `edit`): `edit` patches in place, keeping the same `s<N>`; `fork` derives a new `s<M>`. A drift-tracked mirror is forked automatically on `edit`, with a warning. Each member is linked cradle-to-gate independently when assessed, so swaps and additions bring their own background; only unit compatibility is checked, so a swap can change a dataset's geography, technology and reference year. Members are `p<N>` refs; UUIDs are not accepted. Linked and single-process systems are edited with `lca_edit_linked`. The returned ref can be assessed with `lca_run_assessment`.
lca_edit_linkedPatch a saved linked (explicit process network) or single-process system (`s<N>`). Graph ops: `add_link` (wire a supplier onto a consumer input; its provider joins automatically), `remove_link` (drop matching edges; an orphaned member is pruned), `rewire_link` (repoint one edge). Also `replace_provider` (swap a supplier on every edge it feeds; a bare `unit_process` swap warns, as its background is not wired), `set_target_amount` and `set_title`. Only unit compatibility is checked on a swap, so geography, technology and vintage can change. `lca_get(ref='s<N>', form='authored')` shows every edge and the `consumer_input_index` needed when a consumer takes one flow on several inputs. A link's `amount` only validates; links carry topology, not quantities. `mode` `edit` (default) patches in place; `fork` derives a new `s<M>`; a mirror is forked automatically. A single-process system takes only the two setters. Composed systems use `lca_edit_assembly`. Takes `p<N>`/`f<N>` refs; UUIDs are not accepted.
lca_get_task_statusPoll a long-running call that returned a `task_id` instead of a result. Takes that id. Returns `status`: 'pending' (still running; a full assessment can take 1–15 minutes), 'success' (`result` holds the tool's normal payload, refs included) or 'error' (with `can_retry`). Only calls that returned a `task_id` have one; a tool that returned its result directly has nothing to poll. A `task_id` is readable only by the session that started it, and only for a day.
lca_switch_workspaceMove this connector session to a different workspace for the rest of the session — typically out of the sandbox a new connection starts in and into a workspace the user works in. `name` is the workspace name as `lca_get(kind='workspaces')` shows it (a code span; backticks optional). Everything afterwards — saving, listing, assessing — happens in the new workspace; there is no per-call workspace argument. Switching invalidates workspace refs: `s<N>` system, `a<N>` assessment, `c<N>` comparison, `b<N>` breakdown, `v<N>` sensitivity and `r<N>` report are per-workspace ordinals, so after a switch the same number names a different object, and current refs come from `lca_get(kind='systems' | 'assessments' | 'comparisons')`. Engine-catalog refs (`p<N>`, `e<N>`, `f<N>`, `m<N>`) are unaffected.
lca_switch_engineChange which engine database this connector session browses and composes against. `name` is the engine name as shown, matched case-insensitively (a code span, accepted with or without its backticks). Only new browsing (`engine_search` / `engine_get` / `engine_list_methods`) and composing move. Nothing saved moves: the workspace binding and every `s<N>`/`a<N>`/`c<N>`/`b<N>`/`v<N>` ref are unaffected, and saved systems keep solving on their own engine. Catalog refs (`p<N>`, `e<N>`, `f<N>`, `m<N>`) stay bound to the database that minted them: reading one still works, since `engine_get` and `lca_run_assessment` follow the ref back to its own database, but `lca_compose_*` and `lca_edit_*` refuse a member ref from another database, so members for a new system come from searches run after the switch.
load_skillReturn a skill's full playbook as this tool's result. It performs no action itself: a playbook is step-by-step guidance for a multi-step job that tool descriptions are too short to cover, and is most useful read before starting that job. `product_system_authoring` covers building a new product system with `lca_compose_assembly` / `lca_compose_linked`: build order, which of the two fits, and failure modes the tool descriptions omit. A loaded skill's text stays in context, so one load per session is enough. Skills are gated on what the token can call; requesting one that is not available returns the list of those that are.
knowledge_searchDiscover documents in the knowledge library. Returns ref-numbered metadata only (title, authors, year, journal, DOI) — no abstract, no excerpts. Refs (e.g. `k1`, `k7`) persist for this session and are accepted by `knowledge_get_excerpts` (passages) and `knowledge_get_full_document` (the full paper). `limit` defaults to 12; a larger limit suits broad literature surveys. Optional filters: `journal` (its full name) and `year_from` / `year_to`.
knowledge_get_full_documentFull text of a single document, by a `k<N>` ref from a recent `knowledge_search` (e.g. `k1`, `k7`). `knowledge_get_excerpts` returns abstracts and matching passages, which usually suffice; this returns the whole paper. Refs marked [ref-only] have no full text, so for those it returns the same abstract `knowledge_get_excerpts` does.
knowledge_get_excerptsGet document abstracts and matching passages. Three modes: (1) `query` only → discover documents AND return each one's abstract + relevant chunk excerpts in one call; (2) `document_refs` only → abstract + first chunks per doc as a table-of-contents glimpse; (3) both → re-rank chunks against the query, scoped to those refs. At least one of `query` or `document_refs` is required. In `query`-discovery mode you may also scope by `journal` / `year_from` / `year_to` (ignored when `document_refs` is given).