Skip to main content
Glama

Aevia

by ai.aeviamodeler
OverviewDiscussionsAdmin

Get workspace item

lca_get
Read-onlyIdempotent

Read a saved workspace object by ref, or list systems, results or workspaces. Takes exactly one of ref (one object's detail) or kind (a list). A ref is read in the workspace named by workspace, which it requires: each workspace numbers its objects from 1. A kind list reads that workspace, else this connection's default. Refs: s/a/c/b/v/r<N> → system / assessment / comparison / contribution analysis / sensitivity analysis / report. An s<N> read also states the system's kind and its edit tool; form='authored' returns the authored shape the compose and edit tools accept. Kinds: 'systems' / 'assessments' / 'comparisons' / 'contribution_analyses' / 'sensitivity_analyses' / 'reports' return paginated lists of this workspace (filters: query, system_ref, method, assessment_status); 'workspaces' / 'engines' list those available, marking the default. UUIDs are not accepted.

Input Schema

NameRequiredDescriptionDefault
refNoSingle-entity ref: `s`/`a`/`c`/`b`/`v`/`r<N>`. Mutually exclusive with `kind`.
formNoref='s<N>' only. 'snapshot' (default) is the structural read. 'authored' returns the system lifted back to the AUTHORED form — the shape `lca_compose_assembly` / `lca_compose_linked` speak, tagged with its `kind`, carrying a multi-stage bill of quantities' stage DAG unflattened and a linked system's `links[]` (neither of which the snapshot has). Read this before editing a system you did not just author.
kindNoCollection mode. Mutually exclusive with `ref`. 'workspaces' and 'engines' are the odd ones out: they list the WORKSPACES / ENGINE DATABASES available to you rather than the contents of the current one.
limitNo
queryNoFree-text match on name/description (case-insensitive).
methodNokind='assessments': substring match on method_name.
offsetNo
workspaceNoName of the workspace to read, as `lca_get(kind='workspaces')` lists it. Required with `ref`: each workspace numbers its objects from 1, so a ref is read in the workspace it came from. Omitted with `kind`: this connection's default workspace, which every conversation on the connection shares and which is often an empty sandbox.
system_refNokind='assessments': filter to assessments on a single system.
assessment_statusNokind='assessments': filter by status.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / kind / enum
      Previous value: -[
-  "systems",
-  "assessments",
-  "comparisons",
-  "workspaces",
-  "engines"
-]New value: +[
+  "systems",
+  "assessments",
+  "comparisons",
+  "contribution_analyses",
+  "sensitivity_analyses",
+  "reports",
+  "workspaces",
+  "engines"
+]
    • changedInput schema / properties / ref / description
      Previous value: -"Single-entity ref. `s<N>` system, `a<N>` assessment, `c<N>` comparison. Mutually exclusive with `kind`."New value: +"Single-entity ref: `s`/`a`/`c`/`b`/`v`/`r<N>`. Mutually exclusive with `kind`."
  2. Changed1 schema field changed
    • removedInput schema / properties / include_stale
      Removed value: -{
-  "description": "kind='systems': when true, also returns OUT_OF_SYNC / NOT_FOUND / UNREACHABLE / ARCHIVED rows.",
-  "type": "boolean"
-}
  3. Changed1 schema field changed
    • changedInput schema / properties / workspace / description
      Previous value: -"Name of the workspace to read, as `lca_get(kind='workspaces')` lists it. Omitted: this connection's default workspace, which every conversation on the connection shares and which is often an empty sandbox."New value: +"Name of the workspace to read, as `lca_get(kind='workspaces')` lists it. Required with `ref`: each workspace numbers its objects from 1, so a ref is read in the workspace it came from. Omitted with `kind`: this connection's default workspace, which every conversation on the connection shares and which is often an empty sandbox."
  4. Changed1 schema field changed
    • changedInput schema / properties / workspace / description
      Previous value: -"Name of the workspace to read, as `lca_get(kind='workspaces')` lists it. Omitted: this connection's default workspace, which every conversation on the connection shares."New value: +"Name of the workspace to read, as `lca_get(kind='workspaces')` lists it. Omitted: this connection's default workspace, which every conversation on the connection shares and which is often an empty sandbox."
  5. Changed4 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
    • addedInput schema / properties / system_ref / maximum
      Added value: +9007199254740991
  6. Changed1 schema field changed
    • addedInput schema / properties / workspace
      Added value: +{
+  "description": "Name of the workspace to read, as `lca_get(kind='workspaces')` lists it. Omitted: this connection's default workspace, which every conversation on the connection shares.",
+  "maxLength": 255,
+  "minLength": 1,
+  "type": "string"
+}
  7. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's job is narrower; it still adds real behavioral context: refs are numbered per-workspace and UUIDs are rejected, 'workspaces'/'engines' list globally rather than per-workspace, and the default workspace is shared across the connection and often an empty sandbox. It does not describe pagination mechanics or error behavior when both ref and kind are omitted.

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 dual-mode purpose is front-loaded in the opening clause, and the following sentences are densely informative rather than redundant. It is long and run-on in places (the ref-prefix mapping is packed inline), but nearly every clause carries load-bearing constraint or identifier information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter, dual-mode read tool with no output schema, the description covers the ref/kind split, ref syntax, workspace resolution, filter options, and the authored-vs-snapshot distinction. What remains thin is the return shape of snapshot reads and pagination behavior, though the annotations and schema carry much of the rest.

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?

With 80% schema description coverage the baseline is 3, but the description goes further by mapping ref prefixes to their meanings (s/a/c/b/v/r<N> → system/assessment/comparison/contribution analysis/sensitivity analysis/report) and enumerating the list filters (query, system_ref, method, assessment_status), which the schema only partially documents. It also clarifies that ref/kind are mutually exclusive, adding constraint semantics absent from the flat schema.

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 states a specific verb and resource with both operating modes: 'Read a saved workspace object by ref, or list systems, results or workspaces.' It is immediately distinguishable from siblings like lca_delete, lca_compose_assembly, or lca_get_task_status because it names exactly what is read and what is listed.

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?

It gives a clear selection rule between the two modes ('Takes exactly one of `ref` ... or `kind`'), states that `ref` requires `workspace` while `kind` falls back to the connection default, and notes the auth/form caveat via 'Read this before editing a system you did not just author' in the schema. It stops short of explicitly naming alternative sibling tools (e.g. lca_edit_assembly) as the route for modification.

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