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

Goes well beyond the annotations (destructiveHint=true). It discloses that the default dry-run is rolled back, that a real edit triggers a Revit Keep/Cancel confirmation dialog, that values are interpreted in project display units (e.g. "2500" mm), and that real edits require explicit user consent. This is exactly the behavioral context a destructive 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the one-line purpose, then breaks the mode/unit guidance into discrete lines with no filler. Dense but every line earns its place; slightly repetitive between the opening scope line and the mode lines.

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 an output schema present, return values need not be described, and the annotation safety profile is enriched by the rollback, confirmation-dialog, unit, and consent details. Minor gaps remain: behavior above the 200-element cap, the meaning of revit, and idempotency expectations.

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 0%, so the description must carry parameter meaning. It documents chay_thu's two modes and the value/unit semantics of gia_tri, and implies ids (200-element cap), but leaves revit and tham_so unexplored. Partial compensation for a 5-parameter tool.

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 (gán giá trị = assign a value), the resource (a parameter on elements), and an explicit scope limit (tối đa 200 phần tử). An agent can immediately tell this is a write-back operation on Revit element parameters, distinct from the read-only statistics siblings.

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?

Clearly explains the two operating modes and gives an explicit precondition: only use chay_thu=False when the user has explicitly agreed. This is strong mode-selection guidance, though it does not compare the tool against any sibling alternative.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds only the fact that counting is grouped by category, with no mention of scope, filtering, or misconfiguration behavior — nearly nothing 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?

A single front-loaded sentence with no padding, which is appropriate in length. It is concise, though the brevity contributes to the under-specification noted elsewhere.

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-shape explanation is not required, but the tool still leaves the lone parameter undocumented and offers no usage routing across many similar siblings. For a counting tool in a crowded family, this is not enough for an agent to invoke it confidently.

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 0% and the single parameter is the opaque token 'revit' (string or null). The description says nothing about what this parameter means, whether it selects a model/file/connection, or what happens when it is omitted, so it fails to compensate for the coverage gap.

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?

Names a specific verb (đếm/count) and resource (phần tử mô hình theo hạng mục/model elements by category), so an agent can tell it aggregates counts rather than listing elements. It does not explicitly contrast itself with siblings like thong_ke_phong or khoi_luong_*, but the purpose itself is unambiguous.

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 description gives no when-to-use guidance, no prerequisites, and no mention of an alternative among the ten sibling counting/statistics tools. The agent must infer from the name alone that this is the category-aggregation option.

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

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 profile is fully covered and the description is not required to restate it. The description does add that results are grouped by material and type, which is genuinely useful behavioral context, but says nothing about project/level scope or connectivity requirements.

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?

A single short sentence, front-loaded with the output (thể tích m3) followed by the subject scope. Every clause earns its place, though the brevity borders on under-specification rather than tight conciseness.

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 structure needn't be explained, and read-only annotations cover risk. However, for a quantity take-off tool the description leaves unclear what scope is measured (whole model vs. selection vs. level), what the undocumented 'revit' argument does, and whether a prior connection check (kiem_tra_ket_noi) is required.

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 0% and the single parameter 'revit' has no title description, type detail, or default explanation. The description never mentions this parameter, so an agent gets no guidance on what value to pass or what omitting it (null default) does.

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 names a specific computation (volume in m3) and enumerates the exact structural elements covered: cột, dầm, móng. This implicitly separates it from the sibling volume tools (khoi_luong_tuong for walls, khoi_luong_san for floors), though it never names those alternatives explicitly.

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 by the element scope: an agent can infer this is the tool for structural (column/beam/foundation) quantities rather than walls or slabs. There is no explicit when-to-use statement, no prerequisite (e.g. an active Revit connection), and no routing guidance toward or away from siblings.

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

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 profile is covered. The description adds the aggregation grain (by type and floor) and the units of the returned quantities, which is genuine extra context, but says nothing about scope limits, permissions, or how the optional revit argument changes behavior.

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?

