GenHTTP Lambda

Change a feature's name, notes or base

update_feature

DestructiveIdempotent

Rename a feature, change what it says about itself, or move its base. merge_feature refuses a feature that is not based on the newest version, since merging it would undo what was saved after it branched off: bring the newer versions' changes into the feature first, then move base to the newest version here. Nothing checks that the changes really are in - that is up to you.

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>",
      "feature": "<feature>"
    },
    "name": "update_feature"
  }
}

Input Schema

Name	Required	Description
`base`	No	The version the feature is now based on, once that version's changes are in its files.
`name`	No	A new name.
`change`	No	What it changes, in one line - what the version it is merged into will say.
`feature`	Yes	The feature, from create_feature or read_lambda.
`privateKey`	Yes	The editor key.
`specification`	No	What the user wants from it and why.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 2, 2026
- changedInput schema / properties / base / type
```
Previous value: -"integer"New value: +[
+  "integer",
+  "null"
+]
```
- addedInput schema / properties / name / maxLength
```
Added value: +80
```
AddedSep 28, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true; the description adds a caveat those annotations cannot express — that no validation occurs that the newer changes are actually present, so correctness is the caller's responsibility. It does not explain what the destructive hint means concretely (e.g. whether the previous name/change text is overwritten), which keeps it below 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?

Three sentences, no filler, with the action list front-loaded. The middle sentence is long and its clauses are chained awkwardly, but every sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and six parameters mean the description must carry the load; it handles the base-move workflow well but leaves the metadata-editing half (name, change, specification, required feature/privateKey) unaddressed and never spells out the consequence of the destructive hint.

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 coverage is 100%, so all six parameters are already documented in the schema. The description adds sequencing meaning for base ('once that version's changes are in its files') but nothing for change vs. specification, which remain the least obvious pair in the schema.

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?

Specific verb+resource: rename a feature, edit its description text, or move its base. The mention of merge_feature in the same breath distinguishes it from that sibling, though 'change what it says about itself' is a vague gloss for the change/specification fields and never names them.

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 an explicit routing rule for the base-move case: merge_feature refuses a feature not based on the newest version, so bring the newer changes in first and then move base here. That is real when-to-use guidance with a named alternative, but nothing is said about when to use this for name or note changes versus leaving the feature alone.

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.