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

The annotations confirm the mutation, but the description adds real context: acks bump the femboy://progress and femboy://state resources, so other windows stop drawing the same celebration twice. It also states the expiry fallback, which no structured field conveys. This is exactly the kind of side effect an agent needs before calling.

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, with the action front-loaded and every sentence carrying distinct information: the operation, the side effects, and the fallback. Nothing 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?

This covers what an agent needs for a 2-param, 0-required mutation: the action, the side effects, the expiry safety net, and the idempotent annotation. It could say what happens when toast_id is unknown or already expired, but the missing detail is small, and no output schema is needed.

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 both toast_id and all, including the default and the omit-or-all behavior. The description mentions removing 'an achievement popup' but adds no syntax or format over what the schema provides. The baseline of 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?

The description states a specific verb and resource: removing an achievement popup from the rail. No sibling among the femboy_* tools touches toasts, so the scope is naturally unambiguous. An agent can tell exactly what this call accomplishes.

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?

Timing is clear: ack after the status line displays the toast. It also explains that acks are optional because toasts expire, so a client that skips this is never stuck. That is useful when-not guidance. It loses a point only because it names no alternative tool and gives no ordering prerequisites for the all=true case.

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 and closed-world, so safety is covered. The description adds that output mirrors notification _meta, but says nothing about journal retention, truncation when limit caps results, or ordering — gaps that matter for a replay 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?

Two sentences, zero waste, with the core action front-loaded and the audience/use case and return shape following. Nothing repeats the name or title.

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, and the description does summarize the return (revisions plus touched keys, matching _meta). With annotations covering safety and full schema coverage, only the limit/truncation and stale-revision behavior remain unstated.

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 both uri and since_revision are documented in the schema itself. The description's "differential" framing reinforces since_revision's semantics but adds no syntax, default, or edge-case detail (e.g. an expired revision) 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?

States a specific verb and resource: "Replay the differential change journal for a resource," and clarifies the payload shape. It does not name any sibling (e.g. femboy_recall or femboy_ack_toast) to distinguish itself, but the read-only journal replay purpose is unambiguous.

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?

"for a client that was offline and missed notifications" gives a concrete triggering scenario for when to use this tool. It offers no explicit exclusions or named alternatives, so the agent must infer that live-state reads should go elsewhere.

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 this is a non-read-only, non-idempotent, non-destructive write. The description adds real behavioral context: it logs the confession, reacts, writes a diary entry, asks exactly one socratic question back, and awards an achievement for slow or multi-question resolutions. It also discloses the return style (a question comes back) despite there being no output schema.

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 compact sentences, front-loaded with the core action and its limitation, then the update path, then reward mechanics. The achievement/accessory sentence is flavor-heavy but does encode a real trigger condition, so it earns most of its space.

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

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

Given a mutation tool with no output schema, the description covers purpose, both call modes, key side effects, and even the achievement trigger. It leaves some gaps (what the response looks like beyond the socratic question, how 'abandoned' or 'thinking' status values behave), which keeps it from a 5.

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 goes beyond by explaining the consequence of the combination ('confession_id + status "resolved" ... restores patience a lot and clears the fail streak'), which gives the agent a reason to set those values rather than just their 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 names a specific verb and resource ('Tell the companion about a bug') and immediately clarifies the crucial scope point: she does NOT solve it, she logs it and responds. That behavioral framing plus the second-mode instruction (call again with confession_id + status 'resolved') makes the tool's identity unambiguous against siblings like femboy_write_diary_entry.

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 clearly states the two usage modes: open a new confession by describing the bug, and close one by re-calling with confession_id + status 'resolved' when fixed. It does not say when NOT to use it or when a sibling (e.g., femboy_report_command, femboy_write_diary_entry) is the better choice, so it falls short of the explicit alternatives bar.

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 a non-read-only, non-idempotent, non-destructive write, and the description is consistent with that while adding real value: it spells out the stat deltas per item and the situational caveat for monster_energy. It still doesn't say what the response looks like or confirm that repeated calls stack, but the behavioral picture is good.

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: purpose, per-item effects, inventory consequence. Front-loaded and every clause carries information; 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?

For a single-parameter tool with no output schema, this covers purpose, item choice, and side effects adequately. Only the return value and any repeat-use/cooldown behavior are left implicit.

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%, but the schema's only prose is the unhelpful "One of the known items." The description compensates by explaining what each of the three enum values actually does, which is exactly the meaning an agent needs to pick correctly.

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?

