Skip to main content
Glama
arctop

Seamless

by arctop
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

notes_append

Append a UTC-timestamped line to an existing note by ID, preserving its ID and place in plan composition while adding to investigation logs or decision records.

Instructions

Append a UTC-timestamped line to an existing note's body, by id. Use it when a note is already the right home for what you learned -- a running investigation log, a decision record gaining one more data point -- so the note keeps its id, slug, and place in any plan composition instead of fragmenting into near-duplicates. Appending only ever adds: use notes_update to correct or restructure what is already there, and notes_create when the finding deserves an artifact of its own. Needs the note's id (ULID), which notes_create returns and briefings and plan compositions carry; notes_read resolves one from a slug.

Input Schema

NameRequiredDescriptionDefault
idYesnote id (ULID)
bodyYestext to append (aliases: content, text)
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. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false; the description is consistent and adds the additive-only guarantee ('Appending only ever adds'), which tells the agent nothing existing is lost. It doesn't restate idempotency or explain the mutation's full effect, but it meaningfully supplements the safety profile.

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?

Front-loads the verb and mechanism, then routes to alternatives. Three dense sentences all carry information, though the middle sentence's framing is slightly elaborate for the payload being described.

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

Completeness4/5

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

Covers purpose, id sourcing, alternatives, and additive semantics for a mutation tool with clear annotations and no output schema. The only minor gap is that it never indicates what a successful append returns, but with annotations covering safety and a full-coverage schema this is a small omission.

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?

With 100% schema coverage the baseline is 3, but the description adds real meaning: it explains that the id is a ULID sourced from notes_create, briefings, or plan compositions, and that notes_read resolves one from a slug. This is operational guidance the schema does not provide.

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 precise verb (append), resource (an existing note's body), the key behavior (UTC-timestamped line) and the addressing key (by id). It explicitly distinguishes itself from notes_update and notes_create, so an agent can separate it from siblings without reading any schema.

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

Usage Guidelines5/5

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

Gives both when-to-use ('when a note is already the right home ... a running investigation log, a decision record') and when-not-to-use ('use notes_update to correct or restructure ... notes_create when the finding deserves an artifact of its own'). Alternatives are named with the selecting condition.

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