Server Quality Checklist

Tool Scores

• create_harness_workflowC
  2.8/5.0
  Behavior2/5

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

  With no annotations, the description carries the full behavioral burden but discloses little beyond the step list: nothing about whether the workflow is persisted, whether creation is idempotent, side effects, or what the created workflow's state is. Listing the orchestration steps is useful context but does not explain the mutation's behavior.

  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 the purpose sentence, then a compact numbered list of the default steps. No filler; every line addresses the tool's function.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No annotations, no output schema, and 0% parameter coverage mean the description must do more work than it does. It explains the default pipeline but omits parameter meaning, return behavior, and how the created workflow relates to advance_harness_workflow/list_harness_workflows.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% for two parameters ('goal' optional, 'idea' required), and the description never mentions either parameter, their formats, or how 'idea' drives the workflow. For a tool with undocumented params, the description should compensate but provides nothing.

  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 ('创建' / create) and resource ('DeepSeek Harness 顶层设计工作流'), and the sibling set (list_harness_workflows, advance_harness_workflow) makes the create-vs-list-vs-advance distinction inferable. The named default orchestration sequence also clarifies the scope of what gets created.

  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 usage by presenting a '默认编排' (default orchestration) pipeline, suggesting this tool kicks off a standard design flow. However, it never states when to choose this over advance_harness_workflow or how a custom (non-default) workflow is triggered, leaving the selection criteria implicit.

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

• add_design_nodeC
  2.9/5.0
  Behavior2/5

  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 does not state whether this mutates persisted state, whether duplicate node names are allowed, what identifiers are returned, or how the new node relates to the existing tree — all critical for a write operation with zero annotation coverage.

  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 purpose sentence is front-loaded and the kind list is compact and scannable. It is appropriately sized for the information conveyed, with no obvious filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutation tool with no annotations, no output schema, and 0% parameter description coverage, the description should disclose the node lifecycle, persistence, and return behavior. It supplies only the kind vocabulary, leaving most operational questions unanswered.

  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 0% and the kind parameter has no enum, so the description's enumerated kind values (concept/tech/design/requirement/risk) genuinely add meaning beyond the schema. However, it leaves 'name' and 'note' semantics (and whether note is free text or markup) entirely undocumented.

  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 ('add a node') scoped to the design tree / bidirectional graph, which lets an agent distinguish it from the sibling add_design_relation. However, it does not explicitly name or contrast itself with any sibling, so it stops short of full differentiation.

  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 explicit when-to-use or when-not-to-use guidance; the agent must infer from the tool name and the presence of siblings like add_design_relation and get_design_tree. The kind list hints at intended usage but does not state conditions or alternatives.

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

• assess_risksC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries the full disclosure burden. '快速' hints at latency and the mention of human decision-making hints at the consumer, but nothing is said about permissions, what the assessment contains, or whether anything is persisted.

  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?

  A single front-loaded sentence with no filler; the purpose leads. It is efficient, though so terse that it omits nearly all supplementary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema, no annotations, and 0% parameter coverage mean the description is the only guidance available, yet it omits return shape, risk dimensions assessed, and parameter behavior. For a tool meant to feed top-level decisions, this is too thin.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It only echoes the two field concepts (想法/设计) without explaining that 'design' is optional or how a design refines the assessment, leaving the parameter relationship unexplained.

  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?

  Names a concrete verb+resource pair (风险评估 on 想法/设计), so an agent knows it produces a risk assessment rather than a design listing or a question probe. It does not, however, differentiate itself from close siblings like analyze_upper_design or probe_idea_question.

  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 clause '供人做顶层决策' implies the decision context in which the tool is useful, giving implicit usage guidance. It never states when NOT to use it or which sibling to prefer for adjacent tasks, so guidance remains inferential.

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

