R3

List entity templates

r3_entity_list

Read-onlyIdempotent

List this R3 account's entity templates: reusable bundles (a ship, a lamp post) saved from an Entity in a project, each with its current version and member count. community: true lists everyone's public templates instead. r3_entity_read shows one template's members and versions; r3_entity_import puts a copy into a project; r3_entity_save_template saves an Entity of a project as a template.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "r3_entity_list"
  }
}

Input Schema

Name	Required	Description
`limit`	No	How many (default 25, max 100).
`cursor`	No	Continue a list: the nextCursor of the previous page.
`search`	No	Only templates whose name matches, searched across all of them.
`community`	No	true lists the PUBLIC templates of every user instead of this account's own.

Output Schema

Name	Required	Description
`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.
`filter`	Yes
`hasMore`	Yes
`templates`	Yes
`nextCursor`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds real context beyond them: that results are scoped to the calling account by default, that community widens the scope to all users' public templates, and that each listed item carries a current version and member count. It says nothing about pagination limits or result ordering, which the schema only partly covers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action and resource, then the scope exception, then the sibling disambiguation. Dense but every clause carries routing or meaning; there is no filler or repetition of the title.

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?

With an output schema present, the description needn't explain return shape, and annotations carry the safety profile; the definition covers purpose, scope, and sibling routing. The only shortfall is that paging behavior (default 25 / max 100, cursor continuation) is left entirely to the schema, so an agent skimming the description alone could under-fetch.

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% (limit, cursor, search, community are all documented in-schema), so the baseline is 3. The description restates the community flag's semantics but adds no syntax, default, or edge-case detail for limit/cursor/search beyond what the schema already provides.

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?

Specific verb + resource ("List this R3 account's entity templates") with an immediate gloss of what a template is ("reusable bundles (a ship, a lamp post) saved from an Entity in a project"). It explicitly names the three sibling tools it is not (r3_entity_read, r3_entity_import, r3_entity_save_template), so an agent can distinguish it 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?

The scope switch is spelled out: "community: true lists everyone's public templates instead" of the account's own. Each nearby alternative is given its own condition — read for one template's members/versions, import to copy into a project, save_template to create a template from an Entity — which is exactly the routing an agent needs.

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

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?