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

Annotations already establish that this is a non-read-only, idempotent, non-destructive operation. The description usefully adds that files are placed in canon/ and ingested by the daemon, but it does not disclose overwrite behavior or what happens if the filename already 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?

The description is two sentences with no filler. The action and location are front-loaded, and the example list is compact while still conveying the range of acceptable canon material.

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

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

For a simple two-parameter write tool with annotations covering the safety profile, the description covers the where, what, and why. It does not mention overwrite semantics or return values, but these are minor gaps given the tool's simplicity and available schema/annotation 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?

Since the schema already documents both filename and content at 100% coverage, the baseline is 3. The description adds semantic value by explaining what kind of content belongs in canon (character sheets, maps, lore, style guides), which helps an agent populate the content parameter appropriately.

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

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

The description opens with a specific verb and resource: adding a reference document to the canon/ directory, and clarifies the daemon's ingest purpose. The canon/ location and reference-material examples distinguish it from sibling tools like add_note and the get_* tools.

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

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

The description implies usage by enumerating worldbuilding content types (character sheets, maps, lore, timelines, style guides) that belong in canon. However, it never explicitly contrasts this with add_note or states when not to use this tool, leaving the routing mostly implicit.

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

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

The description reveals that notes are not acted on immediately but are read by the daemon at scene boundaries, a meaningful behavioral detail beyond the annotations. It adds useful context about the mechanism and purpose without contradicting the readOnly/idempotent/destructive hints.

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 only two sentences long and front-loads the core action and mechanism first, followed by practical use cases. Every sentence adds value, and no filler or repetition exists.

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 low-complexity tool with two parameters, full schema coverage, and annotations already covering safety traits, the description provides all necessary context: what the tool does, how it behaves, and why it matters. No output schema is present, so the lack of return-value details is not a gap here.

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 both parameters are already documented in the input schema. The description reinforces the category meanings in prose but does not add new parameter-level semantics beyond what the schema provides, keeping this at the baseline for high coverage.

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 action ('Add a note') and a specific resource ('that the daemon reads at each scene boundary'), making the tool's function immediately clear. It also frames notes as the primary feedback mechanism, which positions this tool distinctly against siblings like add_canon.

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

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

The description gives clear practical contexts for use: steer the story, protect elements, flag concerns, or record observations. It does not explicitly name alternatives or exclusion criteria, but the usage guidance is strong enough to guide an agent on when this tool is appropriate.

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 mark the tool as read-only and idempotent, so the description only needs to add context. It adds that the log contains scene completions, reviews, and errors, and that lines are the most recent. It doesn't describe formatting, ordering, or empty-log behavior, but with annotations this is adequate.

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

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

Two sentences with no filler; the core action and scope are front-loaded in the first sentence. Every word earns its place.

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

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

For a single-optional-parameter read tool with safety annotations and no output schema, this description provides the resource, what it returns, and representative content types. Nothing critical 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?

The schema fully documents the only parameter ('Number of lines to return (default 20, max 200)'), and the description adds no parameter-specific semantics. Baseline 3 applies due to 100% schema description coverage.

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?

Description opens with 'Read the most recent lines from the daemon's activity log', naming a specific verb, resource, and temporal scope. It further distinguishes itself from sibling getters (get_progress, get_review_state, get_status) by naming the log and its content (scene completions, reviews, errors).

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?

