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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

With no annotations provided, the description carries the full burden. It discloses important behavioral traits: the dependency on prior verbatim capture, the requirement to write verbatim_refs, and the semantic shift for tier (now only represents record form, not API tier). This is substantial behavioral context for a create operation.

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

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

The description is compact, with key information front-loaded about the derived-record purpose. The tier explanation is dense but necessary. It earns its place, though it could be slightly more structured for readability.

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

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

For a 21-parameter create tool with no output schema and no annotations, the description covers the most critical preconditions (verbatim capture) and the ambiguous tier parameter. It doesn't explain all parameters, but the sibling tools and schema already provide structural context. The core call-critical constraints are well covered.

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

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

Schema coverage is only 5%, so description must compensate. The description explains the critical tier parameter semantics ('记录层 tier 仅表示记录形态，不再表示调用档位') and the verbatim_refs requirement, which are not self-evident from the schema. It also clarifies the salience range for light tier. This meaningfully adds value beyond the bare schema.

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

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

The description uses a specific verb ('创建派生记录' - create derived record) and resource, and differentiates it from capture tools by stating it creates derived records. However, it doesn't explicitly distinguish itself from sibling tools like personal_add_followup or personal_add_hypothesis, so it's clear but lacks sibling differentiation.

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

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

The description provides clear context: it must be used after a verbatim capture when the source is user-supplied, and specifies when to use tier=light vs full. However, it doesn't explicitly state when NOT to use this tool or name alternatives, leaving some room for inference.

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

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.

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.

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.

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.

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.

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.

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

The description discloses meaningful behavioral traits: it respects a capture gate, requires capture_id for normal reads, and maintenance=true performs an audited read-only fallback that does not write archives. However, it doesn't describe the response format, data freshness, or side effects of the tier=full re-declaration, so it is adequate but not comprehensive.

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

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

The description is dense but compact, delivering key behavioral rules in two sentences. It front-loads the main purpose and then explains the exception path. Some may find it dense, but each clause carries operational meaning; missing a short hint about the view param's role.

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

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

With no annotations and no output schema, the description covers operational preconditions, the fallback path, audit implications, and the post-read discipline, which is strong for a read tool. It doesn't explain the difference between view enum options or return format, but for a survey read operation the critical workflow context is present.

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

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

Schema description coverage is low (25%), and the description adds significant parameter semantics: it explains the capture_id precondition, the maintenance=true fallback's purpose, side effects (trace audit, no archive writing), and the requirement to later re-declare with tier=full. It does not explicitly explain the view enum values, but it contextualizes the key parameters well.

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

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

The description names the verb (读取/read) and the central resource (v2 全局勘察/global survey), distinguishing it as the read tool for the v2 global survey. It doesn't explicitly distinguish from siblings like personal_retrieve or personal_derivation_status, so it is clear about what it reads but not fully differentiated from all siblings.

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

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

The description gives explicit usage conditions: regular reads must first complete turn preflight capture and provide capture_id, and when footprint/strategy messages are blocked by the capture gate, maintenance=true can be used for read-only fallback. It implies when not to use it (when writing is needed, use capture/add_record), but doesn't name specific alternatives.

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

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the burden and does disclose important behavioral constraints: the precondition on linked records and the requirement to write a concrete reason, including citing the deduplication hit for zero additions. It does not disclose side effects, reversibility, or return/error behavior, so it remains incomplete for a finalizing 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.

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

Three short sentences carry the action, prerequisites, conditional requirements, and the call-time rule with no filler. The most actionable instruction ('must call before answering') is placed at the end but all content earns its place.

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

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

For a 3-parameter finalization tool with no output schema and no annotations, the description covers the required inputs, the enum branches, the conditional reason, and the sequencing rule. It is missing post-condition/effect details and a definition of 'bidirectional link record', but the provided instructions are sufficient for correct invocation in most cases.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the meaning of disposition by tying derived to the bidirectional-link precondition and no-derivation-needed to a specific written reason, and it spells out what the reason must contain in the zero-add case. capture_id is only implied as 'current', which is the main gap.

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

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

The description names a specific action ('close'/'finalize') on a specific resource ('current raw-quote capture derivation loop'), which is enough to distinguish it from sibling tools like add_record or validate. It loses a point because 'current' and 'derived loop' rely on context and no explicit contrast with sibling tools is given.

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

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