• finalize_planC
  2.9/5.0
  Behavior2/5

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

  No annotations and no output schema are provided, so the description carries the full behavioral burden, yet it only says a plan is produced. It never states whether this is a write/side-effecting operation, whether it persists or overwrites a plan, what happens to the design and decisions inputs, or what the caller receives back.

  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?

  A single short sentence that is front-loaded on the outcome and free of filler. Its brevity is efficient, though it shades into under-specification given the undocumented parameters.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a three-parameter tool with no annotations, no output schema, and no sibling differentiation, one sentence about producing a plan is not enough. An agent cannot determine required inputs, side effects, or when this tool supersedes the other design/analysis siblings.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% for three parameters (idea, design, decisions), and the description mentions none of them. The only hint is that inputs are '汇总' (aggregated) into the plan, which does not clarify the role, format, or required/optional distinction of design and decisions. With three undocumented parameters, the description 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a concrete action and artifact ('汇总成一份高层计划') plus its audience ('供人审阅和拍板'), so an agent can tell it produces a consolidated plan rather than raw analysis. However, it says nothing to distinguish it from design-oriented siblings such as analyze_upper_design or create_harness_workflow, so it lands at 'clear but undifferentiated'.

  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?

  '供人审阅和拍板' implies this is a terminal step used when a human must review and approve, which gives weak, inferred guidance about when to call it. There is no explicit when-not clause and no alternative tool is named, so the routing decision 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.

• get_design_graphC
  2.9/5.0
  Behavior2/5

  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 implies a read of the whole graph but says nothing about cost, size limits, pagination, or whether relationships are directional in the returned payload — significant gaps for a whole-graph fetch.

  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?

  A single short sentence with no filler, and the key scope word ('整张') is front-loaded. It is efficient but borders on under-specification rather than true conciseness.

  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?

  With no output schema and no annotations, the description is the only source of information about what comes back, and it gives just one line. An agent cannot tell the return shape (nodes/edges, nesting, size) or how it relates to get_design_tree.

  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 there is nothing for the description to disambiguate. Baseline 4 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a verb and resource ('返回...设计树/双向关系图') but the resource overlaps heavily with the sibling get_design_tree, and '整张' (entire) is the only differentiator. The description never clarifies how this differs from get_design_tree or why a graph view exists separately.

  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?

  No when-to-use guidance, no prerequisites, and no mention of the obvious alternative get_design_tree. The agent is left to guess which of the two tree-returning tools to call.

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

• save_insightC
  2.9/5.0
  Behavior2/5

  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 states the card is stored for later retrieval but says nothing about persistence guarantees, permissions, whether saves are idempotent or reversible, or what happens on duplicate subjects.

  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-loads the purpose in one sentence, then a compact bulleted value list. No filler; the only minor cost is that the taxonomy bullets occupy space without covering the other parameters.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutating tool with no annotations, no output schema, and 0% parameter coverage, the description is materially incomplete: three of four parameters and all behavioral traits are undocumented, so an agent lacks enough to call it confidently.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate for all four parameters. It only explains insight_type (with suggested values), while subject, content, and related_idea are left entirely undefined in both schema and description.

  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: saving a design insight/learning card for later lookup and reuse. Clear what it does, but it does not distinguish itself from siblings like capture_idea or list_insights, leaving the agent to infer the boundary.

  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 insight_type taxonomy (upper/reverse/github/risk/decision) gives implied guidance on what kind of insight fits here, but there is no explicit when-to-use vs when-not, no mention of capture_idea as an alternative, and no prerequisites.

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

• get_design_treeB
  3/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It does add useful behavioral context by describing the four relationship categories the view surfaces (upper design, implementation, reverse question, related concepts), which is beyond what the bare schema tells you. However it says nothing about read-only nature, permissions, or how depth affects traversal.

  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 purpose sentence followed by a tight four-item bullet list of what the view contains. Well structured with little waste, though the bullets describe output rather than helping an agent decide when to call 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?

  No output schema and no annotations, so the description must be self-sufficient. It covers the conceptual shape of the result via the four categories but omits depth semantics and any return-format detail, leaving moderate gaps for a tool whose only real knob is traversal depth.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0% and there are 2 parameters, so the description must compensate. It only weakly implies the 'subject' input via '某个主题' and gives no meaning at all for 'depth' (its default of 2 or what increasing it yields). The semantics of the second parameter are entirely undocumented.

  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 gives a clear verb+resource: extracting a related view of a subject from the design tree / bidirectional relationship graph, and enumerates the four relationship kinds returned. It is specific about what the tool produces, but it does not distinguish itself from overlapping siblings such as get_design_graph, analyze_upper_design, or reverse_reasoning, whose outputs it partially duplicates.

  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 explicit when-to-use, when-not-to-use, or alternative routing. Given that siblings analyze_upper_design, reverse_reasoning, and find_related_technologies overlap with the views this tool exposes, the absence of any routing guidance is a real gap and leaves selection to inference.

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

