Skip to main content
Glama

MIDAS CIVIL NX tools (MIDAS IT Europe)

Which load cases make up a combination's result

combination_contributions
Read-only

Load Combination Contribution Analyzer, step 2. Splits one or more load combinations' results at a set of items into the load cases that produced them: for every item, output point (beam I/J and intermediate points, plate nodes and centre), component and max/min, the signed contribution of each case, its share of the gross, and the governing permutation written out with factors multiplied down (e.g. 1.35Self weight(ST) + 1.5LM1(MV:max)). Add superposes; an Envelope is resolved to the child that governs at each item (the governing child is counted per envelope); ABS gives |f·R| shares; SRSS energy shares. Moving-load, settlement and response-spectrum cases enter at their max or min end. Construction-stage cases are read at the final stage's last step. Cases are identified by type and name together. EVERY item is recomposed and must match the value CIVIL NX reports for the combination at the same item, part, component and sense — if any does not, the run stops and nothing is reported. Returns per combination: the cases ranked by share of the gross over the run, cases zero everywhere, envelope governing counts, and the critical item (largest |value|) per component and sense with its full breakdown; rows largest |value| first; csv: true stores every row. Tables: BEAM, TRUSS, PLATE (per unit length, local axes), ELASTICLINK, GENLINK, REACTION (supported nodes only — CIVIL NX answers other nodes with a made-up total; zero reaction rows it omits are read as zero), DISPLACEMENT. Items in set syntax (elements 101to148, nodes N1toN20, general links L5, elastic links EL7) and/or structure groups (for node tables: the group's nodes plus the nodes of its elements). Read-only (only /post/TABLE reads). Runs as a job on the website.

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": {
      "combinations": "<combinations>",
      "table": "<table>"
    },
    "name": "combination_contributions"
  }
}

Input Schema

NameRequiredDescriptionDefault
csvNoAlso store every row with every case's contribution as a CSV and return its link.
itemsNoItems in set syntax, e.g. "101to148", "N9001toN9006", "EL1toEL10". Typed ids must exist and be of the table's kind; ranges keep only what fits.
senseNoFor max/min-pair combinations: which end(s). Ignored for single-valued ones.both
tableYesWhich result table to decompose.
unitsNoUnits to report in (CIVIL NX converts). Default: the model's own.
groupsNoStructure group names to add to the set.
maxRowsNoAt most this many rows inline (largest |value| first).
componentsNoComponents to decompose (table column names, e.g. Moment-y, Shear-z, FZ, DZ, Mxx). Default: all of the table's.
combinationsYesOne General-tab combination name, or up to 10 decomposed at the same items in the same run.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

The description adds substantial behavioral detail beyond the readOnlyHint: it states that only /post/TABLE reads are used, that the run stops if any recomposition fails, and that REACTION rows for unsupported nodes are handled specially. It also explains how envelopes, ABS, SRSS, moving loads, settlement, and construction stages are treated.

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 purpose and scope are front-loaded, and the dense detail is mostly justified by the tool's complexity. The description is long, but nearly every sentence conveys operational or behavioral 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?

Given the tool's complexity, nine parameters, no output schema, and limited annotations, the description is complete enough for an agent to invoke it correctly. It covers inputs, return behavior, table-specific quirks, job execution, and validation behavior.

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 schema already documents all parameters. The description adds some useful meaning beyond the schema, notably group semantics for node tables and the fact that set ranges keep only valid ids, but most parameter detail is still carried by the 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 description names a specific operation and resource: it splits load combination results into contributing load cases. The 'step 2' framing and the detailed scope distinguish it clearly from the sibling combination_tree tool.

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?

The description gives clear usage context by identifying itself as step 2 of the Load Combination Contribution Analyzer and by explaining what it decomposes. It does not explicitly name an alternative tool or state when not to use this one, so it falls short of a 5.

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