read_noteRetrieve a full note from the vault using its note_id, as returned by search, to inspect or edit its complete content. Supports an optional max_chars limit for truncated reads.
Read a full note from the vault by its id (as returned by search).
| Name | Required | Description | Default |
|---|---|---|---|
| note_id | Yes | ||
| max_chars | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.6.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Full note' usefully signals that complete content (not a snippet) is returned, but it omits what happens when the note is missing, how max_chars truncates output, and any permission requirements. An output schema exists, which lightens the return-value burden.
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 sentence with no filler, front-loading the verb and resource while embedding the id-provenance hint in a parenthetical. Every element 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 two-parameter read tool with an output schema, the description covers the core contract. The remaining gap is max_chars truncation semantics and error/not-found behavior, which are minor for this tool class.
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 note_id's provenance ('as returned by search'), which adds genuine value, but says nothing about max_chars (default 6000) or its truncation behavior — half the parameters remain 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?
States a specific verb ('Read') and resource ('a full note from the vault'), and the phrase 'full note' implicitly distinguishes it from the sibling search tool that returns summaries. It stops short of explicitly naming search as the alternative, so it isn't quite a 5.
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 clause 'by its id (as returned by search)' implies the workflow — ids come from search — which is useful context for when to reach for this tool. However, there is no explicit when-to-use vs when-not guidance or routing to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.