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

Adds substantial context beyond annotations: no model calls, exact return shape {approved, plan, instruction?}, the ARC_NOT_ACTIVE failure when no arc is active, and the STALE_VALIDATION_RECEIPT/status=clean_fail behavior when a new chapter was published after generation. Annotations only cover safety/idempotency, so this extra failure-mode disclosure is real value.

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?

Five tight sentences front-load the core action, then prerequisites, then failure modes, then return shape. No filler or restatement of the name; every sentence carries distinct operational 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?

With no output schema present, the description supplies the return contract and all the failure states (ARC_NOT_ACTIVE, clean_fail) an agent needs to interpret outcomes. Nothing required to invoke or react to this tool is missing.

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 schema already documents action, workId, and project fully, including the enum meanings and the feedback-loop guidance. The description adds outcome semantics (clean_fail) but no per-parameter syntax beyond what the schema provides, so 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 verb pair (승인/거절) and resource (아크 계획), and names its producer sibling lore_arc_plan so the agent knows where the input comes from. It is clearly distinguishable from the other *_decide siblings by the arc-specific scope.

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 to call it after the user has reviewed the plan and decided, states the downstream condition (an active arc is required for lore_write), and gives the reject path's next step: re-call lore_arc_plan with feedback. Both when-to-use and what-to-do-instead are covered.

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?

Annotations only say destructiveHint=true/readOnlyHint=false; the description goes far beyond by stating it unconditionally replaces the current plan (overwriting a pending plan at the same number and replacing an in-progress active arc with a next-numbered arc). It also discloses that status=needs_model will surface roughly three times during generation/quality/language validation, which is critical multi-turn behavior.

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?

Front-loaded with purpose, then preconditions, then replacement semantics and return shape. Every sentence carries load, though the single dense block is longer than strictly necessary and could be split for scannability.

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 complex, destructive, multi-turn planning tool with no output schema, the description covers preconditions, side effects, approval flow, expected needs_model cycles, and the return shape {plan(episodes, quality), needsApproval, instruction}. Nothing an agent needs to call it safely is missing.

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 schema already documents all six parameters (mode enum semantics, workId pattern, episodes range, feedback/direction usage). The description adds the unconditional-replacement behavior but no additional per-parameter meaning, 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 verb+resource with scope: generates the next arc's promise plus 3-20 episode beats, runs structural/quality validation, and writes .vibelore/arc-plan.json (with per-arc copies in .vibelore/arcs/). This clearly separates it from siblings lore_arc_status, lore_arc_review, and lore_arc_decide.

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 explicit invocation conditions ('call before lore_write once lore_arc_status confirms no active arc, or when an arc has ended') and an explicit exclusion ('do not call mid-arc'). It also names the required upstream artifacts (foundation, approved StoryProfile/StorySpine/WriterSkill) and references the sibling tool that gates it.

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 annotations covering mutation safety (readOnlyHint=false, destructiveHint=false), the description adds rich behavioral context: it overwrites .vibelore/experience-ledger.json, pattern-ledger.json, and arc-reviews/, does not modify the manuscript, and emits status=needs_model N+1 times. It also discloses error cases. This goes well beyond the annotations.

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 front-loaded: purpose first, then the lore_write relationship, then side effects, execution statuses, and errors. Every sentence contributes relevant information and none is redundant.

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 mutation tool with no output schema, the description covers the key gaps: what artifacts are overwritten, what is not changed, what status signals occur, and what inputs cause errors. An agent has enough to call it correctly in context.

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 schema already documents workId, project, and throughChapter, including the checkpoint rule for throughChapter. The description reinforces the checkpoint concept and error behavior but adds no syntax or format detail beyond the schema; 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 specific verb+resource: reread written chapters in the current arc and regenerate per-chapter PatternLedger and an arc quality review. It distinguishes the tool from the sibling lore_write by explaining that lore_write performs the same review automatically, making this optional. An agent can identify what this tool does without opening the schema.

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 explicitly says when to use this tool: only when manually updating or re-viewing reviews, because lore_write already does it at each checkpoint. It also gives error conditions (non-checkpoint chapter or chapter without body). No alternative-selection inference is needed.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description usefully adds the two possible response shapes and the null-currentEpisode signal. It does not, however, discuss failure modes such as a missing workId target.

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?

Front-loaded with the purpose, then the usage trigger, then the return shape. Dense but every sentence carries information, especially since there is no output schema to describe return values.

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, the description responsibly documents the return object and the null-currentEpisode handoff to lore_arc_plan. Coverage is strong for a read-only status tool; minor gaps remain around error/edge 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 100% with only two parameters, and the schema already documents workId format and project semantics. The description adds no parameter-level detail beyond what the schema provides, so 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 verb (read-only query) and resource (current arc plan), and explicitly names the sibling lore_arc_plan as the follow-up when currentEpisode is null. An agent can distinguish it from lore_arc_plan/lore_arc_decide without opening any schema.

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 explicit when-to-use (call first on receiving a writing request to check for an active arc) and a conditional routing rule (if currentEpisode is null, lore_arc_plan is needed). Both the trigger and the alternative are stated, not inferred.

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?

