list_filesThe 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.
| Name | Required | Description | Default |
|---|---|---|---|
| feature | No | List this feature's copy of the data instead. | |
| privateKey | Yes | The editor key, or the key of a demo. |
Changes observed during successful MCP inspections.
Input schema / properties / featureAdded value: +{
+ "description": "List this feature's copy of the data instead.",
+ "type": "string"
+}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.
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.
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.
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.
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.
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.
Add one secure layer between your agents and this server.