Skip to main content
Glama

Aevia

by ai.aeviamodeler
OverviewDiscussionsAdmin

Get database item

engine_get
Read-onlyIdempotent

Detail for one engine-catalog object by ref: p<N>, e<N>, f<N> or m<N>. Refs come from engine_search and name objects in the connected engine database. Polymorphic on the prefix: p<N> → process, e<N> → engine product system, f<N> → flow, m<N> → LCIA method. A workspace s<N> is a different object, read with lca_get(ref='s<N>'); this tool rejects it. Process detail defaults to a summary of both sides (top 20 each: product flows first, then elementary, grouped by unit, largest amount first); section='inputs'|'outputs' with offset pages one side, and limit (max 100) sizes the page. Every heading states the true total; a follow-up hint appears whenever rows remain. include_providers=true on a flow ref lists the processes that produce it. An m<N> returns the method's categories; section='factors' adds their characterization factors (rarely needed). A process's exchange rows and reference product carry f<N> refs, which the compose and edit tools accept directly.

Input Schema

NameRequiredDescriptionDefault
refYesThe item to look up — a reference like p1, e3 or f7 taken from an earlier search. Run `engine_search` first if you don't have one.
limitNoHow many rows to show per side. Default 20, up to 100.
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.
offsetNoSkip this many rows to page further down the list. Starts at 0 (the top).
sectionNoProcesses: show only the inputs (what the process uses) or only the outputs (what it makes or emits), one page at a time; leave unset for a short summary of both. Methods: `factors` adds the characterization factors of each impact category (heavy; rarely needed).
include_providersNoAlso list the processes that produce this flow — i.e. where it comes from. Flows only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / section / description
      Previous value: -"Show only the inputs (what the process uses) or only the outputs (what it makes or emits), one page at a time. Leave unset for a short summary of both. Processes only."New value: +"Processes: show only the inputs (what the process uses) or only the outputs (what it makes or emits), one page at a time; leave unset for a short summary of both. Methods: `factors` adds the characterization factors of each impact category (heavy; rarely needed)."
    • changedInput schema / properties / section / enum
      Previous value: -[
-  "inputs",
-  "outputs"
-]New value: +[
+  "inputs",
+  "outputs",
+  "factors"
+]
  2. 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
  3. 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"
+}
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly/idempotent/non-destructive/closed-world), yet the description still adds substantial behavior: the default two-sided summary with top-20-per-side ordering, grouping by unit, largest-amount-first, true totals in headings, follow-up hints when rows remain, and paging semantics for section+offset. This is well beyond what structured fields convey.

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?

One dense paragraph, but it is front-loaded with the purpose and ref-prefix legend before the paging and edge-case detail. Almost every sentence carries operational content; a mild deduction for length and for re-covering limit/section behavior already present in the schema.

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 must describe returns, and it does — default summary composition, pagination, totals, and hints. For a read-only lookup with 6 params, nothing an agent needs to call it correctly appears to be 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, but the description adds real meaning the schema lacks — notably what each ref prefix resolves to (p=process, e=product system, f=flow, m=LCIA method) and that process exchange rows carry f<N> refs usable by compose/edit tools. It largely restates limit/offset/include_providers behavior that the schema already documents.

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?

Opens with a specific verb+resource ('Detail for one engine-catalog object by ref') and immediately decodes the four ref prefixes (p/e/f/m). It explicitly separates itself from siblings: refs come from engine_search, and workspace s<N> objects belong to lca_get, not this tool.

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?

States the prerequisite (run engine_search first for a ref), the exclusion (rejects s<N>, use lca_get instead), and per-type usage guidance (section='factors' is 'rarely needed'; include_providers only applies to flow refs). An agent can route correctly without opening any schema.

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