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

Annotations (readOnlyHint, idempotentHint, destructiveHint false) already cover the safety profile. The description goes much further by disclosing the Trash edge case (returns a status summary instead of content), the inherited_instructions semantics (outermost-first, inbox carries brain plus space root), and the missing-brain fallback behavior. This is far beyond what annotations provide.

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 long (several dense sentences) but every sentence delivers a specific fact: return field list, instruction-layer semantics, brain-fallback, Trash behavior, and required parameter. It is front-loaded with the core purpose, so the verbosity is earned rather than padded.

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 and only one simple parameter, the description must carry the full explanation of what is returned and how edge cases behave. It covers the complete return field list, the Trash summary shape, and the missing-brain fallback to instructions-get. Nothing an agent needs to call it correctly is omitted.

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%, so the parameter id is fully documented in the schema as 'Note ID (required)'. The description only repeats this as 'Required: id (integer)' and weaves id into the purpose, adding no new meaning such as format constraints, valid ranges, or id-related behavior. Baseline 3 is correct.

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

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

Opens with 'Get a single note by ID' and names the full content bundle (Markdown body, tags, container path, linked notes, backlinks, attachments, inherited_instructions), making it clearly distinct from notes-list, notes-restore, and instructions-get. The phrase 'so no separate instructions lookup is needed' explicitly differentiates it from the instructions-get sibling.

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 concrete routing: trashed notes are summarized and should be restored via notes-restore before reading/editing, and missing brain entries fall back to instructions-get with level 'brain'. It does not explicitly state 'use this instead of notes-list when you need one note by ID', but the ID-focused purpose implies this clearly, so it earns a 4 rather than a 5.

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