Design RO membrane systems: feed pressure, permeate TDS, energy use, flux and per-stage results.
Scored across 5 tools
Each tool maps to a distinct RO design workflow step: feed-water analysis, membrane element search/detail lookup, scheme templates, and full design simulation. The get_element vs list_elements split is clearly defined as detail-lookup vs filtered search, and analyze_water vs run_design as pre-check vs system calculation.
All tool names follow a consistent snake_case verb_noun pattern: analyze_water, get_element, list_elements, list_schemes, run_design. The verbs are clear and consistently used across the set.
Five tools is well-scoped for a reverse osmosis design assistant, with each tool covering a necessary stage of the workflow. There are no redundant or clearly missing tools at the count level.
The core RO workflow is covered: feed-water analysis, membrane selection, reference scheme lookup, and design calculation with performance outputs. Minor gaps exist around saving/exporting/comparing designs or detailed pretreatment and cost optimization, but these are workaroundable.
进水水质分析：由离子组成算出 TDS、渗透压、电导率、LSI/CCPP 等结垢指数、碳酸平衡（CO2/CO3/HCO3）与碱度。判断这股水能否直接进 RO、需不需要软化或加酸。
| Name | Required | Description | Default |
|---|---|---|---|
| f | No | 离子浓度 mg/L（以该离子计） | |
| k | No | 离子浓度 mg/L（以该离子计） | |
| ba | No | 离子浓度 mg/L（以该离子计） | |
| ca | No | 离子浓度 mg/L（以该离子计） | |
| cl | No | 离子浓度 mg/L（以该离子计） | |
| mg | No | 离子浓度 mg/L（以该离子计） | |
| na | No | 离子浓度 mg/L（以该离子计） | |
| ph | No | 进水 pH，默认 7.0 | |
| sr | No | 离子浓度 mg/L（以该离子计） | |
| nh4 | No | 离子浓度 mg/L（以该离子计） | |
| no3 | No | 离子浓度 mg/L（以该离子计） | |
| po4 | No | 离子浓度 mg/L（以该离子计） | |
| so4 | No | 离子浓度 mg/L（以该离子计） | |
| hco3 | No | 离子浓度 mg/L（以该离子计） | |
| sio2 | No | 离子浓度 mg/L（以该离子计） | |
| boron | No | 离子浓度 mg/L（以该离子计） | |
| temperature | No | 进水温度 ℃，默认 25 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden。 It is transparent about what is computed and that the result is a feasibility judgment (implicitly read-only), but it does not address what happens with missing ions, minimum required inputs, or the shape of the returned values beyond naming the indices。
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 dense sentences that front-load what is calculated and follow with the actionable conclusion。 No filler, no repetition of the schema。
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 17-parameter tool with no output schema, the description compensates reasonably by enumerating the returned indices and the decision outcome。 The remaining gap is that it never states a minimum viable ion set, which matters because all 17 parameters are optional。
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 units (mg/L per ion), pH default 7.0, and temperature default 25 are already documented。 The description only restates that inputs are ion composition and adds no extra meaning such as which ions are mandatory or how to handle undetected species。
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 verb and resource (进水水质分析), lists the exact derived quantities (TDS、渗透压、电导率、LSI/CCPP、碳酸平衡、碱度), and states the decision it supports (能否直接进 RO)。 This clearly distinguishes it from its siblings get_element/list_elements/run_design。
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 second sentence establishes a clear use context: assessing whether a feed water can go straight into RO or needs softening or acid dosing。 However, it never names run_design as the alternative or says when to prefer it, so there is no explicit exclusion or sibling routing。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按元件名称取完整参数（尺寸、性能、测试条件、极限值）。设计计算前若要核对某个元件的适用边界（最高温度、pH 范围、最大压差），用它。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 元件名称，须与 list_elements 返回的名称完全一致 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full behavioral burden. It usefully discloses that the tool returns complete parameter data and names example limit fields, but it does not describe error behavior when the name does not match or explicitly confirm read-only semantics.
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 compact sentences with no wasted text. The retrieval behavior is front-loaded and the usage condition follows immediately.
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, but the description compensates by listing the categories of data returned, including limit values. It is nearly complete for a simple lookup, though it omits not-found behavior and exact return structure.
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 schema has 100% description coverage for the single required name parameter, explaining that it must exactly match a name returned by list_elements. The tool description adds little beyond restating that retrieval is by element name, so the baseline of 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 uses a specific verb and resource: it retrieves full parameters by element name, and it enumerates the kinds of data returned (size, performance, test conditions, limit values). It does not explicitly contrast itself with list_elements in the description itself, though the schema mentions list_elements for exact name matching.
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 a clear usage condition: use it before design calculations to verify an element's applicable boundaries such as max temperature, pH range, or max pressure differential. It does not state when not to use it or name list_elements as the alternative for browsing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询膜元件库（共 733 件，覆盖 Hydranautics/Toray/CSM/DuPont/Ovay/LG/Vontron/Veolia）。可按品牌、系列、关键词、适用 TDS 筛选，返回膜面积、产水量、脱盐率、测试条件等关键参数。选型时先用它挑出候选元件。
| Name | Required | Description | Default |
|---|---|---|---|
| tds | No | 计划进水 TDS mg/L，只返回适用范围内包含该值的元件 | |
| brand | No | 品牌代码：Hydranautics / Toray / CSM / DuPont / Ovay / LG / Vontron / Veolia，留空为全部 | |
| limit | No | 最多返回条数，默认 30，上限 200 | |
| family | No | 系列：1=海水淡化膜 2=苦咸水膜 4=抗污染苦咸水膜 5=海水淡化膜 6=纳滤膜 7=超滤膜 8=家用/低压 RO 膜 15=高容量海水膜 | |
| keyword | No | 元件名称关键词，如 ESPA / BW30 / TMG |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description must disclose behavior itself, and it does: it declares the corpus scope, the fields returned (膜面积、产水量、脱盐率、测试条件) and that filtering is inclusive by applicability range. It stops short of stating result ordering, truncation behavior or that the call is a pure read-only lookup.
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?
Three dense sentences: corpus, then filter and return contract, then workflow placement. Front-loaded and free of repetition; each sentence adds a distinct fact.
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 output schema, the description compensates by enumerating the returned parameters, and it covers corpus size, filter dimensions and workflow role. That is everything an agent needs to invoke it correctly; limit behavior is left to the schema, which documents it fully.
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 100%, so the schema already documents every parameter, including the family code enum and TDS range semantics. The description only restates the filter dimensions (brand, series, keyword, applicable TDS) without adding format or interpretation detail beyond 'tds 筛选是按适用范围包含该值', which is already in 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 and resource (查询膜元件库) and immediately scopes it with a concrete corpus size (733 件) and brand list (Hydranautics/Toray/CSM/DuPont/Ovay/LG/Vontron/Veolia). '选型时先用它挑出候选元件' positions it relative to the downstream get_element/run_design siblings, so an agent can tell it is the candidate-narrowing entry point.
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?
Explicit about when to use it: at the start of a selection task, to narrow to candidates. It does not name the alternate siblings or state when to skip it (e.g. when the exact model is already known and get_element suffices), so routing is clear but not fully disambiguated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出「通用方案」里的行业配置模板（电力、制药、电子、食品饮料、海水淡化等），含关键设计参数，可作为起点参考。
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | 分类代码：energetics/medicine/electronics/beverages 等，留空为全部 | |
| limit | No | 最多返回条数，默认 30 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool returns templates with key design parameters and that they serve as a reference, but omits read-only confirmation, pagination behavior, authentication needs, or response format details.
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 that efficiently conveys the tool's scope and purpose. No redundant or filler content.
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 two-parameter list tool with no annotations and no output schema, the description is adequate but incomplete. It indicates the returned content includes key design parameters, yet it lacks details on result ordering, pagination, or the exact fields in each template.
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 both parameters are already documented in the input schema. The description lists industry examples (电力、制药、电子等) that loosely correspond to the group parameter, but adds no syntax or format details beyond what the schema provides.
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 (通用方案里的行业配置模板), and gives concrete examples of industries. The purpose is clear and distinct from siblings like list_elements or analyze_water, though it does not explicitly name a sibling to avoid.
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 phrase '可作为起点参考' implies the tool is used when a starting template is needed, but it does not state when to prefer this over alternatives like run_design or analyze_water. Usage is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
跑一次完整的反渗透系统设计计算（与 rofilter.cn 网页端同引擎）。给定进水水质、回收率、产水量和膜排列，返回进水压力、产水 TDS、浓水浓度、能耗、通量、逐段结果。这是本服务最核心的工具。判读：平均通量低于 12 lmh 说明膜面积偏大（投资浪费），高于 20 lmh 偏小（污染快），vessels 应按目标通量反算。
| Name | Required | Description | Default |
|---|---|---|---|
| water | Yes | 进水水质 | |
| design | No | 设计参数，缺省时回收率 75%、产水量 100 m³/h | |
| stages | Yes | 膜排列，按段顺序；单段就写一个元素 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the calculation uses the same engine as rofilter.cn, lists the returned performance values, and gives practical interpretation thresholds for flux. It does not describe error behavior or side effects, but for a calculation tool this is otherwise fairly transparent.
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 compact and front-loaded: it states the calculation first, then explains that this is the core tool, then gives interpretation guidance. Every sentence adds useful information, and the flux thresholds are especially valuable for an agent evaluating results.
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?
Given the nested input schema and absence of an output schema, the description does a good job listing the key return values and interpreting flux. The schema covers detailed parameter semantics. It does not specify the exact response structure or explicitly route agents to list_elements for element names, leaving a minor completeness 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 the schema already documents the water, design, and stage parameters in detail. The description restates the major inputs and adds a vessel-sizing heuristic, but does not add units, formats, or constraints beyond what the schema provides. Baseline 3 is appropriate.
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 action and resource: running a complete reverse-osmosis system design calculation, and it enumerates the main outputs such as feed pressure, permeate TDS, concentrate concentration, energy, flux, and stage-by-stage results. It also calls itself the service's core tool. It does not explicitly distinguish itself from siblings like analyze_water or list_elements, so it falls 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?
The description implies when to use it: when feed water quality, recovery, permeate flow, and membrane arrangement are known and a full design calculation is needed. It adds useful interpretation guidance for average flux and vessel sizing. However, it does not explicitly name alternatives such as analyze_water or state when not to use this tool, so guidance remains implied rather than explicit.
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.
analyze_waterget_elementlist_elementslist_schemesrun_designBioprocess design: generate purification routes, simulate fermentation and separations, run TEA.
Design, solve and simulate HVAC systems from real components, weather years and buildings.
Estimate automation cash costs, time-valued capacity and simple payback from your assumptions.
MACKORN hydraulic cone crusher selection and crushing-plant design. 21 tools, callable over HTTP.
Add one secure layer between your agents and this server.