Skip to main content
Glama

MIDAS CIVIL NX tools (MIDAS IT Europe)

Auto Structure Groups

auto_structure_groups

Creates one structure group per section, per material, or per section + material pair, with the Auto Structure Groups plugin's own engine: it reads every element's section and material, names each group from the prefix and the section/material names (cleaned and cut to 40 characters, as in the plugin; elements with no section/material go to UNASSIGNED), largest group first. Optional: include each group's nodes, skip groups with fewer than minElements elements, or write only the groups named in groups. A name that already exists is skipped unless existing: 'overwrite' — and then this run's members are ADDED to that group (CIVIL NX merges a write into an existing group; it never removes members). Previews unless apply: true with confirmPlanHash; the plugin's writer re-reads db/GRUP, writes in batches and checks the read-back. auto_structure_groups_undo reverses it.

Input Schema

NameRequiredDescriptionDefault
modeNoWhat one group holds: one section, one section + material pair, or one material.section
applyNoWrite to CIVIL NX. Only after the user approved the preview.
groupsNoWrite only these proposed groups (names from the preview); default all.
prefixNoPut in front of every group name.SG_
existingNoA proposed name that already exists: leave that group alone, or add this run's members to it.skip
minElementsNoSkip groups with fewer elements than this (2 or more turns the filter on).
includeNodesNoAlso put each group's element nodes in the group.
confirmPlanHashNoplanHash from the approved preview; the write is refused if the plan differs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond annotations: it explains naming rules (prefix + cleaned section/material names, 40-character cut, UNASSIGNED fallback), ordering (largest group first), overwrite semantics ('members are ADDED... it never removes members'), and write verification (re-reads db/GRUP, batches, read-back checks). These details are critical for a mutating tool and are not contradicted by the annotations.

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 description is front-loaded with purpose and scope, then layers in optional behaviors and safety details. It is dense but mostly earns its length; minor readability could be improved by breaking the single long paragraph into shorter logical chunks.

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?

No output schema exists, so the description must carry the burden of explaining results. It mentions the preview/planHash workflow and the undo tool, but it does not detail the preview response structure (e.g., proposed group names, counts, planHash). For a complex 8-parameter mutating tool, this is a small remaining gap.

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 earns a 4 by adding meaningful behavior for key parameters: how 'existing: overwrite' merges rather than replaces, how 'groups' limits the write to named preview groups, and how prefix/minElements/includeNodes affect the generated groups.

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 opens with a precise verb and resource: 'Creates one structure group per section, per material, or per section + material pair.' It clearly scopes the tool to grouping by section/material using the Auto Structure Groups engine, making it easy to distinguish from sibling operations like auto_structure_groups_undo.

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 explains the preview-first workflow ('Previews unless apply: true with confirmPlanHash') and names the undo sibling as the reversal path. It does not explicitly compare to other grouping or stage tools, but the workflow guidance is clear enough to select and invoke the tool correctly.

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