Skip to main content
Glama

RelayLink

Search the notebook

notebook_find
Read-onlyIdempotent

Search and filter the user's RelayLink notebook by words, kind, project, tag, status, date or due date. Answers "what do I need to do today", "find the idea I saved about X", "what is still open in this project", "bring back yesterday's journal entry". Returns previews with entry ids; notebook_open gets the full text of one. Archived and deleted entries are found by asking for them with lifecycle. Reads only. 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

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "notebook_find"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagNoOne tag.
kindNoNarrow to one kind: note | task | journal | report | email_draft | project | handoff | preference | lesson | routine | decision | exploration | outcome | reflection.
textNoWhat the user is looking for, in their own words — a half-remembered phrase is fine. Matched on word stems rather than exact strings, so "forking" finds "fork"; a misspelling gets one attempt against words this notebook actually uses, and the reply says which word was searched for. Results are ordered by how well they match, not by date, so an old entry is not buried. Optional: omit it to list rather than search.
limitNoRows per page. Searching by words returns 5 by default and at most 10 — the answer is at the top of a ranked search, and notebook_open reads one in full. Listing without words returns 20 by default and at most 50.
sinceNoOnly entries changed on or after this date (2026-09-01).
untilNoOnly entries changed on or before this date.
offsetNoSkip this many rows (default 0). The reply says where the next page starts.
pinnedNotrue for pinned only, false for unpinned only.
statusNoTask status: open | doing | blocked | done.
projectNoA project name or id.
parentIdNoOnly additions to this entry_id.
dueBeforeNoOnly things due on or before this date — "what do I need to do today".
lifecycleNoactive (default) | archived | deleted. Deleted entries can be restored for 30 days.
includeSuggestionsNoInclude entries you suggested and the user has not adopted (default true).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and "Reads only" merely restates that. The description does add value the schema does not: it states results come back as previews with entry ids, that ranking is relevance-based rather than date-based, and that archived/deleted entries require an explicit lifecycle request. It stops short of describing pagination metadata or preview contents in detail.

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?

Purpose and return shape are front-loaded, and the ambiguity/routing paragraph is dense with decision-relevant content rather than filler. It is on the long side for a search tool, and the memory_add vs notebook distinction runs several sentences, but no sentence is pure repetition of the schema.

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 14 optional parameters and no output schema, the description supplies exactly the missing pieces: what a result looks like (preview + entry id), how to get full text (notebook_open), and default/cap behavior implied by the schemas. An agent can call this correctly from the description alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and each parameter already documents its own semantics (stem matching, limit caps, lifecycle values) more precisely than the description does. The description only restates the facet list, so the baseline 3 applies.

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?

Opens with a specific verb+resource ("Search and filter the user's RelayLink notebook") and enumerates the facets it can filter on. It explicitly contrasts itself with notebook_open ("gets the full text of one") and memory_add, so an agent can route 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 when-to-use triggers (user names RelayLink/notebook, continuing kept work, picks a RelayLink entry), explicit when-not (durable facts about the user go to memory_add; bare "add a task" may belong to another app), and a tie-break rule ("ask once, then stay with the answer"). This is unusually complete routing guidance.

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