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

Annotations already declare read-only, non-destructive, non-open-world behavior. The description adds important beyond-annotation context: data is a saved snapshot and may be stale, and freshness depends on last logout, /reload or /coach. It does not cover error behavior, but that is minor for a read 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?

Front-loaded purpose followed by usage, coverage, freshness caveat, and Args. There is slight repetition in the field lists (quests/talents/gear/gold/location), but otherwise no meaningless 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?

Given one optional parameter and an output schema, the description supplies the missing operational context: scope, Markdown format, freshness, and argument semantics. Nothing essential 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 coverage is 0%, so the description must carry parameter meaning; it does. It explains character can be 'Testchar' or 'Name-Realm', is case-insensitive, and may be omitted to use the most recently saved character.

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?

Specific verb and resource: 'Get the full current status of a WoW character as Markdown,' with enumerated coverage. It is clear this is a comprehensive snapshot rather than a list or wiki lookup, though it does not explicitly name sibling 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 concrete triggers: player asks what to do next, what to upgrade, or about quests, talents, gear, gold or location. It does not state when not to use it or point to alternatives such as progress_summary.

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, destructiveHint=false and openWorldHint=false, so safety and scope are covered structurally. The description adds ordering behavior and the exact per-line content, which is genuinely useful context beyond the annotations. It doesn't discuss pagination or what happens with zero characters, 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-loaded with the verb, resource and ordering before any procedural instruction. The second sentence is long and enumerates return-field details that partially duplicate the existing output schema, but every clause remains informative and there is no filler.

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

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

For a zero-parameter, read-only list tool with an output schema and full annotation coverage, the description supplies everything an agent needs: when to call it, ordering, and why the call matters to the session. Return-value explanation is a bonus rather than a necessity 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?

