Skip to main content
Glama
arctop

Seamless

by arctop
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

notes_read

Read-onlyIdempotent

Retrieve a note by ID or slug from the current project, falling back to a global note with the same slug. Use it to read briefings, plan narratives, or notes created earlier.

Instructions

Read a note by id, or by slug within the current project (falling back to a global note of the same slug). A plan's slug is not a note's: a miss on one names the plan's narrative note.

Input Schema

NameRequiredDescriptionDefault
idNonote id (ULID); pass exactly one of id or slug
slugNonote slug, as briefings, plan compositions, and notes_create responses name notes (alias: name)
projectNoproject slug for the slug lookup; defaults to the bound session's project
sessionNothe session to act as: the name session_start returned, the cc/<id> or cx/<id> on your briefing's 'Seam session' line, or a session ULID. It scopes and credits this call. Defaults to this connection's session; pass it on every call when session_start reports the connection as stateless

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.4
    • addedInput schema / properties / session
      Added value: +{
+  "description": "the session to act as: the name session_start returned, the cc/<id> or cx/<id> on your briefing's 'Seam session' line, or a session ULID. It scopes and credits this call. Defaults to this connection's session; pass it on every call when session_start reports the connection as stateless",
+  "type": "string"
+}
  2. Changed1 schema field changedv0.1.3
    • changedInput schema / properties / id / description
      Previous value: -"note id (ULID)"New value: +"note id (ULID); pass exactly one of id or slug"
  3. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description still adds real behavior beyond them: the fallback chain from project-scoped slug to a global note of the same slug, and the caveat that a plan's slug is not a note's. Return shape is not described, but for a read it is largely self-evident.

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?

Two short sentences, lookup modes front-loaded, no padding. The trailing sentence about plan slugs is densely compressed and reads ambiguously on first pass, which costs a point against perfect concision.

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 lookup with full schema coverage, no output schema, and annotations carrying the safety profile, the description supplies the non-obvious resolution behavior (project-to-global fallback) that an agent needs in order to interpret a miss correctly.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema does not: the ordering semantics of the slug lookup (current project first, then global fallback), which is the parameter behavior most likely to surprise a caller.

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?

States a specific verb+resource ('Read a note') and two lookup modes (by id, by slug within project with global fallback). Clear and distinguishable from write-oriented siblings like notes_append or notes_create, though it never names a sibling to contrast against.

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

Usage Guidelines3/5

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

Conveys the resolution order (project slug, then global fallback) and warns about the plan-slug vs note-slug mismatch, which is useful context for when a lookup will miss. It does not say when to prefer this tool over recall, memory_read, or project-scoped alternatives, so guidance is implied rather than explicit.

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

Deploy Server

Other Tools