One compact sentence with the resource and grouping front-loaded and no filler. It is efficient, but the terseness comes at the cost of leaving usage and parameter information unstated.

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 the description's enumeration of area/volume/thickness is partly redundant and return values need not be explained. The remaining gap is the undocumented 'revit' parameter and the absence of any routing guidance among the several sibling quantity tools.

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 0% and the single parameter 'revit' is never mentioned in the description. With a non-zero parameter count, the description is expected to compensate for the undocumented argument, and it does not.

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 names a specific resource ('Khối lượng sàn' – floor quantity) and scopes it by type and floor, with the computed dimensions (area m2, volume m3, thickness mm) called out. This implicitly separates it from siblings like khoi_luong_ket_cau and khoi_luong_tuong, though it never names those alternatives.

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 statement of when to use this tool versus the structurally similar siblings (khoi_luong_ket_cau, khoi_luong_tuong, thong_ke_phong), nor any prerequisites. The agent must infer usage purely from the tool name and the word 'sàn'.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds useful domain context (what is measured and in which units: m, m2, m3, mm), but says nothing about the optional 'revit' parameter, prerequisites, or rate/scope limits.

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?

A single front-loaded sentence naming the resource first, then the grouping and units. No filler, though it is terse enough that it omits helpful context.

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 description covers the measured quantities. However, the undocumented 'revit' parameter and the absence of any routing guidance relative to sibling quantity tools leave gaps.

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?

There is one parameter, 'revit', with 0% schema description coverage, and the description never mentions it. No meaning, format, or default behavior is added for it, so an agent gets no guidance on what to pass.

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 the specific resource (khối lượng tường – wall quantity) and the grouping dimensions (theo loại và tầng – by type and floor), plus the measurable outputs (length, area, volume, thickness). The word 'tường' distinguishes it from the sibling quantity tools khoi_luong_san and khoi_luong_ket_cau, though no sibling is named explicitly.

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 statement of when to use this tool versus the sibling quantity extractors (khoi_luong_san, khoi_luong_ket_cau) or the exporter xuat_excel_khoi_luong. The scope is inferable from the resource name, but no explicit context or exclusions are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds useful scope context (it verifies both pyRevit and live Revit sessions hosting the agent) plus the prerequisite ordering, but does not describe failure/error behavior when Revit is absent.

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 short sentences with zero padding, and the key action plus the 'call first' directive are both front-loaded and immediately scannable.

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 no parameters, full annotation coverage, and an output schema that documents the return structure, the description supplies everything needed to call it correctly. Only the failure-mode expectations are left implicit.

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 the baseline is 4 — there is nothing for the description to disambiguate, and the schema (empty object) matches the tool's purpose.

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 ('Kiểm tra' / check) and resource (pyRevit and Revit sessions running the agent host), so the agent knows this is a connectivity/environment probe. It is clearly distinguishable from all sibling tools, which are data-query and parameter-setting operations, though it never names a sibling.

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?

'Gọi đầu tiên' (call first) gives explicit, actionable sequencing guidance — this is a prerequisite probe before invoking the statistics/volume tools. It provides clear when-to-use context but no when-not or alternative routing, since no sibling overlaps.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful semantics by defining what counts as a hit ('chưa có hoặc để trống' – absent or left blank), which goes slightly beyond the annotations. It says nothing about scope limits, scan cost, or return volume.

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 one-line purpose is front-loaded, followed by a compact per-parameter gloss with concrete examples. Nothing is padded or repeated. The trailing blank line is trivial noise but the structure is efficient overall.

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. The description covers the purpose and both required inputs in enough detail to call the tool correctly, and annotations cover the safety profile. The only real gap is the undocumented optional 'revit' parameter and the absence of usage guidance.

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 0%, so the description carries the full burden, and it does explain the two required parameters well: hang_muc accepts either a BuiltInCategory name (OST_Doors) or a Vietnamese colloquial name (cua, tuong, phong), and tham_so must be the exact Revit parameter name (e.g. 'Mark', 'Comments'). The third parameter 'revit' is left entirely undocumented in both schema and description, which prevents a 5.

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 operation on a specific resource: finding elements of a category that lack or have an empty parameter. This is clearly distinct from siblings like dat_tham_so (setting a parameter) or dem_theo_hang_muc (counting), though it never names those siblings explicitly. Only the lack of explicit sibling routing keeps it from 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?

