Skip to main content
Glama
Sign In

GenHTTP Lambda

by dev.genhttp
OverviewDiscussionsAdmin

List the lambda's data

list_files
Read-onlyIdempotent

The lambda's data: whether its workspace is switched on, and every file in it with size and last write - the same whichever version is online. With feature, that feature's copy of it. The code and resources of a version are in read_lambda.

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

Input Schema

NameRequiredDescriptionDefault
featureNoList this feature's copy of the data instead.
privateKeyYesThe editor key, or the key of a demo.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / feature
      Added value: +{
+  "description": "List this feature's copy of the data instead.",
+  "type": "string"
+}
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and non-open-world. Beyond that, the description discloses return content (file names with size and last write, workspace switched-on state) and a stability property ('the same whichever version is online'), which is genuine behavioral context not present in the annotations.

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 main purpose is front-loaded, which is good, but the terse dash-heavy phrasing ('the same whichever version is online', 'With feature, that feature's copy of it') is awkward and requires re-reading. It is compact but sacrifices clarity for brevity.

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?

With no output schema, the description carries the return-value burden and does so by describing files plus metadata and workspace state. Annotations already cover the safety profile. It lacks any note on pagination or result limits, which is the only notable gap for a list 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 description coverage is 100%, so the schema already documents both parameters, establishing a baseline of 3. The description adds only marginal meaning by noting that feature yields 'that feature's copy of the data', which essentially restates the schema's own wording.

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?

The description states a specific verb (list) and resource (the lambda's data), and enumerates what that data contains: workspace on/off state plus every file with size and last write. It explicitly contrasts with read_lambda ('the code and resources of a version are in read_lambda'), so an agent can distinguish it from the nearest sibling. The only weakness is that the name list_files undersells the workspace-state content, adding mild ambiguity.

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 routes the agent away from this tool for code/resources by naming read_lambda as the alternative, and clarifies the feature-scoped variant. That is clear contextual guidance, though it stops short of explicit 'use this when...' phrasing or exclusions for the other data-adjacent siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All GenHTTP Lambda toolsInspect
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.

Resources