Skip to main content
Glama

Aevia

by ai.aeviamodeler
OverviewDiscussionsAdmin

Compare assessments

lca_compare_assessments

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 are one product at one amount unless function states the function they all deliver. 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.

Input Schema

NameRequiredDescriptionDefault
nw_setNoCompare 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.
targetsYesSaved-assessment refs to compare, e.g. ['a1', 'a2']. Must have ≥2 items.
functionNoThe function every target delivers, quantified — e.g. 'packaging for 1 L of beverage'. Needed when the targets are not the same product at the same amount: take it from the user's stated goal, or ask them. Saved with the comparison and shown wherever it is read.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / properties / allow_mismatched_fu
      Removed value: -{
-  "default": false,
-  "description": "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.",
-  "type": "boolean"
-}
    • addedInput schema / properties / function
      Added value: +{
+  "description": "The function every target delivers, quantified — e.g. 'packaging for 1 L of beverage'. Needed when the targets are not the same product at the same amount: take it from the user's stated goal, or ask them. Saved with the comparison and shown wherever it is read.",
+  "maxLength": 500,
+  "minLength": 1,
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / nw_set
      Added 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"
+}
  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. Changed2 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
  5. Changed2 schema fields changed
    • 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: -[
-  "targets"
-]New value: +[
+  "workspace",
+  "targets"
+]
  6. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Far exceeds the annotations: it discloses two enforced 400-level preconditions (single LCIA method; single product/amount unless function is stated), that allocation/database/provider differences do not fail but return equivalence warnings, that the result is persisted to a named workspace as primary_ref c<N>, that the matrix is unranked and per-category, and that nw_set only adds already-stored scores. This is a write operation (readOnlyHint=false), and the description makes its side effects and failure modes explicit.

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?

The paragraph is front-loaded with the core action and follows a logical order: what is saved, what a target is, preconditions, non-refused differences, return value, nw_set, skill. It is dense but several clauses paraphrase the schema descriptions, which is mild redundancy.

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?

With no output schema, the description still names the returned artifact (primary_ref c<N>) and describes the matrix's semantics (unranked, per-category, optional nw_set column). Preconditions, failure modes, and prerequisites are all covered, so 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.

Parameters3/5

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

Schema description coverage is 100%, and each parameter already carries a detailed inline description (nw_set's refusal behavior, targets' a<N> pattern and ≥2 requirement, function's quantified-goal guidance, workspace naming rationale). The prose largely restates that same material, adding little syntax or format information the schema does not already provide.

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 ('Save a comparison across 2–8 saved assessments') and immediately distinguishes itself from lca_run_assessment by noting every run already saves one, so no separate save step exists. An agent can tell exactly what this creates and from what inputs.

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?

Gives concrete usage conditions: targets must number 2–8, function is required when targets are not the same product at the same amount, and nw_set requires every target to already carry that set (via lca_apply_nw_set). It points to the assessment_interpretation skill, but never contrasts itself with sibling analysis tools such as lca_analyze_contributions or lca_analyze_sensitivity.

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