GenHTTP Lambda

Merge a feature into the lambda

merge_feature

Destructive

Make a feature's files the next version of the lambda, and delete the feature with its preview and its copy of the data - the lambda's own data is not touched. Its docs/ and tests/ become the version's documentation and tests, so bring them up to date in the feature first, and run its tests against the preview. Refused while the feature is not based on the newest version (update_feature says how to get it there), and while its code does not compile. deploy: true puts the new version online at once; otherwise deploy it when the user wants it live.

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": "merge_feature"
  }
}

Input Schema

Name	Required	Description
`change`	No	What the new version says it changes. Left out, the feature's.
`deploy`	No	Also put the new version online.
`feature`	Yes	The feature.
`privateKey`	Yes	The editor key.
`specification`	No	What the new version keeps as what the user wanted. Left out, the feature's.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026
- addedInput schema / properties / deploy / default
```
Added value: +false
```
AddedSep 28, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the destructiveHint annotation by specifying exactly what is destroyed (the feature, its preview, and its copy of the data) and what is preserved (the lambda's own data). It discloses blocking conditions and the immediate-vs-deferred deployment consequence.

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 its destructive effects, then preconditions, then the deploy option. Dense but nearly every clause carries operational information; the final deploy sentence is slightly redundant with the schema property description.

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?

With no output schema, the description covers the necessary ground: destruction scope, data preservation, gating refusals, prerequisite steps, and deployment timing. An agent has everything needed to call this destructive merge safely.

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; the description adds real meaning for deploy, clarifying that true publishes immediately while false defers going live until the user wants it. It also explains that change/specification default to the feature's values, though that is largely echoed in 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?

States a specific verb and resource ('Make a feature's files the next version of the lambda') plus the consequential side effects (feature, preview and its data copy deleted). It is clearly distinguishable from the sibling update_feature, which it names explicitly for the different job of rebasing.

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 preconditions and refusals: refused while the feature is not based on the newest version (routes to update_feature) and while its code does not compile. It also tells the agent to bring docs/tests up to date and run tests against the preview before merging, and when to set deploy:true versus deploying later.

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.