Server Quality Checklist

Tool Scores

• navigateB
  3.4/5.0
  Behavior3/5

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

  There are no annotations, so the description must carry the behavioral disclosure burden. It does state that the tool opens/focuses the page, injects an execution engine, and returns page title and control count, which gives useful behavioral signals. However, it does not explain side effects, failures, or what '注入执行引擎' entails, so transparency is partial.

  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 sentence with no redundancy; it packs the action, resource, side effect, and return value into a compact statement. It loses a point because the phrase '注入执行引擎' is jargon that could be clearer, but structurally it is efficient.

  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?

  For a simple one-parameter navigation tool, the description is mostly adequate: it names the target, the action, and the return values. However, it lacks any guidance on ordering or prerequisites relative to sibling tools, and the meaning of '注入执行引擎' is left unexplained, making the tool slightly under-specified.

  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% for the single 'url' parameter, so the schema already documents that it is the target form URL. The description adds no extra semantic detail about the parameter format, behavior, or edge cases, matching the baseline for high schema coverage.

  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 clearly identifies the action ('打开/聚焦' – open/focus) and the resource ('目标网申页面' – target application page), and states the expected return values (page title and control count). It distinguishes itself from sibling tools like inspect_form and fill_form by indicating this is the navigation/setup step, though the phrase '注入执行引擎' is somewhat vague.

  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 description implies this tool is used to open or focus the page before form interactions, but it does not explicitly state when to use it versus inspect_form, fill_form, or verify_form. No exclusions or alternative routing are provided, leaving the agent to infer the intended workflow.

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

• verify_formA
  3.8/5.0
  Behavior3/5

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

  There are no annotations, so the description must carry the behavioral burden. '回读' strongly implies a non-mutating read operation, and '当前真实值' adds useful nuance that it returns the actual current value. However, it does not explicitly state that no side effects occur, nor does it describe error cases or return behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two short sentences: the first states the core purpose and behavior, the second covers the special wildcard case. There is no redundant or filler content, and the most important information is front-loaded.

  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 one-parameter read-back tool with no output schema, the description is largely complete: it explains the action, when to use it, and the only special input value. It could mention the return format or behavior for invalid fields, but the sibling tool context and simple scope make this adequate.

  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?

  The schema already documents the msgs parameter well, including the wildcard, so the baseline is 3. The tool description adds context about 'current real values' and the purpose of validation, but it does not meaningfully extend the parameter semantics beyond what the schema already provides.

  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 identifies a specific action (回读/read back), a specific resource (specified msg fields), and the intended use case (post-fill verification). It distinguishes itself from fill_form by describing a read-back operation, though it does not explicitly contrast itself with inspect_form.

  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?

  The description gives clear context: this is for validating after the form has been filled ('用于填写后校验'). It does not list exclusions or explicitly name alternatives, but the usage context is concrete enough for an agent to decide when to call it.

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

• fill_formA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden and does a solid job: it discloses batch behavior, supported control types, addressing by id/name/msg, and the per-item success/readback return contract. It does not detail error handling or side effects, but it is materially transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is three concise, front-loaded sentences with no filler. The first sentence gives the core behavior, the second enumerates capabilities, and the third states the result format.

  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 one-parameter tool with no annotations and no output schema, the description covers input semantics, supported control types, addressing, and return values. The main remaining gap is an explicit per-operation JSON shape or example, but the description is sufficient for an agent to call the tool with reasonable confidence.

  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 schema only documents ops as '填写操作数组，见工具说明', so the description adds real meaning by explaining what ops can contain: supported field types, addressing methods, and return semantics. This exceeds the schema baseline and helps an agent construct valid operations.

  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?

  The description states a specific verb and resource: '按 ops 批量执行填写/纠错' (batch fill/correct according to ops), and further specifies supported control types and addressing modes. This makes it easy to distinguish from sibling tools like navigate, inspect_form, and verify_form.

  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 description makes its context clear: use it to fill or correct form controls in batch. However, it does not explicitly discuss when to prefer a sibling tool or when not to use this tool, such as inspecting the form first or verifying afterwards.

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

• inspect_formA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description must carry the behavioral burden. The verb 采集, combined with the listed outputs, conveys a read-only inspection operation and tells the agent what it will receive. It does not explicitly state 'no side effects', but the inspection framing makes the behavior clear enough.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  One dense sentence front-loads the action and resource, listst the collected elements, and ends with usage purpose. There is no filler, and each clause contributes to an agent's understanding of when and how to invoke it.

  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 no output schema, the description enumerates the main return components — field list, current values, dropdown options, add-more buttons — so an agent can anticipate the result. It could be more explicit about exact return shape or failure behavior, but for a single optional-parameter inspection tool it is largely sufficient.

  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 schema covers the only parameter, url, 100% with a description of optional navigation and collection. The tool description adds the key semantic that omitting url inspects the current form while providing one navigates and inspects a given URL, which goes beyond the schema.

  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?

  The description uses a specific verb, 采集, and a specific resource, 网申表单结构, and enumerates exactly what is collected: fields with msg semantics, current values, dropdown options, and available 'add more' buttons. This clearly distinguishes it from the sibling tools navigate, fill_form, and verify_form.

  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?

  It states the intended context: 用于 Agent 语义规划, which signals use during semantic planning rather than execution. It does not explicitly name fill_form or verify_form as alternatives or state when not to use it, so it stops short of the top score.

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