Opens with a concrete verb and resource: "Feed or treat the companion." That is clearly distinct from siblings like femboy_write_diary_entry, femboy_headpat, or femboy_set_outfit. It stops short of naming any sibling explicitly, but the action is unambiguous.

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 per-item effects give solid guidance for choosing among the three enum values, including a warning that monster_energy is "pointless if she is already wired." However, it never states when to reach for this tool versus related siblings such as femboy_headpat or femboy_say, so usage is only 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?

Goes well beyond the annotations: discloses the energy cost, that a reaction is broadcast on femboy://speech/live, diminishing returns near 100 affection, and a persistent tally that unlocks an achievement and accessory at 100. That is exactly the side-effect and progression context an agent needs for a non-idempotent mutation.

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 front-loaded sentences with zero filler: purpose first, then mechanics/cost, then progression. Each 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?

No output schema exists, and the description fills that gap by explaining what visibly happens (out-loud reaction on the live speech channel) and the durable consequences (tally, achievement, accessory). Nothing needed 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 both parameters (note, intensity with its 1-10 band breakdown) are fully documented in the schema. The description adds no parameter-specific guidance, 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 and resource ("Give the companion a headpat") plus its immediate effect (raises affection, costs energy), which is clearly distinct from siblings like femboy_give_item or femboy_say. An agent can identify the action 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?

Conveys when this is a good action (wanting affection/patience gains) and a built-in caution that it "strongly saturates near 100 affection," which effectively signals diminishing returns. It does not name alternative tools or state hard preconditions, so it stops short of a 5.

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

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

The annotations already declare read-only, idempotent, non-destructive behavior, and the description reinforces that while adding useful context about where mutations occur. It also describes what is returned at a high level, though it does not discuss pagination or exact response shape.

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, front-loaded with the core read action, and every clause maps to useful content or behavioral context. The themed wording does not obstruct the operational meaning.

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 read-only progress-inspection tool with no output schema, the description covers the main return categories and mutation boundary well. It leaves only minor gaps around exact payload structure and view-specific behavior.

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 100% description coverage, including the view enum and only_locked flag, so the parameters are already well documented. The description does not add new syntax or filtering semantics beyond what the schema provides, making 3 the appropriate 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?

The description gives a specific verb and resource: it reads the progress rail and enumerates achievements, wardrobe, toasts, and counters. It also distinguishes this read-only inspection tool from the sibling care/action tools that actually perform unlocks.

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 clearly establishes this as the inspection tool and explicitly says unlocks happen through other care tools and the ticker. It does not spell out when to prefer each view or how it relates to siblings like femboy_ack_toast or femboy_changes_since, but the usage context is still 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 declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds genuinely new behavior: results are ordered by confidence then recency, which the annotations cannot convey. It does not mention truncation behavior when hits exceed the limit, which 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?

Two sentences, front-loaded with the core action and result ordering, with no filler. The sibling reference is placed last where it functions as a routing hint.

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 zero-required-parameter read tool with full schema coverage and full annotation coverage, the description covers what the agent needs to invoke it. With no output schema, a brief note on what a returned entry contains would have closed the last gap.

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 substring semantics, the category slug, and the default of 10 are already documented per parameter. The description restates 'substring search plus optional category filter' without adding format or matching details, 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 the memory log') plus the retrieval semantics (substring search, optional category filter, confidence-then-recency ordering). It explicitly names the sibling it pairs with, femboy_remember_fact, so an agent can distinguish read from write 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?

The 'read-only counterpart of femboy_remember_fact' clause gives clear context for when this tool applies versus the write sibling. It stops short of explicit exclusions, e.g. how it differs from femboy_changes_since or femboy_progress, which also surface stored state.

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 a non-destructive, idempotent, closed-world write, so the safety profile is covered. The description adds genuinely non-obvious behavior: repeated identical facts raise confidence rather than creating duplicates, and the facts feed the companion_persona prompt — downstream effects the 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?

