Read a remio note or local file

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.