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

Annotations already declare readOnlyHint=true, so the description's mention of 'includes note citations when available' adds useful output behavior beyond the annotation, but it does not disclose other behavioral traits such as mode effects or limit semantics.

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, front-loaded with the verb, no redundant or filler 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 tool with three parameters and no output schema, the description is too sparse—it does not clarify the semantics of the 'mode' enum, the meaning of 'limit', or the structure of the answer, leaving significant gaps for the 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 0%, and the description only implicitly references the 'question' parameter; it does not explain the meaning of 'mode' or 'limit', so the description fails to compensate for the lack of schema documentation.

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

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

The description uses a specific verb ('Answers') and resource ('remio knowledge base'), and adds a distinctive detail (note citations), which clearly distinguishes it from siblings like remio_search_notes or remio_read.

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 about when to choose this tool over alternatives; the description only states what it does without mentioning scenarios 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?

Annotations already flag destructive behavior, and the description adds that state-changing commands need confirm=true, which is not captured in annotations. It also identifies itself as a compatibility entry point, adding context. However, it doesn't discuss output format or error handling, leaving some 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 paragraph that states purpose, lists commands, and ends with usage guidance. The command list is long but arguably necessary for a catch-all tool. No wasted filler, though it could have been more compact by omitting the enum duplication.

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 purpose, preference, and the confirm requirement, making basic invocation possible. However, with no output schema, it should explain what the tool returns or how args/pretty behave, which it doesn't. Adequate for a compatibility wrapper but not 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 0%, so the description must compensate. It only clarifies the confirm parameter; args and pretty are left entirely unexplained. The command list duplicates the schema enum, providing no new parameter-level 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 opens with 'Compatibility entry point for every remio CLI command' and enumerates all supported commands, making the tool's role unmistakable. It also differentiates from siblings by explicitly telling users to prefer the structured tools above.

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?

Provides explicit guidance: 'Prefer the structured tools above' directly tells when not to use this tool, and 'State-changing commands require confirm: true' gives a concrete usage condition. This is strong alternative/selection advice.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, signaling a non-read-only but non-destructive mutation. The description adds a valuable behavioral detail: adding by collection title auto-creates the collection if it doesn't exist. This goes beyond the annotations and describes a side effect not otherwise known.

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

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

The description is two sentences, with the most important action stated first. Every word contributes meaning, and there is no redundant filler. It is concise and well-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?

With 5 parameters, no output schema, and 0% schema description coverage, the description is too minimal to be complete. It doesn't explain the purpose of 'confirm', how to specify which collection when both ID and title are available, or what happens on removal when no collection is specified. The tool's full behavior is not adequately captured.

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

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

Schema coverage is 0%, so the description must compensate for documenting parameters. It explains that 'collection_title' can be used for adding and creates the collection if missing, but it does not explain the 'confirm' boolean, the relationship between 'collection_id' and 'collection_title', or the semantics of 'note_id' and 'action' beyond what the schema already shows. Many parameters remain underspecified.

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 function: 'Adds or removes a note from a collection.' This uses a specific verb and resource, and the additional detail about creating a collection by title adds precision. It is easily distinguished from sibling tools like searching or reading notes.

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

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

The description implies usage: you use this tool when you need to add or remove a note from a collection. However, it does not explicitly state when to prefer this over sibling tools, nor does it mention any prerequisites or exclusions. No alternatives are named, so guidance 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?

Annotations already declare readOnlyHint true, and the description adds that the CLI must be locally installed, which is a useful prerequisite. However, it does not disclose return format, error handling, or behavior when command is omitted, so transparency is moderate.

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

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

The description is a single, front-loaded sentence with no filler. Every word adds value, making it both concise and well-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 simple help tool, the description covers the core action but lacks details about output format, optional parameter behavior, and differentiation from remio_cli. Given no output schema, these gaps leave the description somewhat incomplete.

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 'command' parameter is an enum of CLI commands, and the description clarifies it refers to a locally installed remio CLI command. Since schema coverage is 0%, the description partially compensates but doesn't explain the effect of omitting the parameter or how to use the enum values.

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 returns authoritative usage for a locally installed remio CLI command, using a specific verb and resource. This distinguishes it from sibling tools like remio_cli, which presumably execute commands, by focusing on usage information rather than action.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives like remio_cli or other command-specific tools. The use case is only implied by the tool's name and description, with no mention of scenarios 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?

The description adds the behavioral detail 'Requires explicit confirmation for every call,' which is not present in the annotations. While the annotations already indicate destructiveHint=true, the confirmation requirement is a meaningful addition. It does not describe what gets destroyed or other side effects, but for a mutation tool with annotations, this is a useful extra behavior.

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

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

The description is a single concise sentence that communicates its core function and a key requirement. It is front-loaded with the primary action and adds the confirmation note without unnecessary verbosity.

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

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

