Skip to main content
Glama

RelayLink

Check a draft says what they mean

notebook_fidelity_check
Read-onlyIdempotent

Before the user sends something, gather what is needed to check it privately against what they meant and the notebook entries it came from: the draft, the source text, and the things to look for — dropped conditions, a leaning presented as a decision, an inference presented as their position, an unclear ask, a commitment they did not make, background the recipient will not have. This server runs no analysis and returns no verdict; you do the reading and show the user what you found as suggestions. It rewrites nothing and sends nothing, and none of it reaches the recipient. 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

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": {
      "intent": "<intent>"
    },
    "name": "notebook_fidelity_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
intentYesWhat the user actually means to get across, in their words.
draftIdNoA draft_id from draft_package or notebook_share, to read the pending draft itself.
entryIdsNoThe entry_ids the message is supposed to be faithful to.
draftTextNoThe outgoing text, if it is not a saved draft yet.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

The annotations already establish readOnly/non-destructive/idempotent, and the description adds genuinely non-obvious behavior: the server performs no analysis, returns no verdict, rewrites and sends nothing, and nothing reaches the recipient — so the calling agent knows it must do the reading itself. It doesn't describe what shape the returned material takes (the draft text, the entries, the checklist results), which is the remaining gap.

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

Conciseness3/5

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

Purpose and the 'no verdict' caveat are front-loaded, but the single long sentence plus the extended notebook-vs-memory routing paragraph makes it dense and hard to scan. Most sentences carry information, but the routing prose is heavy relative to the tool's simple four-parameter read surface.

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 read-only, four-parameter tool with no output schema, the description covers what to supply, what the server won't do, and how to choose this tool over neighbors. The missing piece is what the caller receives back, which matters because the agent is told it must do the interpretation itself.

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%, so the schema already explains intent, draftId, entryIds and draftText. The description's 'the draft, the source text, and the things to look for' loosely echoes those parameters and adds the checklist categories as conceptual content, but the list of things to look for isn't a parameter and the description doesn't clarify draftId-vs-draftText selection beyond what the schema says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action — checking a draft against the user's intent and the notebook entries it came from — and explicitly separates this notebook from memory_add and from other connected apps. The verb is somewhat buried in 'gather what is needed to check it,' which describes the retrieval rather than naming the tool's outcome, so it's clear but not crisp.

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?

It enumerates triggering conditions (user names RelayLink or their notebook, continuing work kept here, picking a RelayLink entry) and explicit exclusions with the correct alternative: durable facts about the user go to memory_add, bare 'add a task'/'save this note' may belong to another app, and a named destination always wins. It even specifies escalation behavior — ask once if ambiguous, 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