R3

List the R3 projects this account can work on

r3_project_list

Read-onlyIdempotent

List the projects this R3 account can work on — its own and its teams' — last updated first, with the projectId every other project tool takes. It is how a project the user names ("my slot machine") rather than giving an id is found: search for it; its projectId is what r3_project_load takes.

Search by name rather than paging: search: "slot" is matched (case-insensitively, anywhere in the name) against EVERY project by the server, not against the page you are holding. Names are not unique: when more than one project matches, the candidates' name, team and last save tell them apart, and which one is meant is the user's answer.

Each row says whose space it is in (personal, or a team by name), the account's role on it (a viewer cannot save changes), whether it is in the R3 Community, and whether you (this agent key or app connection) created it.

Input Schema

Name	Required	Description
`limit`	No	How many to return (default 25, max 100).
`cursor`	No	Continue a previous listing: pass the nextCursor it returned, unchanged. Omit for the first page.
`search`	No	Match this text against project names, on the server (case-insensitive). Omit for every project.

Output Schema

Name	Required	Description
`limit`	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.
`search`	Yes
`hasMore`	Yes
`projects`	Yes
`nextCursor`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

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: -[
-  "projects",
-  "limit",
-  "search",
-  "hasMore",
-  "nextCursor"
-]New value: +[
+  "projects",
+  "limit",
+  "search",
+  "hasMore",
+  "nextCursor",
+  "answer"
+]

First observedOct 15, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower. The description adds real context beyond that: names are not unique, candidates are disambiguated by name/team/last save, role affects permissions (a viewer cannot save), and search is case-insensitive and server-wide. However it does not describe pagination/nextCursor behavior, so it is solid but not exhaustive.

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 purpose and the projectId rationale, then usage, then row contents. Every sentence carries information, but the three-paragraph block is dense and the middle paragraph is verbose; it is appropriately sized rather than maximally tight.

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?

Although an output schema exists (so return values need not be spelled out), the description still characterizes each row (space ownership, account role, R3 Community flag, creator) and covers the non-unique-name edge case. An agent has everything needed to call and interpret it correctly.

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 coverage is 100%, so baseline is 3. The description adds genuine meaning for `search` (case-insensitive substring match anywhere in the name, executed on the server against all projects rather than the held page), which goes beyond the schema's terse field text. It adds little for limit/cursor, which the schema already documents.

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 (list the projects this R3 account can work on, its own and its teams'), scopes it (last updated first, exposes the projectId), and distinguishes it from the sibling that consumes its output (r3_project_load). An agent can tell it apart from r3_project_create/load/delete 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?

It explicitly says when to use it (finding a project the user names rather than by id, e.g. "my slot machine") and prescribes search over paging, explaining that search matches server-side against EVERY project, not the current page. It also routes to r3_project_load as the consumer of the returned projectId.

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?