• list_design_optionsB
  3.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden, and it does disclose one meaningful behavioral trait: the return always includes five fixed expansion slots in addition to dynamic options. That tells the agent what to expect in the output. It says nothing about read-only nature, side effects, permissions, or whether it triggers downstream calls.

  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?

  Purpose is front-loaded in the first sentence, followed by an efficient bulleted enumeration of the fixed slots. The closing sentence adds justification but is somewhat redundant with the earlier framing of choosing angles.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  There is no output schema and no annotations to lean on, so the description must carry the load. It explains the fixed slots but not the dynamic option format, and it leaves three of four parameters undocumented. For a tool with 4 params at 0% coverage, this is a substantive gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% and the description documents essentially only the 'idea' input implicitly. The domain, max_options (default 12), and search_results parameters are unexplained in both schema and description, leaving their semantics and interplay unclear.

  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 concrete purpose: for a given idea, produce a list of technical options plus a fixed set of expansion perspectives (direct solution, GitHub ideas, upper-level design decomposition, reverse reasoning, risk assessment). This is more than a tautology and the listed slots map recognizably to sibling tools. It is slightly abstract about what a 'technical option' actually is, keeping 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It implies the usage pattern: present options so the user can choose which angle to pursue, rather than judging technical familiarity. That is useful implied guidance for a menu/entry-point tool. However, it never states when to call this versus the sibling tools it routes to, nor any prerequisites or exclusions.

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

• list_insightsB
  3.1/5.0
  Behavior2/5

  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 confirms this is a retrieval operation but says nothing about return format, whether the list is paginated or bounded, or what happens when no filters are supplied — all relevant for a list tool with no annotation coverage.

  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?

  A single sentence that front-loads the resource and appends the filtering capability. No filler, though the terseness contributes to the coverage gaps noted elsewhere.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  There is no output schema and no annotations, so the description should explain enough about the returned collection and filter semantics to call the tool correctly. It covers purpose and filter names but leaves return shape, pagination, and empty-result behavior unspecified for a two-parameter list tool.

  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 0%, so the description must compensate. It loosely maps both parameters by naming the filter dimensions 主题 (subject) and 类型 (insight_type), but it gives no accepted values, casing, or format for either, and insight_type has no enum to fall back on, leaving ambiguity.

  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 clear verb (列出) and resource (设计洞察/学习卡片), and explicitly marks the read operation, which distinguishes it from the write sibling save_insight. It stops short of naming any sibling directly, so it earns a 4 rather than 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?

  支持按主题或类型过滤 implies the filtering use case and hints at two query modes, but there is no explicit when-to-use vs. when-not-to-use guidance and no reference to the save_insight/capture_idea siblings. Usage is implied rather than stated.

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

• add_design_relationB
  3.2/5.0
  Behavior2/5

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

  No annotations exist, so the description carries the full behavioral burden. It discloses one useful trait - the relation is bidirectionally queryable, so a reverse lookup is created - but says nothing about duplicate relations, idempotency, what happens if source/target do not resolve, permissions, or the response shape.

  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?

  One-sentence purpose followed by a tight bulleted list of relation values; no filler. The list earns its space because the schema provides no enum, though the value definitions could be slightly more precise.

  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 three-required-parameter mutation with no annotations and no output schema, the description covers relation values adequately but leaves source/target format and the consequences of the write unspecified. An agent could call it, but may guess at identifiers.

  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 coverage is 0% and there are no enums, so the description must supply meaning. It does this well for the relation parameter by defining four values and their semantics, but source and target are never explained (node IDs? titles? paths?), leaving a real gap.

  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: adding a relation in the design tree, with the distinctive property that it is bidirectionally queryable. This is readily separable from add_design_node, though the description never names that sibling to contrast itself.

  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 ('add a relation in the design tree'); there is no statement of when to link two nodes versus creating a node, or when a relation is preferable to using get_design_graph. The relation-type list does give real guidance on which relation value to pick, which lifts it above pure omission.

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

