Skip to main content
Glama

Compute quantities

compute_quantities
Read-onlyIdempotent

Measured at the body (exact where the solid is planar): NetVolume, NetSideArea, GrossSideArea, NetArea, GrossArea, OuterSurfaceArea, GrossVolume, OuterDimensionSideArea, Centroid, Mass. Length: the axis of a segment, beam, member, column or pile whose body is one extrusion, from the file (source {kind: file, path}) or a coaxial planar mesh (measured mesh); a bend, clipped or mapped body: undetermined, never 0. Other Qto names (Width, Height ...) are file values: find_elements fields or sum. Slope: fall of a straight segment (0.02 = 2 %, positive falls) along its SINK/SOURCE port flow, else start to end; with invert_m, per element. Reinforcing bar or mesh: Length, Count, Mass from the file (Qto, BarLength) else the bars' directrix (source measured/directrix), Mass = length x pi d^2/4 x density - a density the file lacks is steel 7850 as {kind: assumption, rule}, a sum with one assumed term is an assumption. Per element or summed (per group: each find_elements group's set). Every number carries source ({kind: measured, method}), every sum its coverage (elements with a measurable body; one with an unbuilt item is partial_body, none built no_items_built; only quantities defined for the class count). NetVolume, Mass and the areas take at most 100 elements per call (MEASURE_TOO_LARGE names the parts as sets). Mass is NetVolume x Pset_MaterialCommon.MassDensity of the IfcMaterial in the unit the file declares (source.density); none declared, layers of different density or no density unit stay undetermined - never a default (steel of reinforcement above excepted). NetSideArea is the middle plane (NetVolume / thickness); GrossSideArea and GrossArea the same, GrossVolume the volume, of the one file extrusion, before its openings (source file; clipped, no opening: measured; a profile with voids or not one extrusion: undetermined); a file value of one face differs at the ends. NetArea/GrossArea also of pavement, course. CutVolume/FillVolume of a terrain need along. Read-only.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "target": "<target>",
      "quantities": "<quantities>"
    },
    "name": "compute_quantities"
  }
}

Input Schema

NameRequiredDescriptionDefault
perNoOne row per element (default; an unmeasured quantity there as {value: null, reason}) or one sum; coverage counts an element measured only with every asked quantity, coverage_per_quantity each
alongNoCutVolume/FillVolume of one terrain only, then required: sections square to the axis in plan, average end areas, source assumption with deviation_m3
targetYesWhich elements: exactly one of guid, guids, set, filter
earthworkNoYour soil factors, with along; none is assumed, without it no loose or compacted volume. Each result is an assumption naming the factor as source user
quantitiesYesWhich quantities; IfcSpace (guids, set or a filter on IfcSpace alone): GrossArea and GrossVolume of its prism, profile area x height from the file; NetFloorArea = GrossArea minus the plan area of slab openings at its floor. Wall Length: its one upright extrusion, side face / height (source file). IfcRoof body: NetArea, GrossArea the mid surface of its folded plate (measured; Gross only where no opening voids it; a roof of parts: measure the parts). NetArea, NetSideArea beside curved faces only where they are sides (a round hole, a fillet). OuterDimensionSideArea (own name, no Qto): the outer side of a wall with Pset_WallCommon.IsExternal true - the side no space stands beside - run at each corner to the outer face of the touching external wall (source assumption: rule, deviation_m2 against its own side, corners), every opening deducted (openings_m2), no VOB/C rule; no IsExternal, no space or spaces on both sides: undetermined

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, and the description adds substantial behavioral context: measurement methods, source tagging, coverage rules, the 100-element cap with MEASURE_TOO_LARGE, assumption handling for density and earthwork, undetermined versus zero, and missing-density behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense run-on block with no headings or bullets, and key limits such as the 100-element cap are buried mid-paragraph. The content is relevant, but the structure makes it hard to scan and the opening does not front-load the tool's purpose.

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 complex five-parameter tool with no output schema, the description covers measurement semantics, source and coverage metadata, limits, assumptions, and many edge cases. It still lacks an explicit output-shape summary and clear usage routing, so it is not fully complete.

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 adds material meaning for many quantities enum values, such as NetSideArea as the middle plane, Slope along SINK/SOURCE ports, CutVolume/FillVolume requiring along, and per-element versus summed behavior, though it is not organized as parameter documentation and does not address every schema parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description lists quantity names and measurement rules but never states in one clear sentence what compute_quantities does, e.g. that it computes measured quantities for a target set. The purpose is inferable from the tool name and quantities enum, and it indirectly distinguishes measured quantities from file Qto values via find_elements, but the opening is not purpose-first.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies use when measured quantities are needed and notes that other Qto names such as Width and Height are file values to read via find_elements fields or sums. However, it never explicitly says when to call this instead of list_properties or get_element, nor does it state prerequisites beyond the schema-required target and quantities.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources