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.

От сообществаРаботаетБез входаГлобальныйБесплатноТолько чтение

Что умеет

  • 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

Какие данные видит

Нужен ли аккаунт

Не нужен: сервер работает без входа

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

Как подключить

Как подключить Aevia LCA Modeler к Claude

Адрес сервера, который нужно вставить в настройках Claude:

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

  1. Откройте Claude (сайт claude.ai или приложение для компьютера).
  2. Перейдите в Настройки → Коннекторы (в английском интерфейсе: Settings → Connectors).
  3. Нажмите Добавить пользовательский коннектор (Add custom connector).
  4. Вставьте адрес сервера, скопированный ниже, в поле URL удалённого MCP-сервера и нажмите Добавить.
  5. В чате нажмите + → Коннекторы и включите новый коннектор.

Пользовательские коннекторы доступны на тарифах Free, Pro, Max, Team и Enterprise. На Free можно добавить только один. В Team и Enterprise коннектор сначала добавляет владелец организации в Настройки организации → Коннекторы.

Авторизация

После нажатия Добавить откроется окно входа в сервис. Войдите под своим аккаунтом и подтвердите доступ. Пароль Claude не видит.

Как подключить Aevia LCA Modeler к ChatGPT

Адрес сервера, который нужно вставить в настройках ChatGPT:

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

  1. Откройте ChatGPT в браузере (chatgpt.com). Нужен тариф Plus, Pro, Business, Enterprise или Edu.
  2. Один раз включите режим разработчика: Настройки → Приложения → Дополнительные настройки → Режим разработчика (Settings → Apps → Advanced settings → Developer mode).
  3. Откройте Настройки → Коннекторы и нажмите Создать (Create).
  4. Заполните форму: Название (любое), Описание (одна фраза, что делает сервис), URL MCP-сервера (скопируйте ниже).
  5. В поле Аутентификация выберите OAuth, если сервис требует вход, иначе Нет. Нажмите Создать.
  6. В новом чате откройте + → Приложения/Коннекторы и включите коннектор.

Название раздела у OpenAI менялось (Connectors → Apps/Plugins). Если пункт называется иначе, ищите «режим разработчика» в настройках. В рабочих пространствах Business/Enterprise администратор должен разрешить пользовательские коннекторы.

Авторизация

При первом использовании ChatGPT откроет окно входа в сервис. Войдите и подтвердите доступ.

Как подключить Aevia LCA Modeler к Cursor

Адрес сервера, который нужно вставить в настройках Cursor:

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

Быстрый способ: нажмите кнопку Открыть в Cursor ниже, Cursor сам предложит добавить сервер.

Вручную:

  1. В Cursor откройте Settings → Cursor Settings → MCP и нажмите Add new global MCP server.
  2. Вставьте JSON, скопированный ниже, в открывшийся файл ~/.cursor/mcp.json (для одного проекта: .cursor/mcp.json в корне проекта).
  3. Сохраните файл. Сервер появится в списке MCP; при необходимости пройдите авторизацию по кнопке рядом с ним.

Авторизация

Если сервис требует вход, рядом с сервером в списке MCP появится кнопка авторизации.

Список инструментов сервера (20)

Технические названия из tools/list. Нужны только разработчикам.

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