Server Quality Checklist

Tool Scores

• personal_add_recordB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the prerequisite about verbatim captures, but it does not describe the creation semantics, required effects, permission needs, reversibility, or what happens when the source is not a user supplement.

  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 focused sentence with no filler, and the key prerequisite is placed in the second clause. It is compact, though it may be too terse given the tool's 20 parameters and no annotations.

  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?

  A 20-parameter creation tool with no annotations, no output schema, and no sibling differentiation needs far more context. The description only covers one conditional path and leaves the meaning of most fields and the overall derived-record workflow unexplained.

  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 only adds meaning for verbatim_refs through the prerequisite instruction. The other 19 parameters, including required fields like id, kind, and summary, receive no conceptual explanation in the 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?

  The description states a clear action and resource: '创建派生记录' (create derived record). It distinguishes the 'derived' nature of the record, which hints at its role among siblings, though it does not explicitly contrast with personal_add_followup or personal_add_hypothesis.

  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 concrete usage condition: if the source is a supplement from the current user, a verbatim capture must exist first and verbatim_refs must be set. This is clear context for a specific scenario, but it does not give exclusions or alternatives.

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

• personal_preflight_turnB
  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 behavioral burden. It does disclose meaningful behavior: it persists a turn receipt and enforces capture of personal data across request forms. It does not explain side effects beyond persistence, failure modes, or whether it blocks or merely flags content, so transparency is only 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 compact and front-loaded, with two sentences that each add information: what the tool is and what it forces. It is appropriately sized, though the phrasing is somewhat dense.

  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?

  The tool has no output schema or annotations, and the description omits parameter semantics and the relationship to sibling tools. It explains purpose and a key behavior, but an agent would still be uncertain about how to fill the required fields and what will happen after the call.

  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 explain the parameters. It only implies that 'text' is the current user message and never addresses 'turn_id' or 'conversation_id'. This leaves most parameter meaning to inference.

  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 concrete function: a mandatory content preflight for the current user message, and it adds that it persists a turn receipt and enforces capture of personal categories. This distinguishes it from sibling capture tools even though it does not name one directly.

  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 word 'mandatory' and the statement that capture is required even when the request is polishing/summarizing/image viewing give some guidance on when to use it. However, it does not explicitly contrast this with siblings like personal_capture_user_turn or personal_finalize_capture, leaving the exact pipeline placement implied.

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

• personal_add_followupB
  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 burden of behavioral disclosure. It does reveal that the tool registers follow-ups with context and that due items are later checked by a Personal Understanding Skill, which is useful. It does not describe mutation effects, duplicate handling, idempotency, or what happens when due_at is null, but the core persistence-and-check behavior is present.

  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 with no filler. It states the action first and then the relevant follow-up behavior, making it easy for an agent to scan.

  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 seven-parameter write operation with no annotations, no output schema, and no parameter descriptions, this is under-specified. The agent would still need to infer the meaning of several parameters and operational details such as return behavior and due handling.

  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 for seven undocumented parameters. It only alludes to context and due behavior; id, due_rule, priority, and source_refs remain semantically unexplained. One sentence is insufficient to replace absent parameter documentation.

  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 centers on registering a pending follow-up/revisit and adds the lifecycle behavior that it will be actively checked when due. This is specific enough to differentiate its core purpose, though it does not explicitly distinguish it from personal_add_record or other personal_* write tools.

  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 phrase '登记有上下文的待回访问题' implies the tool is for storing context-carrying follow-ups rather than immediate actions, and the due-check behavior gives a signal about when it applies. However, it provides no explicit when-to-use versus alternatives such as personal_add_record or personal_add_feedback.

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

• personal_session_checkB
  3.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 burden and does reveal meaningful behavior: it is a blocking gate, and missing capture or finalize causes failure. It also enumerates what is checked. However, it does not disclose whether the tool is read-only, what warnings mean, whether allow_warnings can bypass failures, or what the response shape looks like.

  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 compact and front-loads the purpose before listing the main failure condition. The dense jargon ('closed loop', 'v2 completeness') slightly hurts comprehensibility, but the structure is efficient and every clause adds information.

  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 two-parameter check with no annotations and no output schema, the description is too thin. It omits allow_warnings semantics, response/error behavior, and any routing guidance against sibling validation tools. An agent would need to infer several important details before calling 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 description coverage is 0%, so the description must compensate. It explains that turn_id is required for personal turns, but it says nothing about allow_warnings, its default, its effect, or the format/expected values of turn_id. Half the parameter surface is effectively 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 clearly identifies the tool as a hard pre-answer gate and lists the dimensions it checks: turn receipt, capture closed loop, structure, and v2 completeness. This goes beyond the bare name and distinguishes it from capture/finalize operations. However, 'v2 completeness' is left unexplained and no explicit verb such as 'validate' or 'check' appears.

  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 gives an explicit use window: run this before answering or claiming the profile has been updated. It also states a hard requirement for personal turns: turn_id must be supplied. It does not mention when not to use it or how it compares with siblings like personal_preflight_turn or personal_validate, but the context is clear.

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

