R3

Suggest a roadmap item

r3_roadmap_suggest

Suggest a feature for R3's public roadmap, in the user's name and naming you (your agent key or app connection). It is HELD until R3's team approves it: not public, not votable, until then. r3_roadmap_list shows whether an item already covers it (r3_roadmap_upvote votes for that one instead). A good suggestion says what the feature lets a person do and why (what was being built when it was missed). Something broken rather than missing is r3_bug_report's. Rate-limited per agent key or app connection (a few a day). Needs the roadmap:suggest right.

Input Schema

Name	Required	Description
`title`	Yes	One line naming the feature, e.g. "Per-wheel tyre grip in the Inspector".
`category`	No	Where it belongs; "other" when unsure.
`description`	Yes	What it lets a person do, and why it is needed.

Output Schema

Name	Required	Description
`id`	Yes
`title`	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.
`approved`	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: -[
-  "id",
-  "title",
-  "approved"
-]New value: +[
+  "id",
+  "title",
+  "approved",
+  "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?

Annotations only cover the generic profile (not read-only, open-world, non-idempotent, non-destructive). The description adds real operational context the annotations cannot: the item is HELD, not public and not votable until R3's team approves it, it is rate-limited per agent key or app connection, and it requires the roadmap:suggest right. The only missing detail is whether a suggestion can be edited or withdrawn later.

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 action and its held-until-approved consequence, then routing rules. Dense and parenthetical-heavy, but each sentence carries distinct information; nothing is filler.

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?

An output schema exists, so return values need no explanation. Between the description, the schema and the annotations, an agent knows the precondition (roadmap:suggest right), the side effects (held, not public), the rate limit, and the sibling tools to check first.

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 the baseline is 3. The description goes slightly beyond the schema by prescribing the content of a good suggestion ('what the feature lets a person do and why'), which maps onto the title/description fields and raises the odds of a valid call.

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 and resource ('Suggest a feature for R3's public roadmap') plus the attribution behavior (submitted in the user's name, naming the agent key/app connection). It also explicitly separates itself from r3_roadmap_list, r3_roadmap_upvote and r3_bug_report, so an agent can pick it without opening any sibling 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?

Names the alternatives and the exact condition selecting each: use r3_roadmap_list to check for an existing item, r3_roadmap_upvote to vote for one that already exists, and r3_bug_report when the thing is broken rather than missing. It also gives positive guidance on what makes a good suggestion.

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?