Skip to main content
Glama

RelayLink

Save to the notebook

notebook_save

Keep something in the user's RelayLink notebook: an idea, a task, a journal entry, a report, an email draft they are not sending yet, a project, a working preference, a lesson from something they tried, a decision, a routine, or where the work has got to for whichever assistant picks it up next. Only body is required — an unfiled thought stays unfiled, and a title is taken from the first line when you do not give one. Pass parentId to add to an entry that already exists (a reflection on a journal entry, a second take on an idea, an outcome on a decision): the original is never rewritten. Text only — no files, no attachments; a link is stored as text and never fetched. Save what the user asked to keep, not the surrounding conversation, and use source "ai_suggested" for anything you inferred rather than heard, so it is offered rather than recorded as theirs. This is the user's RelayLink notebook, for material they are keeping: use it when they name RelayLink or their notebook, when they are continuing work already kept here, or when they pick a RelayLink entry. A durable fact ABOUT them — how they like to be worked with, what they are working on — is memory_add's instead, and a project-scoped preference or one with an end date is this notebook's. A bare "add a task" or "save this note" may be meant for another connected app, and a destination they name outright is always the destination. If more than one place is plausible and nothing settles it, ask once, then stay with the answer for the rest of the task.

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": {
      "body": "<body>"
    },
    "name": "notebook_save"
  }
}

Input Schema

NameRequiredDescriptionDefault
dueNoWhen a task or a decision review falls due: 2026-09-11 for a day, or 2026-09-11T17:00 for a time in their zone. Work out which day "Friday" is before calling; this server does not read it.
bodyYesThe content, in full and in the user's own words where they gave them. Up to 50,000 characters; it is refused, never truncated.
kindNonote | task | journal | report | email_draft | project | handoff | preference | lesson | routine | decision | exploration | outcome | reflection. Defaults to note.
tagsNoTags, lowercase, no spaces. Optional.
titleNoWhat to call it. Optional — taken from the first line of the body when absent.
detailNoKind-specific fields as JSON: a decision takes choice/rationale/expectation/reviewWhen, a lesson tried/happened/stopped/reconsiderIf, a handoff goal/progress/constraints/nextStep, a routine purpose/steps/output/gather, an email draft to/subject. Anything else is refused with the list.
sourceNouser_stated (their words), user_confirmed (yours, they agreed) or ai_suggested (your inference, offered not adopted). Defaults to user_stated — use it only for what they actually said.
projectNoA project name to file it under, created on first mention. Optional.
parentIdNoThe entry_id this is an addition to. Required for exploration, outcome and reflection.
priorityNonormal | low | high. Tasks only, and normal unless the user says otherwise.
reviewAtNoA date to review it (2026-10-01). Saved for review — nothing is scheduled and nothing is delivered.
entryDateNoThe day a journal entry is FOR (2026-09-11), which may not be today. Journal entries only.
expiresAtNoWhen a preference stops applying (2026-12-01). Use it for anything temporary, so a passing constraint does not become a permanent rule.
relatesToNoAn entry_id this one relates to, linked without either owning the other.
relationTypeNoHow it relates: related | led_to | supersedes | answers | bears_on. Defaults to related.
resurfaceCueNoWhy or when to bring this back, in the user's words: "when I'm working on marketing". A note on a row, not a notification.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare the generic safety profile (non-read-only, non-destructive, closed-world); the description adds real behavioral context beyond that: title defaults from the first line, parentId additions never rewrite the original, text-only with links stored as text and never fetched, and source=ai_suggested for anything inferred rather than heard.

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-loaded with what the tool does and then the routing rules, and nearly every clause carries decision-relevant information. The opening list of ~13 kinds is longer than needed and the paragraph is dense, but nothing is filler.

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?

For a 16-parameter, non-idempotent write tool with no output schema, the description covers storage scope, mutation semantics and routing. The remaining gap is that it never says what comes back (an entry id) or that entry ids for parentId/relatesTo come from notebook_find/notebook_open.

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 the baseline is 3; the description still adds meaning on top — body-only requirement is restated as a rule, title derivation from the first line, and the non-destructive semantics of parentId plus the source-selection policy. It stops short of explaining how an agent obtains an entry_id for parentId/relatesTo.

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 ("Keep something in the user's RelayLink notebook") and enumerates the kinds of material it holds, which lets an agent distinguish it from memory_add, project_work_update and the many notebook_* siblings without opening a 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 explicit positive triggers (user names RelayLink/their notebook, continuing kept work, picking an entry), explicit negative routing (durable facts about them -> memory_add; a named destination always wins), plus a disambiguation rule (ask once, then stay with the answer) for the ambiguous bare "save this note" case.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources