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

With no annotations, the description carries the full burden. It discloses that the entity acts autonomously and persists without intervention, but omits whether the call mutates state, what side effects occur, and whether the advancement is reversible or time-limited beyond the schema's default.

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 a clarifying parenthetical. Every word contributes to conveying the tool's concept, with no redundancy.

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 simple one-parameter advancement tool with no output schema, the description covers the core concept but leaves open what the tool returns or how world state changes. It is sufficient to select the tool but not to predict its effects.

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 100%, and the single parameter (seconds) is fully documented in the schema. The description adds no extra meaning, so a baseline 3 is appropriate.

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 clear verb (推进/advance) and resource (自主行为/autonomous behavior), adding that it decides based on drives. It does not distinguish itself from siblings like tick or intervene, but the core purpose is understandable.

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?

There is no explicit guidance on when to use this tool versus alternatives such as tick, event, or intervene. The parenthetical note that the entity survives even without player intervention hints at a condition but does not translate into actionable usage instructions.

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 full burden. It discloses that this mutates personality/emotion state and names the return payload (evolved snapshot + voiceHint/logicHint), but says nothing about persistence, permissions, or whether the evolution is reversible.

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?

Two short sentences that front-load the core action, then the trigger, then the return value. Every clause earns its place with 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 covers action, trigger, and return content, and there is no output schema requiring explanation. However, for a state-mutating tool with no annotations, it omits side-effect and scope details an agent would need to call 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 100%, so tags, text, importance, and drive_deltas are already documented in the schema, including the enum effect of importance=high. The description adds no parameter-level meaning beyond this, so the baseline 3 applies.

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 specific action and effect: feeding a memory event to drive personality/emotion evolution. An agent understands the core job, though the definition does not explicitly differentiate it from siblings like satisfy, intervene, or tick.

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?

"当本轮交互人格相关时调用" gives a clear triggering condition, but there is no mention of when NOT to use it or which sibling to prefer for adjacent needs (e.g. satisfy vs. event). Usage is implied rather than routed.

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 must carry the full behavioral burden. It discloses the output package contents and distribution context, but says nothing about whether files are overwritten, required permissions, side effects, or error behavior for what is clearly a generation/export 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 a single compact sentence with no filler, and it front-loads the core action and outputs. Every element 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 simple one-parameter export tool with no annotations and no output schema, the description conveys the essential purpose and artifacts. However, it remains incomplete regarding usage context and behavioral details such as overwrite semantics, which an agent would need for safe 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 description coverage is 100%, so the single parameter (target_dir) is already fully documented as the output directory defaulting to the current directory. The description adds no parameter-level detail beyond the schema, so the baseline score of 3 applies.

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 (导出/export) and names the exact resource and artifacts (SoulSpec v0.4 package with soul.json, SOUL.md, IDENTITY.md) plus the distribution target (ClawSouls). Sibling tools are all unrelated, so the purpose is unambiguous and easily distinguished.

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 states what the tool produces but gives no guidance on when to use it versus alternatives, no prerequisites, and no exclusion criteria. Usage is only faintly implied by the distribution phrase, but that is insufficient for an agent to decide confidently when to call this tool.

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 full burden. It discloses the default behavior ('不传则随机 baseline') and that it should be called once, but does not explain what happens on subsequent calls, whether it overwrites existing state, or auth requirements.

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?

Two concise clauses with no filler, front-loading the action and timing. Every sentence 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 single-optional-parameter initialization tool with no output schema and no annotations, the description covers purpose, timing, and parameter default. It is sufficient, though additional detail on idempotency would improve completeness.

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 100% and the ocean parameter is documented in the schema. The description adds value by explaining the optional nature and default random baseline when omitted, going beyond the schema's type definition.

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 specific verb '初始化' (initialize) and resource '人格态' (personality state), and clarifies scope with '首次装配人格时调用一次'. Does not explicitly differentiate from siblings like generate_soul or status.

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?

Explicitly says when to call: '首次装配人格时调用一次' (call once when first assembling personality). No alternatives or when-not conditions are given, 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, the description carries the full burden. It does disclose the key behavioral trait — that intervention can either support or oppose the target's drive — which is genuinely useful framing. However it says nothing about reversibility, persistence of the change, or what actually gets mutated, leaving substantial behavioral gaps.

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 front-loaded sentence with the verb first and two balanced clauses, no filler or redundancy. Its brevity is efficient, though it comes at the cost of the behavioral and parameter detail noted above.

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?