The tool takes zero parameters, so there are no per-argument semantics to explain and the baseline of 4 applies. Nothing in the description misrepresents the empty input surface.

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 ('List the player's WoW characters') plus ordering semantics ('most recently played first') and the intent behind it ('to choose from'). An agent can distinguish it from siblings like character_status or progress_summary 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 an explicit trigger point ('at the start of every coaching session, before anything else') and the downstream purpose (choosing a character or creating a new one). No alternative tool is named, but the sequencing instruction is unambiguous enough that ambiguity is not a practical risk.

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/non-destructive/non-openWorld, so the safety profile is covered. The description adds genuine behavioral context beyond that: the lookback window is date-bounded, the output is comparative (diff against the previous session), and it spans multiple data categories. It stops short of noting cost, size, or behavior when no history 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?

Purpose is front-loaded in the first sentence, then usage, then content, then parameters – a sensible order. The Args block mildly duplicates the schema and the trailing 'Compare it with the plan in the journal' is a useful but slightly loose addendum rather than waste.

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?

An output schema exists, so return-shape explanation is not required, and the description still sketches content categories. Both optional parameters are fully described. The remaining gap is sibling disambiguation against character_status and recent_history, which matters given the overlapping toolset.

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 0%, so the description carries the full burden and largely does: it explains 'character' accepts a name or 'Name-Realm', is case-insensitive, and that empty means the most recently saved character; 'days' is the lookback window. It repeats the schema's default value for days, which adds no new meaning, keeping it from a 5.

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: 'Summarize how a character has progressed lately', followed by an enumeration of what the summary contains (sessions, levels, XP, gold, quests, deaths, deltas since previous session). It does not differentiate itself from siblings like character_status or recent_history, which appear to overlap in scope, so an agent must infer the boundary.

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 concrete triggering conditions: 'at the start of a session and whenever the player asks how they are doing', plus a follow-up hint to compare against the journal plan. No explicit when-not-to-use or named alternative tool, 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 cover the safety profile (readOnly, non-destructive, closed-world), so the description correctly spends its words on non-obvious behavior: both parts return with clear headings, and the empty-journal case produces an explicit message rather than a silent failure. It does not describe ordering or size of notes, but that is minor given an 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?

The core purpose and the session-start guidance are front-loaded and earn their place. The trailing 'Args:' block is a docstring artifact that reads as displaced documentation, and its formatting is slightly out of register with the prose above, but it carries real information rather than 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 single-optional-parameter read tool with annotations and an output schema, nothing essential is missing: what it returns, when to call it, the empty-state behavior, and the fallback tool are all covered. An agent can invoke it correctly without inspecting 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 coverage is 0%, so the description must carry the parameter, and it does: accepted formats ('Name-Realm'), case-insensitivity, and the default behavior when left empty (most recently saved character). It stops short of describing ambiguity resolution when a name matches multiple characters.

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 a precisely scoped resource: 'Read the coach's memory: the player notes plus one character's journal.' It names exactly the two artifacts returned, which distinguishes it from read-only siblings like character_status or recent_history that read other data.

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 timing guidance ('at the start of a coaching session, before giving advice') and states the purpose of that timing (to recall preferences, goals, lessons). It also names the counterpart tool and condition for use: if no journal exists, ask for a goal and call save_coach_notes.

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/openWorld/non-destructive, and the description adds real behavioral detail on top: redirects are followed, text is labelled by game version (Classic/Retail/Forever), long pages expose their section names, and max_chars truncates the answer. It does not describe error behavior for a missing title, which keeps it 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 and the routing rule, then the content categories, then per-argument notes — a sensible order with little waste. The prose paragraph runs slightly long and could be bulleted, but no sentence is 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 3-parameter read tool with an output schema, everything an agent needs is present: when to use it, when to route to search_wiki, how sections and truncation work, and how version-specific content is marked. Return value structure is covered by the output schema, so its absence from the description is appropriate.

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

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

Schema description coverage is 0%, so the description carries the full burden and does: title gets two concrete example titles, section gets example values plus the useful hint that long pages list their section names, and max_chars states its default of 6000 and its meaning as the longest returned answer.

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 concrete verb and resource ("Read a Warcraft Wiki page as plain text") plus the shape of the output ("key facts listed first"). It also names the sibling it is not — search_wiki — so the agent can distinguish it from the other wiki 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 explicit content categories the tool is for (NPC locations, vendor stock and prices, quest rewards, items, zones) and an explicit fallback condition: "If you do not know the exact title, call search_wiki first." It also tells the agent to prefer Forever-labelled info, which is a usage rule rather than a capability.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine context beyond that: results are newest-first and the character argument falls back to the most recently saved character, which materially affects behavior. Return shape is covered by the output schema, so nothing critical is missing.

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 purpose sentence, then a single usage sentence with two concrete examples, then a compact Args block. No filler, and the ordering guarantee is stated in the first line where an agent will see it.

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?

All optional parameters are explained, annotations cover the safety profile, and the output schema handles return values. For a two-optional-parameter read tool, 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 0%, so the description must carry the full burden, and it does: character accepts a name or "Name-Realm" form, is case-insensitive, and may be omitted to target the last saved character; limit is capped-count with a stated default of 20. Remaining gaps are minor, such as what happens on an unrecognized character name.

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?

Specific verb and resource: "Get a character's recent events" with concrete event categories (level-ups, deaths, quests) and an ordering guarantee (newest first). It does not explicitly distinguish itself from close siblings like character_status or progress_summary, which also report on player state, so an agent must infer the boundary.

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 concrete when-to-use triggers: "to explain a death" and "to track progress between coaching sessions." No when-not guidance and no explicit pointer to an alternative tool, leaving overlap with progress_summary unresolved.

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, but the description goes beyond that by explaining exactly what is destroyed (the entire journal is overwritten), the mitigation workflow (read first, resend full text), and hard constraints (Markdown, under 100 KB). This is exactly the behavioral context an agent needs before an irreversible write.

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 destructive replacement semantics in the first sentence, then usage, then args. Slight redundancy between the first sentence and the later 'Because it replaces the whole journal' restatement, and the Args block partially repeats inline prose, but no sentence 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 2-parameter destructive write with an output schema present, nothing material is missing: destruction scope, prerequisite read, size/format limits, and per-parameter meaning are all stated. Return values need not be explained because an 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 description coverage is 0%, so the description carries the full burden and does so: 'text' is defined as the complete new content (not a delta), and 'character' accepts a name or 'Name-Realm', is case-insensitive, and defaults to the most recently saved character when empty. That resolves the meaning of an untyped nullable parameter.

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 (save a character's journal) and immediately the key semantic: it replaces everything saved before. It also explicitly contrasts scope with save_player_notes, so an agent can distinguish it from that sibling 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 ('when you learn something worth remembering about THIS character'), enumerates what belongs in the journal, names a mandatory prerequisite (call read_coach_notes first), and routes out-of-scope content to save_player_notes. Both when-to-use and when-not-to-use 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 already declare destructiveHint=true and idempotentHint=true, yet the description still adds non-redundant behavior: the write is a full replacement of prior content, so read_coach_notes must be called first, and the payload must be Markdown under 100 KB. These constraints are not derivable from the 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?

Effectively front-loaded: purpose, then when-to-use, then alternative, then the argument. The trailing "Args:" block partially restates "send the full updated text" from the body, a small redundancy, but no sentence is otherwise 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 one-parameter write tool with an output schema already documenting returns, the description supplies everything an agent needs: the destructive replace model, the read-before-write workflow, format, size limit, and sibling routing.

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 0% and the schema only types the parameter as a bare string, so the description carries the load: it specifies that text is the complete new content (not a delta), the Markdown format, and the 100 KB ceiling. Only a minor gap remains, such as behavior on invalid or oversized input.

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 ("Save the player notes") plus scope ("shared by all characters") and the replace semantics in the first sentence. An agent can distinguish it from the sibling save_coach_notes 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 ("when you learn how the player likes to be coached"), enumerates the kinds of content that qualify, and routes the one-character case to save_coach_notes by name. The read_coach_notes prerequisite is spelled out as part of the workflow.

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 (readOnlyHint, destructiveHint=false, openWorldHint), and the description adds value on top: what the results contain, that Forever-only content is indexed, and a citation obligation ('Always cite the link you used') that appears nowhere in structured fields. It stops short of describing result ordering, empty-result behavior, or any rate limits, so it is strong but not exhaustive.

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 instruction is front-loaded in the first two sentences, and the example queries are short and illustrative rather than filler. The Args block is somewhat redundant stylistically but is justified by the 0% schema description coverage; the 'Forever-only content' aside is domain-specific but does convey a real scope fact.

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 search tool with an output schema already present, nothing an agent needs is missing: when to search, what comes back, what to do next, and the citation requirement. Return-value detail is correctly left to the output schema rather than duplicated.

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 0%, so the description carries the full burden and largely meets it: the Args block explains 'query' as plain-words intent and supplies a constraint the schema lacks entirely — that 'limit' is bounded 1 to 10 with default 5. The schema only declares limit as an unbounded integer with default 5, so this is genuine added meaning; only minor gaps remain (no guidance on phrasing for better matches).

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 specific verb and resource ('Search the Warcraft Wiki') and states the return shape (matching page titles, one-line snippets, links). It also implicitly separates itself from the sibling read_wiki_page by framing itself as the discovery step, so an agent can pick between the two 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?

Explicitly states the triggering condition ('Use this when you do not know the exact page name') with concrete example queries, which by implication tells the agent when not to use it. It then names the alternative and the follow-up flow: 'call read_wiki_page with the title you want.'

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