Server Quality Checklist

Tool Scores

• close_taskB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive 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?

  描述是一句简洁的中文句子，没有冗余信息，直接点明用途和时机。虽然简短，但信息密度高。

  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?

  工具较为简单，3个参数，无输出模式。描述提供了基本使用时机，但参数细节和副作用说明不足，对于代理正确调用已足够基础，但仍缺乏关键上下文。

  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描述覆盖率为0%，描述提到了'结果'和'待办'，对应outcome和next_actions，但未提及必填参数project。描述只补偿了部分参数，没有完整解释所有输入。

  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?

  描述明确了工具的使用时机（任务结束前）和目的（记录结果与待办），动作与资源清晰。虽然名字是close_task，描述没有直接说'关闭'，而是强调保存上下文，但仍然能与兄弟工具区分。

  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?

  明确规定了'每个任务结束前调用'，提供了具体的使用场景。虽然没有显式排除其他工具，但上下文足够清晰，暗示了与load_context的衔接关系。

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

• rememberB
  3.4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must disclose behavior. It reveals that only confirmed information should be saved and that unconfirmed data is not stored, which is useful. However, it doesn't explain what happens to existing entries with the same name or content (overwrite vs. append), or the persistence scope (session vs. long-term), which are important behavioral traits for a memory tool.

  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 concise sentence with a clear instruction followed by a critical constraint. It front-loads the purpose and gives a direct command. No wasted words, but the lack of structure (e.g., bullet points) is fine for a short description. The constraint is placed after the purpose, which is effective.

  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 tool with 4 parameters, no output schema, and no annotations, the description covers the core purpose and the key requirement (confirmed: true). It includes the enum values for 'type' implicitly, but leaves out details like how the tool handles duplicates, the nature of 'project' (optional?), and what the return value is. It's sufficient for basic use but lacks depth for edge cases.

  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. It explains the 'confirmed' parameter (must be true) and lists the possible 'type' values in the description, but doesn't clarify the meaning of 'content' or 'project'. The enum for 'type' is in the schema, but the description repeats it in natural language, adding some redundancy. The description adds value for 'confirmed' but not much for other parameters.

  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 states the tool stores long-term preferences, rules, decisions, facts, todos, or notes, with a specific requirement that they be user-confirmed. It distinguishes itself from siblings like load_context (retrieval) and record_experience (experience) by focusing on explicit user confirmations. However, it doesn't explicitly name the siblings, but the verb 'remember' and the listed content types provide sufficient clarity.

  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 when to use: when the user has explicitly confirmed a fact or preference, and warns not to save model speculation. It provides a clear condition (confirmed: true) but doesn't explicitly contrast with alternatives like 'record_experience' or 'update_project'. The context is implied rather than spelled out, so it's adequate but not explicit.

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

• update_projectA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description must shoulder the burden of behavioral transparency, but it only restates the basic action (update status, summary, next steps) without disclosing side effects, idempotency, or handling of omitted optional fields. It does not mention permissions, rate limits, or error behavior, leaving significant gaps for a mutation tool.

  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 a single, front-loaded sentence that states the action first and a usage condition second, with no redundant words. It is concise and well-structured.

  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?

  Given the tool's simplicity and lack of output schema, the description covers the core action and a usage trigger, but it does not explain behavior when optional parameters are omitted, inter-tool dependencies, or error conditions. It is minimally adequate but leaves room for more context.

  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's mention of 'status, summary, and next steps' helps map the generic parameter names (status, summary, next_actions) to domain concepts. However, it omits the 'project' parameter and does not clarify value formats or constraints, partially compensating for the schema's lack of detail.

  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 states the tool updates the current project's status, summary, and next steps, using a specific verb and resource. It does not explicitly differentiate from sibling tools, but the purpose is unambiguous and the usage hint adds clarity.

  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 provides a clear contextual condition: 'suitable to call when there is stable progress during a task.' This gives a when-to-use hint, though it does not list exclusions or alternative tools. The guidance is direct but lacks explicit comparison to siblings.

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

• load_contextA
  4.2/5.0
  Behavior4/5

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

  With no annotations present, the description carries the burden of behavioral disclosure. It clearly states that the tool reads existing stored context rather than modifying it ('读取'), and it enumerates the kinds of data returned: preferences, rules, project status, and confirmed memories. It does not detail failure modes or return formatting, but the core read-only behavior is 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 two short sentences with no wasted words. The mandatory call-time instruction is front-loaded, followed immediately by a compact list of what is loaded. Every clause contributes essential information.

  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 low-complexity tool with no required parameters and no output schema, the description covers when to call it, what it loads, and which optional parameter matters for project context. It does not explicitly describe the result format, but the 'loads context' semantics make the return behavior reasonably inferable.

  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%, so the baseline is 3. The description only loosely maps to the parameters ('关键词' to query and '指定项目' to project) and adds limited meaning beyond the schema, such as implying the project parameter is used to load project status. No additional syntax or filtering details are provided.

  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 identifies a specific action ('读取'/'loads') and a concrete resource: user long-term preferences, fixed rules, project status, and confirmed memories. It also states an explicit usage role ('must be called at the start of every task'), clearly separating it from the write-oriented sibling tools like remember and record_experience.

  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 explicit timing guidance: '每个任务开始时必须先调用' ('must be called first at the start of every task'). It does not explicitly discuss exclusions or alternatives, but the mandatory position and read-only nature make the intended usage clear relative to the sibling tools.

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

• record_experienceA
  4.7/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 that repeated calls for the same project+task overwrite the previous experience (update semantics), and it explicitly forbids recording sensitive data. It doesn't note failure modes or that calls may overwrite irreversibly, but the core behavioral traits are covered.

  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 dense sentence that front-loads the trigger conditions, then states the purpose, update behavior, and security constraint. No filler, every clause earns its place.

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

  Completeness5/5

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

  For a record/update tool with no output schema and 4 parameters (2 required), the description covers when to call, what it stores, update semantics, and prohibited content. The schema provides param types and descriptions; nothing essential is missing.

  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 covers 75% of params with descriptionscars (task, successful_workflow, problems_and_fixes have descriptions; only project lacks one). The description adds important semantics: it explains the update key (project + task) and warns not to include secrets, which meaningfully supplements the schema. Adequate value 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 states a specific verb (record), the resource (experience), and the exact trigger conditions (after problems with eventual success, or when validating a reusable workflow). It distinguishes itself from sibling tools like remember and update_project by framing a persistent, deduplicating experience store tied to task+project.

  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?

  Explicitly states when to call: after a task succeeds following problems, or upon first validating a reusable workflow. It also gives a negative rule (what not to record: secrets), which effectively tells the agent when NOT to use it. This is clear, actionable guidance without needing to read the siblings.

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