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

No annotations are provided, so the description carries the full disclosure burden. It does add genuine behavioral context: latency expectations (~2-10 s) and the presence of a confidence value plus cited chunks. However it says nothing about auth requirements, rate limits, corpus scoping, or what happens on a low-confidence/no-match result.

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 tight sentences with the core purpose and latency front-loaded and the alternative routing placed second. No filler, though slightly less compact than a single sentence that would still convey the same content.

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 values need not be explained, and the description still gives a useful preview (confidence + cited chunks). For a single-param read/query tool this is nearly complete; only the relationship to the other corpus retrieval siblings is left unaddressed.

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

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

One parameter with 100% schema coverage, so the schema already documents the 'question' argument including an example. The description adds no syntax, length, or formatting guidance beyond what the schema provides; 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 ('LLM-grounded answer over the corpus') plus the output shape ('short synthesized answer with a confidence value and the cited chunks'), and explicitly names corpus_deep_ask as the contrasting sibling. An agent can distinguish it from corpus_search and corpus_semantic_search 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?

Gives a clear positive case (quick answer) and an explicit alternative with its selector condition ('For deep multi-source research with [S1][S2] citations, use corpus_deep_ask instead'). It does not distinguish against corpus_search / corpus_semantic_search, which are the other plausible choices, so it stops short of full when/when-not coverage.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses the 30-120 s latency, the one-question-at-a-time constraint, and that the output carries [S1], [S2] source markers. It omits any statement about authentication, rate limits beyond latency, or cost, 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?

Three short sentences, front-loaded with purpose, then output format, then caveats. Every sentence carries information; only the follow-up guidance could be considered optional.

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?

Because an output schema exists, the description need not explain return values, yet it usefully notes the source markers and how to resolve them via corpus_get_doc. For a slow, single-parameter tool with no annotations, latency, batching guidance, and follow-up are all covered.

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?

Only one parameter and schema description coverage is 100%, so the baseline is 3. The description reinforces the usage pattern ('one question at a time') but adds no semantics about question phrasing, length, or scope that the schema does not already provide.

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 combination (LLM-assisted question answering) and a clear scope (the entire corpus, ~220K chunks) that distinguishes it as the 'deep' synthesis tool. It does not explicitly name the closest sibling (corpus_ask) or contrast itself with corpus_semantic_search, so differentiation is implied rather than stated.

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?

Offers useful operational guidance: 'Ask one question at a time' and a latency warning, plus a follow-up path via corpus_get_doc(doc_id). However, it never says when to prefer this over corpus_ask or corpus_semantic_search, which is the key selection decision for an agent facing these siblings.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that content is returned chunk by chunk and that interview chunks expose speaker/timestamp_start and audio/source URLs, but it omits whether one call returns all chunks or paginates, and says nothing about volume limits or auth needs.

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

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

Two short lines, front-loaded with the core purpose and followed by the one non-obvious return detail. Little waste, though the parenthetical '(chunk by chunk)' and the metadata sentence could be tightened.

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

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

An output schema exists, so return structure need not be re-explained. The description covers the essential retrieval behavior and a special-case field note, leaving only pagination/volume behavior unaddressed for a 2-param read tool.

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%: doc_id format/source and max_chars_per_chunk semantics (including 0 = no limit) are fully documented in the schema. The description adds no parameter detail beyond that, so baseline 3 applies.

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

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

States a specific verb+resource+scope: 'Fetch a document's full content (chunk by chunk).' An agent can tell this is a retrieve-by-id operation, distinct from corpus_search/corpus_suggest. It stops short of naming the search siblings it complements, so it isn't a 5.

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

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

Usage context is only implied: the doc_id flows from search results (documented in the schema, not the description), and the description adds a narrow hint about interview chunks and audio_url/source_url. There is no explicit when-to-use/when-not or named alternative.

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

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

No annotations are provided, so the description carries the burden. It implies a read-only diagnostic ('Status and stats') and names the fields reported, but never states explicitly that it is non-mutating, whether it hits the network or a cache, or how expensive/quick it is. The Returns list adds some behavioral value.

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

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

