RelayLink

File, tick off or put away

notebook_organize

Idempotent

Change where an entry sits in the user's RelayLink notebook without touching its text: task status, priority, pinning, project, tags, links, archiving, deleting and restoring, when to see it again, and adopting a suggestion. Completing a task is status "done" here and nothing else does it — reading a task never completes it. Deleting is reversible for 30 days (lifecycle "active" restores it). Only pass what is changing; everything omitted is left alone. 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_organize"
  }
}

Input Schema

Name	Required	Description
`due`	No	A new due date or time. Tasks and decisions only.
`adopt`	No	true when the user accepts a suggestion you saved. Only ever on their say-so — this is what turns your inference into something recorded as theirs.
`linkTo`	No	An entry_id to link this one to.
`pinned`	No	true to pin it to the top of lists, false to unpin.
`status`	No	Task status: open \| doing \| blocked \| done. Tasks only.
`unlink`	No	An entry_id to unlink from, in either direction.
`addTags`	No	Tags to add.
`entryId`	Yes	The entry_id to change.
`project`	No	A project name or id to file it under, created on first mention.
`clearDue`	No	true to remove the due date.
`linkType`	No	related \| led_to \| supersedes \| answers \| bears_on.
`priority`	No	normal \| low \| high.
`reviewAt`	No	A date to review it, or an empty string to remove one. Saved for review; nothing is scheduled or delivered.
`expiresAt`	No	When a preference stops applying, or an empty string to remove the expiry. Preferences only.
`lifecycle`	No	active \| archived \| deleted. Archived is out of the way and findable; deleted is recoverable for 30 days.
`removeTags`	No	Tags to remove.
`snoozeUntil`	No	Hold it back until this date, or an empty string to stop holding it back.
`clearProject`	No	true to take it out of its project.
`resurfaceCue`	No	Why or when to bring it back, in the user's words. Empty string clears it.
`stopResurfacing`	No	true when the user says to stop bringing it back. Never set this on your own.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 28, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already cover readOnly=false, idempotent=true, and destructive=false, but the description adds important behavioral detail: task completion only happens via status "done"; reading never completes a task; deletion is reversible for 30 days and lifecycle "active" restores it; omitted fields are left unchanged. It also adds consent constraints for adopt and stopResurfacing, which are meaningful beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose and core behavior, then layers usage routing and consent details. Despite its length, every part is relevant to a 20-parameter mutation tool, and there is no filler or repeated boilerplate.

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?

Given a complex 20-parameter tool with full schema descriptions and annotations, the description supplies enough context about purpose, usage boundaries, reversibility, partial updates, and consent-sensitive operations. No output schema exists, but return-value detail is not necessary for an agent to select and invoke it 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 the schema already documents all 20 parameters and provides the baseline 3. The description adds useful semantics beyond the schema—partial-update behavior, the special meaning of status "done", deletion recovery through lifecycle "active", and consent rules for adopt/stopResurfacing—though it does not explain every parameter in detail.

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: changing where an entry sits in the RelayLink notebook without touching its text, with concrete examples of what can change. It also distinguishes this notebook tool from memory_add and from other connected apps, so an agent can identify its role among siblings.

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?

Explicitly says when to use it: when the user names RelayLink or their notebook, continues work kept there, or picks a RelayLink entry. It also names alternatives and exclusions—memory_add for durable facts about the user, other apps for ambiguous bare save/add requests, and asking once when multiple destinations are plausible.

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

All RelayLink tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?