This is a state-mutating tool with no annotations and no output schema, so the description is the sole source of behavioral information. It omits what state is mutated, how the two directions map onto the given parameters, magnitude semantics for amount, and whether effects are reversible — too thin for a mutation tool at this complexity.

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 67%: text and amount carry descriptions, drive relies on a self-explanatory enum. The critical problem is that the description introduces a direction concept (顺/逆) for which no parameter exists — amount is a plain number and text is loosely '干预描述' — so the agent must guess whether direction is encoded via amount sign, text, or something else.

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 concrete action (人工干预) and qualifies it with two operational modes — 顺驱力 (reinforce the target's own drive) and 逆驱力 (push against its will) — which lets an agent grasp what the tool actually does. It never references any sibling tool (satisfy, event, tick), so differentiation is left to inference, capping it at 4.

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 parenthetical explains what each mode means, which implicitly helps an agent pick a direction, but there is no explicit when-to-use guidance, no prerequisites, and no mention of how this differs from satisfy or event for the same drive. Usage is implied rather than stated.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses almost nothing. It does not state that this mutates drive state, how satisfaction is applied, whether repeated calls compound, or what the effect ('闭环') actually means. The single parenthetical is suggestive but not informative.

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 one-line description is front-loaded and wastes no words, which is structurally sound. But the brevity here reflects under-specification rather than efficiency, so it earns only a middling mark.

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 state-mutating operation with no annotations, no output schema, and a 50%-covered parameter set, the description is too thin. An agent lacks the effect semantics, default behavior, and call-context it would need to invoke this 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 coverage is 50%: 'amount' is documented in the schema itself (0–1, default 0.3) while the 'drive' enum of Maslow-style values lacks a description. The description adds no meaning to either parameter and does not compensate for the undocumented enum.

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 verb '满足' (satisfy) plus the resource '驱力' (drive) give a clear action-object pair, so an agent can grasp the basic intent. However, the parenthetical '（闭环）' (closed loop) is unexplained, and nothing distinguishes this from siblings like intervene or event, which also plausibly affect internal state.

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?

There is no guidance on when to call this versus intervene, event, tick, or autostep, nor any precondition or exclusion. The agent must infer timing entirely from the sibling list.

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 full burden and discloses the read-only nature (读取), the exact returned state components, the presence of an injectable prompt fragment, and the intended re-injection behavior every round. It does not cover side effects or error handling, but for a zero-parameter read tool the behavioral profile is largely 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?

Two dense sentences, front-loading purpose and following with the usage rationale. Every phrase earns its place with 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?

No output schema exists, so the description must characterize the return; it names the identity components and the prompt fragment. It could specify format or type more precisely, but for a simple snapshot tool the description is nearly complete.

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?

Zero parameters, so the baseline is 4. The description does not need to explain parameters and adds no conflicting information.

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 clear read operation and names the exact content: compact identity state (OCEAN + dominant emotion + drive) plus an injectable prompt fragment. It does not explicitly distinguish this tool from siblings like status, but the resource is specific enough for an agent to select it.

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 provides a clear usage context: re-inject into the host prompt each round to resist compression amnesia. No alternatives or when-not conditions are named, but the operational cadence is explicit.

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 full behavioral burden. It says nothing about whether inspection is read-only, what 'status' actually contains, or whether it triggers side effects. 'For debugging' hints at a safe read but does not disclose behavior explicitly.

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 short sentence with no waste; the debug-use caveat is placed inline. Nothing to trim, though it is arguably under-specified rather than concise.

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?

There is no output schema, so the description should explain what the returned 'status' comprises. It does not, leaving the agent unable to anticipate the payload for a tool whose entire purpose is inspection.

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

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

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

The description states a verb+resource ('完整状态检视' – full status inspection), but because the tool is literally named 'status', this largely restates the name and is close to tautological. It adds only the qualifier '(调试用)' (for debugging). No distinction is drawn from siblings like snapshot or event, which may also surface state.

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 parenthetical '(调试用)' implies the tool is intended for debugging, which is a light usage cue. However, it gives no guidance on when to prefer this over snapshot or the other state-related siblings.

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 full burden, and it does disclose two behavioral effects: drives become naturally urgent and drift decays. It stops short of stating what else changes, whether the operation is reversible, or how concurrent/idle state is affected, leaving meaningful gaps for a state-mutating 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?

It is a single short line with no filler and the core idea is front-loaded. It is terse to the point of terseness being the risk, but as a conciseness judgment it is efficient.

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 output schema or annotations, the description must carry everything, and while it conveys the core effect it leaves unanswered what the return looks like and how the resulting state change interacts with sibling tools. Adequate for a single-param tool, but thin for a simulation-state mutation.

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 100% with a single optional 'seconds' parameter, so the schema already documents the input and the default. The description adds no syntax or semantics beyond it, making the baseline 3 appropriate.

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 operation (advancing time / a 'time-lapse heartbeat') and states its two effects (drives becoming naturally urgent and drift decaying), which is more than a tautology. However, the phrasing is domain jargon and it never distinguishes itself from closely related siblings like autostep or event, so an agent cannot easily tell which time-advancing tool to pick.

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 offers a trigger condition — 'call during idle/heartbeat' — which is real, if vague, usage guidance. It gives no exclusions and names no alternative, so the boundary with autostep/event/intervene is left to inference.

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