Qiao-MCP

Overview Schema Source Related Servers Discussions Admin

Materials, sections and time effects / 材料截面与时变属性

edit_properties

Destructive

Create or modify shared material, section, and plate-thickness definitions used by structural elements, including creep, shrinkage, tapered sections, and property updates.

Instructions

Create or modify the shared material, section and thickness definitions used by structural elements (编辑单元共用的材料、截面和板厚定义).

Choose request.operation by how the property is specified:

create_material and time/creep/shrinkage operations define material data.
create_section uses a parameterized shape; create_polygon_section uses closed loops/holes; create_line_width_section uses thin-wall segments; create_section_from_properties uses supplied engineering properties.
create_tapered_section references two existing end-section IDs; add_tapper_section_group sets variation along selected frame elements.
add_thickness supplies a plate thickness definition, not a frame section.

Use edit_geometry to assign an existing definition to elements; edit_prestress defines tendon properties. query_model reads saved values or trial-calculates candidate geometry without storing it. The selected branch determines shape fields and units: a thickness ID and a section ID occupy different namespaces even if their integers match.

update_section_property writes one full property vector at the selected end; calculate_section_property recalculates and stores properties for ALL existing sections. Do not use the latter as a readback of a manual override. remove_section deletes an explicit selection, while remove_unused_sections lets the bridge identify unreferenced definitions. Check element references before overwriting or removing shared data.

Writes refresh the model and return status/message confirmations. Requested IDs are not a guaranteed allocation result: read saved IDs and values through query_model before assigning them. There is no automatic backup, rollback or solve, and a definition change can affect many existing elements. Inspect an uncertain write before repeating it.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`request`	Yes	Choose operation and supply only its matching fields. Each branch retains its original defaults, units and validation; an operation's nested request stays nested (选择操作并按对应分支填写参数，保留原有嵌套 request).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`status`	Yes	The tool completed without an execution error.
`message`	Yes	Operation summary, query results, or instructions for the next step.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.6.0Oct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds material context beyond them: no automatic backup, rollback or solve; a definition change can affect many existing elements; requested IDs are not a guaranteed allocation result and must be read back via query_model; distinct ID namespaces for thickness vs section. This is exactly the 'what gets destroyed / what is not reversible' disclosure a mutation tool needs.

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?

It is long, but the length is justified by a 17-branch polymorphic schema; the purpose is front-loaded and the middle is organized by branch family rather than prose bloat. Some routing sentences lightly restate per-branch schema descriptions, which keeps it short of a 5.

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?

For a high-complexity write tool with an output schema, the description supplies everything an agent still needs: return shape is a status/message confirmation (not the allocated ID), the mechanism for getting real IDs, cross-tool handoffs (edit_geometry to assign, query_model to verify), and the no-backup warning. Nothing material is left implicit.

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 description coverage is 100%, so the per-branch field docs do the heavy lifting and a baseline 3 applies. The description nonetheless adds genuine meaning the schema does not: the selection rule for request.operation ('Choose request.operation by how the property is specified') and the namespace caveat that a thickness ID and a section ID are distinct even when their integers coincide.

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 opening sentence gives a precise verb+resource ('Create or modify the shared material, section and thickness definitions used by structural elements') and immediately distinguishes the tool from named siblings (edit_geometry for assignment, edit_prestress for tendons, query_model for reads). An agent can tell what this tool owns without opening the 17-branch oneOf schema.

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

Usage Guidelines5/5

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

It routes the agent across every operation branch (create_material vs add_time_parameter vs the five section-creation variants, add_thickness vs frame sections) and states explicit exclusions, e.g. 'Do not use the latter [calculate_section_property] as a readback of a manual override' and 'remove_section deletes an explicit selection, while remove_unused_sections lets the bridge identify unreferenced definitions.' When-not conditions and alternatives are both present.

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

Deploy Server