It states explicitly that the tool must be called before answering, and gives the precondition for derived (at least one bidirectional link) and the mandatory content for no-derivation-needed. It does not name alternative tools or when not to call, but the operational trigger is clear.

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

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

With no annotations provided, the description carries the full behavioral burden, and it does substantial work: it discloses a persistent side effect (turn receipt), capture expectations, footprint discipline (pre-write dedup, exactly one micro record, zero-new no-derivation), and deprecated-tier handling. It stops short of describing return values, errors, or downstream effects of invoking skip/full, so it is strong but not fully transparent.

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

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

The description is dense but purposeful, front-loading the core purpose before tier rules. Some long clause chains make parsing harder, but every sentence contributes policy or behavioral detail, and there is no filler.

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

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

The tool has no annotations and no output schema, and the domain is policy-heavy, so the description must do more. It thoroughly covers tier selection and capture discipline, but it omits the role of turn_id/conversation_id, what the tool returns, and what the agent should do after a full/skip result. An agent could select the tier but not confidently construct a complete invocation.

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

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

Schema coverage is only 25%; only tier is documented there. The description richly explains tier semantics and implies text is the current user message, but it never clarifies turn_id or conversation_id. Since those two parameters are undocumented in both schema and description, the low coverage gap is only partially compensated.

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

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

The description clearly identifies the tool as a mandatory content preflight for the current user message and states that it persists a turn receipt while requiring capture of personal materials. This is a specific verb+resource pairing that distinguishes it from sibling capture/retrieve tools, though it never explicitly names or compares itself to siblings like personal_capture_user_turn or personal_finalize_capture.

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

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

The description gives explicit when-to-call and when-not-to-call rules: full/auto for personal or activity-footprint turns, skip for technical/eating/shopping/zero-value turns, and light treated as deprecated. It does not name alternative tools, but for a gate/preflight tool the call/skip decision itself is the main usage guidance.

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

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 the closure action, requires a specific note, and states the ledger-existence precondition for capture_id, but it does not mention side effects, reversibility, permissions, or what happens after closure.

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

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

A single dense sentence packs the operation, enum meanings, field requirements, and an optional binding rule without filler. It is efficient and front-loaded, though slightly dense due to multiple clauses packed together.

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

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

Input semantics are well covered, including required fields and preconditions. However, with no output schema and no annotations, the description omits return behavior and broader operational consequences, which is a noticeable gap for a state-changing tool.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it defines the resolution enum semantics, clarifies that note must be specific, and explains capture_id binds an existing ledger capture. Only the id parameter is left unexplained, which is acceptable given its obvious role.

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

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

States a precise verb and resource: '关闭一条回访' (close a follow-up), and explains the distinct meanings of the three resolution values: answered, declined, and resolved. This clearly separates the tool from siblings like personal_add_followup and personal_finalize_capture.

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

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

Provides explicit conditions for each resolution choice ('answered 回访完成 / declined 用户不再跟进 / resolved ...'), so an agent knows which resolution to select in which scenario. It does not explicitly name sibling alternatives or say when not to use the tool, so it falls just short of a 5.

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

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

With no annotations, the description carries the behavioral burden. It discloses a critical non-obvious behavior: the tool refuses to read unless the current turn preflight capture is completed and capture_id is provided. It does not describe return values or other failure modes, but the key enforcement behavior is clearly surfaced.

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

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

The description is two compact sentences with no filler. The main purpose is front-loaded, and the prerequisite/refusal behavior follows immediately, making the critical information easy to parse.

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

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

For a 5-parameter tool with no output schema and no annotations, this description is incomplete. It captures the main precondition but leaves most parameter semantics, result shape, and relationship to the many sibling tools unaddressed, so an agent would still struggle to invoke it correctly.

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

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

Schema description coverage is only 20%, so the description must compensate for underdocumented parameters. It only gives meaningful context for capture_id; ids, query, and level remain effectively unexplained beyond their schema types/enums/defaults, leaving the agent unable to construct well-formed calls.

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

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

The description clearly states the action ('读取' / read) and the resource ('probe/deep'), and scopes the access by v2 events, entities, and scenario cards. It does not explicitly differentiate from sibling tools, but the phrasing makes its role as a retrieval step after preflight distinct enough.

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

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

The description gives explicit usage context: retrieval requires the current turn's preflight capture and a valid capture_id, otherwise the tool refuses. It lacks explicit when-not-to-use guidance or named alternatives, so it is one step below full routing guidance.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.