Skip to main content
Glama
Sign In

remnus

by io.github.Ranork
OverviewDiscussionsAdmin

get_changes_since

Read-only

Everything created, updated or deleted since a cursor (from the workspace digest/map or a previous call) or an ISO time — pages, databases, rows and deletions, oldest first. Omit both to bootstrap. Always keep nextCursor for the next call: this is how to catch up instead of re-reading the tree. An entry stamped in the cursor's own second may appear once more — dedupe by id.

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": "get_changes_since"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
sinceNoISO 8601; ignored when cursor is given
cursorNoFrom the digest/map header or a previous nextCursor

Output Schema

NameRequiredDescriptionDefault
changesYesChronological, oldest first
hasMoreYes
nextCursorYesAlways present — pass back as cursor to continue or resume a later sync

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / cursor / description
      Previous value: -"Pagination cursor from a previous response's nextCursor field — takes priority over since for resuming a sync"New value: +"From the digest/map header or a previous nextCursor"
    • removedInput schema / properties / limit / description
      Removed value: -"Maximum changes per page (default 100)"
    • changedInput schema / properties / since / description
      Previous value: -"ISO 8601 timestamp — only return changes after this time (e.g. \"2026-07-01T00:00:00Z\"). Ignored when cursor is provided. Omit both for a full crawl."New value: +"ISO 8601; ignored when cursor is given"
    • changedOutput schema / properties / nextCursor / description
      Previous value: -"Pass back as cursor to continue or resume a later sync"New value: +"Always present — pass back as cursor to continue or resume a later sync"
    • changedOutput schema / required
      Previous value: -[
-  "changes",
-  "hasMore"
-]New value: +[
+  "changes",
+  "hasMore",
+  "nextCursor"
+]
  2. Changed7 schema fields changed
    • changedOutput schema / properties / changes / description
      Previous value: -"Changes in chronological order (oldest first)"New value: +"Chronological, oldest first"
    • changedOutput schema / properties / changes / items / properties / databaseId / description
      Previous value: -"Parent database ID, present for database_row entries"New value: +"Present for database_row entries"
    • changedOutput schema / properties / changes / items / properties / id / description
      Previous value: -"Item ID (pass to get_page or query_database)"New value: +"Pass to get_page or query_database"
    • removedOutput schema / properties / changes / items / properties / title / description
      Removed value: -"Item title (last known title for deleted items)"
    • removedOutput schema / properties / changes / items / properties / updatedAt / description
      Removed value: -"When the change happened (ISO 8601) — for \"deleted\", when the deletion happened"
    • removedOutput schema / properties / hasMore / description
      Removed value: -"Whether more changes exist beyond this page"
    • changedOutput schema / properties / nextCursor / description
      Previous value: -"Cursor for the next page (present when hasMore) — also use this to resume a later sync from where this call left off"New value: +"Pass back as cursor to continue or resume a later sync"
  3. Added

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the read-only annotation, the description discloses important behavior: returned changes include deletions, results are oldest-first, the cursor must be persisted, and an entry in the cursor's own second may reappear, requiring deduplication by id. This is valuable operational context not otherwise visible.

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?

Three dense sentences carry the full story: what it returns, how to use it correctly, and the one caveat to handle. There is no filler or repetition of schema text.

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 the output schema exists and the annotations cover safety, the description supplies all essential procedural details: cursor chaining, bootstrapping, scope, ordering, and deduplication. An agent can call and paginate this tool correctly from the description alone.

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?

The schema already documents since and cursor, and the description adds useful context about cursor provenance (digest/map header or previous nextCursor) and bootstrap semantics. The limit parameter remains undocumented in the description, but its default and self-explanatory name reduce the gap.

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?

The description states a specific verb and resource: 'Everything created, updated or deleted since a cursor... or an ISO time,' and enumerates the covered item types (pages, databases, rows, deletions) and ordering (oldest first). This clearly distinguishes it from sibling read tools like get_page or get_pages.

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 gives explicit usage direction: omit both parameters to bootstrap, always retain nextCursor for the next call, and use this tool to catch up 'instead of re-reading the tree.' This tells the agent exactly when and how to invoke it iteratively.

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

All remnus 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