R3

List R3's public roadmap

r3_roadmap_list

Read-onlyIdempotent

The public R3 roadmap: what is planned, in progress, proposed by the community and shipped, with each item's vote count and whether the user has voted for it — plus the user's OWN suggestions still awaiting R3's approval, marked pending, and the ones R3 declined, marked declined with R3's reason (only the user sees them; neither is votable); a declined item is not suggested again. It shows whether an item already covers an idea before r3_roadmap_suggest: r3_roadmap_upvote votes for that one instead of a duplicate. Narrow it with search (title and description, any case) and status.

Input Schema

Name	Required	Description	Default
`search`	No	Words to find in the title or description, any case.
`status`	No	Only items with this status.

Output Schema

Name	Required	Description
`items`	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.
`pending`	Yes
`declined`	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: -[
-  "items",
-  "total",
-  "pending",
-  "declined"
-]New value: +[
+  "items",
+  "total",
+  "pending",
+  "declined",
+  "answer"
+]

First observedOct 15, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: vote counts, whether the user voted, that pending/declined items are visible only to the user, are non-votable, and that a declined item cannot be suggested again. It does not mention pagination or rate limits, but adds substantial value.

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?

The purpose is front-loaded, but the body is one long run-on sentence stitched together with em-dashes, a colon and semicolons, making it hard to parse. Most content is relevant, yet the pending/declined/votability clauses could be tightened into cleaner sentences.

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?

An output schema exists, so return values need not be re-explained, and the annotations cover the safety profile; the description still usefully characterizes what the list contains (vote counts, user's private suggestions, decline reasons). Together with full schema coverage, an agent has enough to call it correctly.

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 documents both params including the enum values and the 'any case' search semantics. The description only restates that search narrows by title/description and status narrows by status, adding essentially nothing beyond the schema. 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?

States a specific verb+resource ('The public R3 roadmap') and enumerates its scope (planned, in-progress, proposed, shipped, plus the user's own pending/declined suggestions). It explicitly names and contrasts with siblings r3_roadmap_suggest and r3_roadmap_upvote, so an agent can distinguish it without opening another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: use this to check whether an item already covers an idea before calling r3_roadmap_suggest, and use r3_roadmap_upvote to vote for the existing item instead of creating a duplicate. This gives clear context and named alternatives, though it lacks an explicit 'when not to use' beyond the duplicate case.

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?