R3

List what others changed in a project

r3_project_changes

Read-only

What OTHER people changed in a project — the user in any R3 tab, their other agents — oldest first, grouped per author and per thing: properties set, code and help updated (with versions), components added, deleted or restored, the project renamed. Your own changes are never listed. Every answer about a project already ends with a short "Since your last call" line; this is its full list.

Without since: from where you last looked (and moves that mark to now, unless advance: false). The mark belongs to your agent key or app connection, not to the conversation: two conversations on one share it. With since (a seq, e.g. the one the "+N more" line names, or 0 for everything still in the log): from there, without moving anything. Needs project:read.

Input Schema

Name	Required	Description
`limit`	No	At most this many groups, the newest (default 50, at most 200); the rest are counted.
`since`	No	List from this seq on (the "+N more" line names it; 0 = everything the log still holds).
`advance`	No	Without since: move your mark to now (default true). false reads without moving it.
`projectId`	Yes	The project (r3_project_list).

Output Schema

Name	Required	Description
`more`	Yes
`first`	Yes
`toSeq`	Yes
`total`	Yes
`answer`	Yes	This answer in words: what was done, what R3 measured, decided or refused, and what to do next. The same text as the result's text block. Read it: the fields beside it are the data, this is the guidance.
`groups`	Yes
`unread`	Yes
`fromSeq`	Yes
`projectId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 17, 2026

changedInput schema / properties / advance / description

Previous value: -"Without since: move this key's mark to now (default true). false reads without moving it."New value: +"Without since: move your mark to now (default true). false reads without moving it."

Changed2 schema fields changedOct 15, 2026

addedOutput schema / properties / answer

Added value: +{
+  "description": "This answer in words: what was done, what R3 measured, decided or refused, and what to do next. The same text as the result's text block. Read it: the fields beside it are the data, this is the guidance.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "projectId",
-  "first",
-  "fromSeq",
-  "toSeq",
-  "total",
-  "more",
-  "unread",
-  "groups"
-]New value: +[
+  "projectId",
+  "first",
+  "fromSeq",
+  "toSeq",
+  "total",
+  "more",
+  "unread",
+  "groups",
+  "answer"
+]

First observedOct 15, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing a state side effect the schema can't convey: without `since` the call MOVES the read mark, and the mark belongs to the agent key/app connection so two conversations share it. That is exactly the kind of hidden behavior an agent needs. It falls short of 5 only because it doesn't note the mild tension with readOnlyHint (the cursor is mutated) nor any rate/volume caveats beyond the limit cap.

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-loads purpose in the first clause and keeps the summary formation/last-call relationship early. The second paragraph is dense but each sentence carries real routing or semantics information; minor cost is that the parentheticals make it harder to scan than it needs to be.

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?

Output schema exists so return values need no explanation, annotations carry the read-only profile, and the description still adds the mark lifecycle, the auth requirement ('Needs project:read'), and the exhaustion behavior. An agent has everything needed to call this correctly on the first try.

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 description coverage is 100%, so baseline is 3, but the description adds genuine meaning: it explains what a `seq` is, that `0` means everything still in the log, and — crucially — the interaction between `since` and `advance` (whether the mark moves). That interaction is not derivable from the field descriptions alone.

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?

Names a specific verb and resource — listing what OTHER people changed in a project — and immediately narrows scope with 'oldest first, grouped per author and per thing' plus a concrete enumeration of change types. The line 'Your own changes are never listed' crisply separates it from any self-activity tool among the 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 positions the tool against a known alternative surface: 'Every answer about a project already ends with a short "Since your last call" line; this is its full list.' It then splits usage into the two calling modes (with vs. without `since`) and states the conditions selecting each.

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

All R3 tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?