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 or engine_list_methods 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, and a follow-up call hint is included whenever rows remain. include_providers=true on a flow ref lists the processes that produce it. A process's exchange rows and reference product carry f<N> refs, which the compose and edit tools accept directly.

Input Schema

TableJSON 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).
sectionNoShow 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.
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. 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
  2. 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"
+}
  3. 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), and the description adds substantial behavior beyond that: default returns a two-sided summary (top 20 per side, grouped by unit, largest first), section+offset+limit paginate one side, headings report true totals, follow-up hints appear when rows remain, and include_providers only applies to flow refs. It also notes that returned exchange rows carry f<N> refs usable by compose/edit tools.

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 ref grammar, then behavior, then paging semantics — a logical order with no filler sentences. It is dense and some sentences are long, but each carries distinct, useful information.

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-shape burden and does so: it specifies the default summary format, ordering, grouping, per-page sizing, total counts, and pagination hints, plus the meaning of include_providers output. An agent has everything needed to call and interpret the result.

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 cross-parameter meaning the schema does not: section with offset pages one side, limit caps at 100, include_providers is flows-only, and engine is the database versus the ref's own origin. Minor noise: it references scope_ref, which is not a parameter of this tool.

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 ('Detail for one engine-catalog object by ref') and then decodes the polymorphic ref grammar (p/e/f/m prefixes) so the agent knows exactly what it will get for each ref type. It also explicitly distinguishes itself from lca_get for workspaces and from the search/list tools that supply refs, so siblings are cleanly separated.

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?

Explicitly routes: refs come from engine_search or engine_list_methods, a workspace s<N> is a different object read via lca_get(ref='s<N>') and is rejected here. This is a clear when-to-use, when-not-to-use, and named alternative.

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