Skip to main content
Glama

Write the project's help overlay

r3_help_write
Destructive

Set the instructions that ship WITH a project — controls, what to press, what it does. R3 renders them in a modal behind a floating "?" button and the H key, in the editor and in the live portal alike, so whoever opens your preview link can read them. This is the built-in surface for that, so a Code component needs no overlay of its own.

The body is markdown — headings, bullets, code, links: the controls as a player needs them, e.g. "## Controls\n\n- Space — jump".

A project has ONE help. Call this again and it replaces the text rather than adding a second. REPLACING needs baseVersion, the codeVersion r3_component_read gave for the Help: text is never merged, so a write on an older version is refused with the current text. The first Help needs none. The optional title is the modal's heading ("Controls", "How to play"); leave it out to keep "Help".

Kept at once in the project's live copy: every R3 tab with the project open shows it now. The result gives you the component's entityRef — pass that to r3_component_set to change the trigger key, move or hide the button, or have the help open automatically on load.

Input Schema

NameRequiredDescriptionDefault
titleNoHeading shown at the top of the modal, e.g. "Controls". Default "Help".
markdownYesThe help text, as markdown. Replaces whatever is there.
projectIdYesThe project to write into, from r3_project_create or r3_project_load.
baseVersionNoREQUIRED when the project already has a Help: its codeVersion, from r3_component_read. Leave it out for the first Help.

Output Schema

NameRequiredDescriptionDefault
seqNo
nameYes
titleYes
actionYes
answerYesThis 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.
warningsNo
entityRefYes
projectIdYes
codeVersionYes
componentIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • 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: -[
      -  "projectId",
      -  "action",
      -  "componentId",
      -  "entityRef",
      -  "name",
      -  "title",
      -  "codeVersion"
      -]New value: +[
      +  "projectId",
      +  "action",
      +  "componentId",
      +  "entityRef",
      +  "name",
      +  "title",
      +  "codeVersion",
      +  "answer"
      +]
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing the replace-not-append semantics, the optimistic-concurrency rule that an older baseVersion is refused with the current text, and that the change is applied at once to the project's live copy. It does not discuss permissions or whether the write is undoable, so it stops just short of full behavioral coverage for a destructive mutation.

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?

Five short paragraphs, purpose front-loaded and each block carrying distinct information. It is longer than strictly necessary and restates the baseVersion requirement that the schema also documents, but there is little 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?

For a destructive, non-idempotent write with an output schema, everything an agent needs is present: lifecycle of the single Help entity, concurrency handling, live-propagation behavior, and a pointer to the downstream tool that consumes the returned entityRef.

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, but the description adds real meaning: why baseVersion exists and when to omit it, what the title does by default, and a concrete markdown format example for the body. The syntax-level detail the markdown parameter accepts is the main thing left to the schema.

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?

"Set the instructions that ship WITH a project" is a specific verb and resource, and the description immediately distinguishes it from adjacent tools by noting a Code component "needs no overlay of its own" and that trigger/layout changes go to r3_component_set.

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 states when to call (setting help text), when baseVersion is required vs. omitted (replace vs. first write), what happens on a stale version, and explicitly routes the agent elsewhere for trigger key/move/hide via r3_component_set.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources