findingsteel-steel-sections

Name: findingsteel-steel-sections
Author: cdaily1995-create

by io.github.cdaily1995-create

Server Details

Chinese (GB) standard steel section properties and theoretical weight lookup, search and calculator.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-10-23 03:17
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: cdaily1995-create/findingsteel-steel-sections-mcp
GitHub Stars: 1
Server Listing: FindingSteel Steel Sections MCP Server

TDQS

A3.7/5.0

Scored 2026-10-17 06:00 across 7 tools

Disambiguation4/5

Most tools target distinct operations: categories, search, exact lookup, welded section calculations, weight calculation, and material densities. Minor overlap exists because weight_calculate can also handle standard GB sections by designation, while section_lookup already returns kg/m, so weight-related intent could be slightly less clear.

Naming Consistency4/5

All names use snake_case and are grouped by clear section_ and weight_ prefixes. The pattern is predictable, though it is not a strict verb_noun convention because several names are noun or adjective compounds.

Tool Count5/5

Seven tools is well-scoped for a steel section lookup and calculation server. Each tool appears to earn its place, covering distinct subdomains without excessive fragmentation.

Completeness4/5

The surface covers category listing, keyword search, exact section lookup, welded I/box section properties, theoretical weight calculations, and material densities. Minor gaps remain, such as no general custom-section property calculator beyond welded I and box shapes, but the core domain is well covered.

Available Tools

7 tools

section_categoriesList steel section categoriesA

Read-onlyIdempotent

Inspect

列出国标型钢全部类别（HW/HM/HN、工字钢、槽钢、角钢、C/Z型钢、方管、矩形管）及库存规格总数。List all standard section categories and total count of stored specifications.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`total`	Yes
`categories`	Yes

TDQS

A3.6/5.0

Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

section_lookupLook up section properties by designationA

Read-onlyIdempotent

Inspect

按精确型号查国标型钢截面特性：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.

ParametersJSON Schema

Name	Required	Description	Default
`designation`	Yes	精确型号，如 HN400×200×8×13

Output Schema

ParametersJSON Schema

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

TDQS

A3.6/5.0

Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

section_searchSearch standard steel sectionsA

Read-onlyIdempotent

Inspect

按类别（category）或关键词（query）搜索国标型钢规格，返回型号、标准、尺寸与每米重量。类别示例：HN / 工字钢 / 槽钢 / 等边角钢 / C型钢 / 方管。关键词可匹配型号片段，如 "HN400" 或 "200×200"。Search GB steel sections by category or keyword; returns designation, standard, dimensions, kg/m.

ParametersJSON Schema

Name	Required	Description
`limit`	No	返回条数上限（默认 50）
`query`	No	型号或标准关键词片段，如 HN400 或 200×200
`category`	No	类别，如 HN / 工字钢 / 槽钢 / 等边角钢 / 不等边角钢 / C型钢 / Z型钢 / 方管 / 矩形管

Output Schema

ParametersJSON Schema

Name	Required	Description
`hint`	No
`total`	Yes
`returned`	Yes
`sections`	Yes

TDQS

A3.6/5.0

Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

section_welded_boxCompute welded box-section propertiesB

Read-onlyIdempotent

Inspect

由总高 h、总宽 b、腹板厚 tw、翼缘厚 tf（mm）计算焊接箱形截面特性。Compute section properties of a welded box section from plate dimensions (mm).

ParametersJSON Schema

Name	Required	Description
`b`	Yes	总宽 mm
`h`	Yes	总高 mm
`tf`	Yes	翼缘厚 mm
`tw`	Yes	腹板厚 mm

Output Schema

ParametersJSON Schema

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

TDQS

B3.2/5.0

Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

section_welded_iCompute welded I-section propertiesB

Read-onlyIdempotent

Inspect

由总高 hw、腹板厚 tw、翼缘宽 bf、翼缘厚 tf（mm）计算焊接工字形截面特性。Compute section properties of a welded I-section from plate dimensions (mm).

ParametersJSON Schema

Name	Required	Description
`bf`	Yes	翼缘宽 mm
`hw`	Yes	腹板高/总高 mm
`tf`	Yes	翼缘厚 mm
`tw`	Yes	腹板厚 mm

Output Schema

ParametersJSON Schema

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

TDQS

B3.2/5.0

Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

weight_calculateCalculate steel theoretical weightA

Read-onlyIdempotent

Inspect

计算常用钢材理论重量。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.

ParametersJSON Schema

Name	Required	Description
`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

Output Schema

ParametersJSON Schema

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

TDQS

A3.8/5.0

Behavior4/5

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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

weight_materialsList material densitiesA

Read-onlyIdempotent

Inspect

列出内置材质密度表（Q235/Q355、304、316、铝、铜）与默认值。List supported material densities.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`default`	Yes
`materials`	Yes

TDQS

A4.2/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesOct 17, 2026

Changedsection_categories1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "categories": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "total": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "categories",
+    "total"
+  ],
+  "type": "object"
+}

Changedsection_lookup1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "A": {
+      "type": "number"
+    },
+    "Ix": {
+      "type": "number"
+    },
+    "Iy": {
+      "type": "number"
+    },
+    "Wx": {
+      "type": "number"
+    },
+    "Wy": {
+      "type": "number"
+    },
+    "category": {
+      "type": "string"
+    },
+    "designation": {
+      "type": "string"
+    },
+    "dimensions": {
+      "additionalProperties": {
+        "type": "number"
+      },
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "found": {
+      "type": "boolean"
+    },
+    "ix": {
+      "type": "number"
+    },
+    "iy": {
+      "type": "number"
+    },
+    "kgPerM": {
+      "type": "number"
+    },
+    "message": {
+      "type": "string"
+    },
+    "standard": {
+      "type": "string"
+    },
+    "suggestion": {
+      "type": "string"
+    },
+    "units": {
+      "additionalProperties": {},
+      "properties": {
+        "A": {
+          "type": "string"
+        },
+        "Ix": {
+          "type": "string"
+        },
+        "Iy": {
+          "type": "string"
+        },
+        "Wx": {
+          "type": "string"
+        },
+        "Wy": {
+          "type": "string"
+        },
+        "ix": {
+          "type": "string"
+        },
+        "iy": {
+          "type": "string"
+        },
+        "kgPerM": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "A",
+        "Ix",
+        "Iy",
+        "Wx",
+        "Wy",
+        "ix",
+        "iy",
+        "kgPerM"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "found"
+  ],
+  "type": "object"
+}

Changedsection_search1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "hint": {
+      "type": "string"
+    },
+    "returned": {
+      "type": "number"
+    },
+    "sections": {
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "category": {
+            "type": "string"
+          },
+          "designation": {
+            "type": "string"
+          },
+          "dimensions": {
+            "additionalProperties": {
+              "type": "number"
+            },
+            "propertyNames": {
+              "type": "string"
+            },
+            "type": "object"
+          },
+          "kgPerM": {
+            "type": "number"
+          },
+          "standard": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "standard",
+          "category",
+          "designation",
+          "dimensions",
+          "kgPerM"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "total",
+    "returned",
+    "sections"
+  ],
+  "type": "object"
+}

Changedsection_welded_box1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "A": {
+      "type": "number"
+    },
+    "Ix": {
+      "type": "number"
+    },
+    "Iy": {
+      "type": "number"
+    },
+    "Wx": {
+      "type": "number"
+    },
+    "Wy": {
+      "type": "number"
+    },
+    "ix": {
+      "type": "number"
+    },
+    "iy": {
+      "type": "number"
+    },
+    "kgPerM": {
+      "type": "number"
+    },
+    "message": {
+      "type": "string"
+    },
+    "units": {
+      "additionalProperties": {},
+      "properties": {
+        "A": {
+          "type": "string"
+        },
+        "Ix": {
+          "type": "string"
+        },
+        "Iy": {
+          "type": "string"
+        },
+        "Wx": {
+          "type": "string"
+        },
+        "Wy": {
+          "type": "string"
+        },
+        "ix": {
+          "type": "string"
+        },
+        "iy": {
+          "type": "string"
+        },
+        "kgPerM": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "A",
+        "Ix",
+        "Iy",
+        "Wx",
+        "Wy",
+        "ix",
+        "iy",
+        "kgPerM"
+      ],
+      "type": "object"
+    },
+    "valid": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "valid"
+  ],
+  "type": "object"
+}

Changedsection_welded_i1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "A": {
+      "type": "number"
+    },
+    "Ix": {
+      "type": "number"
+    },
+    "Iy": {
+      "type": "number"
+    },
+    "Wx": {
+      "type": "number"
+    },
+    "Wy": {
+      "type": "number"
+    },
+    "ix": {
+      "type": "number"
+    },
+    "iy": {
+      "type": "number"
+    },
+    "kgPerM": {
+      "type": "number"
+    },
+    "message": {
+      "type": "string"
+    },
+    "units": {
+      "additionalProperties": {},
+      "properties": {
+        "A": {
+          "type": "string"
+        },
+        "Ix": {
+          "type": "string"
+        },
+        "Iy": {
+          "type": "string"
+        },
+        "Wx": {
+          "type": "string"
+        },
+        "Wy": {
+          "type": "string"
+        },
+        "ix": {
+          "type": "string"
+        },
+        "iy": {
+          "type": "string"
+        },
+        "kgPerM": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "A",
+        "Ix",
+        "Iy",
+        "Wx",
+        "Wy",
+        "ix",
+        "iy",
+        "kgPerM"
+      ],
+      "type": "object"
+    },
+    "valid": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "valid"
+  ],
+  "type": "object"
+}

Changedweight_calculate1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "densityGPerCm3": {
+      "type": "number"
+    },
+    "kgPerM": {
+      "type": "number"
+    },
+    "lengthM": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "material": {
+      "type": "string"
+    },
+    "message": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "note": {
+      "type": "string"
+    },
+    "quantity": {
+      "type": "number"
+    },
+    "shape": {
+      "type": "string"
+    },
+    "shapes": {
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "dims": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "name": {
+            "type": "string"
+          },
+          "note": {
+            "type": "string"
+          },
+          "shape": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "shape",
+          "name",
+          "dims",
+          "note"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "totalKg": {
+      "type": "number"
+    },
+    "totalTons": {
+      "type": "number"
+    },
+    "valid": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "valid"
+  ],
+  "type": "object"
+}

Changedweight_materials1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "default": {
+      "type": "string"
+    },
+    "materials": {
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "density": {
+            "type": "number"
+          },
+          "key": {
+            "type": "string"
+          },
+          "nameEn": {
+            "type": "string"
+          },
+          "nameZh": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "key",
+          "nameZh",
+          "nameEn",
+          "density"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "materials",
+    "default"
+  ],
+  "type": "object"
+}

7 tool updatesOct 16, 2026
- First observedsection_categories
- First observedsection_lookup
- First observedsection_search
- First observedsection_welded_box
- First observedsection_welded_i
- First observedweight_calculate
- First observedweight_materials

Related MCP Connectors

china-export-rebate-mcp A
io.github.rainbow686
China export tax rebate rate & HS code lookup (官方退税率).
Government Data Finance
31
HanyuGuideOAuth
com.hanyuguide
Chinese dictionary, pinyin, stroke order, HSK quiz words and your HanyuGuide study lists.
Education & Learning Tools Language Translation
1
steel-tools A
ai.structupath
Steel takeoff, weight and gauge calculators plus RFQ, RFI, NCR and Bluebeam markup generators.
Research & Data
141
calendar-mcp A
cn.pianam.mcp
China holidays and lunar calendar lookup, solar-to-lunar conversion and yearly schedule.
Open Data
1

Related MCP Servers

cn-food-mcp
Health & Wellness Research & Data
ruffood
A
license
A
quality
D
maintenance
Provides comprehensive Chinese food nutrition data with tools to search, compare, and filter foods by nutrient values.
Updated 8 months ago (2026-02-14 23:18 UTC)
5
9 npm
8
MIT
律师教你怎么做official
Legal & Compliance Search Government Data
wjorg-law
A
license
A
quality
C
maintenance
Enables AI clients to search roughly 4,600 Chinese legal-practice articles and guides by licensed lawyers, pinpoint and read individual provisions among 17,000+ statutes, and look up criminal charge elements, sentencing ranges, provincial compensation standards, courts, procuratorates, detention centers and other judicial resources, plus run 56 legal calculators. Responses return summaries and source links rather than full article text.
Updated 3 days ago (2026-10-19 17:56 UTC)
11
MIT
HS Code MCP Server
Government Data Legal & Compliance Search
dcd887
A
license
Not graded
quality
C
maintenance
Enables AI agents to search Chinese HS commodity codes, retrieve detailed tariff and regulatory information, and calculate import taxes using 2026 import/export tariff data.
Updated 13 days ago (2026-10-10 03:38 UTC)
MIT
stock-mcp-server
Finance Research & Data Search
niuheilong
A
license
A
quality
B
maintenance
Real-time A-share stock data for AI assistants. Provides real-time stock prices, K-line data, financial indicators, and sector fund flow analysis for Chinese A-share market. Multi-source data validation ensures accuracy.
Updated 20 days ago (2026-10-03 14:47 UTC)
7
4
MIT