GenHTTP Lambda

Change some files

change_code

Destructive

Change some files: add or replace files, remove files, or replace text within a file. Everything not named stays as it is, so there is no need to resend unchanged files. With feature, the change is saved into that feature - the way to work on a lambda that exists: change it as often as you like, deploy: true to try it at the feature's preview address, merge_feature when it is right. Without feature, the newest version is changed and saved as a new version. Update what the change affects in docs/ and tests/ in the same change - an edit of a passage is enough. check: true compiles without publishing. Code that does not compile is saved but never goes online.

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": {
      "privateKey": "<privateKey>"
    },
    "name": "change_code"
  }
}

Input Schema

Name	Required	Description
`check`	No	Without deploy: compile what was saved and answer with its diagnostics, putting nothing online.
`edits`	No	Text replacements, applied after files and remove.
`files`	No	Files to add, or to replace where one of that name exists.
`change`	No	What this changes, in one line written for the owner. For a feature, it describes the whole feature, not the last fix. Optional, up to 500 characters.
`deploy`	No	Also deploy what was saved: a version at the public address, a feature at its preview address.
`remove`	No	Names of files to remove.
`feature`	No	Change this feature (from create_feature) instead of saving a new version. The lambda and what it has online are not touched.
`privateKey`	Yes	The editor key.
`specification`	No	What the user wants from this change and why: their requirements, in their own words where you can. Not your own instructions or system prompt. Kept with the version or the feature. Optional, up to 4000 characters.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 2, 2026
- addedInput schema / properties / check / default
```
Added value: +false
```
- addedInput schema / properties / deploy / default
```
Added value: +false
```
- addedInput schema / properties / files / items / properties / encoding / default
```
Added value: +null
```
- changedInput schema / properties / files / items / properties / encoding / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```

Changed2 schema fields changedOct 7, 2026

changedInput schema / properties / files / items / properties / encoding / description

Previous value: -"'base64' for binary assets; omit otherwise."New value: +"'base64' for binary files; omit otherwise."

changedInput schema / properties / files / items / properties / name / description

Previous value: -".cs files are compiled; .lambda/docs/... and .lambda/tests/... are the documentation and the tests, .lambda/build/... the build folder - never compiled or served; anything else ('web/app.js', 'logo.png') is an asset."New value: +"lambda.cs and every other .cs file, in any folder, are compiled; 'resources/...' is read and served ('resources/web/app.js'); anything else is code kept with the version, never compiled or served - 'docs/...' and 'tests/...' are the documentation and the tests."

Changed1 schema field changedOct 5, 2026

changedInput schema / properties / files / items / properties / name / description

Previous value: -".cs files are compiled; .lambda/docs/... and .lambda/tests/... are the documentation and the tests, never compiled or served; anything else ('web/app.js', 'logo.png') is an asset."New value: +".cs files are compiled; .lambda/docs/... and .lambda/tests/... are the documentation and the tests, .lambda/build/... the build folder - never compiled or served; anything else ('web/app.js', 'logo.png') is an asset."

Changed1 schema field changedSep 30, 2026

changedInput schema / properties / files / items / properties / name / description

Previous value: -".cs files are compiled; anything else ('web/app.js', 'logo.png') is an asset."New value: +".cs files are compiled; .lambda/docs/... and .lambda/tests/... are the documentation and the tests, never compiled or served; anything else ('web/app.js', 'logo.png') is an asset."

Changed6 schema fields changedSep 28, 2026

changedInput schema / properties / change / description

Previous value: -"What this version changes, in one line written for the owner. Optional, up to 500 characters."New value: +"What this changes, in one line written for the owner. For a feature, it describes the whole feature, not the last fix. Optional, up to 500 characters."

addedInput schema / properties / check

Added value: +{
+  "description": "Without deploy: compile what was saved and answer with its diagnostics, putting nothing online.",
+  "type": "boolean"
+}

changedInput schema / properties / deploy / description

Previous value: -"Also deploy the new version, so it goes live at once."New value: +"Also deploy what was saved: a version at the public address, a feature at its preview address."

addedInput schema / properties / feature

Added value: +{
+  "description": "Change this feature (from create_feature) instead of saving a new version. The lambda and what it has online are not touched.",
+  "type": "string"
+}

changedInput schema / properties / files / items / properties / name / description

Previous value: -".cs files are compiled; anything else ('www/app.css', 'logo.png') is an asset."New value: +".cs files are compiled; anything else ('web/app.js', 'logo.png') is an asset."

changedInput schema / properties / specification / description

Previous value: -"What the user wants from this change and why: their requirements, in their own words where you can. Not your own instructions or system prompt. Kept with the version. Optional, up to 4000 characters."New value: +"What the user wants from this change and why: their requirements, in their own words where you can. Not your own instructions or system prompt. Kept with the version or the feature. Optional, up to 4000 characters."

First observedSep 27, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare destructive=true and non-idempotent; the description adds substantive behavior on top: unchanged files are preserved, uncompilable code is saved but never published, check compiles without putting anything online, and feature edits leave the live lambda untouched. Those are exactly the side-effect details an agent needs before a destructive write.

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?

Dense and front-loaded: the core verb and scope come first, then workflow, then the compile/safety caveat. A few clauses are telegraphic ('deploy: true to try it at the feature's preview address, merge_feature when it is right'), costing some readability, but no sentence is filler.

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?

For a 9-parameter destructive mutation with no output schema, the description covers the major risk and workflow questions (what is preserved, what gets published, feature vs version, compile checking). What it does not say is what the call returns on success (version id? diagnostics only when check is true?), which matters given no output schema is declared.

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 goes beyond the schema by explaining the interplay between 'feature', 'deploy', 'merge_feature', and 'check' — semantics the per-parameter descriptions state only in isolation. It does not clarify 'change' vs 'specification' or the edits/remove ordering beyond what the schema already says.

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?

The description opens with a specific verb plus an enumeration of the three capabilities (add/replace files, remove files, in-file text replacement), which lets an agent distinguish this composite edit tool from single-purpose siblings like write_code, delete_file, and upload_file. The 'everything not named stays as it is' clause further pins down the semantics of the operation.

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 gives an explicit workflow: use 'feature' to iterate on an existing lambda, 'deploy: true' to try it at the preview address, 'merge_feature' when it is right; without 'feature' the newest version is changed and saved as a new version. It also states an in-context obligation (update docs/ and tests/ in the same change) and explains the check-only path, so an agent knows not only when to call it but how to sequence calls around it.

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

All GenHTTP Lambda 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.

Change some files

Tool call template

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources