Aevia

Search LCA database

engine_search

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 3, 2026

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."

Changed3 schema fields changedSep 27, 2026

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
```

Changed1 schema field changedSep 24, 2026

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"
+}

First observedSep 23, 2026

TDQS

A4.4/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Aevia tools Inspect

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

Need Help?