Skip to main content
Glama

Aevia

by ai.aeviamodeler
OverviewDiscussionsAdmin

Build linked product system

lca_compose_linked

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.

Input Schema

NameRequiredDescriptionDefault
linksNoSupply edges connecting members: a supplier's product into a consumer's input, or a consumer's waste output into its treatment.
titleNoHuman title for the authored system.
engineNoName of the engine database, as `lca_get(kind='engines')` lists it (case-insensitive). Omitted: this connection's default engine.
dry_runNoWhen 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.
workspaceYesName of the workspace to work in, as `lca_get(kind='workspaces')` lists it (backticks optional). Named on every call: several conversations can share one connection, and each names its own workspace. The connection's default is often an empty sandbox rather than the user's work.
ref_flow_refNo`f<N>` ref of the reference product flow (a product OUTPUT of the ref process). Omitted, it is the reference process's own quantitative reference.
target_amountNoFunctional-unit amount (default 1.0).
temporal_scopeNoTemporal scope of the system (e.g. '2020-2024', 'Reference year 2022').
cutoff_criteriaNoExplicit cutoff criteria (e.g. 'Mass cutoff 1%; energy cutoff 1%'). Overrides the scope-derived default.
ref_process_refYes`p<N>` ref of the reference process (the functional unit). It must also be listed in `member_process_refs`.
target_unit_refNoThe 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_scopeNoExplicit geographical scope (e.g. 'Switzerland'). Overrides location codes derived from member processes.
member_process_refsYes`p<N>` refs of every process in the system — include the reference process.
functional_unit_descriptionNoFree-text description of the functional unit (e.g. 'One house, 160 m², 50-year service life').

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / ref_flow_ref / description
      Previous value: -"`f<N>` ref of the reference product flow (a product OUTPUT of the ref process)."New value: +"`f<N>` ref of the reference product flow (a product OUTPUT of the ref process). Omitted, it is the reference process's own quantitative reference."
  2. Changed6 schema fields changed
    • changedInput schema / properties / links / description
      Previous 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."
    • changedInput schema / properties / links / items / properties / amount / description
      Previous value: -"Quantity consumed (in the consumer input's unit)."New value: +"Quantity on this edge (in the consumer exchange's unit)."
    • changedInput schema / properties / links / items / properties / consumer_input_index / description
      Previous 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."
    • changedInput schema / properties / links / items / properties / consumer_ref / description
      Previous 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."
    • changedInput schema / properties / links / items / properties / flow_ref / description
      Previous 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."
    • changedInput schema / properties / links / items / properties / provider_ref / description
      Previous 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)."
  3. Changed1 schema field changed
    • changedInput schema / properties / workspace / description
      Previous value: -"Name of the workspace to work in, as `lca_get(kind='workspaces')` lists it (backticks optional). Named on every call: several conversations can share one connection, and each names its own workspace."New value: +"Name of the workspace to work in, as `lca_get(kind='workspaces')` lists it (backticks optional). Named on every call: several conversations can share one connection, and each names its own workspace. The connection's default is often an empty sandbox rather than the user's work."
  4. Changed4 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / links / items / additionalProperties
      Removed value: -false
    • addedInput schema / properties / links / items / properties / consumer_input_index / maximum
      Added value: +9007199254740991
  5. Changed3 schema fields changed
    • addedInput schema / properties / engine
      Added value: +{
+  "description": "Name of the engine database, as `lca_get(kind='engines')` lists it (case-insensitive). Omitted: this connection's default engine.",
+  "maxLength": 255,
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / workspace
      Added value: +{
+  "description": "Name of the workspace to work in, as `lca_get(kind='workspaces')` lists it (backticks optional). Named on every call: several conversations can share one connection, and each names its own workspace.",
+  "maxLength": 255,
+  "minLength": 1,
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "ref_process_ref",
-  "member_process_refs"
-]New value: +[
+  "workspace",
+  "ref_process_ref",
+  "member_process_refs"
+]
  6. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare write/non-idempotent/non-open-world; the description goes much further, disclosing atomicity ('Every member and supply edge is sent in one call', corrected calls must resend the complete system), validation semantics (validated against the DB; on failure nothing is saved and errors[]/missing_required[]/warnings[] are returned), dry_run behavior, that a tool error means the engine is unavailable, that an unreachable member blocks the build, and that the user's own writable engine is required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded: the core purpose and the 'structure only' scope lead, followed by routing, semantics, and failure behavior. It is long, and the middle sentences about link routing and ref_process_ref sit far from the corresponding schema fields, but for a 14-parameter tool nearly every sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description specifies the return contract: system_ref on success, and errors[]/missing_required[]/warnings[] on invalid input, plus the dry_run envelope. Combined with the validation and permission constraints, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond it: the waste-routing semantics of consumer_ref/provider_ref, that ref_process_ref must also appear in member_process_refs, that target_unit_ref is a unit name and not a ref (f/p/s refs rejected), and that p<N>/f<N> refs are required with UUIDs not accepted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Build a product system as an explicit process network with supply edges') and immediately scopes it ('Structure only; no LCIA runs'). It differentiates from the sibling lca_compose_assembly by naming it and the condition that selects it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: use lca_compose_assembly for a flat list of materials/quantities, and lca_run_assessment to run LCIA on the returned system_ref. It also points to the product_system_authoring skill. It does not, however, address when to use this versus lca_edit_linked for modifying an existing system.

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

All Aevia toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources