Related Servers

Several tool pairs have genuinely unclear boundaries: add_elements_to_group is a subset of add_to_structure_group, switch_display_stage and change_construct_stage both switch the displayed stage (one by name, one by ID), update_node with new_id duplicates update_node_id, and calc_section_property vs calculate_ection_property are near-identically named while doing different things. Long, detailed descriptions mitigate confusion, but an agent will frequently select the wrong tool among these overlapping pairs.

The dominant snake_case verb_noun pattern is highly consistent across 132 tools: create_* for builders, add_* for properties/loads, set_* for settings, apply_* for loads, update_* for modifications, remove_* for deletion, get_* for queries. Notable deviations: calc vs calculate, tapper (misspelled) vs tapered, and switch_display_stage vs change_construct_stage use different verbs for the same operation — but these are minor against the overall strong pattern.

At 132 tools this is a very large surface —well beyond even the 25+ 'too many' threshold. The bridge-engineering domain is genuinely broad (modeling, loads, tendons, construction stages, moving loads, concrete checking, visualization), which justifies substantic coverage, but the set contains clear redundancy (6 update_element_* variants, two group-add tools, two stage-switch tools, multiple tendon query splits) that could be consolidated.

The core domain is remarkably well covered: full node/element/section lifecycle, boundary conditions, loads, construction stages, tendons, moving loads, concrete checks, results, display, file I/O, and one-click bridge templates. Notable gaps exist (no material update/delete, no load-case/load-group deletion, no tendon removal, no boundary-group removal/rename), but the list_qtmodel_api + call_qtmodel_api escape hatch prevents dead ends for long-tail operations.