Letterly

Get Note

get_note

Read-onlyIdempotent

Get a single note by its ID with metadata and a character-range window over its transcription.

The MCP response is capped at 24,000 characters. Since a note's transcription can be arbitrarily long, you can read it in chunks using offset and length. The response header always shows the total number of characters and the exact range currently shown; when more text follows, it names the next offset to continue with.

Rewrites (including translations) are listed with their IDs and char counts — use get_rewrite(note_id, rewrite_id) to read their text.

Args: note_id: The unique numeric ID of the note. offset: Starting character offset in the transcription (0-based). Must be 0 or more and not past the end of the text. Default 0. length: Max characters to return, 0 or more. length=0 returns metadata only. If omitted, returns as much as fits within the MCP response budget.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "note_id": "<note_id>"
    },
    "name": "get_note"
  }
}

Input Schema

Name	Required	Description	Default
`length`	No
`offset`	No
`note_id`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Adds substantial behavior beyond the readOnly/idempotent annotations: a 24,000-character response cap, arbitrarily long transcriptions, chunked reads via offset/length, a response header showing total characters and current range, next-offset hints, and rewrite listings with IDs and char counts. This is rich operational context for correct invocation and pagination.

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

Conciseness5/5

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

Front-loads the purpose, then groups pagination behavior, rewrite redirection, and parameter documentation into short, scannable sections. Every part carries necessary information given the 0% schema coverage; there is no filler.

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

Completeness5/5

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

For a read-only single-item retrieval tool, the description covers purpose, chunking, metadata-only mode, and rewrite crossover, while annotations cover safety and the output schema covers return shape. Nothing critical for correct invocation is missing.

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

Parameters5/5

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

Schema description coverage is 0%, but the Args section fully defines all three parameters: note_id as the unique numeric ID, offset as a 0-based nonnegative position within the transcription, and length as the max characters with length=0 returning metadata only and omitted length filling the response budget. It compensates completely for the missing schema documentation.

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

Purpose5/5

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

States a specific verb and resource: 'Get a single note by its ID' with metadata and a character-range window over its transcription. It explicitly routes rewrite text to get_rewrite, making it easy to distinguish from get_rewrite/get_rewrites and from list/search tools.

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

Usage Guidelines4/5

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

Explains the primary use case of retrieving a note when the ID is known and names get_rewrite(note_id, rewrite_id) as the alternative for rewrite text. It also clarifies length=0 and offset chunking behavior, though it does not explicitly compare against list_notes or search_notes.

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

All Letterly tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.