Skip to main content
Glama

Renderball

by com.renderball
OverviewDiscussionsAdmin

Submit one page

submit_page

Save one page you wrote (page 1: the file with Section0 and the shared design; page N: only its Section), with its direction (one sentence: the thing, the motion that acts out the claim, one craft detail). A page is accepted only after its brief was handed to you. The reply carries the next page's brief; when every page is saved the deck is merged, checked and rendered and the reply carries the rendered pages. To fix one page later, submit just that page.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageYes
labelNoWho wrote it, e.g. 'claude-code'. Shown in the deck's trace.
sourceYesPage 1: the file with Section0 and every shared constant, helper and chrome. Page N: ONLY `export const Section{N-1}`. Raw code or a ```tsx fenced block.
deck_idYes
directionYesThis page's direction in one sentence — the thing, the motion that acts out the claim, one craft detail. It goes into the page as its // Direction: line.
next_briefNoDefault true: the reply carries the next page's brief. A helper writing just one page sends false.
guest_tokenNoOnly for a deck created WITHOUT an account: the guest_token create_deck returned.
wait_secondsNoWhen this page completes the deck: how long to wait for the import (default 25).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / direction / description
      Previous value: -"THE STUDIO'S METHOD, step 4: the one you chose, in one sentence — the thing, the motion that acts out the claim, one craft detail."New value: +"This page's direction in one sentence — the thing, the motion that acts out the claim, one craft detail. It goes into the page as its // Direction: line."
    • removedInput schema / properties / pictures
      Removed value: -{
-  "description": "THE STUDIO'S METHOD, step 2: the six to eight pictures you considered for this page (at least two far-fetched), one short phrase each.",
-  "items": {
-    "maxLength": 200,
-    "minLength": 2,
-    "type": "string"
-  },
-  "maxItems": 10,
-  "minItems": 6,
-  "type": "array"
-}
    • changedInput schema / required
      Previous value: -[
-  "deck_id",
-  "page",
-  "source",
-  "pictures",
-  "direction"
-]New value: +[
+  "deck_id",
+  "page",
+  "source",
+  "direction"
+]
  2. Changed4 schema fields changed
    • addedInput schema / properties / direction
      Added value: +{
+  "description": "THE STUDIO'S METHOD, step 4: the one you chose, in one sentence — the thing, the motion that acts out the claim, one craft detail.",
+  "maxLength": 400,
+  "minLength": 15,
+  "type": "string"
+}
    • addedInput schema / properties / next_brief
      Added value: +{
+  "description": "Default true: the reply carries the next page's brief. A helper writing just one page sends false.",
+  "type": "boolean"
+}
    • addedInput schema / properties / pictures
      Added value: +{
+  "description": "THE STUDIO'S METHOD, step 2: the six to eight pictures you considered for this page (at least two far-fetched), one short phrase each.",
+  "items": {
+    "maxLength": 200,
+    "minLength": 2,
+    "type": "string"
+  },
+  "maxItems": 10,
+  "minItems": 6,
+  "type": "array"
+}
    • changedInput schema / required
      Previous value: -[
-  "deck_id",
-  "page",
-  "source"
-]New value: +[
+  "deck_id",
+  "page",
+  "source",
+  "pictures",
+  "direction"
+]
  3. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false / destructiveHint=false. The description goes well beyond that by disclosing the reply payload (next page's brief), and the side effect that saving the final page triggers merge/check/render. Auth/guest nuances are left to the schema, so not a full 5.

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 core action and information-dense across four sentences with no filler. The 'direction' parenthetical repeats the schema description almost verbatim, which is the only wasted space.

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 no output schema, the description carries the return-value burden and does so ('the reply carries the next page's brief... the rendered pages'). Combined with the annotation-provided safety profile, an agent has enough to invoke this correctly, though account vs guest paths are left implicit.

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 75%, so most parameters are already documented. The description still adds meaning for the two undocumented ones (page numbering semantics) and binds 'direction' and 'source' to the actual content each should hold, which is more than the schema alone conveys.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Save one page you wrote') and clarifies the page-1-vs-page-N distinction, which is essential given the idiosyncratic Section0 model. It does not explicitly contrast itself with submit_deck or get_page_brief, so it lands at a clear-but-undifferentiated 4.

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?

Gives a real, non-obvious precondition ('A page is accepted only after its brief was handed to you') and a distinct later-use case ('To fix one page later, submit just that page'). No alternatives are named outright, so it stops short of a 5.

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

All Renderball toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources