AI-powered life cycle assessment and modelling: connect to LCA databases, build and analyze systems
Scored across 23 tools
Tools are mostly distinct by resource and action, with domain prefixes (engine_, knowledge_, lca_) separating catalog browsing, literature search, and workspace operations. The closest overlaps—compose_assembly vs compose_linked and edit_assembly vs edit_linked—are explicitly differentiated by system topology, and apply_nw_set vs run_assessment's nw_set is clarified in descriptions, so misselection is unlikely but possible.
Every tool name follows a consistent snake_case verb_noun pattern, grouped predictably by domain prefix (engine_, knowledge_, lca_). The one unprefixed tool, load_skill, still uses the same verb_noun convention, so the set is highly predictable.
At 23 tools, the server is heavy for a single MCP surface, though the LCA domain genuinely spans catalog search, knowledge retrieval, workspace lifecycle, authoring, calculation, and analysis. Each tool has a plausible role, but the count is borderline over-scoped rather than well-scoped.
Core LCA lifecycle is covered—search, compose, edit, run, analyze, compare, normalize, import, and delete systems. However, there are notable gaps: no standalone delete for assessments, comparisons, or workspaces, no report-generation or document-upload tools despite the report_writing skill and library uploads, and the description references an unexposed lca_delete_authored tool.
Detail for one engine-catalog object by ref: p<N>, e<N>, f<N> or m<N>. Refs come from engine_search or engine_list_methods and name objects 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: product flows first, then elementary, grouped by unit, largest amount first); 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.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | The item to look up — a reference like p1, e3 or f7 taken from an earlier search. Run `engine_search` first if you don't have one. | |
| limit | No | How many rows to show per side. Default 20, up to 100. | |
| engine | No | Name of the engine database, as `lca_get(kind='engines')` lists it (case-insensitive). Omitted: this connection's default engine. Not combined with `scope_ref`, which picks the database a ref came from. | |
| offset | No | Skip this many rows to page further down the list. Starts at 0 (the top). | |
| section | No | Show only the inputs (what the process uses) or only the outputs (what it makes or emits), one page at a time. Leave unset for a short summary of both. Processes only. | |
| include_providers | No | Also list the processes that produce this flow — i.e. where it comes from. Flows only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond that: default returns a two-sided summary (top 20 per side, grouped by unit, largest first), section+offset+limit paginate one side, headings report true totals, follow-up hints appear when rows remain, and include_providers only applies to flow refs. It also notes that returned exchange rows carry f<N> refs usable by compose/edit tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the ref grammar, then behavior, then paging semantics — a logical order with no filler sentences. It is dense and some sentences are long, but each carries distinct, useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-shape burden and does so: it specifies the default summary format, ordering, grouping, per-page sizing, total counts, and pagination hints, plus the meaning of include_providers output. An agent has everything needed to call and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 cross-parameter meaning the schema does not: section with offset pages one side, limit caps at 100, include_providers is flows-only, and engine is the database versus the ref's own origin. Minor noise: it references scope_ref, which is not a parameter of this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Detail for one engine-catalog object by ref') and then decodes the polymorphic ref grammar (p/e/f/m prefixes) so the agent knows exactly what it will get for each ref type. It also explicitly distinguishes itself from lca_get for workspaces and from the search/list tools that supply refs, so siblings are cleanly separated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes: refs come from engine_search or engine_list_methods, a workspace s<N> is a different object read via lca_get(ref='s<N>') and is rejected here. This is a clear when-to-use, when-not-to-use, and named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List an engine database's LCIA methods, or one method's impact categories. The database is the one named by engine, else this connection's default. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | `m<N>` from a recent `engine_list_methods()` listing. Omit to list available methods. | |
| engine | No | Name of the engine database, as `lca_get(kind='engines')` lists it (case-insensitive). Omitted: this connection's default engine. Not combined with `scope_ref`, which picks the database a ref came from. | |
| scope_ref | No | Optional (list only). An engine ref whose database's methods to list instead of the active connection's. | |
| include_factors | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds useful context beyond them: the default-engine fallback, that `engine` and `scope_ref` are mutually exclusive, and that include_factors materially expands the payload but is rarely needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core list action, then mode selection, then the scope_ref nuance. Dense but every sentence carries information; no filler. Slightly long sentences reduce it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing returns, and it does: methods each with an `m<N>` ref, or a method's impact categories plus optional factors. It covers the key behaviors an agent needs; pagination or result-size limits are not addressed, which is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, and the description meaningfully augments it: it explains the `m<N>` ref format and its provenance, the default-engine behavior when `engine` is omitted, and the exclusivity of `engine` vs `scope_ref`. The one gap is `include_factors`, whose cost/verbosity implication is only gestured at with 'rarely needed.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'List an engine database's LCIA methods, or one method's impact categories.' It cleanly distinguishes the two operating modes and the resource scope, which separates it from siblings like engine_get or engine_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the conditions that select each behavior: omit `ref` to list methods, pass `ref` (m<N>) to get categories, and use `scope_ref` to list another database's methods. It also flags `include_factors=true` as 'rarely needed,' steering default usage. No explicit when-not-to-use guidance, but the branching is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search an LCA database for processes, product systems or flows. The database is the one named by engine, else this connection's default. 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, for comparing across databases; refs minted that way stay bound to that database.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | What to search for. 'all' queries processes, systems, and flows in parallel. | all |
| limit | No | Max results per page (default 20). | |
| query | Yes | Free-text query, matched word by word against dataset names, categories and location codes — there is no meaning-based matching, so the nouns a dataset is named by (a material, a process, a product) find more than a description of the use (`polypropylene injection moulding`, not `plastic plate`). A place matches by name or code (`Switzerland`, `CH`). When no hit contains every word, the closest partial matches come back, labelled as such. Use `*` (or an empty string) to list everything of the given `kind` — the way to enumerate what a database contains. | |
| engine | No | Name of the engine database, as `lca_get(kind='engines')` lists it (case-insensitive). Omitted: this connection's default engine. Not combined with `scope_ref`, which picks the database a ref came from. | |
| offset | No | Start index for pagination (default 0). | |
| flow_type | No | Only meaningful when kind=flow. | |
| scope_ref | No | Optional. An engine ref (`p`/`e`/`f`/`m`) whose database to search instead of the active connection. Omit to search the active connection. | |
| process_type | No | Only meaningful when kind=process. Restrict to unit processes vs aggregated (system) processes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/destructive, so the description's job is secondary. It nonetheless adds meaningful behavior: refs stay valid for the session, refs minted via scope_ref stay bound to that database, and system hits are engine-catalog `e<N>` refs rather than workspace `s<N>`. Return format details (total count, paging) are lightly covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense and front-loaded: the core search-and-enumerate behavior leads, examples follow. It is a long run-on paragraph and repeats some schema-documented parameter semantics, costing a little crispness, but nearly every clause carries operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter search tool with no output schema, it covers enumeration mode, scoping/kind interplay, cross-database ref binding, and ref lifetime — everything an agent needs to call it correctly and route its output to engine_get/lca_run_assessment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaningfully enriches `query` (word-by-word matching, no semantic matching, wildcard enumeration), `scope_ref` (binding/lifetime semantics), and the kind/flow_type/process_type interplay beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (LCA database of processes, product systems, flows), and immediately scopes what kinds are searchable. It clearly distinguishes itself from engine_get/engine_list_methods by framing itself as the search-and-enumerate surface.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives strong contextual guidance: query='*' enumerates all of a kind, scope_ref searches a different database for cross-database comparison, engine vs scope_ref are mutually exclusive. It names related tools (engine_get, lca_run_assessment) as consumers of returned refs, but lacks explicit when-not-to-use framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the library and return abstracts with 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).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max documents (only applies when document_refs is omitted, default: 10). | |
| query | No | Search text. Required when no documents are selected (discovery mode) — finds matching documents. Optional once document_refs are given: include it to rank those documents' chunks by relevance, or omit it to pull each document's abstract + opening chunks. The library is English-language: technical terms and scientific names match best. | |
| journal | No | Optional. Restrict the search to ONE journal, by its full name (e.g. "Journal of Cleaner Production"). A distinctive fragment also works ("Cleaner Production"), but a fragment matching several journals is rejected with the candidates listed — never guessed at — so prefer the full name. To compare journals, run one search per journal. Omit to search every document this session can reach — including the user's own uploads and anything else with no journal recorded, which a journal filter would exclude. | |
| year_to | No | Optional inclusive upper bound on publication year. Omit for no upper bound. | |
| year_from | No | Optional inclusive lower bound on publication year (e.g. 2020 for "recent"). Omit for no lower bound. | |
| document_refs | No | Specific documents to pull from, as knowledge refs from a recent knowledge_search (e.g. ["k1", "k7"]). Provide these to fetch those exact documents (abstract + chunks) instead of discovering by query — the metadata filters (Scope / years) then no longer apply. Required if query is omitted. | |
| top_k_chunks_per_doc | No | Max chunks to return per document (default: 3). |
Full text of one library document, by its k<N> ref. The ref comes from a recent knowledge_search (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.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes | Ref like `k1`/`k7` from a recent knowledge_search. Titles, DOIs and document uuids are rejected. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, yet the description adds real behavioral context: [ref-only] documents return only an abstract rather than failing or returning empty. It could go further on size/truncation behavior for large full texts, hence not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, front-loaded with what the tool returns and the ref contract, then the sibling comparison and the edge case. No padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still tells the agent what comes back (full text, or the same abstract as excerpts for ref-only entries) and where the input ref originates. Nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents the k<N> format and the rejection of titles/DOIs/uuids. The description restates the ref origin ('comes from a recent knowledge_search') without adding format or syntax detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Full text of one library document') and scopes it precisely by ref type. It explicitly contrasts itself with knowledge_get_excerpts and knowledge_search, so an agent can distinguish it from siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use-this-vs-alternative rule: excerpts 'usually suffice', this tool is for the whole paper, and it names which refs are even eligible ([ref-only] excluded). That is a genuine routing decision, not vague context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 130,000+ peer-reviewed sustainability papers and the account's uploads. Articles from Sustainability, the Journal of Cleaner Production, the International Journal of Life Cycle Assessment and the Journal of Industrial Ecology, 1993 to the present — LCA, material flows, energy, food and agriculture, materials, waste, buildings and policy. English-language; most entries are abstract and metadata only. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default: 12). Bump toward 30 for broad literature surveys. | |
| query | Yes | Search query. The library is English-language: technical terms and scientific names match best. | |
| journal | No | Optional. Restrict the search to ONE journal, by its full name (e.g. "Journal of Cleaner Production"). A distinctive fragment also works ("Cleaner Production"), but a fragment matching several journals is rejected with the candidates listed — never guessed at — so prefer the full name. To compare journals, run one search per journal. Omit to search every document this session can reach — including the user's own uploads and anything else with no journal recorded, which a journal filter would exclude. | |
| year_to | No | Optional inclusive upper bound on publication year. Omit for no upper bound. | |
| year_from | No | Optional inclusive lower bound on publication year (e.g. 2020 for "recent"). Omit for no lower bound. |
Break 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.
| 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 |
| 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 | `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. | |
| cutoff | No | Upstream only: drop nodes contributing less than this fraction of the total impact (0–1, default 0.01). | |
| method | No | `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. | |
| source | No | Which kind of target this analysis runs on — set it to match the ref you pass: 'assessment' with `assessment_ref`, 'system' with `system_ref`. | |
| 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. | |
| system_ref | No | 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. | |
| compartment | No | Flow only: filter substances to one environmental compartment (medium) — e.g. 'air', 'water', 'soil'. Case-insensitive substring against the compartment path. | |
| assessment_ref | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses the 3–5 s background engine preparation on the first call per solve, the reuse of that engine on later calls, the 422 failure conditions for unsupported mode/target combinations, and the fact that the returned `b<N>` breakdown is a separate object from the analysed `a<N>`. This explains why readOnlyHint=false is correct (a new breakdown artifact is created), so no contradiction arises.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then mode-by-mode semantics and constraints in a compact run of sentences; no filler. It is dense and somewhat long for a single paragraph, and the clause clarifying that the `b<N>` result is 'a separate object from the `a<N>` it analyses' is slightly redundant, keeping it below a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so by naming the `b<N>` breakdown ref and the `p<N>`/`f<N>` row refs for follow-up detail. Combined with the error conditions, timing note, and per-mode behavior, an agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 cross-parameter semantics the schema cannot express: `amount` and `method` only apply with `system_ref` and are ignored with `assessment_ref`, and `source` must match whichever ref is passed. Minor gap: `top_n`, `cutoff` and `depth` are left entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb+resource ('break down what drives an impact category'), and the rest pins down scope precisely: it analyses either a saved assessment (`a<N>`) or a saved system (`s<N>`). An agent can distinguish it from siblings like lca_run_assessment because the description names the exact target refs it consumes and the `b<N>` artifact it produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Strong on when/when-not: 'source' must match the target, `system_ref` needs no prior assessment, and composed bill-of-materials systems support only `process` via `assessment_ref` ('flow', 'upstream' and 'system_ref' return 422). It references lca_run_assessment only for the amount/method defaults rather than routing the agent away from or toward the closest siblings such as lca_analyze_sensitivity, so it stops short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quantify 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.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Analysis type. | tornado |
| steps | No | Sweep: number of points. | |
| category | No | Impact category to analyse. Defaults to the method's first. | |
| variable | No | Sweep: the single variable to walk — a composed `member:<slug>` id (analytic), an engine `param:<name>` id (openLCA dataset parameter — re-solves the model, deferred), a unique name fragment (resolved server-side), or `system:amount` (scale the whole system: service-life / replacement-count). An engine `driver:<slug>` is NOT sweepable (tornado only) — use `param:<name>` instead. Unresolvable → 422 with the valid list. | |
| range_max | No | Sweep: upper multiplier. | |
| range_min | No | Sweep: lower multiplier. | |
| scenarios | No | Scenarios: named override sets vs the same baseline, e.g. [{name: 'worst case', overrides: {'member:steel': 1.5}}]. Keys are composed `member:<slug>` / `system:amount` ids (analytic) OR, for an engine target, engine `param:<name>` ids (re-solves the model, deferred) — name fragments resolve server-side either way, but a scenario set may not MIX driver/member and param keys. An unresolvable key 422s. | |
| threshold | No | Sweep: break-even vs a fixed value. Mutually exclusive with `reference_ref`. | |
| variables | No | Variables to rank: composed `member:<slug>` ids, engine `driver:<slug>` ids, OR unique name fragments (resolved server-side; a default tornado's rows list every id). Naming ONLY engine `param:<name>` knobs instead re-solves the model under those parameters (deferred) rather than ranking drivers — mixing `driver:`/`param:` ids in one call 422s. Omit for all (composed members, or the E1 driver tornado). `system:amount` is NOT valid here (use sweep/scenarios). | |
| 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. | |
| reference_ref | No | Sweep: break-even vs another assessment's total (`a<N>`). Mutually exclusive with `threshold`. | |
| variation_pct | No | Tornado: perturb each variable by ±this percent. | |
| assessment_ref | Yes | Saved-assessment ref in the form `a<N>` (e.g. `a3`) — study the setup this composed assessment captured. List current assessments with `lca_get(kind='assessments')` — never pass UUIDs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare non-read-only, non-destructive, non-idempotent; the description is consistent with these and adds real context: composed systems are 'exact and instantly' while engine targets 're-solve' and are deferred, and 'Every result states its nature, source and limits'. It also discloses that a durable v<N> is created alongside the analysed a<N>.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and target, then proceeds mode-by-mode with the id-syntax legend last. Dense but telegraphese makes it slightly harder to scan; nearly every clause carries operational information, so little is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description partially compensates by telling the agent what comes back (a durable v<N>, plus stated nature/source/limits). With 13 params fully documented in the schema, this is close to complete for a complex multi-mode tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning the schema does not: the distinction between composed/analytic vs engine/deferred targets, mutual exclusivity (threshold vs reference_ref), server-side fragment resolution, and the 422-with-valid-ids failure path for unresolvable variables. This is more than restating the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource: 'Quantify which inputs drive a system's result, and by how much,' which is distinct from the sibling lca_analyze_contributions and lca_compare_assessments. The three modes are named and their scope stated, so an agent can route 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use each mode (tornado ranks, sweep walks one variable with break-even, scenarios compares overrides) and names the exact alternatives to avoid: driver:<slug> is 'tornado only — use param:<name> instead', and system:amount 'is NOT valid here (use sweep/scenarios)'. Error behavior and id-resolution fallbacks are also documented.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a normalization/weighting set to a saved assessment (a<N>). ref is an a<N> in the workspace named by workspace; nw_set names one of its method's sets, and an unknown name is refused with the sets the method offers. Nothing is recalculated: the set's factors are read from the engine that calculated the assessment, and normalized and weighted results per category plus a single score are stored beside the unchanged characterized results. Applying the same set again refreshes it. A set may cover only some of the categories; the result names the ones it leaves out of the single score. lca_compare_assessments with nw_set compares assessments that all carry the same set. Weighting expresses value choices, and ISO 14044 §4.4.5 bars it from a comparative assertion disclosed to the public.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | The saved assessment `a<N>` to re-score. | |
| nw_set | Yes | Name of one of the assessment method's normalization/weighting sets (exact, or a unique part of the name). An unknown name is refused with the sets the method offers. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: nothing is recalculated, factors are read from the engine that produced the assessment, results are stored beside unchanged characterized results, re-application refreshes (consistent with idempotentHint), partial category coverage is possible, and it cites the ISO 14044 restriction on public comparative assertions. This is unusually rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core action and keeps every sentence substantive, but it is dense with several distinct topics (storage semantics, refresh, partial coverage, ISO caveat) that could be tightened. No filler sentences, so it stays efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining what gets produced: normalized/weighted results per category plus a single score, stored alongside unchanged characterized results, with omitted categories named. An agent has everything needed to invoke and interpret the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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: ref is an a<N> in the named workspace, nw_set must match one of the method's sets (exact or unique part), and workspace is mandatory per call because connections are shared. It reinforces and contextualizes the schema rather than merely repeating it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb+resource: applying a normalization/weighting set to a saved assessment. It explicitly distinguishes itself from lca_compare_assessments (which uses nw_set only to compare assessments all carrying the same set), so an agent can route correctly without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use conditions: apply to a saved assessment, unknown set names are refused, re-applying refreshes rather than duplicates, and comparison of sets belongs to lca_compare_assessments. Alternatives and preconditions are named, not implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save 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 workspace named by 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. nw_set adds the targets' stored single scores for that set beside the matrix; every target must already carry it (lca_apply_nw_set). The assessment_interpretation skill (load_skill) documents comparison discipline.
| Name | Required | Description | Default |
|---|---|---|---|
| nw_set | No | Compare by the single score of this normalization/weighting set (its name, or a unique part of it); every target must carry it, see `lca_apply_nw_set`. A target missing it, or carrying a different copy, is refused with what to do. Omit for the characterized matrix only. | |
| targets | Yes | Saved-assessment refs to compare, e.g. ['a1', 'a2']. Must have ≥2 items. | |
| 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. | |
| allow_mismatched_fu | No | Compare targets that declare DIFFERENT functional units (e.g. 1 kg vs 1 unit). Default false refuses with a 400 naming both. Setting it true does NOT make the comparison valid — it stamps a warning onto the result. Only set it when the user has said the two functional units are equivalent for their question, and say so in your answer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-read-only, non-destructive, non-idempotent mutation; the description adds substantial context beyond them: which mismatches are refused with 400 vs returned as equivalence warnings, that the result is saved into the named workspace and returned as `primary_ref` (`c<N>`), and that the matrix does not rank targets. This is rich behavioral disclosure the annotations alone do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and sized appropriately for a tool with four interacting parameters and several preconditions. Sentences are dense and cross-reference other tools heavily, which is efficient but places a mild reading burden; nearly every clause carries distinct information, so little is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still explains the return (`primary_ref` `c<N>` holding the full matrix, plus `nw_set` scores beside it), the refusal behavior, and the interpretation skill pointer. For a mutation tool with non-obvious preconditions, this is complete enough to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaning beyond it: `a<N>` ref shape and its source (`lca_get`), the requirement that every target already carry `nw_set`, and the consequence of `allow_mismatched_fu` (a warning is stamped, not validity). The workspace rationale (shared connection, empty default sandbox) further clarifies its purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Save a comparison across 2–8 saved assessments') and immediately scopes it against siblings: it notes that `lca_run_assessment` already saves each assessment so there is no separate save step, and directs listing to `lca_get(kind='assessments')`. An agent can distinguish this from the analyze/compose siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear conditions: use for 2–8 saved refs, the two enforced 400 preconditions, and precise guidance on when to set `allow_mismatched_fu` (only when the user asserts equivalence). It does not explicitly contrast when to reach for this versus `lca_analyze_contributions`/`lca_analyze_sensitivity`, so it falls short of a full when/when-not/alternatives treatment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a product system as a bill of quantities of database processes. Each member's amount is sent in one call. Structure only; no LCIA runs. The assembled product is the functional unit; each member is linked to its full upstream when assessed, so the total is a full-upstream figure for the declared scope, 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, not 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.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | System boundary. 'cradle_to_gate' (default) = materials through manufacture. 'cradle_to_grave' = ALSO include end-of-life (add disposal/treatment process leaves). 'end_of_life' = treatment of a product at end of life only; the functional unit is the treated product, e.g. '1 kg of end-of-life PV module, treated'. A cradle-to-grave system spans life-cycle phases — prefer `stages` over a flat `inputs` list so each phase gets its own subtotal. | |
| title | Yes | Name for the assembly, e.g. 'Wooden house assembly, 100 m²'. | |
| engine | No | Name of the engine database, as `lca_get(kind='engines')` lists it (case-insensitive). Omitted: this connection's default engine. | |
| inputs | No | FLAT bill of quantities: one entry per member. Use for a single cradle-to-gate group of parts with no phases to separate. If the system spans life-cycle phases (materials/transport/use/end-of-life) or is a comparison, prefer `stages` instead — same total, per-phase subtotals. Set this OR `stages`, not both. | |
| stages | No | MULTI-STAGE DAG (preferred for cradle-to-grave, multi-phase, or comparison systems — same total as a flat list, but each phase gets its own subtotal): named stages, each consuming process leaves and/or other stages. Declare stages + what each consumes; DO NOT wire links or name the final product — the compiler derives the edges and the final (sink) stage. Cycles are rejected. Set this OR `inputs`, not both. | |
| dry_run | No | When true, validate ONLY — return the envelope without persisting (and without a confirmation prompt). Default false: a valid system is built and its s-ref returned in this one call. | |
| 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. | |
| output_name | Yes | Name for the assembled product, e.g. 'Wooden house, 100 m²'. | |
| output_unit | No | Declared unit for the assembled product (e.g. 'house', 'm2', 'tonne'). Used as the functional-unit unit in the scope editor. | |
| target_amount | No | Functional-unit amount (default 1.0). | |
| temporal_scope | No | Temporal scope of the system (e.g. '2020-2024', 'Reference year 2022'). | |
| cutoff_criteria | No | Explicit cutoff criteria (e.g. 'Mass cutoff 1%; energy cutoff 1%'). Overrides the scope-derived default. | |
| geographical_scope | No | Explicit geographical scope (e.g. 'Switzerland'). Overrides location codes derived from member processes. | |
| functional_unit_description | No | Free-text description of the functional unit (e.g. 'One house, 160 m², 50-year service life'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the write/non-idempotent/non-destructive profile, but the description adds substantial context the annotations cannot: validation against the database before saving, the errors[]/missing_required[]/warnings[] failure contract with 'nothing is saved', the requirement that a corrected call carry the complete system, and the distinction between a tool error (engine unavailable) and an invalid result. Not covered: permissions/auth prerequisites for writing into a workspace.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then validation and failure semantics, then sibling routing. Every sentence is functional, though the block is dense and the member-ref/UUID rule could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter, no-output-schema, non-idempotent mutation tool, the description covers construction (inputs vs stages), validation/failure contract, the returned system_ref, dry_run, and sign/unit conventions. Nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already carries the per-parameter meaning; the description correctly gets baseline 3. It adds a small amount of non-duplicative constraint ('Members are p<N> refs; UUIDs are not accepted', and the inputs-vs-stages exclusivity), but most parameter guidance is repeated from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence gives a specific verb and resource: 'Build a product system as a bill of quantities of database processes.' It explicitly names the sibling it is not (lca_compose_linked builds explicit supply edges instead), so an agent can route without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing rules: inputs OR stages but not both, with a stated preference for stages when the system spans life-cycle phases; dry_run for validate-only; and lca_run_assessment named as the consumer of system_ref. It even points to the product_system_authoring skill for build order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a product system as an explicit process network with supply edges. Every member and supply edge is sent in one call. Structure only; no LCIA runs. For a list of materials and quantities, lca_compose_assembly is simpler. A link may route a waste output to its treatment (consumer_ref outputs it, provider_ref treats it). ref_process_ref is the functional unit's process and also appears in member_process_refs. It 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 (not an invalid result) means the engine is unavailable. Takes p<N>/f<N> refs; UUIDs are not accepted. Requires the user's own writable engine; an unreachable member blocks the build. The product_system_authoring skill (load_skill) covers build order and failures.
| Name | Required | Description | Default |
|---|---|---|---|
| links | No | Supply edges connecting members: a supplier's product into a consumer's input, or a consumer's waste output into its treatment. | |
| title | No | Human title for the authored system. | |
| engine | No | Name of the engine database, as `lca_get(kind='engines')` lists it (case-insensitive). Omitted: this connection's default engine. | |
| dry_run | No | When true, validate ONLY — return the envelope without persisting (and without a confirmation prompt). Default false: a valid system is built and its s-ref returned in this one call. | |
| 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. | |
| ref_flow_ref | No | `f<N>` ref of the reference product flow (a product OUTPUT of the ref process). | |
| target_amount | No | Functional-unit amount (default 1.0). | |
| temporal_scope | No | Temporal scope of the system (e.g. '2020-2024', 'Reference year 2022'). | |
| cutoff_criteria | No | Explicit cutoff criteria (e.g. 'Mass cutoff 1%; energy cutoff 1%'). Overrides the scope-derived default. | |
| ref_process_ref | Yes | `p<N>` ref of the reference process (the functional unit). It must also be listed in `member_process_refs`. | |
| target_unit_ref | No | The functional unit's unit, when it is NOT the reference exchange's own unit (which is derived for you). A unit NAME as the engine spells it ('t', 'kg', 'MJ'), resolved against the reference flow's unit group — NOT a ref: there is no `u<N>` kind, and an f/p/s ref here is rejected. | |
| geographical_scope | No | Explicit geographical scope (e.g. 'Switzerland'). Overrides location codes derived from member processes. | |
| member_process_refs | Yes | `p<N>` refs of every process in the system — include the reference process. | |
| functional_unit_description | No | Free-text description of the functional unit (e.g. 'One house, 160 m², 50-year service life'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only give the safety flags (readOnly=false, destructive=false, idempotent=false, openWorld=false); the description adds substantial behavior: atomic one-call submission, validation against the DB before saving, nothing persisted on invalid input with errors[]/missing_required[]/warnings[] returned, a corrected call must carry the complete system, dry_run skips persistence and the confirmation prompt, and a tool error (vs. an invalid result) signals engine unavailability. It also flags that UUIDs are rejected and an unreachable member blocks the build.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose and scope, and nearly every sentence carries distinct operational information (routing, validation, errors, dry_run, refs, engine requirement). It is long at roughly eleven sentences, with some overlap between the one-call statement and the structure-only statement, but there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter authoring tool with no output schema and thin annotations, the description covers the full lifecycle an agent needs: input shape, validation outcome, error envelope contents, persistence semantics, dry-run behavior, downstream hand-off via system_ref, and the prerequisite of a writable engine.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all 14 parameters; the baseline is 3. The description adds genuine interpretation beyond the schema: the waste-routing rule (consumer_ref outputs the waste, provider_ref treats it), the fact that ref_process_ref must also appear in member_process_refs, the p<N>/f<N> ref format with UUIDs rejected, and that target_unit_ref is a unit name rather than a ref.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Build a product system as an explicit process network with supply edges') and immediately scopes it ('Structure only; no LCIA runs'), which cleanly separates it from the sibling lca_compose_assembly, named explicitly as the simpler option.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing: use this for an explicit process network, use `lca_compose_assembly` for a list of materials and quantities, and use `lca_run_assessment` downstream with the returned `system_ref`. It also names the `product_system_authoring` skill for build order and failure handling, and explains `dry_run` as the validate-only path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a workspace and return the name later calls pass as workspace. The workspace is the user's own, and later calls work in it by passing that name. By default it creates a new, empty workspace and makes it the connection's default — the workspace a call naming none reads, shared by every conversation on the connection; tools that save still take workspace on every call. With adopt_sandbox: true, the default workspace, when it is a sandbox created for this connection, becomes that workspace instead: renamed to name and made an ordinary workspace, with everything already saved in it kept in place and every workspace ref still valid; a later connection starts in a new sandbox. Either way the workspace counts toward the account's workspace limit and appears in the Aevia app. A name the user already has is refused rather than reused; an existing workspace is used by passing its name as workspace. goal_statement records the study's goal (ISO 14040 §4.2).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for the workspace. Must differ from every workspace the user already has (matched exactly, including case). With `adopt_sandbox`, the sandbox's current name is also accepted. | |
| description | No | Short free-text description of the workspace. | |
| adopt_sandbox | No | When true, the connection's default workspace, when it is a sandbox, becomes the new workspace, keeping everything already saved there and every workspace ref. Refused when the default is not a sandbox. Default false: a new, empty workspace. | |
| goal_statement | No | The study's goal (ISO 14040 §4.2): intended application, reasons, audience, and whether comparative assertions are intended. Shown with the workspace in the Aevia app. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (non-read-only, non-idempotent, non-destructive). The description adds substantial context beyond them: the workspace counts toward the account limit, appears in the Aevia app, duplicate names are refused rather than reused, adoption renames and preserves the sandbox contents with refs still valid, and a later connection starts fresh in a new sandbox.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the outcome, but the prose is long-winded and redundant, restating the workspace-name-passing idea twice ('return the name later calls pass as `workspace`' and 'later calls work in it by passing that name'). Several clauses could be tightened without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly states the return value (the workspace name). It covers side effects, limits, and adoption semantics thoroughly, though the interaction between the connection's default workspace and per-call `workspace` passing remains slightly tangled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already defines each parameter; a baseline of 3 would be defensible. The description nonetheless adds meaning: why `adopt_sandbox` matters behaviorally, that `workspace` name is the handle future calls use, and the ISO 14040 §4.2 framing for `goal_statement`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (create a workspace) and goes further by naming the return value that later calls pass as `workspace`. It implicitly separates itself from sibling lca_switch_workspace by noting an existing workspace is used by passing its name instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear conditions for the two modes: default creates a new empty workspace and makes it the connection default, while `adopt_sandbox: true` converts an existing sandbox. It also states the refusal case (duplicate name) and how to use an existing workspace. It stops short of naming sibling tools like lca_switch_workspace explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a saved product system (s<N>) and its assessments from a workspace. The system is system_ref in the workspace named by workspace. The deletion cannot be undone. Its assessments (a<N>) are deleted with it and leave any comparison (c<N>) they belong to; contribution and sensitivity analyses (b<N>, v<N>) are kept, detached; reports (r<N>) citing it are kept, but those citations stop resolving. Without confirm: true the call returns a preview listing every one of them by ref, and deletes nothing. The system's copy in its openLCA engine is kept unless delete_engine_copy: true, which deletes it too only when Aevia created that copy and the engine is writable; the preview and the result say which applies. delete_engine_copy changes the openLCA database, so it needs this connection at the Execute access level; below it the call is refused, and deleting without it is allowed. A process or flow authored into an engine is deleted by lca_delete_authored.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Delete it. Without it the call returns a preview of everything the delete takes with it, and deletes nothing. | |
| 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. | |
| system_ref | Yes | The saved product system `s<N>` to delete. | |
| delete_engine_copy | No | Also delete the system's copy in its openLCA engine — honoured only when Aevia created that copy and the engine is writable. Kept by default. Needs the Execute access level (it changes the openLCA database); below it the call is refused. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description goes far beyond them: it enumerates the exact cascade (assessments deleted, comparison membership lost, contribution/sensitivity analyses detached, report citations left dangling), states irreversibility, and explains the preview path. It also discloses the engine-copy deletion preconditions and the authorization level required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and irreversibility, then organized by consequence, preview, and engine copy. It is dense rather than padded, but repeats the confirm/preview behavior already stated in the schema and runs long for four parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, non-idempotent mutation with no output schema, the description covers everything needed: what is destroyed, what survives, what the preview returns, and the permission gate. No output schema exists, so explaining return values is unnecessary and its absence is not a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds semantic linkage the schema does not: it ties `confirm` to a preview that lists every affected ref by type, and ties `delete_engine_copy` to the 'Aevia created it and engine writable' condition plus the refusal threshold. That is genuine added meaning, though much of it overlaps the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Delete a saved product system (`s<N>`) and its assessments') plus the scope ('from a workspace'), and explicitly distinguishes itself from the sibling `lca_delete_authored` for engine-authored processes/flows. An agent can route correctly without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete when-to-use conditions: without `confirm: true` it only previews, and it names the alternative tool for a different object type. The access-level prerequisite for `delete_engine_copy` (Execute level, otherwise refused) is also spelled out, so the agent knows both the trigger and the exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Patch 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.
| Name | Required | Description | Default |
|---|---|---|---|
| ops | Yes | Ordered list of edits to apply in one call. | |
| ref | Yes | Saved product-system ref `s<N>` to patch. | |
| mode | No | `edit` (default) → edit the system IN PLACE, appending a new content version and keeping the same `s<N>` (self-contained systems; a drift-tracked mirror auto-forks to a new `s<M>` with a warning, since it can't be mutated in place). `fork` → always derive a NEW `s<M>`, leaving the baseline `s<N>` untouched. | edit |
| 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. | |
| base_version_seq | No | REQUIRED here: the system's current content `version_seq`, as `lca_get s<N>` reports it — the version you computed this edit against. Rejected (409) if the system has moved on since, and nothing is changed. Re-read the system between edits: a successful in-place edit advances the version. (Kept optional in the schema so an omission gets the backend's instructive 422 rather than a bare validation error.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the destructiveHint/readOnlyHint annotations: discloses the drift-tracked mirror auto-fork warning, that only unit compatibility is checked on swaps (geography/technology/year can change), that each member is linked cradle-to-gate independently, the negative-amount sign-flip semantics, and the 409 rejection tied to base_version_seq. This is rich operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded: the verb, op list, mode semantics, and ref-routing all arrive before the finer behavioral notes. It is long for a description, yet nearly every clause carries distinct operational information with little redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description closes that loop by naming the returned ref and the tool that consumes it (lca_run_assessment). Combined with mode, versioning, mirror-drift, and unit-handling details, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaning the schema does not: members are `p<N>` refs and UUIDs are rejected, and the stage DAG must remain acyclic with a single sink. These constraints clarify how ops may be combined, pushing above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Patch a saved composed (bill-of-materials) system') and enumerates every supported op with parenthetical glosses. It explicitly names the sibling it is not ('Linked and single-process systems are edited with lca_edit_linked'), so an agent can route correctly 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use and when-not-to-use guidance: names lca_edit_linked as the alternative for linked/single-process systems, distinguishes `mode=edit` (in place, with auto-fork of drift-tracked mirrors) from `mode=fork` (new `s<M>`), and points to lca_run_assessment for the returned ref.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Patch a saved linked or single-process system (s<N>). A linked system is an explicit process network. Graph ops: add_link (wire a supplier onto a consumer input, or a waste output onto its treatment; the provider joins automatically), remove_link (drop matching edges; orphans are pruned), rewire_link (repoint one edge). Also replace_provider (swap a supplier on every edge it feeds; a bare unit_process swap warns: its background is unwired), set_target_amount and set_title. A swap checks only unit compatibility, 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 has one flow on several exchanges. A link's amount only validates. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| ops | Yes | Ordered list of edits to apply in one call. | |
| ref | Yes | Saved product-system ref `s<N>` to patch. | |
| mode | No | `edit` (default) → edit the system IN PLACE, appending a new content version and keeping the same `s<N>` (self-contained systems; a drift-tracked mirror auto-forks to a new `s<M>` with a warning, since it can't be mutated in place). `fork` → always derive a NEW `s<M>`, leaving the baseline `s<N>` untouched. | edit |
| 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. | |
| base_version_seq | No | REQUIRED here: the system's current content `version_seq`, as `lca_get s<N>` reports it — the version you computed this edit against. Rejected (409) if the system has moved on since, and nothing is changed. Re-read the system between edits: a successful in-place edit advances the version. (Kept optional in the schema so an omission gets the backend's instructive 422 rather than a bare validation error.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare mutation/destructive/non-idempotent; the description adds substantial context beyond that: in-place edits append a content version, mirrors auto-fork with a warning, orphans are pruned on removal, a provider swap checks only unit compatibility so geography/technology/vintage can change, and a bare `unit_process` swap warns its background is unwired.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then dense semicolon-separated clauses. Nearly every sentence carries distinct information (ops semantics, mode behavior, ref format), though the wall-of-text style is slightly heavy even for a tool this complex.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a nested `ops` array, six op types, and no output schema, the description is remarkably complete: it enumerates each op, the mode semantics, ref format constraints, the authored-view workflow, and the single-process caveat. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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: refs take `p<N>`/`f<N>` and 'UUIDs are not accepted', `amount` on a link is validation-only, and `consumer_input_index` is required when a consumer has 2+ exchanges of a flow. These clarify usage beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Patch') and resource (a saved linked or single-process `s<N>` system), and explicitly distinguishes itself from `lca_edit_assembly` for composed systems and notes the single-process restriction. An agent can tell it apart from siblings 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use routing: 'A single-process system takes only the two setters' and 'Composed systems use `lca_edit_assembly`'. It also points to `lca_get(ref='s<N>', form='authored')` as the way to discover edges and the required `consumer_input_index`, and explains when `fork` vs `edit` applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a saved workspace object by ref, or list systems, results or workspaces. Takes exactly one of ref (one object's detail) or kind (a list). A ref is read in the workspace named by workspace, which it requires: each workspace numbers its objects from 1. A kind list reads that workspace, else this connection's default. 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 connection's default. Refs are short handles; UUIDs are not accepted.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Single-entity ref. `s<N>` system, `a<N>` assessment, `c<N>` comparison. Mutually exclusive with `kind`. | |
| form | No | ref='s<N>' only. 'snapshot' (default) is the structural read. 'authored' returns the system lifted back to the AUTHORED form — the shape `lca_compose_assembly` / `lca_compose_linked` speak, tagged with its `kind`, carrying a multi-stage bill of quantities' stage DAG unflattened and a linked system's `links[]` (neither of which the snapshot has). Read this before editing a system you did not just author. | |
| kind | No | Collection mode. Mutually exclusive with `ref`. 'workspaces' and 'engines' are the odd ones out: they list the WORKSPACES / ENGINE DATABASES available to you rather than the contents of the current one. | |
| limit | No | ||
| query | No | Free-text match on name/description (case-insensitive). | |
| method | No | kind='assessments': substring match on method_name. | |
| offset | No | ||
| workspace | No | Name of the workspace to read, as `lca_get(kind='workspaces')` lists it. Required with `ref`: each workspace numbers its objects from 1, so a ref is read in the workspace it came from. Omitted with `kind`: this connection's default workspace, which every conversation on the connection shares and which is often an empty sandbox. | |
| system_ref | No | kind='assessments': filter to assessments on a single system. | |
| include_stale | No | kind='systems': when true, also returns OUT_OF_SYNC / NOT_FOUND / UNREACHABLE / ARCHIVED rows. | |
| assessment_status | No | kind='assessments': filter by status. |
Poll a long-running call that returned a task_id instead of a result. Takes that id and waits up to 45 seconds for the task to finish. Returns status: 'pending' (still running after that wait; calling again waits again), 'success' (result holds the tool's result text and its ref; the saved object is read with lca_get) 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.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | The task id a previous tool call returned, e.g. `df_a1b2…`. |
Import an engine product system (e<N>) into a workspace as a saved system. The e<N> from engine_search is imported from its own database; the saved copy gets 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.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Engine product-system ref `e<N>` from `engine_search(kind='system')`. | |
| mode | No | `full` (default) mirrors the full definition — assessable + editable. `link_only` stores just a reference that calculates against the live engine (advanced; can't be reopened for editing). | full |
| confirm | No | Over the Aevia MCP connector this call PREVIEWS by default — it reports what would be imported and writes nothing. Read the preview, then call again with `confirm:true` to apply. Ignored in the Aevia app, where the confirmation dialog plays this role. | |
| 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. |
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.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Target ref: a saved system `s<N>`, or a catalog process `p<N>` / engine system `e<N>` from `engine_search`. | |
| amount | No | How 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_set | No | 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. | |
| 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. | |
| allocation | No | Allocation 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_preference | No | Preferred LCIA method (e.g., 'ReCiPe', 'CML'). Default: ReCiPe 2016. |
Set this connection's default engine database. The default is the database browsing and composing use when a call names no engine. The default is shared by every conversation on the connection. name is the engine name as shown, matched case-insensitively (a code span, accepted with or without its backticks). Nothing saved moves: no s<N>/a<N>/c<N>/b<N>/v<N> ref is affected, 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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the engine connection to bind to, copied verbatim from any result that named it — the `# Engines` listing or a search result's header (matched case-insensitively; the surrounding backticks are optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare mutation (readOnlyHint=false), idempotency, and non-destructiveness; the description substantiates these with concrete behavior: nothing saved moves, no s/a/c/b/v refs are affected, and catalog refs stay bound to their minting database, with lca_compose_*/lca_edit_* refusing cross-database member refs. This is exactly the kind of beyond-annotation detail that earns a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence, and the subsequent sentences on ref behavior all earn their place. It is dense and fairly long, but no sentence is filler, so it stays near the top of the range.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation tool with no output schema, the description covers the non-obvious consequences (shared default, unaffected saved systems, ref binding, compose/edit refusals) thoroughly enough that an agent needs nothing more to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents case-insensitive matching, optional backticks, and verbatim copying. The description's 'as shown, matched case-insensitively' note largely restates the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Set this connection's default engine database.' It further defines the scope of that default and implicitly distinguishes itself from the sibling lca_switch_workspace by operating on the engine rather than the workspace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the context in which the default matters (browsing/composing calls that name no engine) and the downstream conditions that follow a switch, e.g. members for a new system must come from searches run afterward. It does not state explicit when-not-to-use or name an alternative switch tool directly, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set this connection's default workspace. The default is the workspace a call that names no workspace reads. name is the workspace name as lca_get(kind='workspaces') shows it (a code span; backticks optional). The default is shared by every conversation on the connection, so another conversation can move it too; tools that save take workspace on every call and are unaffected by it. Workspace refs (s<N>, a<N>, c<N>, b<N>, v<N>) are per-workspace ordinals, so on a call naming no workspace the same number now names an object in the new default; each still names its own object on a call that names its workspace. Engine-catalog refs (p<N>, e<N>, f<N>, m<N>) are unaffected.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the workspace to work in, copied verbatim from the `# Workspaces` listing. Names are rendered as code spans and never escaped, so what you read is what resolves; the surrounding backticks are optional. Matched exactly, INCLUDING case — a real workspace name is unique per user, and that uniqueness is case-sensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare it is a non-destructive, idempotent, non-read-only mutation; the description adds that the default is shared across all conversations on the connection and can be moved by another conversation. It also warns that workspace refs are per-workspace ordinals whose meaning shifts after the switch, a consequence an agent could not infer from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and the definition of 'default', and every sentence carries real information. The ref-ordinal passage is dense but earns its place by explaining changed resolution semantics; still, the paragraph is long enough to test an agent's parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, annotation-covered, no-output-schema state mutation, the description covers the operation's scope, sharing behavior, and downstream reference-resolution effects. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaning beyond the schema: the name is what lca_get(kind='workspaces') shows, backticks are optional, and the value's effect is the connection-wide default. The case-sensitivity nuance is already in the schema, so credit is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Set this connection's default workspace') and immediately defines what 'default' means, which is the crux of the tool. An agent can distinguish it from lca_create_workspace and lca_switch_engine without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains clearly when the setting matters ('the workspace a call that names no workspace reads') and when it does not ('tools that save take `workspace` on every call and are unaffected'), which is real routing guidance. It stops short of naming sibling tools as alternatives, but the conditional framing is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How this Aevia connection works, plus playbooks for results, reports, systems. Returns a skill's playbook as the result; takes no action itself. A playbook is step-by-step guidance for a multi-step job, too long for a description. connector_guide covers how this connection works: workspaces, refs, finding data, the library, building, calculating and failures. assessment_interpretation covers reading and comparing results: what an indicator result is and is not, a figure's anchors, functional-unit equivalence and comparison discipline. report_writing covers writing results up as a document, from a screening note to an ISO 14044 study. 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. A loaded playbook stays in context; one load per session suffices. Skills are gated on what the token can call; an unavailable request returns the available list.
| Name | Required | Description | Default |
|---|---|---|---|
| skill_id | Yes | Id of the skill to load, e.g. `product_system_authoring`. An unknown or ungated id returns the list of skills available to this session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive/closed-world, so the description correctly focuses on what annotations cannot say: the tool takes no action, a loaded playbook persists in context, and skills are token-gated with an explicit fallback ('an unavailable request returns the available list'). That last point is valuable error-behavior disclosure, though it does not describe the playbook's size or format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core behavior and result semantics before the enumeration. The per-skill sentences are the value-add rather than filler, though the block is long enough that it could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so: it states the result is a playbook and that an unknown/gated id returns the available list. Combined with the routing detail and session guidance, nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 schema defines no enum and the description compensates by naming the concrete valid skill_ids and their subject matter. This adds real selection value beyond the schema's single generic string description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Returns a skill's playbook as the result') with an explicit scope disclaimer ('takes no action itself'). The enumeration of skill_ids makes it unmistakable from siblings like knowledge_get_full_document or engine_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Goes well beyond 'when to use': it routes the agent to the correct skill_id by describing what each covers ('connector_guide covers how this connection works', 'assessment_interpretation covers reading and comparing results'). It also gives the operational rule 'one load per session suffices'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
knowledge_get_excerpts2 fields changedInput schema / properties / limit / typePrevious value: -"number"New value: +"integer"Input schema / properties / top_k_chunks_per_doc / typePrevious value: -"number"New value: +"integer"knowledge_search1 field changedInput schema / properties / limit / typePrevious value: -"number"New value: +"integer"lca_get1 field changedInput schema / properties / workspace / descriptionPrevious value: -"Name of the workspace to read, as `lca_get(kind='workspaces')` lists it. Omitted: this connection's default workspace, which every conversation on the connection shares and which is often an empty sandbox."New value: +"Name of the workspace to read, as `lca_get(kind='workspaces')` lists it. Required with `ref`: each workspace numbers its objects from 1, so a ref is read in the workspace it came from. Omitted with `kind`: this connection's default workspace, which every conversation on the connection shares and which is often an empty sandbox."lca_import_system1 field changedInput schema / properties / engineRemoved 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"
-}lca_run_assessment1 field changedInput schema / properties / engineRemoved 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"
-}lca_apply_nw_setlca_compare_assessments1 field changedInput schema / properties / nw_setAdded value: +{
+ "description": "Compare by the single score of this normalization/weighting set (its name, or a unique part of it); every target must carry it, see `lca_apply_nw_set`. A target missing it, or carrying a different copy, is refused with what to do. Omit for the characterized matrix only.",
+ "maxLength": 200,
+ "minLength": 1,
+ "type": "string"
+}lca_run_assessment1 field changedInput schema / properties / nw_setAdded 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"
+}engine_search1 field changedInput schema / properties / query / descriptionPrevious value: -"Free-text query against names/categories. Use `*` (or an empty string) to list everything of the given `kind` — the way to enumerate what a database contains."New value: +"Free-text query, matched word by word against dataset names, categories and location codes — there is no meaning-based matching, so the nouns a dataset is named by (a material, a process, a product) find more than a description of the use (`polypropylene injection moulding`, not `plastic plate`). A place matches by name or code (`Switzerland`, `CH`). When no hit contains every word, the closest partial matches come back, labelled as such. Use `*` (or an empty string) to list everything of the given `kind` — the way to enumerate what a database contains."lca_compose_linked6 fields changedInput schema / properties / links / descriptionPrevious value: -"Supply edges connecting members."New value: +"Supply edges connecting members: a supplier's product into a consumer's input, or a consumer's waste output into its treatment."Input schema / properties / links / items / properties / amount / descriptionPrevious value: -"Quantity consumed (in the consumer input's unit)."New value: +"Quantity on this edge (in the consumer exchange's unit)."Input schema / properties / links / items / properties / consumer_input_index / descriptionPrevious value: -"When the consumer has 2+ input exchanges of `flow_ref`, the 0-based index (ordered by exchange id) of which one this edge feeds. Omit when unambiguous."New value: +"When the consumer has 2+ input exchanges of `flow_ref` (for a waste: 2+ output exchanges of it), the 0-based index (ordered by exchange id) of which one this edge pins. Omit when unambiguous."Input schema / properties / links / items / properties / consumer_ref / descriptionPrevious value: -"`p<N>` of the process consuming the flow."New value: +"`p<N>` of the process consuming the flow — for a waste flow, the process that OUTPUTS the waste."Input schema / properties / links / items / properties / flow_ref / descriptionPrevious value: -"`f<N>` of the product flow routed along this edge."New value: +"`f<N>` of the product flow routed along this edge, or of a waste routed from its generator to its treatment."Input schema / properties / links / items / properties / provider_ref / descriptionPrevious value: -"`p<N>` of the upstream process supplying the flow."New value: +"`p<N>` of the upstream process supplying the flow — for a waste flow, its treatment (reference = that waste as an input)."lca_delete_systemlca_edit_linked4 fields changedInput schema / properties / ops / items / properties / consumer_input_index / descriptionPrevious value: -"Which of the consumer's input exchanges of `flow_ref` this edge feeds — the 0-based index `lca_get form='authored'` reports per link. add_link: REQUIRED when the consumer has 2+ input exchanges of that flow (the call tells you the valid range if it is). remove_link/rewire_link: optional, narrows the match to one edge."New value: +"Which of the consumer's input exchanges of `flow_ref` this edge feeds (for a waste: which OUTPUT exchange of it) — the 0-based index `lca_get form='authored'` reports per link. add_link: REQUIRED when the consumer has 2+ such exchanges of that flow (the call tells you the valid range if it is). remove_link/rewire_link: optional, narrows the match to one edge."Input schema / properties / ops / items / properties / consumer_ref / descriptionPrevious value: -"add_link/remove_link/rewire_link: `p<N>` of the process that CONSUMES the flow. It must already be a member of this system."New value: +"add_link/remove_link/rewire_link: `p<N>` of the process that CONSUMES the flow (for a waste: the process that OUTPUTS it). It must already be a member of this system."Input schema / properties / ops / items / properties / flow_ref / descriptionPrevious value: -"add_link/remove_link/rewire_link: `f<N>` of the product flow on the edge."New value: +"add_link/remove_link/rewire_link: `f<N>` of the product flow on the edge, or of a waste routed to its treatment."Input schema / properties / ops / items / properties / provider_ref / descriptionPrevious value: -"add_link: `p<N>` of the process that SUPPLIES the flow (it joins the system's members automatically). remove_link: OPTIONAL — narrows the removal to edges from this supplier; omit to remove every supplier of that flow into the consumer."New value: +"add_link: `p<N>` of the process that SUPPLIES the flow — for a waste, its treatment (it joins the system's members automatically). remove_link: OPTIONAL — narrows the removal to edges from this supplier; omit to remove every supplier of that flow into the consumer."knowledge_get_excerpts1 field changedInput schema / properties / query / descriptionPrevious value: -"Search text. Required when no documents are selected (discovery mode) — finds matching documents. Optional once document_refs are given: include it to rank those documents' chunks by relevance, or omit it to pull each document's abstract + opening chunks."New value: +"Search text. Required when no documents are selected (discovery mode) — finds matching documents. Optional once document_refs are given: include it to rank those documents' chunks by relevance, or omit it to pull each document's abstract + opening chunks. The library is English-language: technical terms and scientific names match best."knowledge_search1 field changedInput schema / properties / query / descriptionPrevious value: -"Search query"New value: +"Search query. The library is English-language: technical terms and scientific names match best."lca_analyze_contributions1 field changedInput schema / properties / workspace / descriptionPrevious 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."lca_analyze_sensitivity1 field changedInput schema / properties / workspace / descriptionPrevious 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."lca_compare_assessments1 field changedInput schema / properties / workspace / descriptionPrevious 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."lca_compose_assembly1 field changedInput schema / properties / workspace / descriptionPrevious 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."lca_compose_linked1 field changedInput schema / properties / workspace / descriptionPrevious 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."lca_edit_assembly1 field changedInput schema / properties / workspace / descriptionPrevious 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."lca_edit_linked1 field changedInput schema / properties / workspace / descriptionPrevious 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."lca_get1 field changedInput schema / properties / workspace / descriptionPrevious value: -"Name of the workspace to read, as `lca_get(kind='workspaces')` lists it. Omitted: this connection's default workspace, which every conversation on the connection shares."New value: +"Name of the workspace to read, as `lca_get(kind='workspaces')` lists it. Omitted: this connection's default workspace, which every conversation on the connection shares and which is often an empty sandbox."lca_import_system1 field changedInput schema / properties / workspace / descriptionPrevious 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."lca_run_assessment1 field changedInput schema / properties / workspace / descriptionPrevious 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."engine_get3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / offset / maximumAdded value: +9007199254740991engine_list_methods2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseengine_search3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / offset / maximumAdded value: +9007199254740991knowledge_get_excerpts6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / year_from / maximumAdded value: +9007199254740991Input schema / properties / year_from / minimumAdded value: +-9007199254740991Input schema / properties / year_to / maximumAdded value: +9007199254740991Input schema / properties / year_to / minimumAdded value: +-9007199254740991knowledge_get_full_document2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseknowledge_search6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / year_from / maximumAdded value: +9007199254740991Input schema / properties / year_from / minimumAdded value: +-9007199254740991Input schema / properties / year_to / maximumAdded value: +9007199254740991Input schema / properties / year_to / minimumAdded value: +-9007199254740991lca_analyze_contributions2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falselca_analyze_sensitivity4 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / scenarios / items / additionalPropertiesRemoved value: -falseInput schema / properties / scenarios / items / properties / overrides / propertyNamesAdded value: +{
+ "type": "string"
+}lca_compare_assessments2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falselca_compose_assembly5 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / inputs / items / additionalPropertiesRemoved value: -falseInput schema / properties / stages / items / additionalPropertiesRemoved value: -falseInput schema / properties / stages / items / properties / inputs / items / additionalPropertiesRemoved value: -falselca_compose_linked4 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / links / items / additionalPropertiesRemoved value: -falseInput schema / properties / links / items / properties / consumer_input_index / maximumAdded value: +9007199254740991lca_create_workspace2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falselca_edit_assembly5 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / base_version_seq / maximumAdded value: +9007199254740991Input schema / properties / ops / items / additionalPropertiesRemoved value: -falseInput schema / properties / ops / items / properties / inputs / items / additionalPropertiesRemoved value: -falselca_edit_linked5 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / base_version_seq / maximumAdded value: +9007199254740991Input schema / properties / ops / items / additionalPropertiesRemoved value: -falseInput schema / properties / ops / items / properties / consumer_input_index / maximumAdded value: +9007199254740991lca_get4 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / offset / maximumAdded value: +9007199254740991Input schema / properties / system_ref / maximumAdded value: +9007199254740991lca_get_task_status2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falselca_import_system2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falselca_run_assessment2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falselca_switch_engine2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falselca_switch_workspace2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseload_skill2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falselca_compose_assembly2 fields changedInput schema / properties / scope / descriptionPrevious value: -"System boundary. 'cradle_to_gate' (default) = materials through manufacture. 'cradle_to_grave' = ALSO include end-of-life (add disposal/treatment process leaves). A cradle-to-grave system spans life-cycle phases — prefer `stages` over a flat `inputs` list so each phase gets its own subtotal."New value: +"System boundary. 'cradle_to_gate' (default) = materials through manufacture. 'cradle_to_grave' = ALSO include end-of-life (add disposal/treatment process leaves). 'end_of_life' = treatment of a product at end of life only; the functional unit is the treated product, e.g. '1 kg of end-of-life PV module, treated'. A cradle-to-grave system spans life-cycle phases — prefer `stages` over a flat `inputs` list so each phase gets its own subtotal."Input schema / properties / scope / enumPrevious value: -[
- "cradle_to_gate",
- "cradle_to_grave"
-]New value: +[
+ "cradle_to_gate",
+ "cradle_to_grave",
+ "end_of_life"
+]engine_get1 field changedInput schema / properties / engineAdded value: +{
+ "description": "Name of the engine database, as `lca_get(kind='engines')` lists it (case-insensitive). Omitted: this connection's default engine. Not combined with `scope_ref`, which picks the database a ref came from.",
+ "maxLength": 255,
+ "minLength": 1,
+ "type": "string"
+}engine_list_methods1 field changedInput schema / properties / engineAdded value: +{
+ "description": "Name of the engine database, as `lca_get(kind='engines')` lists it (case-insensitive). Omitted: this connection's default engine. Not combined with `scope_ref`, which picks the database a ref came from.",
+ "maxLength": 255,
+ "minLength": 1,
+ "type": "string"
+}engine_search1 field changedInput schema / properties / engineAdded value: +{
+ "description": "Name of the engine database, as `lca_get(kind='engines')` lists it (case-insensitive). Omitted: this connection's default engine. Not combined with `scope_ref`, which picks the database a ref came from.",
+ "maxLength": 255,
+ "minLength": 1,
+ "type": "string"
+}lca_analyze_contributions2 fields changedInput schema / properties / workspaceAdded 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"
+}Input schema / requiredAdded value: +[
+ "workspace"
+]lca_analyze_sensitivity2 fields changedInput schema / properties / workspaceAdded 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"
+}Input schema / requiredPrevious value: -[
- "assessment_ref"
-]New value: +[
+ "workspace",
+ "assessment_ref"
+]lca_compare_assessments2 fields changedInput schema / properties / workspaceAdded 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"
+}Input schema / requiredPrevious value: -[
- "targets"
-]New value: +[
+ "workspace",
+ "targets"
+]lca_compose_assembly3 fields changedInput schema / properties / engineAdded 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"
+}Input schema / properties / workspaceAdded 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"
+}Input schema / requiredPrevious value: -[
- "title",
- "output_name"
-]New value: +[
+ "workspace",
+ "title",
+ "output_name"
+]lca_compose_linked3 fields changedInput schema / properties / engineAdded 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"
+}Input schema / properties / workspaceAdded 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"
+}Input schema / requiredPrevious value: -[
- "ref_process_ref",
- "member_process_refs"
-]New value: +[
+ "workspace",
+ "ref_process_ref",
+ "member_process_refs"
+]lca_create_workspace1 field changedInput schema / properties / adopt_sandbox / descriptionPrevious value: -"When true, the sandbox this session is currently in becomes the new workspace, keeping everything already saved there and every workspace ref. Refused when the current workspace is not a sandbox. Default false: a new, empty workspace."New value: +"When true, the connection's default workspace, when it is a sandbox, becomes the new workspace, keeping everything already saved there and every workspace ref. Refused when the default is not a sandbox. Default false: a new, empty workspace."lca_edit_assembly2 fields changedInput schema / properties / workspaceAdded 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"
+}Input schema / requiredPrevious value: -[
- "ref",
- "ops"
-]New value: +[
+ "workspace",
+ "ref",
+ "ops"
+]lca_edit_linked2 fields changedInput schema / properties / workspaceAdded 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"
+}Input schema / requiredPrevious value: -[
- "ref",
- "ops"
-]New value: +[
+ "workspace",
+ "ref",
+ "ops"
+]lca_get1 field changedInput schema / properties / workspaceAdded value: +{
+ "description": "Name of the workspace to read, as `lca_get(kind='workspaces')` lists it. Omitted: this connection's default workspace, which every conversation on the connection shares.",
+ "maxLength": 255,
+ "minLength": 1,
+ "type": "string"
+}lca_import_system3 fields changedInput schema / properties / engineAdded 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"
+}Input schema / properties / workspaceAdded 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"
+}Input schema / requiredPrevious value: -[
- "ref"
-]New value: +[
+ "workspace",
+ "ref"
+]lca_run_assessment3 fields changedInput schema / properties / engineAdded 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"
+}Input schema / properties / workspaceAdded 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"
+}Input schema / requiredPrevious value: -[
- "ref"
-]New value: +[
+ "workspace",
+ "ref"
+]lca_create_workspaceengine_getengine_list_methodsengine_searchknowledge_get_excerptsknowledge_get_full_documentknowledge_searchlca_analyze_contributionslca_analyze_sensitivitylca_compare_assessmentslca_compose_assemblylca_compose_linkedlca_edit_assemblylca_edit_linkedlca_getlca_get_task_statuslca_import_systemlca_run_assessmentlca_switch_enginelca_switch_workspaceload_skillNatural-language queries over a verified emissions knowledge graph, plus standards validation
Sourced carbon emission factors + audit-traced calculations an AI can cite.
Turn any LLM into your lab assistant: search samples, track experiments, analyze data with AI.
Conversational what-if simulation: build, diagnose and compare Petri-net models; CC0 catalog.
Add one secure layer between your agents and this server.