Three short sentences, front-loaded with the action, then dedup semantics, then downstream effect. Every sentence adds information and nothing is repeated from the schema or annotations.

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 three-parameter write tool with full schema coverage and annotations, the description covers what it does, its dedup behavior, and its consumer (companion_persona). Minor gaps remain: no guidance on retrieval via femboy_recall and no note on how the pre-populated confidence interacts with repeated facts.

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%, including min/max lengths and the confidence scale semantics, so the schema carries the parameter burden. The description only implies brevity ('short fact') without adding syntax or format detail beyond what the schema already gives. 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 ('Persist a short fact ... into the memory log') with clear scope: user or project facts. It does not name or differentiate from the obvious sibling femboy_recall, so the distinction between writing and reading memory is left implicit.

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?

Usage is implied by 'persist a short fact', but there is no explicit when-to-use or when-not guidance, and no mention of femboy_recall for retrieval or femboy_changes_since for observing memory drift. An agent must infer the write-vs-read split from the sibling list.

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

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

It richly discloses behavior beyond the annotations: failures raise a streak and affect patience, 3+ failures trigger sympathy mode, successes heal patience, and exit codes 130/143 reset the streak without penalty. It also describes Phase 4 effects such as Git Master chain progression, force-push ending the chain, achievements, and Night Owl 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?

The description front-loads the core purpose in the first sentence and then expands into behavioral consequences. It is dense and lore-heavy, but most details are relevant to correct invocation and interpretation, with little pure 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?

Given the absence of an output schema and the presence of annotations covering safety/mutation profile, the description supplies the missing behavioral context: exit-code handling, streak and patience effects, achievement triggers, and deployment wiring. An agent has enough information to invoke it appropriately.

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 both parameters. The description adds meaningful semantics beyond the schema, notably that exit code 130/143 has special reset behavior and that the command string is never parsed and can omit secrets.

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 and resource: telling the companion how a shell command ended, including the raw exit code. It is clear enough to distinguish from generic tools, though it does not explicitly contrast itself with the sibling femboy_report_git.

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 usage context by saying to wire this from a pi shell hook or the TUI launcher, and explains how command outcomes affect the companion. It does not explicitly state when to use this instead of femboy_report_git or other reporting siblings, so it stops short of full alternative 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 declare it non-read-only and non-idempotent; the description supplies the missing why — it 'feeds the Git Master chain', so consecutive calls accumulate state, which explains the non-idempotent hint. It also discloses that force_push breaks the streak, implying order sensitivity. It stops short of saying what the response shape or failure mode looks like, but with annotations present the bar is lower.

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, front-loaded with the action and followed by the reward mechanic and the sibling-overlap note; each sentence carries distinct information. The gamification aside is framed as motivation for the chain semantics rather than pure filler, though it is the softest part of the description.

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 three-parameter, fire-and-forget hook reporter with full schema coverage and no output schema, this covers trigger, effect, and sibling overlap adequately. The only gap is that nothing describes what the caller gets back when reporting (the schema hints detail is 'only echoed back'), which would be trivial to add.

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 only indirect meaning — the '20 commits in a row without a successful force-push' streak implies how commit and force_push differ in effect — but it does not reinforce the action enum, the ok toggle, or the detail field in any explicit way. Reasonable, but the schema is doing essentially all of the work.

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 clause states a concrete verb and resource — 'tell the companion a commit landed (or that history was rewritten)' — which is specific enough to know exactly what event is being reported. The parenthetical extends the scope to rewritten history, matching the rebase/force_push enum values. It is clearly distinct from generic siblings like femboy_report_command, and the description explicitly explains the boundary between the two.

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 names the trigger ('the git hook'), the conditions ('a commit landed', 'history was rewritten'), and explicitly addresses the most likely confusion: that a plain femboy_report_command carrying a git command line is classified the same way, so wiring both is harmless. That is a direct when/when-not routing statement against a sibling, not merely implied usage.

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=false, idempotent=false, destructive=false, openWorld=false, so the safety profile is mostly structured. The description adds genuinely new behavior: the buffer is live and ephemeral, lines expire (~20 s default) and are replaced, and the destination is the TUI at femboy://speech/live. Missing only what happens on failure or how the call acknowledgement looks.

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, front-loaded with the action and its effect, then the expiry caveat. No filler and nothing repeated from the 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?