Goes well beyond the annotations: discloses the write target path, that lists and tracking objects are replaced wholesale (empty array = all on) while mergeRecords alone accumulates, that changes apply only from the next commit and never rewrite already-written episodes, and that no model calls occur. These are exactly the mutation semantics an agent needs.

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?

Dense but well ordered: read behavior first, then write trigger, then replacement/accumulation rules, then commit-scope caveat and no-model-call note. Every sentence carries information; only minor redundancy in restating defaults.

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 7-parameter dual-mode mutation tool with no output schema and no annotation detail, the description covers return shape (status ready|incomplete, missing, language/length contract), file target, persistence semantics, and temporal scope. An agent has everything needed to call 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 coverage is 100%, so parameters are already documented, yet the description adds real semantics: default all-on for tracking, replace-vs-accumulate behavior per parameter group, and the merge-from-query-result (mergeCandidates) workflow. This meaningfully exceeds the schema baseline of 3.

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+resource (작품 설정 조회/변경) and clearly explains the dual read/write nature: no-argument calls bundle StoryProfile·StorySpine·WriterSkill into a NarrativeContract. It does not differentiate itself from the sibling lore_status, which plausibly covers similar status territory, so it falls short of a 5.

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 splits behavior by invocation: no arguments = read-only contract, any of the five config keys = write to .vibelore/review-policy.json. That is clear when-to-use guidance, but no alternative sibling is named for the read path and no when-not-to-use exclusion is given.

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?

Annotations only cover the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false). The description adds substantial context beyond them: refusal-without-overwrite semantics, the pre-approval guard, the multi-turn validation loop that returns status=needs_model and requires repeated lore_resume calls, and the atomicity guarantee that no files are written until all validation completes.

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?

Front-loaded with purpose, then workflow, refusal modes, return shape, and the next step — every sentence carries distinct information and none is filler. It is dense and slightly run-on, but nothing can be cut without losing a fact an agent needs.

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 10-parameter, nested-object tool with no output schema, the description compensates by describing the success return shape ({created, genre, language, length, worldFacts, characters, entities}), the failure/interaction protocol, and the downstream step. Nothing material is missing for correct 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% and the schema descriptions are unusually detailed (genre precedence, length defaults, chapterWordCount legacy semantics and LENGTH_CONTRACT_CONFLICT), so the schema does the heavy lifting. The description only restates cross-parameter behavior ('genre만으로도 호출할 수 있다') that the schema already documents, adding little beyond the baseline.

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 and resource — 'automatically designs the foundation of a new work' — and enumerates the concrete artifacts produced (world facts, 3-5 cast members in characters/<id>.md, tracking entities, saved to world/setting.md and .vibelore/). It explicitly distinguishes itself from siblings by naming lore_init (manual settings) and lore_story_plan (next step), so an agent can route correctly without opening any schema.

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 the canonical call site (after lore_profile → lore_profile_decide(approve)), a fallback path (genre-only without a StoryProfile), and an explicit alternative (lore_init for hand-written settings). It also states two when-not conditions: refuses if a foundation already exists, and refuses if a StoryProfile exists but is unapproved.

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?

Goes well beyond the annotations by spelling out side effects per action: approve re-checks the inspection receipt and commits chapters/, summaries/, state and snapshot with status=completed; hold only records; reject ends the workflow without deleting the manuscript file. It also discloses the non-obvious approvalId lifecycle (a new id is issued each time the manuscript re-enters awaiting approval, so stale ids are rejected).

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?

Front-loads the trigger condition and the precondition before enumerating actions, and every sentence carries information. It is dense and somewhat long, but nothing is wasted padding.

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 five-parameter mutation tool with two booleans' worth of useful annotations and no output schema, this covers the decision semantics, the state transitions and the file-safety question an agent needs. Only the shape of the return payload is left unstated, which is minor given no output schema exists.

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%, so the baseline is 3, but the description adds real meaning beyond the schema: feedback is required for request_revision and merely recorded for reject, and approvalId is scoped to the immediately preceding awaiting_approval response with enforced freshness.

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 and resource: it applies a user decision to the manuscript that lore_write returned in guided mode with status=awaiting_approval. This scopes it away from the other *_decide siblings (profile/story/arc/webtoon), though it never names an alternative tool explicitly, so it falls just short of the top band.

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 precondition that doubles as a when-not: call only after showing the user the manuscript and advisory and receiving their answer. It also routes each action semantically (approve=commit, request_revision=fix per feedback, hold=retain, reject=discard and rewrite), but does not contrast with neighbouring decide tools.

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?

Annotations already declare idempotentHint=true and destructiveHint=false, so the safe-write profile is covered. The description adds genuine context beyond that: re-calling does not overwrite but returns adopted=true plus current state, and new works typically return status=needs_model requiring lore_resume before saving. That is useful but not rich enough to max out against annotations that already carry the safety semantics.

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?

Front-loads the core create/adopt purpose before alternatives and workflow caveats, and every sentence carries information. It is slightly dense across multiple clauses, but 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?

