Skip to main content
Glama

RelayLink

Open a notebook entry

notebook_open
Idempotent

Read one entry of the user's RelayLink notebook in full, with its additions, links, revision history and where its words have already been shared. Reading changes nothing: a task is not completed, a journal entry is not archived, and another assistant can still find it. Only markPickedUp writes anything: it records that a hand-off was picked up. Pass revisionId to read an older version or an edit that was refused as stale. Pass compare to get the alternative developments of an entry side by side. 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_open"
  }
}

Input Schema

NameRequiredDescriptionDefault
compareNotrue to lay out this entry's alternative developments beside each other for comparison.
entryIdYesThe entry_id from notebook_find or notebook_save.
revisionIdNoA revision_id from the history, to read that version instead of the current one.
markPickedUpNotrue to record that an assistant has picked this hand-off up. Says nothing about whether it is finished, and does not hide it from anybody else.

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?

Annotations say readOnlyHint=false, and the description pre-empts the apparent conflict by naming the single writing path: 'Only markPickedUp writes anything.' It also discloses side-effect boundaries the annotations cannot convey — a read does not complete a task, archive an entry, or hide it from other assistants, and pickup does not imply completion. This is exactly the extra context the annotations leave open.

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 core action and its consequences, then parameters, then routing rules — a sensible order with no filler sentences. The closing guidance about a bare 'add a task' or 'save this note' and naming a destination reads as write-path advice (notebook_save territory) and slightly dilutes an otherwise tight read-tool definition.

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?

With no output schema, the description still tells the agent what comes back (additions, links, revision history, prior sharing), and it covers the mutation caveat, the stale-revision case, and the comparison mode for a 4-parameter tool. Nothing needed to call it correctly is missing.

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 beyond the schema: revisionId is for 'an edit that was refused as stale' (not just any old version), and compare is framed as laying out alternative developments side by side. markPickedUp's semantics are reinforced rather than merely repeated.

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 — 'Read one entry of the user's RelayLink notebook in full' — and enumerates what the read returns (additions, links, revision history, sharing). It explicitly distinguishes itself from notebook_find/notebook_save (which supply entryId) and from memory_add, so an agent can route without opening schemas.

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 concrete triggers (user names RelayLink or their notebook, continues work kept here, picks an entry) and explicit exclusions (a durable fact about them goes to memory_add; a named destination always wins). It even resolves ambiguity procedurally — ask once, then stay with the answer — which is unusually actionable.

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