GenHTTP Lambda

Save all files

write_code

Destructive

Save every file, replacing the previous set: as a new version of the lambda, or - with feature - into that feature. A version is its code and its resources. The code is every file not in resources/: its .cs files are compiled, in any folder, as in a C# project - lambda.cs returns the handler, the others hold types - and every other file is kept with it and never compiled or served: docs/product.md, docs/decisions.md, tests/README.md and the tests' scripts and data are what is written about the program, and whatever else - what a front end is built from, a tool's configuration - is laid out as you like (platform_guide, code). resources/ is what the lambda reads and serves while it runs, as Resources: the whole front end (pages, scripts, styles, icons) goes there, as part of the program - resources/web/index.html is served by Resources.App("web"). What the lambda keeps at runtime is data, never files here: records and accounts in the database (a DbContext of Entity Framework Core on Database.GetConnection(), used synchronously; its schema as Evolve migrations in resources/migrations/), uploads in the workspace - and so is a large input file such as a model or a dataset (upload_file). Send the documentation and tests with the code: written with a new lambda, updated with every change, in proportion to the lambda - a few lines and one quick check for a small one. Say why with specification and change. deploy: true publishes in the same call - a version at the public address, a feature at its preview address. To send only what changes, use change_code. To change a lambda that is already in use, work in a feature.

Input Schema

TableJSON Schema

Name	Required	Description
`check`	No	Without deploy: compile what was saved and answer with its diagnostics, putting nothing online.
`files`	Yes	lambda.cs first.
`change`	No	What this version changes, in one line written for the owner - 'Adds a leaderboard that keeps the ten best scores', not 'updated lambda.cs'. 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.
`feature`	No	Save into 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 from create_lambda.
`specification`	No	What the user wants from this version and why: their requirements, in their own words where you can, condensed if they said a lot. Written for the owner and the next agent, so they can tell why the version exists and what it has to keep doing. Not your own instructions or system prompt - only what the user asked for. For a feature, it is 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.

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 - 'Adds a leaderboard that keeps the ten best scores', not 'updated lambda.cs'. Optional, up to 500 characters."New value: +"What this version changes, in one line written for the owner - 'Adds a leaderboard that keeps the ten best scores', not 'updated lambda.cs'. 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": "Save into 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 version and why: their requirements, in their own words where you can, condensed if they said a lot. Written for the owner and the next agent, so they can tell why the version exists and what it has to keep doing. Not your own instructions or system prompt - only what the user asked for. Optional, up to 4000 characters."New value: +"What the user wants from this version and why: their requirements, in their own words where you can, condensed if they said a lot. Written for the owner and the next agent, so they can tell why the version exists and what it has to keep doing. Not your own instructions or system prompt - only what the user asked for. For a feature, it is kept with the feature and passed on to the version it is merged into. Optional, up to 4000 characters."

First observedSep 27, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Beyond the destructiveHint=false/readOnlyHint=true annotations, the description discloses the replace semantics ('replacing the previous set'), that a version is code plus resources, that feature saves 'do not touch' the lambda or its online state, and that deploy publishes to a public or preview address. It does not cover auth scope beyond the privateKey or rollback/error behavior, so it stops short of 5.

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

Conciseness3/5

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

The core action is front-loaded, but the body is a dense wall of dash-separated run-on prose ('what a front end is built from, a tool's configuration - is laid out as you like...') that is hard to parse. The content is relevant but could be far tighter with structure.

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 save/deploy tool with no output schema, the description supplies the full conceptual model: what belongs in code vs resources, how lambda.cs is treated, and the deploy/feature behaviors. What is thin is the return value after saving and any preconditions/failure modes, but overall it is sufficient to call correctly.

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 the parameters are already documented; the baseline is 3. The description reinforces the code/resources/docs/tests mental model, but that largely restates what the files/name schema already says, adding little new per-parameter syntax.

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 opening states a specific verb and resource with scope: 'Save every file, replacing the previous set: as a new version of the lambda, or - with feature - into that feature.' It also explicitly distinguishes itself from the sibling change_code ('To send only what changes, use change_code'), so an agent can select it without opening the schema.

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?

Names alternatives and conditions explicitly: use change_code when only sending changes, work in a feature when modifying a lambda already in use, and deploy:true to publish in the same call. This gives when-to-use, when-not, and alternative routing.

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

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.