:

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

With no annotations, the description carries the full burden. It discloses offline operation, local-only scope, no rate-limit cost, and the snippet marker format. Lacking are details on what happens if no results or an error occurs, but the provided behavioral notes are substantive for a read-only search 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?

The description is extremely concise at three sentences, with the most critical information (purpose, technology, offline nature, scope, and limitation) presented upfront. Every sentence adds unique value, achieving high density without sacrifice of 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 moderate complexity of an FTS tool with two parameters and no output schema, the description covers the key aspects: what is searched, performance (millisecond-fast), offline property, and snippet format. Minor gaps exist (no mention of return structure or error handling), but overall completeness is high.

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 50% (only 'query' has a description). The description adds context about FTS5 syntax (plain words, phrases, AND/OR/NOT) and the fields searched, which extends what the schema provides. It implicitly describes the limit parameter's purpose but does not provide per-parameter enrichment beyond the schema baseline.

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

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

The description clearly identifies the tool as performing full-text search over locally stored answers from oe_ask/oe_article_get, specifying the searched fields (questions, titles, answer bodies). It distinguishes itself from the sibling tool oe_history_list by noting coverage of only local data, leaving no ambiguity about its purpose.

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

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

The description states when to use (for fast offline local search) and explicitly advises against using it for complete server-side history, directing users to oe_history_list instead. However, it does not provide guidance on prerequisites or when this tool should be avoided entirely.

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 fully discloses caching behavior, pending status handling, blocking via wait_for_completion, and refresh semantics. It explains that completed answers come from local SQLite store with from_cache:true.

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 paragraph that efficiently conveys key information with good front-loading. Could be slightly more structured (e.g., bullet points) but is concise overall.

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 9 parameters and no output schema, the description covers core usage and behavioral nuances. Missing details on some parameters and output format, but adequate for a fetch-and-cache tool with sibling context provided externally.

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 22%, so the description must compensate. It explains article_id (UUID or URL), wait_for_completion, refresh, timeout_sec, poll_interval_ms, but omits include_bibtex, save_artifacts, crossref_validate, strip_citation_markers. Adds value but not enough for the low schema 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 clearly states the tool fetches an article by id or URL, and explicitly positions it as the 'fetch-later half of fire-and-forget oe_ask', distinguishing it from siblings like oe_ask, oe_answers_search, and oe_article_set_access.

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 tells when to use (after oe_ask) and provides options: retry, wait_for_completion, or refresh. It lacks explicit when-not-to-use statements but the context is clear.

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

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

With no annotations, the description fully covers behavioral aspects: it specifies HTTP method (PATCH), explains the effect of true/false on access levels (ANYONE_WITH_LINK vs CREATOR_ONLY), notes prerequisites (ownership, relay connection), and mentions the return of a shareable URL and the security warning.

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

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

The description is two clear sentences plus a warning, all front-loaded with the verb and resource. Every sentence adds value without redundancy.

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 no output schema, the description states the return value (shareable URL). It covers prerequisites, side effects, and security implications, making it complete for a mutation 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 coverage is 100%, but the description adds meaning beyond schema by explaining the access levels corresponding to boolean values and that article_id accepts both UUID and full URL. This enhances the agent's understanding.

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 starts with 'Set a conversation's share visibility', clearly stating the verb and resource. It distinguishes from siblings by specifying this is for sharing access, while tools like oe_article_get are for retrieving content.

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

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

Explicitly states when to use (to change public/private status), and provides conditions: you must own the conversation and have the relay extension connected. Also warns against publishing PHI, guiding appropriate use.

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 fully bears the burden. It discloses the fire-and-forget return (immediate pending), blocking with wait_for_completion, reliance on relay extension, and deprecation of direct POST. No contradictions.

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 paragraph front-loaded with core behavior and key distinctions. It is dense and efficient, though slightly structured as a block of text. Every sentence adds value.

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?

Despite good coverage of core behavior and two key parameters, with 13 parameters and no output schema, the description omits details on many parameters (e.g., timeout_sec, article_type, include_bibtex) and the full output structure. It is adequate but not fully complete given complexity.

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 only 8% (only original_article_id described). The description adds meaning for wait_for_completion and original_article_id, but covers few of the 13 parameters. Many defaults are listed but not explained in context, so it partially compensates.

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

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

The description clearly states it creates a question, distinguishes fire-and-forget vs. blocking modes, and explicitly differentiates from oe_article_get for fetching results. It also mentions follow-up usage via original_article_id, providing a specific verb and resource.

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

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

