get_note

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It clearly states this is a read operation that returns markdown content, implying no side effects. However, it does not disclose error behavior (e.g., missing note), whether frontmatter is included, or explicitly confirm the operation is read-only. The basic behavior is clear, but the description adds no detail beyond the verb 'Read'.

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 that is concise, front-loaded with the action, and contains no filler words or repetition. It effectively states what the tool does without 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?

The description is complete enough for a simple one-parameter read tool. It specifies the return as 'full markdown content', which tells the agent what to expect. The parameter schema covers how to supply the path. While there is no explicit mention of error handling or output format, the lack of an output schema does not make the description incomplete given the clear 'read content' semantics.

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 100% description coverage; the 'path' parameter already includes a detailed explanation (vault-relative, example, instruction to use search/list). The tool description only says 'by its vault-relative path', which adds no new meaning beyond what the schema already provides. Baseline of 3 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 action (Read), the resource (full markdown content of a note), and the method (by vault-relative path). This distinguishes it from sibling tools like get_active_note, which likely operates on the currently active note without requiring a path, and search_notes, which performs a query.

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 get_active_note or search_notes. The only hint is in the parameter description, which suggests using a path returned by search/list, but that does not clarify the use case for get_note itself. No exclusions or alternative routing are mentioned.

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