For a 7-parameter, no-output-schema tool, the description covers purpose, adoption semantics, sibling exclusivity, and the multi-step needs_model/lore_resume saving flow. An agent has everything needed to call it correctly and handle the response.

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 schema already documents genre examples and rejection behavior, povMode omniscient/multi-pov handling, language fallback, and project defaulting. The description adds no parameter-level detail beyond what the schema supplies, so baseline 3 is correct.

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 and resource with concrete artifacts (world/setting.md, empty chapters/summaries/characters dirs, .vibelore/foundation.json) and adds the adoption branch explicitly. It also names the sibling it is not (the lore_profile → lore_profile_decide → lore_create chain), so an agent can distinguish it without opening other schemas.

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 routes the agent: use the profile/decide/create chain for model-driven design, use this tool for an author-filled blank foundation, and notes lore_create rejects when a foundation exists so only one is used. Adds the needs_model → lore_resume follow-up flow, which no other field provides.

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?

Annotations flag a destructive write (readOnlyHint=false, destructiveHint=true), and the description goes well beyond them: every call regenerates and replaces the existing profile, an active profile reverts to pending and blocks later stages, status=needs_model occurs 1-3 times and nothing is saved until lore_resume answers, and language is locked after base generation. This is exactly the behavioral context an agent needs before calling a destructive 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?

Dense but front-loaded: purpose first, then return structure, then the hold/finalize workflow, then mutation and language-lock constraints. Several clauses are load-bearing, though the workflow explanation is somewhat compressed and could be ordered more cleanly.

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, the description still explains the return shape (designReview containing accumulated decisions and up to 5 open questions) and the needs_model/resume hold cycle, plus the downstream blocking behavior. An agent has enough to call it and handle the result 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 100%, so the schema already documents mode, brief, feedback, language, length, workId and project. The description reinforces the workflow meaning of feedback and the review/auto semantics but adds little that isn't already in the field descriptions, so 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 verb and resource: it compiles an interview brief into a StoryProfile and persists it to .vibelore/story-profile.json. It enumerates the profile dimensions (genre, reading contract, difficulty, momentum, POV, style, language, length), so an agent can distinguish it from siblings like lore_profile_decide and lore_profile_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?