The description gives explicit guidance: when to use fire-and-forget (default) vs. wait_for_completion, how to do follow-ups, and the requirement of a connected relay extension. It implies context (browser tab free for other sessions) and notes deprecation of a direct method.

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 full burden. It discloses that the tool performs a full network round-trip and is non-destructive (checking validity). The behavior is simple and well-described.

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 purpose and alternative. No wasted words.

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

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

Tool is simple with no parameters and no output schema. Description fully covers what the tool does and how it differs from alternatives, making it complete for selection and invocation.

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

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

No parameters exist, so the description does not need to add parameter information. Baseline is 4, but the description is perfectly adequate given 100% schema coverage and empty input 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?

Description clearly states the tool checks if the local OpenEvidence session is valid and distinguishes it from the sibling oe_health tool by specifying a full network round-trip versus a fast pipeline-connectivity check.

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

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

Explicitly states when to use this tool (check session validity) and when to use the alternative oe_health (fast connectivity check), providing clear usage 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?

With no annotations, the description only discloses idempotency. It fails to mention permissions, error behavior, or side effects. For a mutation tool, this is insufficient transparency.

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 very concise, with one main sentence plus a note on idempotency. However, it sacrifices completeness for brevity; a tool with two required UUID parameters would benefit from slightly more context.

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 lack of annotations and output schema, the description is incomplete. It does not explain return values, prerequisites, or error conditions, which are critical for an agent to use 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?

Schema description coverage is 0%, yet the description adds no information about the parameters beyond their names. It does not explain what collection_id or article_id represent or how to obtain them, leaving the agent to rely solely on parameter names.

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

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

The description clearly states the action 'Add a chat (article) to a collection', which effectively conveys the tool's purpose. It distinguishes from sibling tools by the specific verb 'add', but does not explicitly differentiate from other collection manipulation 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?

No guidance is provided on when to use this tool versus alternatives like oe_collections_bulk_apply or other collection tools. The description only mentions idempotency, which is a behavioral trait, not usage context.

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, and the description only states 'Create a new collection' without disclosing behavioral traits such as authentication needs, idempotency, limits, or side effects. For a creation tool, this is insufficient.

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 very short (two sentences) and front-loaded with the main action, but it omits important details, making it too concise for a creation tool that requires more context.

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 lack of annotations, output schema, and schema descriptions, the description should compensate with more completeness. It does not cover return values, errors, or usage constraints, leaving significant 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?

The input schema has 0% description coverage, meaning the schema itself provides no explanations. The description adds only a naming convention, not field-specific semantics like what valid values are or how description is used.

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 explicitly states 'Create a new collection', which clearly identifies the action and resource. Among siblings with various collection operations, 'create' is unambiguous. The naming convention hint further clarifies purpose.

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

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

The description gives a naming convention ('agent-managed names start with #') that implies agent usage, but does not provide explicit guidance on when to use versus alternatives, nor any conditions 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 full burden of behavioral disclosure. It states the action and idempotency but does not explain behavior if the database exists, error conditions, or permissions needed. Adequate but could be more transparent.

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 extremely concise: two sentences totalling 20 words. Every word is necessary: the action, the path with default, and the idempotency note. No wasted text.

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

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

For a simple tool with no parameters and no output schema, the description provides the essential information: what it creates, where, and its idempotence. It could mention that this tool should typically be called before others, but given its simplicity, it is largely 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?

There are no parameters, and schema coverage is 100% (empty). According to guidelines, 0 parameters yields a baseline of 4. The description adds no parameter information, which 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 clearly states the tool's purpose: 'Create the local SQLite mirror' at a specific path, with a default provided. The verb 'Create' and resource 'SQLite mirror' are specific, and the tool is distinct from siblings which operate on collections.

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 does not explicitly state when to use this tool versus alternatives. While it mentions 'Idempotent', which suggests safe repeated use, there is no guidance on prerequisites, ordering, or when initialization is necessary. Usage is implied but not explicit.

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 bears full responsibility. It discloses that the result includes nested questions, which adds some behavioral context, but lacks details on side effects, permissions, or error conditions.

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 sentence, concise and front-loaded, with no superfluous 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?

For a simple fetch with one parameter and no output schema, the description adequately states the purpose and mentions the nested structure, but fails to describe the full return format or confirm whether it returns all fields.

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

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

With 0% schema description coverage, the description should compensate. It only repeats 'by id' without explaining the uuid format or providing examples, adding minimal 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?

The description clearly states the verb 'Fetch' and the resource 'collection by id', and distinguishes the tool by mentioning included nested questions (membership list), setting it apart from siblings like oe_collections_list.

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 when you have a collection id and want single collection with membership), but there is no explicit guidance on when to use this versus alternatives like oe_collections_list or oe_collections_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?

With no annotations, the description carries full burden. It indicates a read-only listing operation but lacks details on pagination, sorting, or limits. For a zero-parameter tool, the behavioral disclosure is minimal but acceptable.

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?

Single sentence, no extraneous words, front-loaded with the core action. 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 simple list with no parameters and no output schema, the description adequately covers the tool's purpose and scope. Could add detail about ordering or result limits, but not critical.

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

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

Input schema has zero parameters, so schema coverage is 100%. Per rules, baseline is 4. The description adds no parameter info, which is appropriate given no parameters exist.

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 'List all collections owned by the authenticated user' uses a specific verb (list) and resource (collections) with clear scope (owned by user), distinguishing it from sibling tools like oe_collections_create or oe_collections_get.

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 among many sibling collection tools. Does not mention scenarios where list is appropriate or when another tool like oe_collections_unsorted might be better.

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 cover behavioral traits. It only states what the tool counts and timestamps, but does not mention whether it is read-only, if it requires authentication, or if there are any side effects or limitations (e.g., 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?

The description is extremely concise—only one sentence—yet conveys the tool's core purpose. It is front-loaded with the key counts and timestamps. No unnecessary words.

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

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

The description lacks detail on the return format (e.g., structure of the counts object, how timestamps are represented). Given no output schema, this information would be helpful. Additionally, with many sibling tools, more context on distinguishing usage would improve completeness.

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 no parameters, which the schema reflects completely (100% coverage). The description adds value by listing the specific items counted (chats, collections, etc.), which is meaningful beyond the empty schema.

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

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

The description clearly states it returns counts and last sync timestamps for specific items (chats, collections, hashtag, memberships, unsorted). The verb 'summary' aligns with the tool's name. However, it does not differentiate from siblings like oe_collections_list or oe_collections_get, which could be used for similar purposes.

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

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

No explicit guidance on when to use this tool versus alternatives. The description implies it is for getting summary data, but it does not state when not to use it or mention other tools that might be better suited for specific scenarios.

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

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

The description discloses the pruning behavior, which is a destructive side effect. However, it does not mention other behavioral traits such as idempotency, authentication requirements, or the effect of the rate_seconds parameter. With no annotations, the description carries the full burden but only partially fulfills it.

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 consists of two short, front-loaded sentences with no fluff. Every phrase conveys essential action: refreshing and pruning.

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 tool has only one optional parameter and no output schema, the description is moderately complete. It explains the main action but omits details about the parameter's role and potential side effects, leaving gaps for a sync operation in a multi-tool context.

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

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

The description does not mention the only parameter, rate_seconds, which has 0% coverage in the schema. The parameter name and constraints suggest it controls pacing, but the description provides no clarification, leaving the agent to infer its 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?

The description clearly states it refreshes collections and memberships from API into local SQLite and prunes removed items. This distinguishes it from sibling tools like oe_collections_list or oe_collections_get, which do not perform sync or local storage.

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 it is for syncing and pruning, but does not explicitly state when to use it versus alternatives like oe_collections_db_init or oe_collections_sync_history. No when-to-use or when-not-to-use guidance is 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?

No annotations are provided, so the description carries the full burden. It discloses the incremental behavior and pagination, but does not explain what 'upsert chats' entails in terms of database mutation, idempotency, or potential side effects. The description adds moderate behavioral context but lacks specifics about the operation's safety or impact.

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

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

The description is two sentences, no wasted words, and front-loads the primary action. Every sentence adds value, making it highly efficient.

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 four parameters and no output schema, the description is sparse. It does not cover return values, error conditions, prerequisites (e.g., whether oe_collections_db_init must be called first), or the relationship with sibling tools like oe_collections_sync_db. The lack of detail leaves significant gaps for an AI agent to use this 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?

The input schema has 0% description coverage, yet the description only indirectly references the 'full' parameter via 'incremental by default'. Parameters like 'pages', 'page_size', and 'rate_seconds' are not explained at all. The description adds almost no meaning beyond the parameter names, which is insufficient for a tool with four 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 description clearly states the action: paginate and upsert chats, and identifies the specific API endpoint ("/api/article/list"). It also mentions the incremental behavior which distinguishes it from a full sync. This is specific and differentiates from sibling tools like oe_collections_sync_db.

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 mentions incremental mode and stopping condition (first all-known page), which implicitly suggests when to use (incremental sync) vs full sync ('full' parameter). However, it does not explicitly compare to other siblings like oe_collections_sync_db or provide when-not-to-use scenarios. The usage guidance is implied but not explicit.

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 does not explicitly state read-only behavior, but implies a read operation. It does disclose the return shape ({unsorted_count, shown, items[]}) which provides some insight into what the tool returns. However, it lacks details on pagination, performance, or error handling.

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 sentence defining functionality followed by a brief return value structure. It is front-loaded, concise, and every element serves a purpose with no redundancy.

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 description covers the purpose and return format fully. However, given no output schema, it could mention edge cases (e.g., empty list) or error conditions. Still, for a simple list tool, it is adequate.

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

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

The input schema has two parameters (limit, preview_chars) with defaults and ranges, but 0% schema description coverage. The description does not explain their purpose beyond what can be inferred from names. Since the coverage is low, the description should compensate, but it does not add any 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?

The title and description clearly state the tool lists chats not in any '#'-prefixed collection. This differentiates it from sibling tools like oe_collections_list which lists collections, or oe_collections_summary which provides summaries.

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 does not provide any guidance on when to use this tool versus alternatives. No instructions on prerequisites, limitations, or scenarios where another tool would be more appropriate.

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

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

No annotations provided, so description carries full burden. It discloses local, fast, no network call. However, it does not specify what the output looks like (e.g., boolean, error message), which would be helpful for a complete transparency.

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, no wasted words. Information is front-loaded and efficiently structured.

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, simple health check tool without output schema, the description provides all necessary context: purpose, usage guidance, and behavioral trait (local). Complete enough for agent selection.

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?

No parameters, so baseline is 4. Description adds context by explaining the tool's action beyond the empty schema, such as being local and fast.

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

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

Description clearly states 'Millisecond-fast local check of the relay pipeline (daemon + browser extension)', specifying the verb (check) and resource (relay pipeline). It distinguishes from siblings like oe_auth_status and oe_ask.

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

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

Explicit guidance: use this to confirm pipeline is up before oe_ask, and use oe_auth_status only for login session verification. Provides clear context for when to use this tool vs 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?

With no annotations, the description must disclose behavioral traits but only says "list." It fails to mention pagination behavior implied by limit/offset, whether it returns only the authenticated user's history, or any rate limits. The minimal description does not compensate for missing annotations.

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

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

The description is extremely concise at one sentence, but this brevity sacrifices necessary information about parameters and usage context. It is under-specified rather than efficiently structured, failing to earn its place by omitting critical details.

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 three parameters, no annotations, and no output schema, the description is severely incomplete. It lacks details on pagination, search functionality, return value format, and any prerequisites, making it insufficient for effective tool use.

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 description does not explain any of the three parameters (limit, offset, search). The agent receives no semantic help beyond the schema's basic type/constraint info, leaving the parameters largely unclear.

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 "List question history from OpenEvidence account," clearly identifying the action (list) and resource (question history). It distinguishes from sibling tools like oe_ask (ask questions) and oe_collections_list (list collections), though it could be more specific about what constitutes 'history.'

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention any conditions for use, prerequisites, or when not to use it, leaving the agent without contextual decision support.

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; description carries full burden. Discloses that it parses into Q&A turns (question, answer as markdown, references) and specifies authentication requirements (public vs private). Lacks explicit read-only declaration but 'Read' implies it.

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?

Extremely concise: three sentences covering purpose, setup, and alternative. No redundant information. Front-loaded with primary action.

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

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

With no output schema, description explains output format (Q&A turns with markdown and references). Covers prerequisites and distinguishes from sibling. Minor gap: no explanation of strip_citation_markers behavior.

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

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

Schema coverage is 50% (url described, strip_citation_markers not). Description adds context on URL format and output type but does not explain the boolean parameter strip_citation_markers, leaving it unclear.

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?

Clearly states it reads an OpenEvidence conversation from an /ask/<id> link and parses it into Q&A turns. Distinguishes from sibling oe_article_get which retrieves raw API payload.

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 explains when to use vs not: 'Use oe_article_get when you want the raw API payload + saved artifacts instead.' Also details setup needs for public vs private conversations.

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