Skip to main content
Glama

RelayLink

Revise a notebook entry

notebook_update

Revise the text of an entry in the user's RelayLink notebook, keeping the previous version in its history. ALWAYS pass expectedRevision — the number notebook_open or notebook_find gave you — so a change somebody else made in between is caught rather than overwritten. If it is stale you get the newer text back, your text is kept as an unmerged edit rather than lost, and you show the user both and ask. To add a thought without changing what is there, use notebook_save with parentId instead: a reflection, an outcome or an alternative belongs beside the original, not on top of it. 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": {
      "entryId": "<entryId>"
    },
    "name": "notebook_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyNoThe new full text. Omit to leave the body alone.
titleNoA new title. Omit to leave it alone.
detailNoReplacement kind-specific fields as JSON. Omit to leave them alone.
sourceNouser_stated | user_confirmed | ai_suggested, if the authorship of the text has changed.
entryIdYesThe entry_id to revise.
changeNoteNoOne line on why, for the history. Optional.
expectedRevisionNoThe revision you are editing, from notebook_open. Omit only if you have not read the entry — the reply then tells you which revision it is now at.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description explains version history retention, the optimistic-concurrency contract via expectedRevision, and exactly what happens on a stale write: newer text returned, your text kept as an unmerged edit, both shown to the user. This is the kind of failure-mode disclosure annotations cannot carry.

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 the action and the critical parameter, then the add-vs-revise alternative, then destination routing. Effective, but the routing/ambiguity tail is long relative to a one-required-param tool and portions read as shared preamble rather than tool-specific.

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 7-param mutation with no output schema, the description covers the concurrency contract, what the reply contains on conflict, history behavior, and all the sibling-routing decisions an agent must make. Nothing needed to call it correctly is absent.

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; the description earns above that by giving expectedRevision operational meaning (where to get it: notebook_open or notebook_find) and the consequence of omitting or passing a stale value. Minor tension: the description says "ALWAYS pass expectedRevision" while the schema documents it as optional with a defined omit behavior.

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?

"Revise the text of an entry in the user's RelayLink notebook, keeping the previous version in its history" names a specific verb, resource, and scope, and immediately contrasts with notebook_save (add beside) rather than on top. An agent can distinguish this from every sibling notebook_* tool 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?

Explicit routing: use notebook_save with parentId to add without changing, memory_add for durable facts about the user, another app for a bare "add a task", and a user-named destination always wins. It even prescribes behavior under ambiguity (ask once, then stay with the answer).

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