This server lets you look up Chinese GB-standard steel sections and calculate their theoretical weight and section properties — all read-only, local data.
Browse categories (section_categories): list all section categories (HW/HM/HN, I-beam, channel, angle, C/Z purlin, square/rectangular tube) plus the total stored spec count.
Search sections (section_search): find sections by category or keyword (e.g. HN400, 200×200), returning designation, standard, dimensions, and kg/m.
Look up properties (section_lookup): get full properties for an exact designation (e.g. HN400×200×8×13) — A (cm²), Ix/Iy (cm⁴), Wx/Wy (cm³), ix/iy (cm), kg/m.
Compute welded I-sections (section_welded_i): derive section properties from plate dimensions (hw, tw, bf, tf in mm).
Compute welded box sections (section_welded_box): derive section properties from plate dimensions (h, b, tw, tf in mm).
Calculate theoretical weight (weight_calculate): for plates, round/square/flat/hex/oct bars, rebar, pipe, square/rectangular tube, C/Z profiles, welded I/box, or standard GB sections — with optional length, quantity, material, or custom density, returning kg/m, kg, and tonnes.
List material densities (weight_materials): see built-in densities (Q235/Q355, 304, 316, aluminium, copper) and the default.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@FindingSteel Steel Sections MCP Server Find the weight of 12 metres of HN400×200×8×13, 4 pieces"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for Chinese (GB standard) steel sections: look up section properties and calculate theoretical weight for the sections used in everyday structural steelwork in China.
Built by FindingSteel — a steel structure manufacturer in Foshan, China — and backed by the same verified GB standard data tables used on our website.
GB standard data is missing from most MCP tools. Existing section databases are mostly ASTM / EN / JIS. This server fills the GB/T gap used across Chinese steel fabrication, detailing (Tekla), purchasing and structural design.
Verified values. Every section comes from the GB/T standard tables (see Data sources); designations use the standard Chinese notation such as HN400×200×8×13.
Related MCP server: datacenter-mcp-server
Tool | Description |
| List all section categories (HW/HM/HN, I-beam, channel, angle, C/Z purlin, square/rectangular tube) and total stored count. |
| Search sections by category or designation keyword; returns designation, standard, dimensions, kg/m. |
| Look up full section properties by exact designation: A (cm²), Ix/Iy (cm⁴), Wx/Wy (cm³), ix/iy (cm), kg/m. |
| Compute welded I-section properties from plate dimensions (hw, tw, bf, tf in mm). |
| Compute welded box-section properties from plate dimensions (h, b, tw, tf in mm). |
| Theoretical weight for plates, round/square/hex/oct bars, rebar, pipe, square/rectangular tube, C/Z profiles, welded I/box, or standard sections (kg/m, kg, tonnes). |
| List built-in material densities (Q235/Q355, 304, 316, aluminium, copper). |
# stdio transport (recommended for local clients)
git clone https://github.com/cdaily1995-create/findingsteel-steel-sections-mcp.git
cd findingsteel-steel-sections-mcp
npm install
npm run build
node dist/index.js
# or without cloning:
npx -y findingsteel-steel-sections-mcp{
"mcpServers": {
"findingsteel-steel-sections": {
"command": "node",
"args": ["/absolute/path/to/findingsteel-steel-sections-mcp/src/index.ts"]
}
}
}The server also ships a stateless HTTP entry for remote deployment:
PORT=3001 node src/serve.ts
# -> http://localhost:3001/mcpFind the weight of 12 metres of HN400×200×8×13, 4 pieces
section_lookup { "designation": "HN400×200×8×13" }
# -> A 83.37 cm², Ix 23500 cm⁴, Wx 1170 cm³, kg/m 65.4
weight_calculate { "shape": "standard", "designation": "HN400×200×8×13", "lengthM": 12, "quantity": 4 }
# -> total 3139.2 kg (3.14 t)Weight of pipe 168×6 for 12 m
weight_calculate { "shape": "pipe", "dims": { "D": 168, "t": 6 }, "lengthM": 12 }
# -> 23.97 kg/m, total 287.6 kgAll dimensions in mm; density default 7.85 g/cm³ (carbon steel Q235/Q355).
Section properties: A (cm²), Ix/Iy (cm⁴), Wx/Wy (cm³), ix/iy (cm), kg/m.
Designations use the × separator (e.g. HN400×200×8×13); search is case-insensitive.
weight_calculate accepts shape keys case-insensitively (rectTube = recttube).
GB/T 11263-2017 hot-rolled H-beams (HW / HM / HN)
GB/T 706-2016 hot-rolled I-beams, channels, equal/unequal angles
GB/T 6723-2017 cold-formed C / Z profiles
GB/T 6728-2017 cold-formed square and rectangular hollow sections
Theoretical weight formulas from the corresponding GB standards; density constants from common engineering handbooks.
The same data powers our online steel weight calculator and steel section properties calculator tools.
npm install
npm run typecheck # tsc --noEmit
npm test # smoke + stdio E2E + HTTP E2EMIT
列出国标型钢全部类别（HW/HM/HN、工字钢、槽钢、角钢、C/Z型钢、方管、矩形管）及库存规格总数。List all standard section categories and total count of stored specifications.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| categories | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered externally. The description adds the fact that the result includes a total count of stored specifications, plus the concrete category taxonomy, which is genuinely useful context beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and front-loaded, with the enumeration of categories placed up front. The restatement in both Chinese and English is duplicative for a monolingual reader but does not obscure the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter enumeration tool with a full output schema and strong annotation coverage, the description supplies everything an agent needs to decide to call it. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4. There is no input whose semantics the description needs to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('列出国标型钢全部类别' / 'List all standard section categories') and enumerates the exact category family it covers, which distinguishes it from section_lookup and section_search. It does not explicitly say how it differs from siblings, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: this is the entry point for discovering what categories exist before calling section_lookup or section_search. No explicit when-to-use, when-not-to-use, or named alternative is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按精确型号查国标型钢截面特性：A(cm²)、Ix/Iy(cm⁴)、Wx/Wy(cm³)、ix/iy(cm)、每米重量 kg/m。型号写法用 × 分隔，如 HN400×200×8×13、HW250×250×9×14、L50×5、C140×50×20×2.5。Look up full section properties for an exact GB designation.
| Name | Required | Description | Default |
|---|---|---|---|
| designation | Yes | 精确型号，如 HN400×200×8×13 |
| Name | Required | Description |
|---|---|---|
| A | No | |
| Ix | No | |
| Iy | No | |
| Wx | No | |
| Wy | No | |
| ix | No | |
| iy | No | |
| found | Yes | |
| units | No | |
| kgPerM | No | |
| message | No | |
| category | No | |
| standard | No | |
| dimensions | No | |
| suggestion | No | |
| designation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile needs no restating. The description adds the notation convention (× separators) and sample designations, but says nothing about failure behavior for an unmatched designation, coverage of the catalog, or lookup constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, one per language, with the property list and the format rules front-loaded before the examples. Slight duplication between the Chinese and English sentences, but no filler and nothing extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so listing the returned properties is optional rather than required, and the description nonetheless does so. Combined with the format examples, an agent has enough to invoke this single-parameter lookup correctly; only catalog coverage and mismatch handling remain unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3, but the description goes further than the schema by spelling out the × separator convention and giving four family examples (HN, HW, L, C) that show the accepted shape syntax. This is genuinely additive because the correct delimiter and family prefix are failure-prone for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Look up full section properties for an exact GB designation') and enumerates the exact property set returned (A, Ix/Iy, Wx/Wy, ix/iy, kg/m). The word 'exact' implicitly distinguishes it from the sibling section_search, but no sibling is named explicitly, so differentiation is by inference rather than statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The repeated emphasis on '精确型号'/'exact designation' implies this tool is for when the full designation is already known, which is useful context. However, it never states when-not to use it or names the alternative (e.g. use section_search when only partial dimensions are known), so the usage boundary is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按类别（category）或关键词（query）搜索国标型钢规格，返回型号、标准、尺寸与每米重量。类别示例：HN / 工字钢 / 槽钢 / 等边角钢 / C型钢 / 方管。关键词可匹配型号片段，如 "HN400" 或 "200×200"。Search GB steel sections by category or keyword; returns designation, standard, dimensions, kg/m.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 返回条数上限（默认 50） | |
| query | No | 型号或标准关键词片段，如 HN400 或 200×200 | |
| category | No | 类别，如 HN / 工字钢 / 槽钢 / 等边角钢 / 不等边角钢 / C型钢 / Z型钢 / 方管 / 矩形管 |
| Name | Required | Description |
|---|---|---|
| hint | No | |
| total | Yes | |
| returned | Yes | |
| sections | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without description help. The description adds only the shape of results (designation, standard, dimensions, kg/m), which the output schema already carries, and says nothing about pagination, limit defaults, or empty-result behaviour. With annotations doing the heavy lifting, this is adequate but adds little.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then category examples, then keyword behaviour, then return fields. The bilingual Chinese/English duplication roughly doubles the length for the same content, which is justified for a GB-standard domain but is still redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity search tool with an output schema, full annotation coverage, and 100% schema documentation, the description supplies everything needed to invoke it correctly. The one gap is routing guidance against section_lookup and section_categories, which sibling selection would benefit from.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (limit, query, category) are already documented in the schema, including the same 'HN400' / '200×200' examples the description repeats. The description's category examples add a slightly broader list of valid category strings, but otherwise duplicates structured data — baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — search GB (国标) steel sections by category or keyword — and enumerates what comes back (designation, standard, dimensions, kg/m). It is easy to tell apart from section_categories or the welded-section tools by function, but it never explicitly names or contrasts a sibling such as section_lookup, so it stops short of the top band.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete usage context: category for classification browsing (HN / 工字钢 / 槽钢 / 等边角钢 …) and query for designation fragments like 'HN400' or '200×200', which tells the agent which parameter fits which intent. However there is no when-not guidance or explicit pointer to section_lookup/section_categories as alternatives for exact-match or enumeration cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
由总高 h、总宽 b、腹板厚 tw、翼缘厚 tf（mm）计算焊接箱形截面特性。Compute section properties of a welded box section from plate dimensions (mm).
| Name | Required | Description | Default |
|---|---|---|---|
| b | Yes | 总宽 mm | |
| h | Yes | 总高 mm | |
| tf | Yes | 翼缘厚 mm | |
| tw | Yes | 腹板厚 mm |
| Name | Required | Description |
|---|---|---|
| A | No | |
| Ix | No | |
| Iy | No | |
| Wx | No | |
| Wy | No | |
| ix | No | |
| iy | No | |
| units | No | |
| valid | Yes | |
| kgPerM | No | |
| message | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, closed-world, so the safety profile is covered. The description adds useful context that inputs are plate dimensions in millimetres, but says nothing about modelling assumptions (e.g. whether welds/fillets are ignored or how the section axes are oriented).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and front-loaded, leading with the input dimensions and the computed result. The bilingual duplication is mildly redundant but keeps the definition accessible without bloating it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the four required inputs are fully documented in the schema. Still missing are the engineering conventions that matter for a section-property calculator (axis orientation, weld treatment, thin-walled assumptions), which would help an agent trust and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already carries a Chinese label with units, so the schema does the heavy lifting. The description's mapping of h/b/tw/tf to overall height/width, web and flange thickness adds a little cross-language clarity but no syntax or constraint detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: computes welded box-section properties from four plate dimensions, and the name itself distinguishes it from the sibling section_welded_i. However, it never explicitly contrasts itself with section_welded_i or the generic section_lookup/search tools, so differentiation is left to the reader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance and no mention of alternatives such as section_welded_i or section_lookup. The only implicit signal is that it consumes raw plate dimensions rather than a catalogue designation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
由总高 hw、腹板厚 tw、翼缘宽 bf、翼缘厚 tf（mm）计算焊接工字形截面特性。Compute section properties of a welded I-section from plate dimensions (mm).
| Name | Required | Description | Default |
|---|---|---|---|
| bf | Yes | 翼缘宽 mm | |
| hw | Yes | 腹板高/总高 mm | |
| tf | Yes | 翼缘厚 mm | |
| tw | Yes | 腹板厚 mm |
| Name | Required | Description |
|---|---|---|
| A | No | |
| Ix | No | |
| Iy | No | |
| Wx | No | |
| Wy | No | |
| ix | No | |
| iy | No | |
| units | No | |
| valid | Yes | |
| kgPerM | No | |
| message | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety/idempotency profile is fully covered. The description adds that this is a pure geometric calculation from positive plate dimensions, but this largely restates the parameter domain rather than disclosing new behavior such as output units or determinism notes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact bilingual sentence and the computational purpose is front-loaded. It does redundantly list all four parameters that the schema already names, which is mild waste, but the overall size is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter deterministic calculation tool, the description says what is computed and from which inputs, and an output schema exists to document the returned section properties. The main omission is sibling differentiation, but that is a usage-guidance gap rather than a correctness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (hw, tw, bf, tf) are already documented with physical meaning and mm units in the schema. The description repeats those same mappings without adding any new semantic detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: compute section properties of a welded I-section from plate dimensions (mm). This distinguishes it from the welded-box and lookup siblings implicitly via 'welded I-section' and 'from plate dimensions,' but it never names an alternative tool to make the routing explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no mention of alternatives such as section_welded_box, section_lookup, or section_search. The only implied context is that the caller has four plate dimensions, which is prerequisite information rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
计算常用钢材理论重量。shape 可选：plate钢板 / round圆钢 / square方钢 / flat扁钢 / hex六角钢 / oct八角钢 / rebar螺纹钢 / pipe圆管 / squareTube方管 / rectTube矩形管 / cProfile C型钢 / zProfile Z型钢 / weldedI焊接工字 / weldedBox焊接箱形 / standard国标型钢库（按型号）。尺寸单位 mm，长度 m。Calculate theoretical weight (kg/m, kg, tonnes) for common steel shapes or GB sections.
| Name | Required | Description | Default |
|---|---|---|---|
| dims | Yes | 尺寸 mm：各形状所需键不同（见描述），如 plate 需 t/w/l，pipe 需 D/t，cProfile 需 h/b/c/t | |
| shape | Yes | 形状：plate/round/square/flat/hex/oct/rebar/pipe/squareTube/rectTube/cProfile/zProfile/weldedI/weldedBox/standard | |
| lengthM | No | 长度 m（省略则只返回 kg/m） | |
| material | No | 材质键：q235/q355/ss304/ss316/aluminum/copper（默认碳钢 7.85） | |
| quantity | No | 数量（默认 1） | |
| designation | No | shape=standard 时的国标型号，如 HN400×200×8×13 | |
| customDensity | No | 自定义密度 g/cm³，覆盖 material |
| Name | Required | Description |
|---|---|---|
| name | No | |
| note | No | |
| shape | No | |
| valid | Yes | |
| kgPerM | No | |
| shapes | No | |
| lengthM | No | |
| message | No | |
| totalKg | No | |
| material | No | |
| quantity | No | |
| totalTons | No | |
| densityGPerCm3 | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: units (mm dims, m length), output units (kg/m, kg, tonnes), the default carbon steel density 7.85, and the rule that omitting length returns only kg/m. It does not, however, discuss precision/rounding or failure behavior for invalid designations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The shape enumeration and unit conventions are front-loaded, which is good, but the same shape list appears in both the Chinese and English portions, producing redundant repetition. It is functional but not tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich output schema and full annotation coverage, the description only needs to supply units, defaults, and shape coverage, all of which it does. Given 7 parameters and a nested dims object, it is largely complete, with a minor gap around how dims keys map to each shape and any error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented in the schema, setting the baseline at 3. The description restates the shape keys, units, and output-unit behavior but adds no parameter meaning the schema does not already carry, and it never explains the dims-key-per-shape mapping in more depth than the schema's own notes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('calculate theoretical weight' for steel shapes / GB sections) and enumerates all supported shape keys, so an agent knows exactly what the tool computes and its scope. It is clearly distinct from the sibling lookup/search tools (section_lookup, section_search, weight_materials) which retrieve data rather than compute weight.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the shape enumeration and unit conventions, but there is no explicit when-to-use / when-not-to-use guidance and no mention of alternatives such as section_lookup or weight_materials. An agent must infer that this is the computation tool while the siblings are lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出内置材质密度表（Q235/Q355、304、316、铝、铜）与默认值。List supported material densities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| default | Yes | |
| materials | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds genuinely new context: this is a closed, built-in set of materials with defined defaults, telling the agent no external data source is consulted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short and front-loaded, with the material list up front. The Chinese and English sentences are near-duplicates, a minor redundancy that costs a little efficiency but keeps the definition compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter enumeration tool, the description is complete: it names the domain, the covered materials, and the existence of defaults. An output schema exists, so return-value structure need not be explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline 4 case. The description correctly signals a no-argument call by describing the result set rather than any input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (list built-in material density table) and enumerates the actual materials covered (Q235/Q355, 304, 316, aluminum, copper) plus the presence of defaults. An agent can immediately tell this apart from the sibling weight_calculate, which computes rather than lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: it is a reference lookup whose natural role is to supply density values before calling weight_calculate. There is no explicit when-to-use, when-not-to-use, or naming of an alternative (e.g., custom materials). Adequate but with a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0section_categoriessection_lookupsection_searchsection_welded_boxsection_welded_iweight_calculateweight_materialsScored across 7 tools
The section_* tools have mostly distinct roles (categories lists, search filters by keyword, lookup requires exact designation), though search vs lookup could be confused by a careless agent. The welded_i and welded_box tools are clearly separated by shape, and the two weight_ tools divide cleanly into calculation vs reference data.
Consistent snake_case with logical prefix grouping (section_* and weight_*). Minor deviation: section_categories is a noun phrase rather than a verb_noun, but overall the pattern is predictable and readable.
Seven tools is well-scoped for a steel-sections reference/calculation server, with each tool earning its place (catalog listing, search, lookup, weight calc, material data, two welded-section calculators).
Strong lifecycle coverage: category listing, search, exact lookup, weight calculation, material densities, and welded-section property computation. Minor gap in that only I and box welded sections are supported, but core workflows are covered.
Steel takeoff, weight and gauge calculators plus RFQ, RFI, NCR and Bluebeam markup generators.
Trade-verified steel grade properties, substitution verdicts, and mill-cert guidance for AI agents.
Construction product lookup for Simpson Strong-Tie structural catalog
27 engineering compliance and calculation tools for the built environment (UK, EU, UAE).
