GenHTTP Lambda

Create a lambda

create_lambda

Create a lambda. Returns its public address and a private editor key, the only way back in. It starts with version 1 - an empty starter, or a copy of a demo. Nothing is online until deploy.

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": {
      "acceptTerms": "<acceptTerms>"
    },
    "name": "create_lambda"
  }
}

Input Schema

Name	Required	Description
`view`	No	How the editor opens: 'Full' (the default) shows every section, 'Simple' only the app, how it is doing and a box to ask for a change. Simple suits an owner who is not going to read the code - use it when the user asks for a simple editor, or says they are not a developer.
`template`	No	Left out, the lambda starts empty. The id of a demo from list_demos starts it as a copy of that demo, which is yours to change.
`publicKey`	No	Requested address: lower case letters, digits and dashes. Generated if omitted.
`acceptTerms`	Yes	Must be true: the user accepts the terms in platform_guide (free shared machine, deployments may be removed, nothing malicious).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 2, 2026

changedInput schema / properties / template / description

Previous value: -"Left out, the lambda starts empty. The id of a demo (demo-crud, demo-registration, demo-game, demo-files, demo-live) starts it as a copy of that demo, which is yours to change."New value: +"Left out, the lambda starts empty. The id of a demo from list_demos starts it as a copy of that demo, which is yours to change."

addedInput schema / properties / view / enum

Added value: +[
+  "Full",
+  "Simple",
+  null
+]

removedInput schema / properties / view / type
```
Removed value: -"string"
```

Changed1 schema field changedSep 28, 2026

addedInput schema / properties / view

Added value: +{
+  "description": "How the editor opens: 'Full' (the default) shows every section, 'Simple' only the app, how it is doing and a box to ask for a change. Simple suits an owner who is not going to read the code - use it when the user asks for a simple editor, or says they are not a developer.",
+  "type": "string"
+}

First observedSep 27, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower, yet the description adds genuinely important context: the returned editor key is "the only way back in" (non-recoverable credential), and the lambda is not live until deploy. That is real operational disclosure beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the verb and the return value, then the initial state, then the deployment caveat. No filler and nothing an agent must skip past to find the essentials.

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?

There is no output schema, so the description usefully explains what is returned (public address, private editor key) and the post-creation state. It doesn't mention the mandatory acceptTerms gate, though the schema covers it, leaving only a minor gap for a creation tool.

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 four parameters, including the acceptTerms requirement and the view enum rationale, are already documented in the schema. The description only echoes the template parameter ("an empty starter, or a copy of a demo") without adding syntax or defaults, so baseline 3 applies.

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 ("Create a lambda") followed immediately by what the caller gets back: a public address and a private editor key. It doesn't explicitly contrast with siblings like create_feature or deploy, but the initial-state sentence ("starts with version 1 - an empty starter, or a copy of a demo") makes the tool's scope unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Nothing is online until deploy" implicitly routes the agent to the deploy sibling for going live, and the schema's template description points at list_demos. But the description itself states no explicit when-to-use or when-not-to-use conditions, so guidance is implied rather than declared.

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.