One front-loaded sentence plus a compact field list - no filler. The Returns block partially restates what the output schema already carries, which is mild redundancy but still aids quick reading.

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 no-parameter diagnostic with an output schema present, the description is essentially complete: it says what the tool reports and what the key fields mean. Only an explicit read-only/cost statement would improve 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The prose adds no parameter detail because none exists.

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 resource and outcome: 'Status and stats of the corpus search infrastructure.' This cleanly separates it from every sibling, which are all search/retrieval tools rather than a diagnostics endpoint. It doesn't need sibling routing language because nothing else exposes infrastructure 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?

Usage is only implied - an agent can infer you call this to check whether the semantic index is online. There is no explicit statement of when to call it (e.g., before relying on corpus_semantic_search, or when searches return nothing) and no exclusions.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that the result is metadata only rather than document content, but says nothing about read-only safety, pagination behavior, or how the default limit of 50 affects browsing.

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 filler, with the core capability and the key alternative front-loaded. 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?

An output schema exists, so return values need not be explained, and all three optional parameters are documented in the schema. The description covers the essential purpose and the content-vs-metadata distinction; only richer browsing semantics (pagination, filtering) are missing, which is minor for this tool.

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 limit, series, and extended are already fully documented in the schema. The description adds no extra meaning about these parameters (e.g. how series matching works), 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 ('Browse the corpus library') and clarifies scope with '(metadata list)', which separates it from content-fetching siblings. It explicitly distinguishes itself from corpus_get_doc, though it does not differentiate from closer siblings like corpus_list_series or corpus_list_doc_types.

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 line 'For content use corpus_get_doc' gives one clear routing condition away from this tool. However, there is no guidance on when to pick this over the other list-style siblings (corpus_list_series, corpus_list_doc_types, corpus_search), 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?

With no annotations, the description carries the full burden but only implies a read operation by stating what it returns. It does not disclose read-only status, authentication needs, rate limits, or any other behavioral trait beyond the basic output.

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 concise sentence fragment with no wasted words, front-loading the resource. However, it is not a fully structured sentence, which slightly reduces clarity.

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 many sibling tools and the lack of annotations or usage guidance, the description is incomplete. While an output schema exists, the agent receives no guidance on when to select this tool over others, and no behavioral context is provided.

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 single parameter's description in the schema is complete (100% coverage), so the baseline score of 3 applies. The tool description adds no additional meaning about the extended_only 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?

The description states the resource (authors) and the additional data returned (document counts), which is specific and distinguishes it from siblings like corpus_list_doc_types or corpus_list_series. However, it lacks an explicit verb and is a sentence fragment, so it is clear but not maximally strong.

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

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

There is no guidance on when to use this tool versus alternatives such as corpus_search or corpus_list_doc_types. The description provides no context, exclusions, or prerequisites.

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

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

No annotations are provided, so the description carries the burden. It implies a read-only enumeration returning types and counts, but says nothing about permissions, freshness, or scope limits. Since the output is simple and an output schema documents the return shape, a 3 is reasonable.

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 what it returns and followed by the integration hint. No filler, though the parenthetical list is slightly open-ended with '...'.

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 tool with an output schema, the description covers purpose and downstream usage sufficiently. The remaining gap is minor behavioral context (read-only nature, scope) that annotations would normally supply.

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 the schema imposes nothing to misinterpret. Baseline of 4 applies; no parameter semantics are needed or missing.

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 (list) and resource (document types) with parenthetical examples (article, book, interview) that clarify what a 'doc type' is. Clear enough to distinguish from siblings like corpus_list_authors and corpus_list_series, though it never explicitly contrasts with them.

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

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

Explicitly tells the agent what to do with the result: 'Usable as the doc_type filter in corpus_search.' That is actionable next-step guidance rather than generic context. It stops short of stating when-not to use it or naming alternatives.

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

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

No annotations are supplied, so the description carries the full disclosure burden. For a zero-parameter enumeration tool the behavioral surface is small, and the description does add the useful semantic link that values correspond to the 'series' field in corpus_search — but it says nothing about whether the list is exhaustive, its size, or ordering.

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, front-loaded with what the tool returns and followed by how to use it; the examples earn their place by making the abstract term 'series' concrete. The first sentence is a noun fragment rather than a full clause, a minor structural weakness.

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 values need not be explained, and the description supplies the two things the schema cannot: what 'series' means in this corpus and how the result feeds into corpus_search filtering. Only the lack of any note on completeness/freshness of the list 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?

The tool takes no parameters, so the baseline is 4. There is no parameter surface for the description to compensate for, and it correctly does not waste space inventing argument semantics.

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 resource — the series/collections present in the corpus — and grounds it with three concrete examples ('One Radio Network', 'Ray Peat Newsletter', 'Ask the Herb Doctor'). The verb is carried by the tool name rather than the prose, and it is not explicitly distinguished from similar enumeration siblings like corpus_list_authors or corpus_list_doc_types, so it falls short of a 5.

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

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

It gives clear actionable context by telling the agent that the returned values match the 'series' field in corpus_search results and are 'usable as a filter', which is exactly the downstream use case an agent needs. It stops short of naming alternatives or stating when not to call it, so no exclusion guidance is present.

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

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

With no annotations, the description carries the full burden, and it does disclose the corpus scope and the shape of returned fields (excerpt, doc_id, timestamps, etc.). However, it says nothing about permissions, result ordering, pagination, or behavior when a query matches nothing — meaningful gaps for a tool with zero annotation coverage.

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 tight sentences, front-loaded with the core purpose followed by coverage and return fields. Little waste, though the return-field list is somewhat redundant given the output schema 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?

The corpus scope and covered doc types are well covered, and an output schema exists so return values need not be explained (the description lists them anyway). It is nearly complete for a search tool; only guidance on sibling selection is missing.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including limits, filters, and scope flags. The description adds no parameter-level detail beyond what the schema provides, which is the correct baseline of 3.

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

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

States a specific verb+resource: 'Full-text search across the entire Ray Peat corpus', and enumerates the covered document types. The phrase 'full-text' implicitly contrasts with semantic/ask siblings, but it does not name them, so sibling differentiation is inferential rather than explicit.

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 a corpus-wide keyword search and lists coverage, which gives some usage context, but it never says when to pick this over corpus_semantic_search, corpus_ask, or raypeat_search_articles. No exclusions or prerequisites are stated.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses that results include glossary_terms (synonyms/concepts), which is real behavioral context, but says nothing about filtering behavior, what ray_only or include_extended do, or result ordering across 7 parameters.

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 mechanism and the key differentiator; nothing is padded. Slightly under-specified rather than wasteful.

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 values need not be explained, and the glossary_terms disclosure is a bonus. However, with 43% schema coverage and six undocumented filter/option parameters, the definition is not complete enough for an agent to use the full parameter surface confidently.

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

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

Schema coverage is only 43%, and the description adds no parameter meaning at all — author, series, doc_type, and ray_only are undocumented in both places. Only limit, query, and include_extended have schema descriptions, so the description fails to compensate for the coverage gap.

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 (semantic/embedding search over the corpus) and clarifies the distinguishing mechanism — meaning-based matching rather than exact keywords. It does not name the keyword sibling (corpus_search) explicitly, so the differentiation is implied rather than routed.

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 clause 'even without exact keyword matches' implies when this tool is preferable to keyword search, but no alternative is named and no exclusions or prerequisites are given. Usage is inferable but not stated.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It does not state whether the operation is read-only, how many suggestions are returned, ranking behavior, permissions, or rate limits; it only says that suggestions are produced.

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 wasted words. It immediately communicates the tool's core function.

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, one-parameter tool with an output schema, the description covers the basic purpose. However, it omits usage guidance and behavioral context, which are especially important since no annotations are available.

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

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

Schema description coverage is 100%, so the single query parameter is already well documented with examples. The description adds that suggestions can be terms or document IDs, but does not add further meaning to the query parameter itself.

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: corpus autocomplete for term and document (doc_id) suggestions. It is clear enough to distinguish the tool from full search tools, but it does not explicitly differentiate itself from sibling suggest/search tools such as wiki_suggest or corpus_search.

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 term 'autocomplete' implies usage with a partial query, and the schema example reinforces that context. However, there is no explicit guidance on when to use this versus corpus_search, corpus_semantic_search, or other suggestion 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?

No annotations are provided, so the description carries the full burden, but for a zero-parameter read-only enumeration there is little behavior to disclose. It does not state whether results are paginated, cached, or ordered, and adds nothing beyond the implied read semantics of 'list'.

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 followed by a brief rationale. No filler or redundant restatement of the 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?