With no output schema and full parameter coverage, the description covers the essentials: what gets written, where it goes, and that it is transient. It falls slightly short on what a successful call returns and whether concurrent lines overwrite each other beyond the ttl note.

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 kind, text, and ttl_ms are already documented with enum values and bounds; baseline 3 applies. The description adds the default expiry (~20 s) that the schema leaves unstated, which is a modest but real contribution.

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-plus-resource ('push a line into the live speech buffer') and explains the downstream effect (TUI animates mouth and thought bubble). That is concrete enough to separate it from every sibling, none of which touch the speech buffer.

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?

Usage is implied by the mechanism (speak a short line into the TUI), but there is no explicit statement of when to reach for this versus femboy_write_diary_entry or femboy_headpat, and no when-not-to-use condition. An agent can infer intent but must reason about the choice.

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 a non-readOnly, idempotent, non-destructive, closed-world write. The description adds genuinely new behavioral context: rare/legendary outfits and catalogued accessories consume an achievement (femboy_progress), and free-form accessories get registered as owned — a side effect the annotations do not convey. It leaves the cost's permanence (consumed vs checked) ambiguous.

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 tight sentences with the core action front-loaded and the gating caveats following. The final sentence is dense with two distinct rules (catalogued vs free-form accessories) compressed together, slightly raising parse cost.

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 2-parameter tool with no output schema, this covers action, input forms, and the achievement-cost side effect well. Remaining gaps are error behavior on unknown names/insufficient achievements and whether the achievement is consumed, which matter for an agent deciding whether to call it.

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 value beyond it: it explains the dual name/ref_id acceptance with a concrete example and ties the accessory to the same gating logic as outfits. The omit-vs-null distinction is already in the schema, so it earns no extra credit there.

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?

"Dress the chibi: change the current outfit and optionally the accessory" gives a concrete verb (change/dress) plus the resource (chibi outfit, optional accessory). No sibling tool in the list touches outfit state, so the scope is unambiguous and an agent can select it immediately.

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 specifies accepted identifier forms (display name vs ref_id) and states the gating condition for rare/legendary skins and catalogued accessories. It does not need explicit when-not-to-use guidance because no sibling overlaps, but it stops short of saying what happens on an unknown outfit name.

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=false, idempotent=true, destructive=false and closed-world, so the safety profile is covered. The description adds one useful context: keys are free-form and persisted in femboy://state, implying arbitrary keys may be created. It does not state error behavior for bad keys or whether toggling affects other state.

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 compact sentences, action and scope front-loaded, examples parenthetical rather than bulked out. No wasted text.

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, well-annotated, non-destructive idempotent toggle with a fully described schema and no output schema, this is close to sufficient. The only meaningful gap is what happens when the supplied feature key does not already exist.

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 already provides illustrative keys and the true/false semantics for enabled. The description's only real addition is 'free-form keys', clarifying that the feature parameter is not an enumeration, which is a minor but genuine contribution over 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?

States a specific verb and resource: turning a pastel feature flag on or off, with concrete example flags so the agent knows the domain. No sibling tool overlaps with flag toggling, so no differentiation is strictly needed, though it never explicitly says this is the only flag-mutation entry point.

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?

Usage is implied by the verb and the enabled boolean, but there is no explicit 'use this when' guidance, no note about what happens for an unknown key, and no mention of alternatives or read-only counterparts (e.g. recalling state via femboy_recall).

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 word 'Add' plus 'inner monologue' conveys append-only semantics, which goes beyond the annotations (readOnlyHint=false, idempotentHint=false) by telling the agent it cannot edit or replace prior entries. It stops short of saying whether entries persist across sessions or how many can accumulate, so the mutation profile is only partly characterized.

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, zero filler, with the primary purpose front-loaded and the routing constraint second. Every clause 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?

For a simple two-parameter append tool with a fully described schema and no output schema, the description covers purpose, routing, and tone. Minor gaps remain: no mention of persistence, entry limits, or what happens when the 4000-char bound is exceeded.

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 (entry, mood_tag) are documented there, including the 'in her voice' tone guidance and snake_case storage note. The description adds nothing about parameter format or the optional mood_tag, 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 ('Add a line to the companion's inner monologue') and anchors it to a named store (femboy://diary). It explicitly contrasts with the sibling femboy_remember_fact, so an agent can pick the right tool 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 positive cases ('reflections about the code, small wins, or mood notes') and an explicit exclusion with the alternative named ('not for facts (use femboy_remember_fact)'). Both the when and the when-not are covered.

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