Skip to main content
Glama

Aevia

by ai.aeviamodeler
OverviewDiscussionsAdmin

Search LCA database

engine_search
Read-onlyIdempotent

Search an LCA database for processes, systems, flows or methods. The database is the one named by engine, else this connection's default. kind scopes to processes, systems, flows, projects, methods (m<N> refs), or all (processes, systems and flows). 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>) valid for the session, 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.

Input Schema

NameRequiredDescriptionDefault
kindNoWhat to search for. 'all' queries processes, systems, and flows in parallel. 'project' lists openLCA projects — a project is addressed by its name, which `lca_import_project` takes. 'method' lists the LCIA methods whose name contains every word of `query` (`*` lists all); not part of 'all'.all
limitNoMax results per page (default 20).
queryYesFree-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.
engineNoName 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.
offsetNoStart index for pagination (default 0).
flow_typeNoOnly meaningful when kind=flow.
scope_refNoOptional. An engine ref (`p`/`e`/`f`/`m`) whose database to search instead of the active connection. Omit to search the active connection.
process_typeNoOnly meaningful when kind=process. Restrict to unit processes vs aggregated (system) processes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / kind / description
      Previous value: -"What to search for. 'all' queries processes, systems, and flows in parallel. 'project' lists openLCA projects — a project is addressed by its name, which `lca_import_project` takes."New value: +"What to search for. 'all' queries processes, systems, and flows in parallel. 'project' lists openLCA projects — a project is addressed by its name, which `lca_import_project` takes. 'method' lists the LCIA methods whose name contains every word of `query` (`*` lists all); not part of 'all'."
    • changedInput schema / properties / kind / enum
      Previous value: -[
-  "process",
-  "system",
-  "flow",
-  "project",
-  "all"
-]New value: +[
+  "process",
+  "system",
+  "flow",
+  "project",
+  "method",
+  "all"
+]
  2. Changed2 schema fields changed
    • changedInput schema / properties / kind / description
      Previous value: -"What to search for. 'all' queries processes, systems, and flows in parallel."New value: +"What to search for. 'all' queries processes, systems, and flows in parallel. 'project' lists openLCA projects — a project is addressed by its name, which `lca_import_project` takes."
    • changedInput schema / properties / kind / enum
      Previous value: -[
-  "process",
-  "system",
-  "flow",
-  "all"
-]New value: +[
+  "process",
+  "system",
+  "flow",
+  "project",
+  "all"
+]
  3. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous 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."
  4. Changed3 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
    • addedInput schema / properties / offset / maximum
      Added value: +9007199254740991
  5. Changed1 schema field 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. Not combined with `scope_ref`, which picks the database a ref came from.",
+  "maxLength": 255,
+  "minLength": 1,
+  "type": "string"
+}
  6. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds non-obvious behavioral context the annotations cannot: refs are session-scoped, refs minted via `scope_ref` stay bound to that database, results come back as one page of `limit` plus the true total, and unmatched queries fall back to labelled partial matches.

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?

Purpose and the core enumeration trick are front-loaded, and there is little filler, but the whole definition is one dense unbroken block covering query, kind, flow_type, process_type, engine and scope_ref in sequence, which makes it harder to scan than it needs to be.

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 carries the return-value burden and does: it explains that hits are typed refs (`p1`, `e1`, `f1`), that a system hit is an `e<N>` engine-catalog ref rather than a workspace `s<N>`, and that results are paginated with a true total. Pagination is also covered by the limit/offset schema fields, so nothing an agent needs to call and interpret this tool is missing.

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; the description exceeds it by explaining matching semantics the schema only gestures at (word-by-word against names/categories/location codes, no semantic matching, concrete `polypropylene injection moulding` example) and by clarifying cross-parameter interactions the schema lists separately (flow_type only with kind='flow', scope_ref overrides engine).

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?

The first sentence gives a specific verb and resource ('Search an LCA database for processes, systems, flows or methods') and the rest of the description positions it against engine_get (fetch by ref) and lca_run_assessment (consume refs), so the agent can tell what this tool is for without opening the schema. The scope of what is searchable and what refs are minted is stated up front.

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?

Rich when-to-use guidance: `query='*'` to enumerate a kind, `scope_ref` specifically 'for comparing across databases', `flow_type` only with kind='flow', `process_type` only with kind='process'. What is missing is an explicit statement of when NOT to use it (e.g. use `engine_get` when you already hold a ref), though the ref handoff is implied.

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