This is a highly complex tool with 19 parameters, 7 enum actions, and no output schema or parameter descriptions, yet the description is only one sentence. It does not explain the range of actions, which parameters apply to which operation, or how confirmation works. The schema alone is insufficient for an agent to select and invoke 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 schema has 19 parameters with 0% description coverage, and the description adds no parameter-specific meaning. It only lists broad resource categories (notes, people notes, images, permissions, status) without mapping to any of the input parameters, actions, or options. With such low coverage, the description should compensate but fails to do so.

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 a mutation tool for notes and related resources ('Changes notes, people notes, note images, permissions, or status'). It distinguishes from read-only siblings like remio_search_notes and remio_read by signaling write functionality, though the verb 'Changes' is broad and doesn't enumerate specific operations like create or delete.

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 provides no explicit when-to-use guidance or alternatives. It does not differentiate this tool from siblings like remio_share or remio_collections, nor does it state when not to use it. The only contextual hint is 'Requires explicit confirmation,' which is a usage requirement but not a usage guideline.

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

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

Annotations already declare readOnlyHint=true, so the description only needs to add extra context. It does so by disclosing the conversion-to-markdown behavior and a caution about scope, providing useful behavioral details beyond the annotation.

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

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

Two sentences with no redundancy: the first sentence states the core actions, the second adds a necessary constraint. The description is front-loaded and 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 tool with 5 parameters and no output schema, the description covers the primary use case but omits parameter details (limit, offset, format) and does not explicitly state what the output will be, though it implies markdown for file reads.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'source' via 'note' vs 'file' and 'id_or_path' via 'by note ID' and 'local file', but leaves limit, offset, and format entirely unaddressed.

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

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

The description uses a specific verb+resource: 'Reads a remio note by note ID, or converts a local supported file to markdown.' It clearly distinguishes from siblings by adding the scope limit 'Do not read unrelated local files.'

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 provides clear context that this tool is for reading specific notes or local files, but does not explicitly name alternative tools like remio_search_notes for finding notes. The warning about unrelated files is a boundary constraint rather than a full 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?

Annotations already disclose destructive and open-world behavior. The description adds that the agent may invoke capabilities and requires explicit confirmation, which is useful. However, it does not elaborate on side effects, what capabilities mean, or what happens to the project directory, leaving gaps beyond the annotations.

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

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

Two sentences, front-loaded with the core action, followed by a pertinent safety note. No irrelevant details or repetition, making it appropriately concise.

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

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

This is a complex tool with 8 parameters, no output schema, and open-world/destructive annotations. The description is too sparse to cover the likely side effects, return format, or parameter usage details. The confirmation note is helpful but insufficient for such a high-stakes operation.

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% parameter coverage in the description, it must compensate. It provides semantics for 'project_dir', 'capabilities', and 'confirm', but leaves model, prompt, session_id, timeout_ms, and system_prompt entirely unexplained, so the compensation is only partial.

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 ('Runs') and resource ('a remio Agent'), with a project directory as the context. This distinguishes it from read/search/ask siblings, though it doesn't specify what the agent actually accomplishes beyond invoking capabilities.

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 offers no guidance on when to use this tool versus alternatives like remio_ask or remio_syscall. The only hint is that it may invoke capabilities and requires confirmation, which is more of a safety warning than a usage guideline.

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

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

Annotations already declare readOnlyHint=true, and the description aligns with that by describing a search operation. The description adds useful context about the breadth of content searched (notes, files, email, etc.) but does not disclose return format, pagination, or other behavioral details beyond what annotations provide. Given the annotation coverage, this is adequate but not richly 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 two sentences, front-loaded with the core action and scope, and ends with a strategic usage tip. Every sentence earns its place, and there is no redundant repetition of the tool name or title.

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

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

This is a high-complexity search tool with 15 parameters, no required fields, and no output schema, so the description needs to provide substantial guidance. It covers purpose and preference but omits essential context about parameter usage, result shape, pagination, or edge cases. The description is minimal and leaves the agent to infer too much from parameter names alone.

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

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

Schema description coverage is 0%, so the description bears the burden of explaining parameters. However, it only lists content categories (notes, files, email, Slack, meetings) without mapping these to any of the 15 parameters. It does not clarify query syntax, filter semantics, sort options, or limit behavior, leaving parameter usage mostly undocumented.

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 a search operation over the remio knowledge base, enumerating content types like notes, files, email, Slack, and meetings. It also distinguishes itself from the read-by-ID sibling tool by urging preference for search before direct reads.

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 explicitly states when to use this tool ('Prefer this before reading a note by ID'), providing a direct usage guideline and implicitly distinguishing it from remio_read. This is clear, actionable guidance for 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?

