GenHTTP Lambda

Start a feature

create_feature

Start a feature: a place to change a lambda without touching what it has online. It branches off a version - the newest unless base names another - with a copy of its files (its documentation and tests included) and a copy of the lambda's data, and gets an address of its own to try it at. Change it with change_code or write_code and feature (deploy: true puts it online at its preview address), test it there, and merge_feature once it does what was asked. The lambda goes on serving its visitors from the version online the whole time.

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

Input Schema

Name	Required	Description
`base`	No	The version to branch off. Defaults to the newest - leave it out unless the user asked to start from an older one.
`name`	Yes	What the feature is, in a few words for the owner - 'Leaderboard', 'Dark mode'.
`privateKey`	Yes	The editor key.
`specification`	No	What the user wants from it and why, in their words where you can. Kept with the feature and passed on to the version it is merged into. Optional, up to 4000 characters.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 2, 2026

changedInput schema / properties / base / type

Previous value: -"integer"New value: +[
+  "integer",
+  "null"
+]

changedInput schema / properties / name / description

Previous value: -"What the feature is, in a few words for the owner - 'Leaderboard', 'Dark mode'. Up to 80 characters."New value: +"What the feature is, in a few words for the owner - 'Leaderboard', 'Dark mode'."

addedInput schema / properties / name / maxLength
```
Added value: +80
```

AddedSep 28, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations, the description discloses important behavior: the feature branches from a version, copies files and lambda data, gets its own address, and leaves the live lambda serving visitors throughout. This makes the non-destructive, state-creating nature of the operation explicit and is consistent with destructiveHint=false and idempotentHint=false.

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?

The description is front-loaded with the core concept and organized as a workflow, with no obvious filler. It is somewhat long for a four-parameter tool, but the length is largely earned by explaining the branching model and subsequent workflow.

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 complex create/branch/deploy/merge workflow with no output schema, the description gives a complete mental model of what is created and how to proceed. It does not describe the exact return shape, such as whether the preview address or feature identifier is returned, which leaves a minor gap.

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 description coverage is 100%, so all four parameters are already documented in detail. The description contextualizes 'base' by explaining that the feature branches off a version and defaults to the newest, but it mostly restates schema-level meaning rather than adding substantial new parameter guidance.

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 uses a specific verb and resource ('Start a feature') and immediately explains the concrete outcome: an isolated place to change a lambda without affecting what is online. It distinguishes the tool from create_lambda, change_code, deploy, and merge_feature by describing the branching model and preview address.

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?

It clearly states when to use the tool ('a place to change a lambda without touching what it has online') and names downstream tools for the workflow: change_code/write_code for editing, deploy for preview publishing, and merge_feature for completion. It does not explicitly state when not to use it or contrast it with update_feature/delete_feature, but the context is clear.

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.