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

TableJSON 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).
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. 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)."
  2. 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."
  3. 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
  4. 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"
+]
  5. First observed

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

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