• analyze_upper_designB
  3.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the internal two-step process (abstract, then analyze implementation), which is meaningful behavioral context. However it says nothing about output shape, whether the analysis is stored/persisted, permissions, or side effects.

  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 core definition is front-loaded in a single clause, followed by compact examples that earn their place by making an abstract concept tangible. Structure is clear and free of filler.

  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 2-param analytical tool with no annotations and no output schema, the description conveys the transformation well but omits the 'idea' parameter entirely and gives no expectation of what the analysis returns, leaving a real 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 coverage is 0%, so the description must compensate. The examples richly clarify what 'subject' means (K8s RBAC, MCP, Raspberry Pi camera) and what the resulting upper-level design is. The second parameter 'idea' is never mentioned, leaving half the inputs undocumented.

  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 transformation: abstract upward from a concrete technology/solution to a higher-level design, then analyze how it is implemented. The three worked examples make the intent concrete. It does not, however, distinguish this from siblings like reverse_reasoning or probe_technology_details.

  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?

  The examples imply where the tool applies, but there is no explicit when-to-use statement, no conditions or exclusions, and no named alternative among the numerous siblings (reverse_reasoning, probe_technology_details, list_design_options). The agent must infer routing.

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

• capture_ideaB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description carries the full behavioral burden. It conveys that this is a create/record action, but says nothing about persistence semantics, whether it overwrites prior entries, required permissions, error behavior, or what the caller receives back. The second sentence describes downstream use rather than this tool's own behavior.

  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 short sentences with the core purpose front-loaded and the entry-point framing following. Every sentence is relevant, though the second sentence is more about the broader workflow than about this tool specifically.

  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 4-parameter creation tool with no annotations, no output schema, and 0% schema description coverage, the description is only partially complete: it explains intent and three of four inputs but omits preferred_approach, and it leaves behavioral traits (persistence, return, idempotency) undocumented.

  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 0%, so the description must compensate, and it does partially: it names the idea, the top-level goal, and the constraints, mapping 3 of the 4 parameters. However, preferred_approach is never mentioned, and no format or content expectations (e.g., granularity of constraints) are given for any parameter.

  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 (记录/record) and resource (一个新想法/an idea) plus the associated goal and constraints, and frames itself as the entry point of a top-level design flow. It does not, however, explicitly distinguish itself from siblings like save_insight or add_design_node, so an agent must infer the boundary.

  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?

  It implies usage by calling itself 'the entry point for top-level design' and names downstream activities (listing options, decomposing, reverse-reasoning), which suggests this is the first step. But it never states when NOT to use it nor names a concrete alternative sibling tool, leaving the routing decision to inference.

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

• list_harness_workflowsB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It discloses the important scope constraint ('current process'), but says nothing about whether this is a read-only operation, whether it can fail, or what a consumer should expect from the result set.

  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?

  A single short sentence with the scope constraint front-loaded and no filler. Nothing could be trimmed without losing meaning.

  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 zero-parameter read tool with no output schema, the description covers the essentials. However, with no output schema to explain the return shape, a brief note on what each workflow entry contains (id, name, status) would have closed the remaining gap.

  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 there is nothing for the description to disambiguate. Baseline 4 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?

  States a specific verb (列出) and resource (DeepSeek Harness 工作流) with a clear scope qualifier ('当前进程内'). It is distinguishable from create_harness_workflow and advance_harness_workflow by verb alone, but it never explicitly contrasts itself with those siblings.

  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?

  No when-to-use guidance, prerequisites, or alternative tools are mentioned. An agent must infer that this is the discovery entry point before creating/advancing a harness workflow purely from the name.

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