There is no statement of when to use this tool versus the many sibling audit/statistics tools (dat_tham_so, kiem_tra_ket_noi, thong_ke_phong). The agent must infer the use case from the purpose sentence alone. No preconditions, exclusions, or alternatives are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and closed-world, so the safety profile is covered. The description adds one behavioral trait beyond that: chi_tiet=True switches the output to per-door rows and names the extra fields (id, tầng, cao bệ, ký hiệu). It says nothing about ordering, performance, or scope limits, so it is adequate but not rich.

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 short lines with zero filler: the grouping dimensions come first, and the detail-mode behavior follows immediately. Every sentence earns its place.

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 and full annotations exist, so return format and safety need not be restated. However, with a 0%-covered schema, the unexplained revit parameter is a real gap that an agent must guess at before invoking the tool.

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 0%, so the description must carry the burden. It explains chi_tiet well, including the exact fields returned in detail mode, but the revit parameter is never mentioned at all, leaving half the inputs undocumented in both schema and description.

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: statistics of doors/windows grouped by family, type, size in mm, and floor. This clearly distinguishes it from thong_ke_phong (rooms) and the khoi_luong_* volume siblings, though it never names those alternatives explicitly.

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 by the resource scope (use it when you need door/window counts by family/type/size/floor), but there is no explicit when-to-use/when-not-to-use statement nor any reference to the sibling statistics tools that could produce overlapping results.

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

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 the description. The description adds the result shape (per-floor aggregation and an 'error rooms' bucket), which is useful behavioral context, but it does not cover the optional 'revit' parameter's effect or any filtering scope.

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?

A single semicolon-delimited line that front-loads the entity being listed and then the fields and aggregations. Nothing is padded, though the terse telegraphed style leaves little room for the routing information an agent actually needs.

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 the description is not obliged to spell out return values, and its enumeration of fields is a reasonable complement. The remaining gaps — what 'revit' does and how this tool differs from its many statistics siblings — are what keep it at merely adequate for a read-only reporting tool.

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 0% and the single parameter 'revit' is never mentioned in the description, so an agent has no explanation of what it selects (model connection? project file?). With one undocumented parameter and no compensating text, this falls below the baseline-3 case that applies when the schema does the work.

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 names a concrete domain resource and enumerates what the result contains: room number, name, floor, area (m2), perimeter (m), plus per-floor totals and error rooms. It is a specific 'what it produces' statement rather than a tautology. It does not, however, differentiate itself from siblings like thong_ke_cua or khoi_luong_tuong, which are similarly shaped statistics tools.

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 statement of when to call this tool, when not to, or which sibling to prefer for a different breakdown. The presence of near-identical siblings (thong_ke_cua, dem_theo_hang_muc) makes this omission costly, since nothing in the text tells an agent which statistics tool to pick.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered elsewhere. The description's only content is a list of returned data, which is redundant given an output schema exists, so it adds no behavioral context of its own.

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?

It is short with no wasted words and front-loads the returned fields, but as a verbless fragment it is not a structured tool definition and reads like a schema dump rather than a purpose statement.

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?

Because an output schema exists, the description did not need to enumerate return values — yet that is all it does. With one undocumented parameter and no purpose or usage statement, an agent cannot confidently decide to invoke this tool over its siblings.

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 single parameter "revit" has 0% schema description coverage, so the description carries the full burden of explaining it. It never references the parameter at all ("phiên bản Revit" is a returned field, not the argument), leaving its format and filtering role entirely opaque.

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 is a noun-phrase list of data fields ("Tên mô hình, phiên bản Revit, danh sách tầng...") rather than a statement of what the tool does; there is no verb or action. It only restates the scope implied by the name thong_tin_du_an and never distinguishes itself from siblings such as kiem_tra_ket_noi or thong_ke_phong.

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 statement of when to call this tool, no prerequisites, and no mention of any alternative among the ten sibling tools. An agent receives zero routing guidance.

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

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

Annotations are present, so the bar is lower, yet the description still adds real behavioral value: files are numbered NN_, never overwritten, and 'Hao hụt và mã hiệu để trống cho kỹ sư điền'. It also scopes the write behavior — it reads the Revit model and writes a file, explaining why readOnlyHint is false despite 'chỉ đọc mô hình'.

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 the core purpose, followed by short, information-dense lines. No filler; each sentence carries a distinct fact (destination, naming, non-overwrite, read-only scope).

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 no explanation, and the write/destination behavior is well covered. The only meaningful gap is the undocumented 'revit' parameter and the absence of when-to-use routing against the sibling set.

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 0%, so the description must carry both parameters, but only 'thu_muc' is explained (absolute path, blank defaults to Documents\vn-revit-mcp). The 'revit' parameter is left completely undefined in both schema and description.

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 — 'Xuất bảng khối lượng ... ra file Excel' — and enumerates the covered categories (tường, sàn, kết cấu, cửa, phòng). The 'ra file Excel' output distinguishes it implicitly from the computation-only siblings (khoi_luong_tuong, thong_ke_cua, etc.), but no sibling is named explicitly.

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?

Provides operational context (default save location, NN_ numbering, no overwrite) but never states when to choose this tool over the many quantity/statistics siblings. Usage is implied by the export framing rather than explicitly scoped.

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