AgentMarketMCP / SKILL 资产档案馆

目录 / Aevia LCA Modeler

MCP 鉴权未知 未评级 已上架

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.

该来源不提供完整文件导出（国内平台多为平台内托管），仅存元数据与原链

接入信息

传输形态
http
鉴权方式
鉴权未知
端点
https://aevia-lca-modeler.run.tools
鉴权方式未标注，请核对官方文档后再接入——不要直接使用以下片段
{
  "mcpServers": {
    "Aevia LCA Modeler": {
      "url": "https://aevia-lca-modeler.run.tools"
    }
  }
}

能力清单

工具说明
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).
纠错与举报（发现条目失效、署名有误或涉及侵权？）
提交举报 / 纠错

侵权举报经核验成立后，我们会即时下线该条目并删除已存的内容副本。