An output schema exists, so the return shape needn't be described, and with no parameters the description is nearly complete. It could be strengthened by noting how these topic tags relate to filtering/search tools, but nothing essential 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to clarify beyond what an empty schema already conveys. The inline examples of tag values are a modest, helpful addition.

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 ('List') and resource ('the corpus's topic tags') and concretizes it with real examples ('thyroid', 'pufa', 'cortisol'). It is clearly distinguishable from siblings like corpus_list_doc_types and corpus_list_authors by naming a distinct resource, though it does not explicitly contrast itself with them.

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 second sentence gives a reason to call it ('Useful to see what themes the corpus is organized around'), which implies usage context. However, it offers no when-not guidance and never names an alternative tool (e.g. corpus_search) for actually querying those themes.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the return content ('titles and URLs') and implies a read-only listing, but omits pagination, ordering, authentication, and rate-limit 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?

Two sentences, front-loaded with the action and scope, followed by the return shape. No filler or repetition; every element earns its place.

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

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

For a simple zero-parameter list tool with an output schema, the description identifies the source and return contents well. It is complete enough to invoke correctly, though it could mention whether the list is paginated or ordered.

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, and the schema is an empty object with additionalProperties false. There is nothing for the description to clarify, so the baseline of 4 for a no-parameter tool 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 gives a specific verb ('List') and resource ('all of Ray Peat's articles on raypeat.com'), making the scope clear. It distinguishes itself from siblings like raypeat_read_article and raypeat_search_articles by listing all articles, but it does not explicitly name or contrast those alternatives.

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: use this when you need the complete list of Ray Peat articles. However, the description does not state when to prefer this over raypeat_search_articles or raypeat_read_article, nor does it mention any prerequisites or exclusions.

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

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

No annotations provided, so the description carries the full burden. 'Read' implies a non-destructive operation, but the description does not explicitly state that it is read-only, nor does it mention any authentication, rate limits, or error behavior. It adds little beyond the verb.

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

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

A single, front-loaded sentence with no wasted words. It is appropriately concise for the tool's simplicity.

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 read tool with a fully specified schema and an output schema, the description covers the core purpose. However, without annotations, it should at least state that it is a read-only operation and clarify its relationship to sibling tools like raypeat_search_articles and raypeat_list_articles. The missing usage context leaves gaps.

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

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

Schema coverage is 100% and the single parameter 'path' is fully described in the schema, including examples. The description adds no additional parameter semantics, 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 ('Read') and resource ('Ray Peat's articles') and scope ('as full text'). It does not differentiate from sibling tools like raypeat_search_articles or raypeat_list_articles, so it earns a 4 rather than 5.

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

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

No when-to-use guidance, no alternatives mentioned. The agent must infer that this is for retrieving full text when the path is known, as opposed to searching or listing.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only lookup but says nothing about result limits, pagination, ranking, or case sensitivity, and never states what happens if no title matches.

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

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

A single front-loaded sentence with zero filler that communicates verb, resource, and scope immediately.

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 values need not be explained, and the tool is a simple one-parameter search. However, with no annotations and no sibling differentiation, the definition leaves the agent unable to confidently choose it over semantic or list alternatives.

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

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

Schema coverage is 100% and the single 'query' parameter is fully documented with examples, so the baseline is 3. The word 'keyword' in the description hints at exact-term matching rather than semantic similarity, adding mild value but no syntax or formatting detail beyond the schema.

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

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

States a specific verb (search) and resource (Ray Peat article titles) with a clear scope qualifier ('titles', not full text). It does not name or contrast with the obvious sibling corpus_semantic_search or raypeat_list_articles, so the agent must infer the distinction.

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

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

There is no guidance on when to prefer keyword search over corpus_semantic_search or corpus_ask, no exclusions, and no note that only titles (not article bodies) are matched beyond the implicit 'titles' phrase. The agent is left to guess the retrieval strategy.

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

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

With no annotations, the description carries the full behavioral burden. It implies a read-only operation but does not disclose pagination behavior, how the limit is applied, whether redirects or talk pages are included, or any other behavioral traits beyond the basic purpose.

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 that wastes no words. It immediately communicates the core purpose without unnecessary detail.

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 read tool with a fully documented schema and an output schema, the description covers the essential purpose. However, it remains minimal and omits any contextual guidance, leaving it adequate but not fully complete for an agent that needs to choose among many similar wiki tools.

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

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

Schema description coverage is 100%, so the schema already documents both 'title' and 'limit' with descriptions and a default. The description adds no additional parameter meaning, but the baseline is 3 when the schema does the heavy lifting.

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

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

The description clearly identifies the tool's purpose as finding pages that link to a given page, using the phrase 'reverse link map' to distinguish it from outgoing-link tools. It does not explicitly name the sibling tool wiki_get_page_links, so it misses full sibling differentiation.

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

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

There is no guidance on when to use this tool versus alternatives like wiki_get_page_links or wiki_search. The purpose implies usage, but no context, exclusions, or prerequisites are provided.

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

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

With no annotations, the description carries the full burden of behavioral disclosure and largely fails it: it says nothing about pagination, ordering, or whether a category must exist. Worse, 'List all pages' is misleading given the limit parameter defaults to 50, so a reader may expect an unbounded result set.

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

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

A single short sentence with no wasted words, and the core action is front-loaded. It errs toward under-specification rather than verbosity, but structurally it is clean.

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

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

The presence of an output schema means return values need not be explained, and the schema documents both params. Still, for a list tool with a truncating default limit, the description should at minimum flag that results may be capped or paginated.

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 both parameters are documented in the schema, including the category format and limit default. The description contributes nothing beyond the schema, which is the expected baseline at full 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 verb ('List') and resource ('pages in a category'), which is enough for an agent to know what the tool returns. However, it does not differentiate itself from siblings such as wiki_list_all_pages or wiki_get_page_categories, which an agent could plausibly confuse it with.

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 mention of prerequisites, and no reference to any alternative tool. The agent must infer from the name alone that this is the right choice over wiki_list_all_pages or wiki_get_page_categories.

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

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

With no annotations, the description carries the full burden. 'Get the raw content' implies a read-only operation and unrendered output, but says nothing about permissions, rate limits, error handling for missing pages, or what 'raw' excludes. Most behavioral disclosure is absent.

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

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

A single front-loaded sentence with zero wasted words. For a simple getter, this is appropriately sized.

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 values need not be explained, but with no annotations and a crowded set of near-identical siblings, the description should at minimum differentiate itself from wiki_read and wiki_get_page_summary. That gap leaves the agent under-informed.

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 both 'title' (with namespace examples) and 'format' (wikitext vs html) are already fully documented in the schema. The description adds no parameter detail beyond that, matching the baseline of 3.

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

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

States a specific verb ('Get') and resource ('raw content of a wiki page'), which is clear enough to distinguish it from wiki_get_page_summary and wiki_read by the word 'raw'. However, it never names or explicitly contrasts those siblings, so the differentiation must be inferred.

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 on when to use this tool versus the many similar siblings (wiki_read, wiki_get_page_summary, wiki_search). No prerequisites, no conditions, no exclusions are stated; usage is only implied by the tool 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?

No annotations are provided, so the description carries the burden, but 'Show' does convey a read-only, non-destructive lookup and an output schema exists to define the return shape. It says nothing about behavior for missing pages, redirects, or result limits, which is a real gap for a tool with zero annotation coverage.

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?

One short, front-loaded sentence with zero filler. 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-parameter read tool with an output schema, the definition covers the essentials and the return shape is delegated correctly. Minor gaps remain around edge-case behavior, but nothing critical to invoking 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% with a single 'title' parameter, so the schema already documents the input fully. The description adds no format hints (e.g., namespace prefixes, case sensitivity) beyond what the schema states, which is the expected baseline.

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

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

States a specific verb ('Show') and resource ('categories a page belongs to'), and the per-page scoping implicitly separates it from siblings like wiki_list_categories (all categories) and wiki_get_category_members (reverse direction). It stops short of naming those siblings, so an agent must infer the distinction.

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 prerequisites, and no mention of alternative tools for related lookups. The agent must derive usage purely from the one-line purpose.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read operation by listing metadata fields, but says nothing about permissions, rate limits, behavior for missing pages, or whether the page must exist 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?

Eight words with zero waste and the key information front-loaded, which is good. But the noun-fragment form is terse to the point of under-specification for a tool that needs routing guidance.

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

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

An output schema exists and the schema fully documents the sole parameter, so much of the burden is lifted. Still, with 11+ wiki siblings and no disambiguation or usage context, the definition is only minimally sufficient to call the tool 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?

There is a single parameter (title) and schema description coverage is 100%, so the schema already documents it fully. The description adds no format, namespace, or case-sensitivity detail beyond the schema, matching the baseline 3 for schema-covered parameters.

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 fragment names the resource (page metadata) and enumerates the returned fields (last edit, length, last revision id, URLs), which hints at the distinction from wiki_get_page. However there is no verb and no explicit differentiation from close siblings like wiki_get_page_summary or wiki_get_site_stats, so the agent must infer the scope.

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

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

The description contains no when-to-use guidance, no prerequisites, and does not name an alternative tool. An agent gets no signal about when to pick this over wiki_get_page, wiki_get_page_summary, or wiki_get_site_stats.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read via 'List' but says nothing about pagination (limit defaults to 50), truncation behavior, permission requirements, or whether the result is a flat list versus grouped output.

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

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

A single front-loaded sentence with no wasted words. The parenthetical adds mild scope framing, though it is vague enough to be borderline 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?

An output schema exists, so return values need not be explained, and the tool is simple with full schema coverage. However, an agent still cannot tell from the description whether results are outgoing links only or how the limit behaves, leaving a modest 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 description coverage is 100% (title = 'Page title', limit = 'Max links'), so the schema already documents both parameters. The description adds no syntax or format detail beyond that, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb (List) and resource (wiki links contained in a page), and the phrase 'contained in a page' implicitly distinguishes it from the sibling wiki_get_backlinks (which would return inbound links). It does not name that sibling explicitly, so it falls short of full sibling differentiation.

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

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

The parenthetical '(related-topic discovery)' hints at when the tool is useful, but there is no explicit when-to-use guidance, no prerequisites, and no named alternative such as wiki_get_backlinks or wiki_search for contrasting cases.

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

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

No annotations are provided, so the description carries the full burden. The verb 'List' signals a non-destructive read, which is adequate for such a simple lookup, but it says nothing about ordering, pagination, or behavior for missing/nonexistent pages.

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?

One short sentence, front-loaded with the verb and resource, and the parenthetical adds useful disambiguation with zero 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?

For a one-parameter read tool with an output schema covering the return shape, the description is largely sufficient. The only gap is the absence of any usage routing relative to the many sibling retrieval tools.

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

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

Schema description coverage is 100% with a single 'title' parameter fully documented in the schema, so the baseline is 3. The description adds no extra meaning such as title format, case sensitivity, or resolution behavior.

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 ('List') and resource ('a page's section headings'), with a clarifying gloss '(table of contents)'. It implicitly distinguishes itself from content-returning siblings like wiki_get_page and wiki_read, but does not name them explicitly.

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 stated alternative, and no condition under which this tool is preferable to wiki_get_page or wiki_get_page_summary. An agent must infer that this is the lightweight TOC lookup from the phrasing alone.

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

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

No annotations are provided, so the description carries the burden, and it only says what content is returned (intro extract). It does not disclose behavior for missing pages, redirects, or disambiguation titles. For a simple read tool with an output schema, this is adequate but thin.

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 waste, with the core purpose front-loaded and the terse 'Fast overview' as a useful trailing qualifier.

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 format need not be explained. For a one-parameter read tool the description covers what is needed; only edge-case behavior is unaddressed.

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

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

Schema coverage is 100% for the single 'title' parameter, so baseline is 3. The description adds nothing about the parameter (e.g., whether it must be an exact title vs a search term, handling of spaces/normalization).

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 ('Get') and resource ('wiki page') plus the exact scope ('first paragraph (intro extract)'), which distinguishes it from the fuller wiki_get_page sibling. It does not name that sibling explicitly, so differentiation is implied rather than stated.

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?

'Fast overview' hints at the use case (quick orientation rather than full content), which is enough to infer usage against wiki_get_page. But no explicit when-to-use/when-not or named alternative is given.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read, but says nothing about whether pages are distinct, whether it hits the network, resolution/caching behavior, or how the result set is shaped beyond the schema's count bound. For a tool with zero annotation coverage this is thin.

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 followed by a brief usage nudge. 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?

An output schema exists so return values need no explanation, and the tool is trivial (one optional parameter). However, with no annotations and no note on randomization/distinctness, the definition is only minimally complete.

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

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

Schema description coverage is 100% and the single 'count' parameter documents its range (1-10) directly in the schema, so the description need not repeat it. Baseline 3 applies; the description adds no extra meaning.

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 (get) and resource (random wiki page(s)), and the word 'random' clearly distinguishes it from siblings like wiki_search and wiki_get_page. It is clear but does not name any sibling explicitly for differentiation.

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?

'Great for exploration' implies a use case (serendipitous browsing/discovery) but gives no when-not guidance or alternatives. An agent must infer that this is not for targeted lookups.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It implies a read-only listing but does not disclose ordering, time window ('recent' is undefined), pagination behavior, authentication requirements, or rate limits.

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

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

A single, front-loaded sentence with no wasted words. It is appropriately sized for a simple list tool.

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

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

The tool is simple, an output schema exists (so return values need not be explained), and the only parameter is documented. However, the description leaves 'recent' ambiguous and does not clarify the scope or context of the listing, leaving a gap for an agent.

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

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

Schema description coverage is 100%, with the single 'limit' parameter fully documented (default 10, range 1-50). The description adds no additional parameter semantics, so the baseline score of 3 applies.

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

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

States a specific verb ('List') and resource ('recent edits on the wiki'), making the tool's function clear. However, it does not differentiate itself from sibling tools like wiki_search or wiki_list_all_pages, so it falls short of a 5.

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

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

No guidance on when to use this tool versus alternatives such as wiki_search or wiki_list_all_pages. The description provides no context about appropriate scenarios, prerequisites, or exclusions.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about read-only safety, auth requirements, or caching/staleness of the statistics. For a simple stats getter the risk is minimal, but the description adds no behavioral context beyond the subject matter.

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

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

A single short fragment with no filler, front-loading the subject immediately. It is terse to the point of being a label rather than a sentence, but nothing 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 zero-argument tool with an output schema that documents the returned structure, the description need only identify what the endpoint is. It does that cleanly; only the missing safety/behavioral note keeps it from being fully complete.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The enumerated stat categories loosely describe the output, which is a small bonus.

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 the resource (wiki statistics) and enumerates the dimensions returned (pages, edits, users, files), so an agent knows exactly what it fetches. No other sibling exposes site-wide statistics, so differentiation is implicit rather than stated. The verb is carried by the tool name rather than the prose.

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

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

There is no guidance on when to call this versus alternatives or what problem it solves for the agent. Since it is a unique zero-arg stats endpoint, the risk is low, but nothing is stated about context or timing.

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

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

With no annotations, the description must carry the behavioral load. It does disclose the alphabetical ordering behavior, which is real context beyond the schema. However, it says nothing about pagination, whether 'limit' truncates the total set, or read-only safety, leaving meaningful gaps.

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

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

A single front-loaded sentence with no filler; the core action, ordering, and filter are all conveyed economically.

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 values need not be explained, and both parameters are documented. For a simple enumeration tool the description is nearly sufficient, with only usage routing against sibling search tools missing.

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

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

Schema description coverage is 100%, so both parameters are already fully documented with defaults and an example. The description's mention of the prefix filter adds no syntax or format detail beyond what the schema provides, making 3 the correct baseline.

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

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

States a specific verb (List) and resource (wiki pages) plus ordering semantics ('alphabetically'), which is more than a restatement of the name. It does not explicitly distinguish itself from the sibling wiki_search, so it falls short of a 5.

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

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

There is no when-to-use guidance and no mention of the alternative tools such as wiki_search for filtered/full-text lookups. The phrase 'optionally filtered by prefix' hints at scope but does not tell the agent when this tool beats a search.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether the listing is paginated or truncated, what the limit does, whether authentication is needed, or how large wikis are handled.

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

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

A single front-loaded sentence with no filler. It is efficient, though the brevity borders on under-specification rather than true conciseness.

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-value shape is covered elsewhere, and this is a simple zero-required-parameter listing tool. However, the unexplained limit parameter and absent pagination/usage context leave gaps an agent would need to probe.

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% and the sole parameter (limit, default 50) is never explained in the description. With one undocumented parameter, the description fails to compensate, so the agent cannot tell if limit caps results, pages them, or is a soft maximum.

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 clear verb+resource: 'List all categories on the wiki.' An agent can tell it is a broad category enumeration rather than a page-scoped lookup like wiki_get_page_categories, though the description never explicitly draws that distinction.

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 when-to-use guidance, no prerequisites, and no mention of sibling alternatives such as wiki_get_page_categories or wiki_get_category_members. The agent must infer the use case from the name alone.

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

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

No annotations are provided, so the description carries the behavioral burden. 'List all pages' clearly signals a read-only enumeration, and the domain note about Ray Peat's texts is helpful context, but nothing is said about pagination, how `limit` truncates results, or result ordering.

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 lines, front-loaded with the core action and namespace before the domain note and the example call. Every line is doing work, though the example title is illustrative rather than essential.

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 values need no explanation, and the read-only listing nature plus the title format are covered. The only gap is guidance on result volume/pagination relative to the limit parameter.

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?

Only one parameter (limit) with 100% schema coverage and a default of 50 already documented in the schema. The description adds no syntax or behavior for this parameter, so this is the baseline case where the schema does 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?

States a specific verb (List) and resource (pages in the Library namespace) plus the title format 'Library:<title>', so the agent knows exactly what comes back. It does not explicitly contrast itself with the nearby siblings wiki_list_all_pages or wiki_search, so sibling differentiation is only 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?

Gives a useful follow-up ('Read one with wiki_read(...)') and tells the agent what kind of content lives in this namespace, which implies when to use it. However, it never states when to prefer this over wiki_list_all_pages, wiki_list_categories, or wiki_search, and offers no exclusions.

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

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

With no annotations, the description carries the full behavioral burden but says nothing about error behavior for missing pages, permissions, or whether output is paginated/cached. The 'plain text' note is the sole behavioral hint and is partly redundant with the 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?

Two short sentences, front-loaded with the core action and no filler. It is efficient, though the extreme brevity leaves gaps that some added structure could have filled.

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

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

The output schema exists, so return values need not be explained, and both parameters are fully documented in the schema. Still missing is sibling differentiation and failure-mode context, leaving it minimally complete for a tool with 15+ near-name siblings.

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

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

Schema coverage is 100% and the schema already documents both parameters, including '0 = whole page, N = only section N' and the pointer to wiki_get_page_sections. The description's 'section number' wording adds no meaning beyond what the schema provides, 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 ('Read') and resource ('wiki page') plus the output format ('as plain text'), and the section caveat clarifies scope. However, it does not differentiate itself from close siblings like wiki_get_page or wiki_get_page_summary, which an agent must disambiguate on its own.

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 and no named alternatives despite a crowded wiki_* sibling set (wiki_get_page, wiki_get_page_summary, wiki_get_page_sections). The only conditional ('With a section number...') describes parameter behavior, not tool selection.

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

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

No annotations are provided, so the description carries the full burden; it discloses a genuine behavioral quirk (the built-in MediaWiki search is brittle on multi-word queries) and scopes the tool to wiki pages only. It does not mention pagination limits, ranking behavior, or auth needs, but the output schema is available to cover return values.

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 zero filler; the core action comes first and the routing note and caveat follow. 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?

With a full output schema and 100% parameter description coverage, the description only needs to add routing and behavioral context, and it does both. An agent has everything required to call the tool correctly and to know when to prefer corpus_search.

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% with both 'query' and 'limit' fully described in the schema, so the baseline is 3. The description mentions searching 'by title or content,' which adds a small amount of meaning about how the query is matched, but no syntax or format guidance 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 ('Search wiki pages by title or content') and identifies the underlying mechanism (MediaWiki search). It also explicitly separates itself from the full-corpus sibling, so an agent can select it 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?

Names the alternative (corpus_search) and the condition that selects it ('For the full corpus (interviews, books, ...)'), plus a caveat that multi-word queries may return zero hits, which tells the agent when to retry or switch tools. Both when-to-use and when-not-to-use are present.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose matching semantics (prefix vs substring vs fuzzy), case sensitivity, result limits, or whether it hits the wiki index versus a full-text index. Only the trivial fact that it is a suggestion endpoint is conveyed.

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?

One clean sentence with no waste and the purpose front-loaded. It is arguably too terse for the behavioral questions an agent may have, but nothing is padding.

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

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

An output schema exists, so return values need not be explained, and the tool is simple with one fully documented parameter. The remaining gap is routing: with ~30 siblings including wiki_search, the description should say when this autocomplete beats a real search.

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 single parameter is fully documented in the schema (100% coverage), including examples ('thyr', 'asp'), so the schema does the heavy lifting. The description adds only the notion that the query is a partial in-progress string, which is marginal value 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+resource: autocomplete of wiki page titles. It implies a title-only, incremental response, which differentiates it from wiki_search, though it never names that sibling explicitly.

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?

"While typing" hints at a typeahead context, but there is no explicit when-to-use guidance and no mention of wiki_search or corpus_suggest as alternative or complementary tools. The agent must infer that this is for incomplete-query title lookup only.

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