• reverse_reasoningB
  3.2/5.0
  Behavior3/5

  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 does convey the nature of the reasoning output (the problem solved, why it exists, whether it's needed), which is genuine behavioral context, but says nothing about determinism, latency, or how the optional 'idea' input 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.

  Conciseness4/5

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

  The operation is stated up front in one line, and the examples are compact and directly useful for understanding invocation. Structure is efficient with little waste.

  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?

  With no output schema and no annotations, the description is the sole source of context. It adequately explains the reasoning operation but omits any explanation of the 'idea' parameter and offers no guidance on outputs or when this analysis should be chosen over sibling tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It illustrates the required 'subject' parameter with examples but never mentions the optional 'idea' parameter at all, leaving half of the inputs semantically undocumented.

  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 names a specific cognitive operation (reverse-inferring the problem/solution-rationale behind a given subject) and illustrates it with three concrete examples, so an agent understands what the tool produces. It does not, however, distinguish itself from potentially overlapping siblings such as probe_technology_details or probe_idea_question.

  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 examples of valid subjects, so an agent can infer how to invoke it. But there is no explicit statement of when to choose this over probe_technology_details or list_design_options, and no when-not guidance or prerequisites.

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

• search_github_ideasB
  3.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and does disclose a critical behavioral trait: the tool has no network access and behaves differently depending on whether github_results is supplied. It omits return format and processing depth, but the offline constraint and conditional branching are well surfaced.

  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?

  Purpose is front-loaded in the first clause, followed by a compact two-branch bullet list. No filler sentences, though the query-passing branch could be worded more precisely.

  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?

  There is no output schema and no annotations, so the description should specify what the distillation produces. It hints at 'patterns' and 'suggestions' but does not describe the returned content or format, and the interaction between the query input and the query the tool supposedly emits is unresolved.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must explain all three parameters. It clarifies github_results (pass upstream results in), but the required 'idea' parameter is never explained and 'query' is ambiguous — the text describes a query being *returned* by the tool, which conflicts with query being an input property.

  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 action (接受上游 GitHub 搜索结果，提炼可借鉴的模式) and explicitly corrects the misleading tool name by noting the MCP does not go online itself. An agent can understand what actually happens, though the name 'search_github_ideas' still suggests live searching.

  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?

  It gives conditional usage guidance ('if upstream found results, pass via github_results; if not, the tool returns a query and suggestions'), which is genuinely useful routing logic. However, it never contrasts this tool with plausible siblings such as find_related_technologies or probe_idea_question, so alternative selection 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.

• advance_harness_workflowA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden, and it does disclose the key state transition: marking the current step complete then moving to the next pending one. It omits important behavioral facts such as what happens when no pending step remains, whether the operation is idempotent, and what the call returns.

  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 one-line purpose followed by two short bullets is front-loaded and wastes no words. Structure maps cleanly onto the two behavioral modes, though it could be slightly tighter or surface an outcome sentence.

  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 two-parameter, stateful mutation tool with no annotations and no output schema, the description covers the primary branching logic but leaves the result of the operation (return value, failure when no pending step exists) unstated, which an agent calling it would want to know.

  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 description coverage is 0%, so the description must compensate, and it does explain the crucial optional parameter: omitting completed_step completes the current step, while passing it completes a named step and then searches for the next pending one. workflow_id is left implicit but its meaning is evident from the name.

  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 and resource: advancing a DeepSeek Harness workflow. It clearly conveys the tool's function but never names or contrasts with siblings such as create_harness_workflow or list_harness_workflows, so the agent must infer the routing from the resource name alone.

  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?

  It explains the two invocation modes driven by the optional completed_step argument, which is useful implied guidance. However, it says nothing about when to reach for this tool versus create_harness_workflow or the other workflow siblings, and no prerequisites or preconditions are given.

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

• find_related_technologiesA
  3.6/5.0
  Behavior3/5

  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 discloses the caching context (cache-miss fallback) and the return shape, which is useful, but says nothing about whether the call is read-only, latency/cost implications, or result limits beyond max_options.

  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-loads purpose in one line, then uses labeled Args/Returns blocks. Nothing is padded; the example for idea earns its place by clarifying expected input granularity.

  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 3-parameter tool with no output schema and no annotations, the Args/Returns documentation covers parameters and result fields adequately. The remaining gap is routing guidance against the many sibling tools, which is left unaddressed.

  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 description coverage is 0%, so the description must compensate, and it largely does: idea is explained with a concrete example, domain is given an effective value list (vision/audio/llm/iot/web/robot/data) acting as an informal enum, and max_options is defined as candidate count.

  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?

  Specific verb+resource: 'search/organize a list of related technologies' from a new idea. Clearly distinguishable from probe_technology_details (which goes deep on one technology), though it never names a sibling explicitly to sharpen the boundary.

  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 parenthetical '供缓存未命中时使用' (use when cache misses) gives a triggering condition, which is real usage guidance. However, it does not name alternatives (e.g., when to call probe_technology_details instead) or state exclusions, so it stays 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.

• probe_idea_questionA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and does most of it: it discloses the cache-miss precondition, that the tool performs technology search internally, and that the return contains question, options, and a cache_hit marker. It omits latency/cost and whether external network calls happen implicitly, so it is short of exhaustive but well beyond minimum.

  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 the core purpose, then workflow, args, and returns in clearly headed sections; every block is scannable. The Args/Returns sections restate some schema content and could be trimmed slightly, but there is no filler prose.

  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 4-parameter tool with no output schema and no annotations, the description supplies the calling prerequisites, the meaning of every argument, and the shape of the return value. The only meaningful gap is that nothing is said about failure modes or cost when the internal technology search is triggered.

  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 description coverage is 0%, so the description must compensate, and it documents all four parameters: idea, domain as an accuracy hint for built-in knowledge matching, search_results with a concrete example format, and max_options with a recommended 8-15 range for long multiple-choice. Only `idea` stays at a bare restatement of its name, which keeps this just under full credit.

  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: on a cache miss for a new idea, search related technologies and generate a long multiple-choice counter-question. That is concrete enough to separate it from siblings like find_related_technologies or probe_technology_details, though it never explicitly names them, so the differentiation is inferred rather than stated.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  A numbered workflow tells the agent exactly when to call this tool (cache/knowledge-base miss), when not to (cache hit), and what to pass in each case, including handing over already-performed external search results. Nothing about invocation timing 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.

• probe_technology_detailsA
  4.3/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses a non-obvious behavior — that selected_ids are auto-resolved to technology names from a cached prior question ('会自动尝试从刚才的提问缓存里转成技术名') — and describes the return shape (structured follow-ups plus a ready-to-read natural-language question). Auth/permission and failure behavior are not covered.

  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?

  Uses labeled Args/Returns sections and front-loads the core purpose, which aids scanning. Slightly verbose in the setup paragraph and the Returns block duplicates what Args already implies, but nothing is genuinely wasted.

  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 multi-step interactive tool with no annotations and no output schema, the description supplies the missing pieces: the pipeline position, each parameter's role, and the return format. An agent has enough to call it correctly, though edge cases (e.g. what happens when selected_ids cannot be resolved) are 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 description coverage is 0%, but the description documents all three parameters, including the tricky selected_ids semantics (comma-separated indices, auto-conversion from cache) and the relationship between selected_ids and selected_technologies. This compensates well for the empty 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?

  States a specific action (追问技术细节) on a specific resource (users' confirmed technologies) and explicitly positions itself as the second step of probe_idea_question, so an agent can distinguish it from that sibling without opening either schema. Concrete examples (YOLO 版本, MediaPipe API, 树莓派型号) make the intent unmistakable.

  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 a clear precondition ('用户确认了想了解/想用的技术后') and names the preceding alternative (probe_idea_question) as step one, so the sequencing is unambiguous. It does not spell out when this tool should be skipped, but the trigger condition is well defined.

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