Skip to main content
Glama

Create or change a shared code module

r3_module_write
Destructive

Create a shared code module (baseVersion 0) or write its next version (baseVersion = the version you read). The code is a FUNCTION BODY that returns the exports, e.g. return { createShip(host, config) { … return {start, update, dispose, api}; } };. It runs once per run with this undefined (it reaches no component: the importing script passes in what it needs) and the same globals as a script (Event, EntityManager, THREE, GraphicsThree). Variables at its top level are shared by every script that imports it; per-instance state goes in what its factory returns. A module cannot import another module. A write on an older version is refused with the current code, never merged. Projects that follow the latest version run the new one at once (open editors reload it); pinned projects and published releases keep their version.

PATCH a long module instead of sending all of it: replacements [{old, new, count?}] with baseVersion and baseSha256 (the version and sha256 r3_module_read answered), no code. They apply in order, each on the text the previous one left; each old must occur exactly count times (default 1), else nothing is saved and the answer names the replacement and how many it found. At most 200 replacements and 60000 characters of old + new text per call. See "HOWTO_CODE_MODULES.md".

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "baseVersion": "<baseVersion>"
    },
    "name": "r3_module_write"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeNoThe whole module: a function body that returns its exports object (at most 250000 characters; comments and readable names are fine). Omit it when you send replacements.
nameYesThe module name: lower-case letters, digits and hyphens, e.g. "ship-core".
notesNoWhat changed in this version (shown in the version list).
baseSha256NoWith replacements only: the sha256 r3_module_read answered for baseVersion (of the WHOLE code).
baseVersionYes0 to create the module; otherwise the version r3_module_read answered (with replacements: the version they apply to, which must be the latest).
descriptionNoWhat the module is for (one line).
replacementsNoInstead of code: exact replacements on version baseVersion, in order (at most 200, 60000 characters of old + new in all).

Output Schema

NameRequiredDescriptionDefault
nameYes
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.
sha256Yes
createdYes
versionYes
moduleIdYes
unchangedYes
totalCharsYes
occurrencesYes
replacementsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedInput schema / properties / baseSha256
      Added value: +{
      +  "description": "With replacements only: the sha256 r3_module_read answered for baseVersion (of the WHOLE code).",
      +  "pattern": "^[0-9a-f]{64}$",
      +  "type": "string"
      +}
    • changedInput schema / properties / baseVersion / description
      Previous value: -"0 to create the module; otherwise the version r3_module_read answered."New value: +"0 to create the module; otherwise the version r3_module_read answered (with replacements: the version they apply to, which must be the latest)."
    • changedInput schema / properties / code / description
      Previous value: -"The module: a function body that returns its exports object (at most 250000 characters; comments and readable names are fine)."New value: +"The whole module: a function body that returns its exports object (at most 250000 characters; comments and readable names are fine). Omit it when you send replacements."
    • addedInput schema / properties / replacements
      Added value: +{
      +  "description": "Instead of code: exact replacements on version baseVersion, in order (at most 200, 60000 characters of old + new in all).",
      +  "items": {
      +    "properties": {
      +      "count": {
      +        "description": "How many times old occurs, all replaced (default 1).",
      +        "maximum": 9007199254740991,
      +        "minimum": 1,
      +        "type": "integer"
      +      },
      +      "new": {
      +        "description": "What replaces it (empty deletes it). Taken literally.",
      +        "maxLength": 60000,
      +        "type": "string"
      +      },
      +      "old": {
      +        "description": "Exact text in the module (whitespace and line breaks count).",
      +        "maxLength": 60000,
      +        "minLength": 1,
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "old",
      +      "new"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 200,
      +  "minItems": 1,
      +  "type": "array"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "name",
      -  "code",
      -  "baseVersion"
      -]New value: +[
      +  "name",
      +  "baseVersion"
      +]
    • addedOutput schema / properties / occurrences
      Added value: +{
      +  "type": [
      +    "number",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / replacements
      Added value: +{
      +  "type": [
      +    "number",
      +    "null"
      +  ]
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "moduleId",
      -  "name",
      -  "version",
      -  "created",
      -  "unchanged",
      -  "sha256",
      -  "totalChars",
      -  "answer"
      -]New value: +[
      +  "moduleId",
      +  "name",
      +  "version",
      +  "created",
      +  "unchanged",
      +  "sha256",
      +  "totalChars",
      +  "replacements",
      +  "occurrences",
      +  "answer"
      +]
  2. Changed5 schema fields changed
    • changedInput schema / properties / code / description
      Previous value: -"The module: a function body that returns its exports object."New value: +"The module: a function body that returns its exports object (at most 250000 characters; comments and readable names are fine)."
    • changedInput schema / properties / code / maxLength
      Previous value: -60000New value: +250000
    • addedOutput schema / properties / sha256
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / totalChars
      Added value: +{
      +  "type": "number"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "moduleId",
      -  "name",
      -  "version",
      -  "created",
      -  "unchanged",
      -  "answer"
      -]New value: +[
      +  "moduleId",
      +  "name",
      +  "version",
      +  "created",
      +  "unchanged",
      +  "sha256",
      +  "totalChars",
      +  "answer"
      +]
  3. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and non-idempotent writes, yet the description adds substantial behavior beyond them: stale-version writes are refused with the current code and never merged, replacements are atomic (all-or-nothing on count mismatch) and applied sequentially, limits of 200 replacements / 60000 characters, and immediate reload for follow-latest projects. It does not cover permissions/auth requirements, which keeps it short of a 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 create-vs-version distinction, then runtime semantics, then the patch alternative, then the doc pointer — a sensible order with no filler. The sentences are very dense (multiple constraints per sentence), which costs a little readability but every clause carries information.

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 7-parameter code-writing tool with an output schema, the description covers everything an agent needs to call it correctly: version model, stale-write refusal, replacement atomicity and limits, module runtime contract, and non-importability. Return values are correctly left to the output schema.

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: baseVersion's two roles (0 to create vs. read-obtained version to update), baseSha256's provenance from r3_module_read over the WHOLE code, and replacement ordering/count failure semantics that the schema does not state. Some phrases ('Omit it when you send replacements') merely restate schema text.

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?

Opens with a specific verb and resource plus the two modes: create (baseVersion 0) or write the next version (baseVersion = the version you read). It clearly separates modules from scripts ('the importing script passes in what it needs'), which distinguishes it from r3_code_write and the other write siblings.

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?

Explicit when-to-use rules for both modes are tied to baseVersion, and it names the alternative path for large edits: 'PATCH a long module instead of sending all of it' with replacements plus baseVersion/baseSha256 from r3_module_read. It also states a hard exclusion ('A module cannot import another module') and the version-propagation consequences for pinned projects.

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