Explicit routing: show open questions to the user, pass answers back as feedback and call again, then finalize via lore_profile_decide when no questions remain or the user approves. mode=review vs auto is tied to a clear condition (only when the user says 'just decide / don't ask').

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?

Adds substantial behavior beyond annotations: no model calls, an error when no profile exists, a side effect (the reading-difficulty contract is recorded with user confirmation), and the return shape {approved, profile, instruction?}. Annotations already cover the safety profile (non-readOnly, idempotent, non-destructive), so the description is doing useful extra work rather than contradicting them.

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?

Six short sentences, front-loaded with the decision semantics, then the approval precondition, side effect, error condition, return shape, and next steps. 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?

For a state-transition tool with no output schema, the description covers error behavior, return shape, side effects, and the follow-up workflow, while annotations cover the safety profile. Nothing an agent needs to invoke it correctly is missing.

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 action enum already explains approve=active and reject=rejected, so the schema carries the parameter burden. The description's '승인(active)하거나 거절(rejected)' merely restates that mapping without adding syntax or edge-case detail.

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 pair (approve/reject) acting on a named resource (the StoryProfile produced by lore_profile), and clearly separates this decision step from the creation step. An agent can distinguish it from siblings like lore_profile, lore_story_decide, and lore_writer_decide without opening schemas.

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 an explicit precondition for approval ('only when the user has explicitly accepted the design or there are no open questions') and names the next tools to run afterwards (lore_create when starting a new work, lore_story_plan when a base exists). The reject path's follow-up (re-call lore_profile with feedback) is documented in the action schema.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so 'read-only' is partly redundant. The description earns its keep by disclosing the actual response behavior: {profiled:false} when absent, and {profiled:true, profile(status: pending|active|rejected, designReview included), language, length} when present. No output schema exists, so this return-shape disclosure is genuinely additive.

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?

Four tight sentences with zero filler: purpose and read-only scope first, return shape second, usage condition third, sibling routing last. Every sentence carries distinct 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?

With no output schema, the description compensates by spelling out both return branches including the status enum and designReview inclusion. Combined with the explicit sibling routing, an agent has everything needed to select and 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 100%, with both workId and project documented in the schema itself. The description adds no format, defaulting, or path semantics beyond what the schema already states, so the baseline 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?

States a specific verb and resource: read-only lookup of StoryProfile only ('StoryProfile만 읽기 전용으로 조회한다'). It distinguishes itself from other status tools by naming lore_status and lore_configure as the tools for other concerns, so an agent can tell them apart without opening any schema.

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 states when to use it ('새 작품을 시작하기 전에 프로필이 필요한지 판단할 때') and routes to the correct alternatives with their conditions: lore_status for overall work progress, lore_configure for missing-config checks. Both the when and the when-not are present.

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?

Annotations declare destructive=true, idempotent=false, and the description confirms and extends this by disclosing the concrete side effects carried over (save/replace/commit) and the fact that re-execution uses the original arguments unchanged. It further discloses error behavior (empty answers or mismatched ids re-return the same requests), 24h runId expiry, deletion on completion, and what remains as the sole result if the agent stops. This is rich behavioral context well beyond the annotations, with no contradiction.

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?

Front-loads what the tool does and the answers format, then layers the operational caveats in logical order. It is dense and longer than typical, but each sentence introduces distinct information (resume point, arg immutability, side effects, multi-round, error handling, expiry, stop behavior), so little is wasted.

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 stateful resume tool with no output schema, the description covers the return/error protocol (same requests re-returned), the lifecycle (24h expiry, deletion on completion), the multi-round norm, and fallback discovery via lore_workflow_status. Nothing an agent needs to call or recover from this tool correctly appears missing.

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 baseline is 3; the description nonetheless adds meaning not in the schema, such as 'requests are mutually independent, so answer all at once', 'previously sent answers are stored, send only new questions', and 'jsonMode requests answer with pure JSON without code fences'. It adds above baseline but overlaps partially with the answers schema text.

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+resource: resumes a task halted with status=needs_model, from the halt point. It distinguishes itself from siblings by naming lore_write and lore_workflow_status and explaining the resume relationship. An agent can tell this apart from the many lore_* decision/plan tools without opening a schema.

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?

Explicit trigger condition (status=needs_model), clear when-to-use in multi-round flow ('여러 번 이어지는 것이 정상이다'), and gives an alternative for a related need (to change arguments, re-invoke the original tool). It also routes to lore_workflow_status to recover a lost runId. When/when-not and alternatives are all present.

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?

Although annotations already flag destructiveHint=true and idempotentHint=false, the description goes far beyond them: it enumerates what is deleted (world/, characters/, chapters/, summaries/), that in-progress workflows, pending lore_resume runIds and inspection receipts vanish, that later lore_configure/lore_style_anchor changes revert, that archives exist but have no restore tool, and that no model calls occur. This is exceptionally rich behavioral disclosure.

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 long but dense and front-loaded: purpose and usage lead, followed by destructive scope, recovery limitations, and return shape. Every sentence carries decision-relevant information, though the density is near the upper limit.

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 complex, irreversible mutation tool with no output schema, the description covers the trigger condition, prerequisite check, destruction scope, secondary side effects, recoverability limits, and the return shape. Nothing an agent needs to invoke it safely is missing.

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 schema already documents workId, chapter, and project. The description's framing of the chapter boundary ('manuscript up to that chapter remains, later ones disappear') largely restates the schema's chapter description, adding little new parameter-level detail. 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?

States a specific verb (rollback/restore) and resource (canon and machine state to a chapter's snapshot) and explicitly distinguishes itself from siblings by naming lore_snapshot_status and lore_sync. An agent can tell exactly what this does versus adjacent 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?

Gives an explicit precondition ('call only when the user has explicitly said to cancel already-committed chapters'), a mandatory first step (check target chapter with lore_snapshot_status), and an alternative for a different case (use lore_sync for manual edits). Nothing 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.

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely new context: snapshots are auto-created per commit under .vibelore/snapshots/<화>/ and are replaced when the same episode is re-committed. It also discloses the return payload shape, which matters since no output schema exists.

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?

Four short sentences, front-loaded with the action and followed by storage semantics, return shape, and the use case. Every sentence carries information, though the snapshot-storage sentence is slightly more detail than strictly needed to call the tool.

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 annotations covering the safety profile and no output schema, the description supplies the missing return shape ({snapshots:[화 번호 오름차순]}, no timestamps) and the pre-rollback use case. Nothing required for correct invocation is absent.

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 both parameters (workId, project) are documented in the schema itself. The description adds no syntax, default, or path-resolution detail beyond that, 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 verb (읽기 전용으로 조회한다) and resource (lore_rollback으로 되돌아갈 수 있는 화 번호 목록), and names the sibling tool it complements. An agent can separate it from lore_rollback (the mutating counterpart) and lore_status without opening either schema.

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 an explicit trigger: use it before rollback to verify the target episode exists, which implicitly routes the agent to lore_rollback for the actual mutation. It does not state any when-not condition or contrast with the broader lore_status, so it stops short of 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?

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so safety is covered; the description goes well beyond by enumerating the returned payload (화수, 다음 화 번호, 등장인물, 세계 사실 수, 미해결 떡밥, 아크 진행, StoryProfile 상태, workingTree) and by disclosing the non-obvious empty-state behavior ('작품이 없으면 오류 대신 initialized=false를 돌려준다'). It also explains that workingTree signals manual edits, which is behavioral context annotations cannot convey.

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?

Purpose and scope are front-loaded in the first sentence, followed by return contents, empty-state behavior, sibling routing, and the write precondition. Every sentence carries distinct information with no restatement of the tool name or schema.

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 must carry return-value semantics, and it does so by enumerating the fields returned and the initialized=false fallback. Combined with the routing and sync precondition, an agent has everything needed to call it correctly and act on the result.

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 both parameters (workId, project) are already documented in the schema, including the workId pattern and the project default. The description adds no syntax or format detail beyond that, so the baseline 3 is correct.

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 (조회/read) and resource (작품 전체 진행 요약) and immediately scopes it as read-only and Published-HEAD-based. It explicitly distinguishes itself from lore_workflow_status, lore_configure, and lore_*_status, so an agent can pick it apart from siblings without opening any schema.

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 explicit when-to-use routing for three adjacent tools ('진행 중인 한 화의 단계는 lore_workflow_status, 설정 누락 점검은 lore_configure, 개별 계획 내용은 lore_*_status로 본다') plus a preconditioned follow-up action (call lore_sync before writing when workingTree is not clean). Both the selection condition and the next step are stated, not implied.

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?

Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is partly covered. The description adds genuinely new context: no model invocation, an error when the StorySpine is absent, the return shape, and the fact that rejection does not delete files (consistent with destructiveHint=false). Missing explicit permission/auth requirements keeps it from a 5.

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?

Five short front-loaded sentences with zero filler; the core action leads and prerequisites, return, and next step follow in a natural reading order.

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 decision tool with no output schema, the description supplies the return shape ({approved, spine}), the error condition, the reversibility of reject, and the next workflow step — everything an agent needs to call 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 100%, with the enum and both required/optional params fully documented in the schema itself. The description adds no syntax or format detail beyond that, so the 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?

States a specific verb (approve/reject) and resource (StorySpine) and explicitly ties itself to the sibling that produced it (lore_story_plan). An agent can distinguish it from lore_arc_decide / lore_writer_decide without opening any schema.

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 the precondition ('call after the user views the StorySpine content and decides'), the failure mode (error if no StorySpine), the reject path (re-call lore_story_plan with feedback), and the follow-on step (lore_writer_skill). When-to-use, when-not, and alternatives are all covered.

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?

Annotations already flag destructiveHint=true and idempotentHint=false, and the description adds substantial beyond-schema behavior: the existing StorySpine is replaced with no history, review mode returns to pending and blocks later stages, roughly three needs_model rounds must be answered before saving, and validation failure aborts with an error and no save. The only gap is it does not quantify cost/latency of the multi-round model interaction beyond the round count.

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?

Front-loaded with the core action and artifacts, then ordering, then side effects and return shape. Every sentence carries distinct information, though the dense parentheticals make it read heavier than necessary.

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 supplies the return shape {spine (with quality), needsApproval}. Combined with prerequisites, ordering, destructive semantics, multi-round interaction, and failure behavior, an agent has everything needed 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 100%, so the baseline is 3. The description still adds meaning beyond the schema by explaining the downstream consequence of mode=review (downstream steps become blocked) and reinforcing the destructive replace semantics, which is not stated in the parameter's own description.

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 and resource (generate the whole-work StorySpine) and enumerates its scope (causal chain, character motivation, mid reinterpretation, cost of the final choice) plus the two artifacts it writes. It explicitly distinguishes itself from siblings by name: arc-level planning is lore_arc_plan's job.

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 explicit ordering (after lore_create, before lore_writer_skill), prerequisites (foundation plus an approved StoryProfile), and a named alternative for a different granularity (lore_arc_plan). It also explains the mode=review consequence of blocking downstream steps.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds value beyond them by disclosing the two return shapes ({planned:false} vs {planned:true, spine(...)}) and the status enum values pending|active|rejected. It does not mention error behavior or path resolution edge cases, so not a 5.

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, zero filler: scope/read-only nature first, return contract second, sibling routing last. Everything is front-loaded and every clause 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?

Although there is no output schema, the description itself documents both possible return shapes and the nested spine fields, and the sibling disambiguation covers the remaining ambiguity. Nothing an agent needs to call this correctly is missing.

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 workId's pattern/limits and project's default (server run directory) are already documented in the schema. The description adds no parameter-level detail, which is the correct baseline when the schema does the heavy lifting.

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 (읽기 전용으로 조회) and resource (StorySpine), and explicitly names the two sibling tools it is not (lore_arc_status for arc planning, lore_status for overall work progress). An agent can distinguish it from siblings without opening any schema.

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 routes adjacent questions to alternatives: arc planning goes to lore_arc_status and whole-work progress goes to lore_status. The condition selecting each alternative is stated, leaving nothing to 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?

Discloses rich behavioral details beyond annotations. It explicitly states that approve swaps the previous anchor in .vibelore/style-anchor.json, confirms no model calls are made, returns a specific object structure, and defines status=missing when no anchor exists. This is critical mutation context that annotations (idempotent, non-destructive) do not cover.

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?

Front-loads the core purpose, then systematically addresses behavioral restrictions, file side-effects, return values, and cross-tool integration without a single wasted sentence.

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?

Complete for a tool that mutates state and has no output schema. The description provides the return structure, the file mutated, the no-op conditions, and user intent requirements, leaving no ambiguity for the agent.

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%, so the schema already documents all parameters. The description adds critical semantic context by explicitly stating that action=status is the default (기본), which is helpful, but the rest of the parameter semantics are already handled by the schema descriptions.

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 dual-purpose verb set (승인한 정본을 문체 기준으로 고정하거나 조회) applied to a well-bounded resource. It clarifies the scope constraint (1~3화) and distinguishes itself from the concept of 'latest chapter' behavior.

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 tells the agent when NOT to use the tool's approve action by stating it does not automatically default to the latest chapter; approve should only be called when the user explicitly approves a specific chapter. It also references a sibling tool (lore_configure) for an alternative behavior.

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?

Annotations only state readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description goes well beyond: inspect writes nothing except the baseline fingerprint, approvalId is single-use, a post-validate file change yields STALE_SYNC_CANDIDATE, and whitespace-only edits are ignored. This is exactly the mutation-safety context annotations cannot express.

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?

Dense and front-loaded: purpose first, then trigger, then the three-stage flow with failure modes. Every sentence carries information, though the approval-flow paragraph is packed tightly enough to require a careful second read.

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 multi-stage, stateful mutation tool with no output schema and no idempotency guarantee, the description supplies the full lifecycle: prerequisites, stage semantics, approval token lifetime, and rejection conditions. An agent can drive the workflow end-to-end from this text alone.

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%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains what each action stage does behaviorally (inspect classifies only, validate issues approvalId, apply consumes it) and why approvalId expires. Only project path handling is left entirely to the 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 first sentence states a specific verb+resource: it reflects human-edited Markdown in world/·characters/·chapters/ into the canon after published HEAD. That scope is distinct from siblings like lore_write and lore_status, which the description explicitly positions itself against.

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 trigger (use when lore_status or lore_write reports working-tree drift/needs_sync, before writing) and an explicit exclusion (prior-chapter manual edits are not reflected; they must be reverted via rewrite_refold_required). The alternative routing to lore_resume on needs_model is also named.

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?

Annotations only say it is destructive and non-idempotent; the description goes much further, disclosing that approve writes/overwrites the project webtoon directory (profile.md, episodes/, references/) and publishes, that a downstream stage may return needs_model, that hold only records, and that reject terminates the workflow. It also states past approvals become unusable when the final file changes.

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 dense but front-loaded: deprecation and purpose lead, then per-action outcomes, then the precondition. The action/outcome sentences each carry weight, though the approval-ID discussion is somewhat compressed.

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 an 8-parameter destructive tool with a nested revisionTarget object and no output schema, the description covers outcomes, next-step routing, and the user-decision precondition well. It could still clarify the return payload shape and the STALE error conditions, which currently live only in the schema.

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 action enum, feedback, revision, approvalId and revisionTarget semantics are already documented. The description's per-action notes (hold/reject) largely restate what the schema says, adding only marginal cross-parameter context, so 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?

The description states a specific verb+resource: it resolves approval decisions for an in-progress per-cut webtoon workflow, and it names the sibling to use afterward (lore_webtoon_scene). The '[deprecated]' prefix muddies whether an agent should still call it, which keeps it from a 5.

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

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

It gives a precondition ('사용자 결정을 받은 뒤에만 호출한다') and a routing rule for after reject ('이후 작업은 lore_webtoon_scene으로 한다'). It does not contrast against the other *_decide siblings (lore_story_decide, lore_arc_decide, lore_writer_decide), so it stops short of explicit 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?

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description goes well beyond them: it discloses that mode=auto auto-passes approval gates and overwrites project webtoon/profile.md, that state lives in .vibelore/webtoon/, and that supplying direction/feedback/responses resets subsequent planning. It also surfaces domain-specific error outcomes (needs_format_support waiting state, no silent vertical fallback), which an agent cannot infer from structured fields.

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?

Front-loaded with the [deprecated] marker and the replacement tool, which is the most important routing signal. The remaining sentences are dense but each carries distinct information (gates, storage path, error states, reset behavior); it is information-rich rather than padded, though the multi-clause sentences are harder to scan than an ideal definition.

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 16-parameter, stateful, deprecated workflow tool with no output schema, the description covers storage location, approval-gate behavior, destructive overwrites, error codes, and reset semantics. The main omission is return/status reporting (e.g. what needs_interview/needs_model responses look like to the caller), but the core call-correctness information 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 100%, so the baseline is 3; the description adds cross-parameter behavior the schema does not encode, namely that direction/feedback/responses jointly force a return to the interview stage and invalidate downstream plan state. It also reinforces the deprecated workflowId/newWorkflow semantics, though per-field syntax is largely left to the 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 states a specific verb+resource ('진행 중인 컷별 작업의 인터뷰·각색 이어가기 전용') and immediately marks itself as deprecated while naming the replacement sibling lore_webtoon_scene. An agent can distinguish this continuation-only tool from lore_webtoon_scene, lore_webtoon_render, and lore_webtoon_decide without opening any schema.

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?

Explicit when-to-use (continuing in-progress per-cut interview/adaptation), explicit when-not (new work and newWorkflow are rejected with WEBTOON_PANEL_PATH_DEPRECATED), and names the correct alternative for new work. It also specifies the interview/direction-approval/adaptation/storyboard sequence the agent is expected to walk through.

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?

Annotations already declare non-readonly, non-idempotent, non-destructive. The description adds genuinely useful behavior beyond that: candidate files land in .vibelore/webtoon/ and only reach project webtoon/ after approval, API execution is host-side with separate billing, needs_image_runtime blocks execution, and lettering-only revisions are scoped by revisionTarget.kind=lettering. No contradiction with annotations.

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?

Front-loads the deprecation and the replacement sibling, which is good, but the remainder is a single dense paragraph mixing routing, billing, file paths, and per-parameter behavior without structure. Given 20 parameters some density is warranted, but it reads as a wall of text rather than organized guidance.

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 deprecated, 20-parameter, deeply nested tool with no output schema, the description covers the key flows (image request/lettering management, approval gating, host-executed API, retry/review handoff). It is complete enough to invoke safely, with the only gap being that most fine-grained semantics live in the schema.

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 schema already documents all 20 parameters; baseline is 3. The description reinforces a few (image choice continuity, lettering-only revision) but adds little syntax or format detail beyond the 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 opening states the scope precisely – '진행 중인 컷별 작업 마무리 전용' (dedicated to finishing in-progress per-cut work) – and names the sibling that handles new work (lore_webtoon_scene). The deprecation is front-loaded, so an agent can immediately tell this is not the tool for fresh jobs. It never quite names the core action as a verb+resource (render/lettering management is only implied).

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?

Explicit routing: new work → lore_webtoon_scene, lettering analysis/render review → needs_model → lore_resume, and candidate files only become real via lore_webtoon_decide approval. That covers when-to-use and several alternatives, though it doesn't enumerate all sibling relationships (lore_webtoon_plan, lore_webtoon_decide).

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?

Annotations only declare the mutation safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds far more: the server never calls the image API, the host must execute the OpenAI request and return it as an asset, state lives in .vibelore/webtoon/ and novel canon plus the project webtoon/ folder are untouched, and existing per-cut workflows are preserved.

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?

Long but densely packed and front-loaded with the core purpose before branching into checkpoints, state location, and error paths. For a 16-parameter workflow tool nearly every clause carries actionable information, though a few state/error details could be tightened.

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 and 16 parameters, the description carries the necessary burden: it describes the checkpoint protocol, the needs_* signals in both directions, error codes (WEBTOON_WORKFLOW_ACTIVE), the completion condition (status=completed), and side-effect boundaries. An agent has enough 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 coverage is 100%, so the baseline is 3. The description still adds flow-level meaning that the schema does not: the confirmImageChoice/feedback round-trip for billing approval, the reuse of an approved choice, and the autoRevisions redesign loop that emits new image requests and records failures in attempts.

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 (creates one image from a single novel scene, with dialogue in the work's original language) and lays out the full pipeline (원작→연출→검증→장면 이미지→시각 검토). It implicitly distinguishes itself from siblings lore_webtoon_plan and lore_webtoon_render by naming its exact scope and the discovery interview that must precede 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?

Explicit when-to-use and prerequisites: webtoon-discovery-interview must fix scope, style, references, panel count and image model first. It names alternative actions for a blocked state (revise/retry when start returns WEBTOON_WORKFLOW_ACTIVE) and routes model stages to lore_resume and missing panel count to needs_interview.

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?

Annotations already declare the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description isn't burdened there. It adds real behavioral context: the exact return shape, a response-size warning when includeModelExchanges=true, and the fact that replaced/archived workflows remain retrievable by id.

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?

Front-loaded with the core purpose, then the alternative, then the return shape, then the size caveat. Each sentence carries distinct, non-redundant information 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?

There is no output schema, yet the description supplies the return shape ({found, workflowId, events, modelExchanges?}), the alternative routing, the parameter caveats, and the archival lookup case. An agent has everything needed to call 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 coverage is 100%, so the schema carries most parameter meaning (baseline 3). The description adds value by explaining that workflowId can target replaced prior workflows and by reinforcing the includeModelExchanges side effect (large responses, ignored for webtoon scenes) beyond what the schema states.

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 and resource ('워크플로의 감사 이력... 조회한다') and enumerates exactly what the history contains (단계 전환·검토 발견·승인·커밋 이벤트). It explicitly distinguishes itself from the sibling lore_workflow_status, so an agent can route without opening a schema.

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?

Names the alternative (lore_workflow_status) and the exact condition that selects it ('현재 상태만 필요하면'). Also flags the when-not case for includeModelExchanges ('웹툰 장면 워크플로에서는 무시된다'), leaving little to 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?

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so safety is covered. The description adds real behavioral context beyond them: the concrete prose return shape {active, workflow, resume?}, that the manuscript body is excluded, the {active:false} no-workflow case, and the resume.runId handoff. It stops short of documenting pagination or the webtoon full-detail payload, keeping it at a strong 4.

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?

Front-loads the core action and then layers sibling-routing, return shapes, and lane behavior in short sentences. Dense but each sentence carries a distinct fact; slightly crowded but 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?

With no output schema, the description carries the full return-value burden and does so: it gives the prose shape, the empty-workflow shape, the body-exclusion note, the webtoon stage semantics, and the resume handoff. Nothing an agent needs to call or interpret it correctly is missing.

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 schema already documents workId, project, lane, detail, and workflowId. The description adds lane-specific return semantics (webtoon returns status as stage) but no format or syntax detail beyond the schema, 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?

Names a specific verb (읽기 전용으로 조회) and resource (진행 중인 한 화/웹툰 장면 워크플로의 단계·시도 횟수·다음 행동·품질 결과), and explicitly distinguishes three sibling tools by name. An agent can tell it apart from lore_status and lore_workflow_history without opening a schema.

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 routes the agent: overall work progress → lore_status, past events → lore_workflow_history, and waiting-for-model continuation → lore_resume via resume.runId. The when-to-use boundaries are stated rather than implied.

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?

Annotations already declare non-readOnly, non-idempotent, non-destructive, and the description adds real value beyond them: it never overwrites existing chapters, resumes in-progress workflows instead of duplicating, discloses retry caps (검사 최대 3회, 수정 최대 2회), and enumerates terminal statuses (completed, awaiting_approval, needs_model, needs_setup, needs_sync, clean_fail, validation_incomplete, provider_error). It does not, however, describe permission/auth requirements or side effects on chapters/ and summaries/ beyond 'commits', leaving some behavioral surface implied.

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 dense and long, but front-loaded with the core purpose and ordered pipeline, and nearly every sentence carries routing or state information rather than filler. The heavy status-code enumeration is justified by the multi-step, multi-tool workflow it governs, though it reads as a single packed block.

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 an 8-parameter, nested-object, no-output-schema tool that orchestrates a multi-step workflow, the description covers the full lifecycle, all handoff tools, and every terminal status an agent must branch on. Nothing needed to invoke or route the call correctly is missing.

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 schema already documents workId, project, autonomy, language, sharedOnce, modelProfile, and retryValidation; baseline is 3. The description nonetheless reinforces the autonomy semantics (guided=approval-then-commit vs auto=commit-on-pass) and warns that the value must be re-passed on follow-up calls, adding meaning beyond the field docs.

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?

It names a specific resource ('기본 집필 도구') and enumerates the ordered pipeline it runs (plan check → draft → semantic/logic checks → receipt → approval/commit), which an agent can distinguish from siblings like lore_webtoon_scene or lore_plan. It also states the scope constraint ('항상 마지막 화의 다음 화를 쓰며 기존 화를 덮어쓰지 않는다').

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?

Explicit routing rules: '소설을 이어 쓸 때는 이 도구만 호출한다', use lore_resume on needs_model, lore_sync on needs_sync, lore_decide on awaiting_approval, and it lists the exact needs_setup reason codes. When-to-use, when-not, and the alternative tool are all named.

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?

Annotations already declare non-read-only, non-destructive, idempotent. The description adds genuine context beyond them: no model invocation occurs, a missing WriterSkill raises an error, and the response is {approved, skill}. It does not cover the clean_fail side-effect path, so it stops short of a 5.

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?

Front-loads the core action, then adds only high-value clauses (no swap, no model calls, error condition, return shape, next step). No redundancy and nothing 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?

For a mutation decision tool with annotations and no output schema, the description covers error behavior, return shape, and workflow positioning. An agent has everything needed to call it correctly and route to the next step.

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 action enum's approve/reject semantics are fully described in the schema itself. The description names the action concept but adds no format or value detail beyond the schema, 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 verb pair (approve/reject) and the exact resource: the WriterSkill chosen by lore_writer_skill's audition. It names the sibling that produces the target and distinguishes the boundary ('no swap function'), so an agent can separate this from lore_writer_skill without opening either schema.

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?

Explicit about the disallowed path (no swapping candidates), the correct workaround (reject, then regenerate via lore_writer_skill with feedback), and the follow-on step after approval (lore_arc_plan). When-to-use and what-not-to-do are both 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?

Annotations declare destructiveHint=true and idempotentHint=false; the description goes further by stating that each call replaces the existing WriterSkill with no history and writes to .vibelore/writer-skill.json and world/writer-skill.md. It also discloses the ~3 status=needs_model round trips and the return payload, which annotations cannot express.

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 core action is front-loaded in the first sentence and each subsequent sentence carries distinct information (design intent, ordering, alternative, side effects, round trips, return shape). It is dense and slightly long, but nothing is padding.

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, the description supplies the return shape ({skill, candidates, needsApproval}), the destructive save behavior, the model-status round trips, and placement in the workflow. Nothing an agent needs to invoke this correctly is missing.

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 schema already documents workId, project, feedback and the mode enum with its review/auto semantics. The description adds no parameter-level detail beyond that, 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?

The description names a specific verb and resource (generate 3 candidate WriterSkills and have a judging model select one) and explicitly contrasts itself with lore_style_anchor. An agent can distinguish this tool from its siblings without opening any schema.

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 sequencing (after lore_story_decide(approve), before lore_arc_plan), states prerequisites (base plus approved StorySpine), and names the alternative it is NOT (lore_style_anchor). This is exactly the routing information an agent needs to pick correctly.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the exact branching of the response on whether a WriterSkill exists, the pending|active|rejected status domain, and the presence of candidate/addition-audition data. It stops short of describing failure or empty-candidate cases.

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?

Compact and front-loaded: the read-only nature, the two return branches, the usage trigger, and sibling routing all appear in a few dense sentences with no filler. The return-shape clause is notation-heavy but each element carries 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?

There is no output schema, so the description is right to encode the return shape itself, and it does so at a useful level of detail. Combined with 100% schema coverage on the two inputs and full annotation coverage, the definition is nearly self-sufficient; only error/empty edge cases are unaddressed.

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% — both workId (pattern, length, single-work-per-directory) and project (absolute path, defaults to server CWD) are fully documented in the schema. The description adds no parameter-level meaning, 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 verb and resource (read-only query of WriterSkill) and goes further by spelling out the two possible return shapes ({planned:false} vs {planned:true, skill(status, candidates, audition prose/scores)}). An agent can distinguish it from lore_writer_decide, lore_writer_skill, and lore_status without opening any schema.

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 gives the trigger condition ('사용자에게 오디션 결과를 보여 줄 때 쓴다') and routes to alternatives for adjacent needs: lore_style_anchor for style anchors and lore_status for overall work progress. It does not, however, name lore_writer_decide as the write counterpart of this read, nor state a when-not condition.

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