• personal_finalize_captureA
  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 burden of behavioral disclosure. It reveals key constraints (precondition for 'derived', reason requirement for 'no-derivation-needed', and mandatory invocation), but omits side effects, idempotency, or error behavior. This is a moderate disclosure given the tool's mutation-like nature.

  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 brief sentence that front-loads the core purpose and the critical usage constraint. There is no wasted text; every clause conveys necessary information.

  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 3-parameter tool with no output schema and no annotations, the description covers the main workflow constraints (preconditions, mandatory call) but leaves out error conditions and the response format. It is adequate for a simple finalization action but not fully comprehensive.

  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 explains the meaning of the disposition enum values ('derived' and 'no-derivation-needed') and the reason requirement, but does not explicitly describe capture_id (though it is inferable from context). It adds some value but not full compensation for all 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 states a specific action (closing the derivation loop) and the resource (current verbatim capture), and distinguishes itself from siblings by being the finalization step required before answering. It is clear enough but uses jargon ('派生闭环') that might be less explicit than 'finalize'.

  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 explicitly says '必须调用' before answering, providing a clear trigger for use. However, it does not list alternatives or conditions when this tool should not be used, leaving the choice among siblings to inference.

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

• personal_validateA
  3.5/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 well: it discloses that the operation is read-only, that it distinguishes failure/warning/clean, and that by default all captures must have completed derivation closure. This goes beyond a generic 'validate' statement and gives an agent useful behavioral expectations.

  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 short, front-loaded with purpose, and every sentence adds distinct value: validation scope, result categories, default behavior, and read-only safety. There is no 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?

  The description adequately covers the tool's purpose, output categories, default behavior, and read-only nature. However, given that the only parameter 'strict' is entirely undocumented in both schema and description, the definition is not fully complete for an agent to invoke it with full confidence.

  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?

  The schema has one boolean parameter, 'strict', with no description and 0% schema description coverage. The description does not explain what 'strict' does or how it interacts with the default derivation-closure requirement, leaving the agent to guess whether setting strict to true relaxes or tightens validation.

  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 ('校验' / validate) and a clear resource ('v2 结构' / v2 structure), and it clarifies the output categories of failure, warning, and clean. It does not explicitly differentiate from siblings by name, but the validate action is distinct enough among the listed siblings.

  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 conveys that this tool is for validating the v2 structure and implies it should be used when such validation is needed. However, it does not explicitly state when to use this over siblings, nor does it provide exclusions or alternative tool guidance.

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

• personal_add_hypothesisA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It usefully discloses that items are stored as 'candidate' by default and must not be presented as facts. However, it does not mention persistence behavior, side effects, idempotency, validation, or what happens after creation.

  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 very short, front-loaded, and contains no filler. Both clauses earn their place, though for a 9-parameter tool with no parameter documentation, the terseness leaves out important 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?

  Given the tool's complexity, the absence of annotations and output schema, and the presence of similar sibling tools, the description is not complete enough. It omits return behavior, required parameter guidance, relationship to other add tools, and any operational constraints beyond the candidate/fact distinction.

  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 does not explain any of the 9 parameters, such as id, claim, mechanism, confidence, or source_refs. It only conveys the overall object type ('candidate causal explanation'), so an agent gets little help with parameter-level semantics.

  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 resource: '登记候选因果解释' (register candidate causal explanation). It also explicitly contrasts hypotheses with facts via '不得冒充事实', which differentiates this tool from fact-recording siblings like personal_add_record.

  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 clearly indicates this tool is for candidate causal explanations and should not be used for established facts. It provides a clear when-to-use context, though it does not explicitly name alternative sibling tools or spell out when to choose them.

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

• personal_catalogA
  3.6/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 behavioral disclosure burden. It discloses a key behavior: the tool refuses to read when the precondition/capture_id is missing, and '读取' indicates a read-only operation. It does not cover output format or error details, but the refusal condition is meaningful.

  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 filler. The first sentence states the operation, and the second states the prerequisite and refusal behavior, keeping the most important usage constraint front-loaded and concise.

  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?

  Given no annotations, no output schema, and 0% parameter schema descriptions, this description is the only guidance an agent has. It includes a crucial prerequisite but omits the meaning of the view and query parameters, and does not describe what the returned survey data contains. This leaves the agent unable to make informed choices about non-required parameters or expected outputs.

  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 for parameter meaning. It explains that capture_id must be provided from the preflight capture, but says nothing about view (survey/routing/full) or query. With one of three parameters explained, the description only partially compensates for the missing schema documentation.

  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 uses a specific verb ('读取') and a specific resource ('v2 全局勘察'), so the agent knows this is a read/catalog operation. It does not explicitly distinguish from siblings like personal_retrieve, but the resource and precondition narrow the purpose enough.

  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 clearly states when the tool is usable: only after the current turn's preflight capture is complete and a capture_id is provided; otherwise it refuses. However, it does not name alternative tools or state when to prefer a sibling tool for other kinds of retrieval.

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