The description discloses that explicit confirmation is required, which is a behavioral trait not captured by the annotations. It also names the three distinct actions including the destructive 'revoke'. While annotations already flag destructiveness, the confirmation requirement adds meaningful context.

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, compact sentence that is front-loaded with the primary action and covers all three modes. No unnecessary words or repetition.

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 with only three parameters and no output schema. The description covers the core behavior and the confirmation caveat, but could benefit from clarifying what 'refresh' does (e.g., invalidates the old URL). Overall, it is sufficiently complete for a tool of this 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?

With 0% schema description coverage, the description compensates by explaining the semantics of the action values (publish, refresh, revoke) and the confirmation requirement. It does not explicitly describe note_id, but its meaning is self-evident from the tool's purpose.

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 function: publishing, refreshing, or revoking a public note link. The verb and resource are specific and distinguish it from sibling tools like remio_read or remio_search_notes.

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 its use case—when you need to manage public sharing of a note—but does not explicitly compare it with alternatives or state when not to use it. It lacks explicit exclusionary guidance, but the purpose is clear enough for basic 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?

The description discloses important behavioral traits beyond the minimal annotations: changes require explicit confirmation, and removing a folder preserves already-created notes. This adds meaningful safety context that the readOnlyHint and destructiveHint booleans do not convey, though it doesn't cover all actions (e.g., pause/resume effects).

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

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

The description is two sentences, front-loaded with the core purpose, and every clause adds value. It avoids repetition or filler.

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

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

The tool has multiple actions and no output schema, yet the description only elaborates on 'remove' and the confirmation requirement. It does not explain what happens with 'add', 'pause', 'resume', or what the result of 'list' looks like. This is incomplete for a multi-action 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?

With 0% schema description coverage, the description must compensate, but it only indirectly explains the 'action' and 'confirm' parameters. The 'path' parameter is completely unexplained, and the enum actions like 'pause' and 'resume' are not elaborated. This falls short for a tool with few 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 tool 'lists or changes folders that remio indexes' with a specific verb and resource. While it doesn't explicitly differentiate from sibling tools, the focus on sync folder management is distinct from other remio tools like remio_notes or remio_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 implies when to use the tool: to manage sync folders. It provides some contextual guidance by noting that changes require confirmation, but it does not explicitly contrast with alternative tools or state when not to use it.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true. The description adds valuable context by warning about 'arbitrary side effects' and the requirement for 'explicit confirmation', which goes beyond the annotations and informs the agent of the risky and user-confirmation-dependent nature of the 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 a single concise sentence, front-loaded with the tool's purpose and followed by the critical safety caveats. Every word earns its place, with no redundancy or filler.

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

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

Despite being a potentially dangerous and complex syscall runner with no output schema and undocumented parameters, the description provides minimal context beyond the escape-hatch nature and confirmation requirement. It does not explain what a syscall is, what actions/payloads are expected, or what the response looks like, making it inadequate for safe and correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate by explaining parameters, but it does not mention 'action', 'confirm', or 'payload' at all. The property names are somewhat self-explanatory, but no semantics are added, leaving the agent to guess what values are valid or how they interact.

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 an escape hatch for running a remio syscall not covered by other sibling tools, which distinguishes it from the more specific tools. The title adds the verb 'Run' and resource 'remio syscall', making the purpose reasonably clear, though 'advanced' and 'not represented above' are somewhat vague.

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 indicates this tool should be used for syscalls 'not represented above', providing a clear when-to-use condition relative to sibling tools. It also states that it 'always requires explicit confirmation', which tells the agent that a confirm parameter must be provided, serving as a usage prerequisite.

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 readOnlyHint annotation already signals safe read-only behavior. The description adds a valuable behavioral trait: fetching never creates a remio note, which clarifies side effects beyond what the annotation provides. It does not mention other behaviors like rate limits or response format, but the added note is meaningful.

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

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

The description is two short, front-loaded sentences with no redundant wording. It efficiently states the tool's function and a key behavioral note, earning a perfect score for conciseness and structure.

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 7 parameters, 1 required, and no output schema, the description is too thin to be complete. It omits parameter semantics, return-value expectations, and any discussion of when to prefer alternatives. The agent would need to guess crucial details like what 'freshness' values mean or what the response contains.

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

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

Schema description coverage is 0%, so the description must compensate. It only vaguely references 'search' and 'extraction' (which map to the action parameter), but fails to explain query, url, count, media, region, or freshness. The agent is left to infer from parameter names, making this inadequate.

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 performs 'web search or clean web-page extraction', explicitly targeting web content. This distinguishes it from sibling tools like remio_search_notes (which searches notes) and remio_read, making the purpose unambiguous.

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

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

The description provides clear context that this is for web content, and the note 'Fetching never creates a remio note' gives a specific behavioral guideline. However, it does not explicitly name alternatives or state when not to use the tool, so it falls short of full exclusion guidance.

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