Skip to main content
Glama

local-mcp

by com.local-mcp

Read Note

read_note
Read-only

Reads the full content of a note by name or ID.

CHECK body_format BEFORE WRITING THE BODY BACK. "markdown" means the note's formatting (headings, bold/italic, bullet/numbered lists, checkboxes, links, monospaced) came through as Markdown and update_note takes it back as-is — literal *, backticks and brackets arrive backslash-escaped so they survive the round trip. "plain_text" means the formatting could NOT be recovered and body is flat text: writing it back REPLACES the note's structure with flat text, so edit the note by other means (or ask the user) instead of rewriting the whole body.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
note_idNo
note_nameNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNo
bodyNo
nameNo
folderNo
modifiedNo
body_formatNoWhat `body` actually is. "markdown": the note's formatting survived and update_note accepts this body back unchanged. "plain_text": the formatting could not be recovered — writing this body back flattens the note.

TDQS

B3.4/5.0
Behavior5/5

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

Annotations already mark this as readOnly and non-destructive, and the description adds genuinely valuable behavioral context by explaining the body_format field and the consequences of writing a plain_text body back. This goes beyond the annotations and warns the agent about a real round-trip hazard that is not visible anywhere else.

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

Conciseness4/5

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

The first sentence is a strong front-loaded purpose statement. The longer body_format paragraph is somewhat verbose and focuses on writing back, but it is relevant to interpreting the read result and earns its place despite being slightly longer than ideal.

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

Completeness3/5

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

The critical body_format semantics are covered, and an output schema exists to explain return values. However, the complete absence of parameter-selection guidance is a meaningful gap for a tool that can look up by name or ID, especially with zero required parameters in the schema.

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

Parameters2/5

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

Schema description coverage is 0% and the schema gives only 'note_id' and 'note_name' as bare strings. The description adds only 'by name or ID', which maps to the two parameters, but it does not clarify whether one is required, what happens if both are provided, or whether names must be exact.

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

Purpose4/5

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

The description opens with 'Reads the full content of a note by name or ID', which clearly states the verb, resource, and scope. The phrase 'full content' hints at a distinction from list/search tools, but it does not explicitly name or distinguish sibling tools like list_notes or search_notes.

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

Usage Guidelines2/5

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

No guidance is given on when to choose read_note over list_notes, search_notes, or other note-related tools. The body_format warning concerns downstream update_note behavior, not the selection of this read tool versus alternatives, so the 'when to use' question is left unaddressed.

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

All local-mcp toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0
Disambiguation3/5

Many tools are clearly distinct per app (e.g., chrome_*, safari_*, m365_*), but there is notable overlap between generic file tools like `file_list` and `finder_list`, both listing files; `search_contacts` and `list_contacts` serve similar purposes; `report_friction` and `report_problem` both send feedback to the team. The large number of tools with similar purposes in different domains creates moderate ambiguity for an agent.

Naming Consistency4/5

The naming convention is very consistent overall: most tools follow a `{app}_action` or `verb_noun` pattern (e.g., `chrome_click`, `create_calendar_event`, `list_reminders`). There are minor deviations like `lmcp_install_upgrade` (two verbs) and `complete_omnifocus_task` vs. `complete_reminder` (inconsistent verb placement). Still, the pattern is predictable and readable across the full set.

Tool Count2/5

With 225 tools, the surface is extremely large and heavy. While it covers many distinct domains (browsers, mail, calendar, files, notes, reminders, video editing, web automation, etc.), the sheer number makes it hard to navigate and likely includes many rarely-used tools. This is far beyond the well-scoped range of 3-15 tools and feels excessive even for a 'local everything' MCP server.

Completeness3/5

For many app integrations, the tool set provides solid CRUD coverage (e.g., Calendar has create, read, update, delete; Apple Notes has create, read, update, list, search; OmniFocus has create, list, search, complete). However, some areas are incomplete: for example, there is no tool to create a new Mail folder or delete notes. The 'web' tools lack a clear update/delete for saved sessions. The suite is broad but has notable gaps within individual domains.

Resources