Skip to main content
Glama
Sign In

ThreadPage

by page.thread
OverviewDiscussionsAdmin

Restore a note

restore_note
Idempotent

Bring a Note back from Trash into its Thread (search with state "trash" finds it). When its Thread is in Trash too, restore_thread first (parent_deleted); for earlier content, use restore_note_version. Can edit and organize restores any Note; Can add notes only the Notes it added. expected_revision is not compared. Answers a receipt with the new revision and url.

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": {
      "operation_id": "<operation_id>",
      "note_id": "<note_id>",
      "expected_revision": "<expected_revision>"
    },
    "name": "restore_note"
  }
}

Input Schema

NameRequiredDescriptionDefault
note_idYesA Note's id, from get_thread, search or get_note.
operation_idYesA new UUID for each write. After a lost answer, send the identical call with the same one, or check get_operation before writing again.
expected_revisionYesIts revision from list_threads, get_thread, list_folders or get_note (not a content_revision); not compared.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / expected_revision / description
      Previous value: -"The revision you last read for it."New value: +"Its revision from list_threads, get_thread, list_folders or get_note (not a content_revision); not compared."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) it discloses that expected_revision is not compared, that a failure mode exists (parent_deleted when the Thread is trashed), and what the call returns (a receipt with the new revision and url). That is behavior an agent cannot derive from the structured fields.

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, then conditions and alternatives in a sensible order, with no filler sentences. The permission sentence ("Can edit and organize restores any Note; Can add notes only the Notes it added") is awkwardly phrased and costs some readability.

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 three required params, no output schema, and a mutation that can fail on a trashed parent, the description covers the prerequisite call, the sibling alternative, the permission gate, and the return shape. Nothing an agent needs in order to invoke it correctly is missing.

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 all three parameters — including the 'not compared' caveat on expected_revision and the operation_id retry protocol — are already documented in the schema. The description largely restates the expected_revision caveat and adds no new syntax or format detail, 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?

Specific verb + resource + effect: brings a Note back from Trash into its Thread, and it names how to find trashed notes (search with state "trash"). It is clearly distinguished from restore_note_version and restore_thread, so an agent can pick it without opening any 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: if the parent Thread is also in Trash, call restore_thread first (the parent_deleted condition is named), and for earlier content use restore_note_version. It also states the permission boundary — edit/organize callers can restore any Note, add-only callers only their own — which is exactly the kind of when-you-may-use guidance an agent needs.

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

All ThreadPage toolsInspect
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