No explicit when-to-use or alternative tools are mentioned. The description implies usage for inspecting recent daemon activity, but doesn't tell the agent when to prefer this over sibling getters like get_status or get_review_state. The content hint partially compensates.

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 provide readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful context — the source ('daemon's output') and the completion constraint — but discloses no further behavioral traits like error behavior for uncompleted chapters. This is consistent with annotations and adds a modest amount of value, matching the lowered bar.

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

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

A single nine-word sentence with the verb and resource front-loaded and zero filler. Every word contributes meaning; there is nothing to trim.

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

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

For a two-parameter, read-only tool with full schema documentation and safety annotations, the description plus schema covers everything needed to invoke it correctly. The only gap is the unspecified behavior when a requested chapter is not yet completed, a nuance that would round out the picture but is not critical.

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% for both required parameters (book and chapter), so the schema carries the full burden and the description need not add parameter detail. The description adds nothing about parameters, which is acceptable under the 100%-coverage 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?

The description uses a specific verb ('Read') and a specific resource ('a completed chapter'), which clearly identifies what the tool does. The 'completed' and 'daemon's output' qualifiers separate it from sibling read tools like get_premise, get_progress, and get_status, though it never names a sibling explicitly. It falls short of a 5 because it doesn't draw an explicit boundary against any sibling.

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

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

There is no when-to-use guidance, no exclusions, and no mention of alternatives despite seven similar get_* siblings. The word 'completed' weakly implies using the tool only after the daemon has finished a chapter, which prevents a 1, but an agent is left to infer all routing decisions on its own.

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 establish readOnlyHint and idempotentHint, and the description reinforces them with 'Read'. It adds behavioral context beyond annotations by identifying the exact files consulted and the role of the premise, though it doesn't describe edge cases like missing files or the exact return format.

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

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

Two short sentences, front-loaded with the core action and resource, followed by a useful one-line context sentence. No wasted words.

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 parameterless, read-only, idempotent tool with no output schema, the description is fully sufficient. It tells the agent what the tool reads, from where, and why the value matters.

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

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

The input schema has zero parameters and 100% schema coverage, so there is nothing left for the description to document. This is the baseline score for a parameterless tool.

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

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

States a specific action ('Read') and resource ('current story premise'), and names the source files (PROGRAM.md or soul.md). It clearly differentiates from the sibling set_premise by indicating this is the read counterpart.

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 clear context for when this tool matters: the premise seeds the daemon's creative direction. It does not explicitly name alternatives or exclusions, but 'Read' paired with set_premise as a sibling makes the usage obvious.

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 and idempotentHint, so the safety profile is covered. The description adds that the output is 'human-readable' and lists its contents, which is useful context beyond the annotations, though it does not disclose deeper behavioral details such as format quirks or failure modes.

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

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

The description is two short sentences with no filler. The main action is front-loaded, and the follow-up sentence provides concrete content details that earn their place.

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

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

For a zero-parameter, read-only tool with no output schema, this description is complete enough. It states the resource, the action, and the key contents of the returned summary, so an agent can correctly invoke and interpret 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?

The tool has zero parameters, so the description need not explain parameter meaning. The baseline of 4 applies because there is no parameter semantics gap to compensate for.

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

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

The description clearly states the resource ('progress summary') and the action ('Read'), and adds what the summary includes (story outline, word counts, chapter status). However, it does not explicitly differentiate this from sibling tools like get_status or get_activity, which could overlap in purpose.

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

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

There is no guidance about when to use this tool versus its siblings. The description simply says what the tool reads, but does not mention alternatives, exclusions, or conditions under which another tool would be more appropriate.

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 and idempotentHint=true, so the safety profile is covered. The description adds value by specifying that this returns the latest snapshot and enumerating its key fields, giving a clearer behavioral picture 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?

A single sentence that immediately names the action, the object, and the key contents. Every word earns its place, and no irrelevant detail is included.

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 parameterless read-only tool with annotations covering safety, this is nearly complete. The description conveys the scope of the returned snapshot; a minor gap is that it does not mention what happens if no snapshot exists yet, but that is not essential for basic 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?

There are zero parameters, so the input schema leaves nothing to document. The description does not need to add parameter-level semantics, and the baseline of 4 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 uses a specific verb ('Read') and a clearly defined resource ('latest review-state snapshot'), while naming the exact contents: daemon phase, word count, and accept rate. This makes the tool's purpose unambiguous and distinct from siblings like get_status or get_progress, which focus on different state.

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

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

No guidance is given on when to use this tool versus alternatives such as get_status, get_progress, or get_activity. The description implies it is for reading review state, but it does not clarify conditions or exclusions that would help an agent choose among the many get_* siblings.

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

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

The annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the 'orient yourself' ordering advice and names returned fields, but does not disclose additional behavioral details such as staleness, cost, or failure modes. 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?

Two short sentences convey the action, the key returned fields, and the recommended invocation timing. There is no filler; every sentence earns its place.

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

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

For a zero-parameter, read-only, idempotent status tool, the description is complete enough. It tells the agent what data the call returns and when to issue it, while the annotations cover side-effect safety. No output schema exists, but the listed fields provide adequate expectations.

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

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

The tool has zero parameters, so the description does not need to explain inputs. The baseline for a zero-parameter tool is 4, and the description appropriately focuses on what the status read returns rather than on parameter syntax.

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

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

The description clearly identifies the operation as reading the daemon's current status and names three concrete fields it returns: phase, word count, and accept rate. It does not explicitly differentiate this tool from overlapping siblings like get_progress or get_review_state, so it stops short of a perfect score.

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?

'Call this first to orient yourself' provides clear contextual guidance on when to invoke this tool at session start. It does not mention alternative tools or when not to use it, so it lacks explicit exclusion criteria.

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 and idempotentHint, so safety is covered. The description adds useful context about the durable nature of the registry and the meaningful categories of output (current work, queued, lifecycle), beyond what the annotation hints provide.

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

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

The description is compact and front-loaded with the primary action and resource, followed by one sentence that summarizes output content. Every sentence contributes meaningwith no repetition or 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 zero-parameter, read-only tool with no output schema, the description gives sufficient context: it names the resource and describes the general content of the result. It does not detail exact result fields, but the high-level output categories ('what's queued, lifecycle state') are 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?

The tool accepts zero parameters, so there is no parameter behavior for the description to clarify. The schema fully covers the empty parameter surface, and the description correctly implies a no-input read operation.

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?

Description states a clear verb ('Read') and a specific resource ('durable work target registry'), then elaborates what it reveals: daemon's current work, queued items, and lifecycle state. This gives a focused, non-tautological purpose and differsnciates it from generic status or activity tools.

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

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

The description gives clear context: use this when you need to inspect the durable work target registry and see what the daemon is working on, queued, and lifecycle state. It does not explicitly name sibling alternatives or provide when-not conditions, but the scope is clear enough for an agent to select it appropriately.

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 mark the operation as idempotent and non-destructive. The description adds valuable behavioral context beyond those hints: the pause is not instantaneous, it occurs at the next scene boundary, and the daemon actively checks for a pause signal between scenes. This is consistent with 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?

Two short sentences with the core action front-loaded and the mechanism in the second sentence. Every word earns its place, and there is no redundancy or 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 parameterless, idempotent, non-destructive tool with no output schema, this description is nearly complete: it states what will happen, when it will happen, and why. The only minor gap is no explicit pointer to the complementary 'resume' tool, but the sibling list already provides that 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?

The input schema has zero parameters, so there are no parameter semantics to clarify. Per the baseline for parameterless tools, the description does not need to compensate for missing parameter documentation, and it doesn't.

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

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

The description uses a specific verb ('Pause'), a clear resource ('the daemon'), and a precise condition ('at the next scene boundary'). It is immediately distinguishable from the sibling tool 'resume' by naming the complementary action.

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

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

The description clearly indicates this is for a graceful, boundary-aligned pause rather than an immediate stop: 'The daemon checks for a pause signal between scenes.' It does not explicitly name alternatives or conditions for not using it, but the intended timing and use case are clear.

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

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

Annotations already establish readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds the mechanism of removing the pause signal but does not disclose additional side effects, error behavior, or conditions beyond that.

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

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

The description is a single, front-loaded sentence with no filler. It states the action, the target, and the mechanism efficiently.

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

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

For a zero-parameter, annotation-covered control operation, the description is sufficiently complete: it names the target, the precondition, and the mechanism. It does not specify return values, but no output schema exists and this is a simple imperative action.

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

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

The input schema has no parameters, so parameter semantics are not applicable. With zero parameters, the baseline is 4, and the description provides enough context about what operation is being performed.

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 action ('Resume') and a specific resource ('a paused daemon'), and clarifies the mechanism ('removing the pause signal'). This clearly differentiates it from the sibling 'pause' tool.

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

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

The description implies the tool should be used when a daemon is paused, and the presence of the sibling 'pause' tool makes the contrast obvious. However, it does not explicitly state when not to use it or name alternative 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 flag destructive/idempotent/read-only-false behavior, and the description adds useful specifics: it overwrites any existing premise, is read by the daemon at startup, and affects both soul.md and PROGRAM.md. This goes beyond the annotation bits without 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?

Three sentences, all informative: core action, daemon/seeding context, and overwrite warning. No filler and the key verb-first statement is front-loaded.

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

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

For a simple one-parameter setter with annotations covering destructive/idempotent behavior, the description is sufficient: it explains effect, side-effect files, startup relevance, and the safe edit path. No output schema exists, so no return-value obligation.

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?

With 0% schema description coverage, the description must explain the single text parameter. It implies that text is the premise content ('write/overwrite the story premise'), but it never explicitly maps text to the new premise or mentions format/length constraints.

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

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

The description opens with a specific verb and resource: 'Write or overwrite the story premise as soul.md plus PROGRAM.md.' It also distinguishes the operation from get_premise by emphasizing replacement, so an agent can tell setter from getter.

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 clear situational guidance: overwrites any existing premise, so use get_premise first if you want to edit rather than replace. This explicitly names the alternative and the condition that selects it.

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