R3

List the R3 documentation

r3_docs_list

Read-onlyIdempotent

Every R3 document this server can give you, IN READING ORDER, with what each one covers and how big it is. R3's documentation begins here: no model has R3 in its pretraining, and code written from tool descriptions alone saves cleanly and then silently does nothing. r3_docs_read returns one.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`docs`	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.
`apiIndexPath`	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: -[
-  "docs",
-  "apiIndexPath"
-]New value: +[
+  "docs",
+  "apiIndexPath",
+  "answer"
+]

First observedOct 15, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered structurally. The description adds the reading-order and content/size disclosure, but says nothing about side effects, auth, or limits beyond the annotations, and return content is likely already in the output schema.

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 verb and scope, then two supporting sentences. The middle sentence is motivational rather than operational, which is slightly at odds with strict economy, but it justifies why the tool exists and earns its place.

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?

With an output schema present, return format needn't be re-explained, and the description covers purpose, ordering, and sibling routing. Nothing an agent needs to invoke this zero-param list tool is missing.

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 tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. No parameter semantics are claimed or needed.

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 ('Every R3 document... list') with scope detail ('IN READING ORDER, with what each one covers and how big it is'). It explicitly differentiates from the sibling by noting 'r3_docs_read returns one', so an agent can route between the two without opening either 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?

Frames this as the entry point ('R3's documentation begins here') and names the alternative r3_docs_read with its single-document behavior, implying list-first then read-one. There is no explicit when-not or exclusion, so it falls just short of full routing guidance.

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?