Match sub-item descriptions to cost indicators from a platform library, sorted by relevance, for investment estimation. Returns candidate indicators without exposing the full database.
造价指标匹配：子项/工程描述 → 平台指标库候选指标（名称/单位/指标值/备注，按相关度排序）。投资估算时逐子项先调本工具匹配，禁止编造指标库中不存在的造价指标；全量指标库不下发，仅返回匹配候选。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 子项描述，如"城市次干路""污水处理厂 5万吨/日""给水管道 DN800" | |
| top_k | No | 返回候选数（1-15，默认8） |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses two non-obvious behaviors: the full library is never distributed and only matching candidates are returned, plus the anti-fabrication constraint. It does not state whether matching is deterministic or how ties/scores are produced, so it is good but not exhaustive.
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 key information (what it does, when to call it, the fabrication ban) is front-loaded in the first clauses, and there is little filler. The final sentence is dense but every clause adds a real constraint, so only minor tightening is possible.
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?
There is no output schema or annotations, so the description must explain return behavior — and it does, listing the returned fields and their relevance ordering. The main remaining gap is what to do when no candidate matches, which an agent may need during estimation.
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 both parameters are documented with concrete examples, so the baseline is 3. The description adds only the framing of query as a sub-item description and the relevance ordering, which the schema already implies via top_k.
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 transformation: a sub-item/project description becomes ranked candidate cost indicators from the platform library, and it even enumerates the returned fields (name/unit/indicator value/note). This clearly distinguishes it from estimate_etou_json and the calc/report 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?
It gives explicit usage context — during investment estimation, call this per sub-item first — and a negative rule (never fabricate indicators that are not in the library). It stops short of naming an alternative tool or a fallback when no candidate matches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.