• personal_add_feedbackA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It discloses that feedback is informal and inferred from user reaction rather than formal scoring, and it names the outcome categories. However, it does not state whether this creates or updates a record, how identifiers should be supplied, or any 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.

  Conciseness5/5

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

  A single compact sentence that front-loads the purpose and ends with a clarifying exclusion. Every part earns its place; no redundant phrasing.

  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?

  Given 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is not sufficient for correct invocation. It lacks details on feedback_id and capture_id provenance and on how the record is stored or returned.

  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 adds meaning for outcome and memory_ids ('用了哪些记忆'), but it leaves the required feedback_id unexplained and does not clarify note or capture_id. An agent cannot reliably know what values to provide.

  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 clearly states the tool records the effect of an answer that relied on personal memory, listing what is recorded (used memories and user reaction) and the outcome categories. This is specific and distinguishes it from sibling tools like personal_add_record or personal_add_followup.

  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 context is clear: use after a memory-dependent answer when the user's reaction indicates helpful, missed, or corrected. It also explicitly excludes formal rating/scoring. It doesn't name alternative siblings, but the intended scenario is unambiguous.

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

• personal_retrieveA
  3.7/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 burden. It does disclose a critical behavioral constraint: it will refuse to read unless capture_id is provided, which is valuable. It does not disclose whether the operation is purely read-only, any side effects, or what the response contains, so some transparency gaps remain.

  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 sentence with high information density. The critical precondition is front-loaded, and every clause adds essential information: the data scope, the level, and the mandatory capture_id. There is no filler or repetition.

  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?

  Given the lack of input schema descriptions, output schema, and annotations, the description leaves important gaps: the meaning of 'ids' and 'query', the expected return structure, and any additional constraints. The tool has 4 parameters and 11 sibling tools, so the description alone is not enough for an agent to confidently invoke it without further inference.

  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 for undocumented parameters. It does mention capture_id (required) and implicitly 'probe/deep' maps to the level enum, but it gives no explanation for the 'ids' and 'query' parameters. Therefore, it only partially compensates for the schema's lack of descriptions.

  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 clearly identifies a specific verb '读取' (read) and a specific resource ('probe/deep'), and it maps directly to the tool name personal_retrieve. It also distinguishes itself from sibling tools by stating the required precondition (preflight capture + capture_id) and the data scope (v2 events, entities, situation cards). No other sibling tool is described as reading probe/deep in this manner.

  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 context on when the tool can be used: after completing the current turn's preflight capture, and with a valid capture_id. It also states the when-not: without the capture_id it will refuse to read. However, it does not explicitly mention any alternative sibling tools or direct the agent to a different tool for other retrieval scenarios.

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

• personal_derivation_statusA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It conveys read-only intent via '读取' and names the checks it performs, which is useful. But it does not explicitly state that the call is side-effect-free or describe what kind of result the agent should expect beyond the named status categories.

  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 concise, front-loaded sentence with no filler. The action, object, and specific checks all fit in a compact line.

  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 zero-parameter, read-only status tool with no output schema, the description covers what the tool does and what it checks, which is sufficient to call it correctly. It could be slightly more explicit about return shape or prerequisites, but the low complexity makes that gap minor.

  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 has zero parameters, so there is no parameter documentation burden. The description adds value by naming the dimensions ('pending, orphaned captures, link drift') that the no-arg call will report on, going beyond the empty input 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 opens with a specific action ('读取', read) and a clear resource ('capture→records 闭环状态'), then lists the exact conditions checked: pending, orphaned captures, and link drift. This distinguishes it from sibling write/capture tools, which perform mutations rather than status inspection.

  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 intended usage is implied: call this tool to inspect the capture-to-records closure status and detect pending/orphaned/link-drift issues. However, the description does not explicitly say when to prefer it over alternatives like personal_validate or personal_session_check, nor does it provide exclusions.

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

• personal_capture_user_turnA
  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 behavioral disclosure burden. It discloses that writes are conditional on a passing preflight and that the tool rejects writes otherwise, plus the post-capture requirement to derive and finalize. It does not cover return values or idempotency, but for a narrow capture tool the key behaviors are stated.

  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 filler. The core purpose is front-loaded, and every clause adds either a precondition, a behavior, or a follow-up requirement.

  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 six parameters, no output schema, and no annotations, the description provides the essential workflow guards but leaves parameter semantics and return/error behavior to inference. It is sufficient for an agent familiar with the domain, but not fully self-contained for a generic caller.

  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, but it only loosely alludes to 'complete user message' (text) and 'turn receipt' (turn_id/capture_id). The optional parameters captured_at, message_kind, and conversation_id are entirely unexplained, leaving the agent to infer their meaning from names alone.

  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: bind a pre-assessed personal turn receipt and save the full user message verbatim. It also clearly distinguishes the tool's role by referencing the preflight prerequisite and the required derive/finalize follow-up, placing it in an unambiguous pipeline.

  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?

  It gives explicit when-not-to-use conditions: if there is no preflight or preflight marks the turn non-personal, writes are refused. It also states that after capture, derivation and finalization are mandatory, effectively instructing the agent on the required next steps within the sibling toolset.

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