GenHTTP Lambda

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

Annotations declare it non-read-only, destructive and idempotent; the description backs this up and goes further, disclosing that it is off until enabled, that counting is UTC daily and written every few minutes, that a year is retained (7 days free / all premium), and that switching off permanently deletes what was counted. This is behavioral context well beyond the annotations and fully consistent with them.

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?

It is one dense run-on paragraph of clauses and semicolons with no separation between return content, retention, and the destructive enable/disable behavior. Every clause is informative, but the lack of structure makes it harder to scan than it needs to be.

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 full burden of describing returns, and it does so by enumerating the metrics returned. Combined with retention, default-on state, and enable/disable semantics, an agent has everything needed to call and interpret this tool correctly.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning: 'days' defaults to the tier maximum, and 'enable' should only be set when the user has asked. That is meaningful guidance layered on top of what the schema already documents.

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 names a specific resource (visitor analytics for a lambda) and enumerates exactly what is reported: visitors, pages, requests per day, referrers, countries, devices, browsers, OS and crawlers. It is clearly a distinct concern from read_logs or read_lambda, though it never names a sibling to route against, which holds it just below a 5.

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 gives an explicit use case ('answer what the user asks about their visitors, or to see which pages matter before changing them') and a conditional rule for the write path ('enable: true switches it on, only when the user asks'). No when-not or named alternative is offered, so it stops short of a 5.

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

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

Annotations declare destructiveHint=true and idempotentHint=false, and the description corroborates by covering removal and replacement. It adds genuinely useful non-obvious behavior: untouched files stay as-is, uncompiled code is saved but never published, and feature edits leave the live lambda untouched. It doesn't state permission requirements or reversibility of a saved version.

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?

Well front-loaded with the core capability first, then workflow detail. The feature sentence is a dense run-on ('...the way to work on a lambda that exists: change it as often as you like, deploy: true to try it... merge_feature when it is right') that takes effort to parse, but no sentence is wasted.

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?

For a 9-parameter mutation tool with no output schema, the description covers the workflow (feature vs version, deploy, check) that the schema alone cannot express. It leaves the multiplexed add/replace/remove ordering only partially covered, but is otherwise sufficient to invoke correctly.

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 baseline is 3, but the description adds real meaning: it clarifies that feature changes an existing feature rather than saving a new version, that check compiles without publishing, and that deploy targets preview vs public addresses. These distinctions go beyond the per-parameter schema text.

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 opens with a specific verb and resource: 'Change some files: add or replace files, remove files, or replace text within a file.' That precisely enumerates the three mutation modes. It doesn't explicitly contrast itself with siblings like write_code or upload_file, which an agent must still disambiguate on its own.

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?

Strong conditional guidance for the feature workflow: use feature to edit an existing lambda, 'deploy: true to try it at the feature's preview address, merge_feature when it is right,' and without feature a new version is saved. It also states when check applies. It stops short of telling the agent when to prefer this over write_code.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower, yet the description adds real substance: nothing is persisted, nothing is deployed, and it discloses the limitation that the handler is not built so deploy may still reject an unserveable return type. That caveat is genuinely non-obvious behavioral context.

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?

Two tight sentences with the core operation and its non-effects front-loaded, followed by one caveat sentence. Nothing is redundant and nothing is padding.

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 correctly carries the return contract ('diagnostics with file and line') and warns about a downstream failure mode. It is close to complete; it does not describe diagnostic severity or error response shape, but nothing essential to invoking it is missing.

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 privateKey and the files array in detail. The description adds no parameter-level syntax or format detail, so the baseline 3 applies.

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?

States a specific verb and resource (compile code) and immediately bounds scope with 'without saving or deploying', which cleanly separates it from write_code/change_code and deploy. An agent can identify the operation 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.

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

The 'without saving or deploying' framing clearly implies the use case (validate before persisting or shipping) and even explains the payoff relationship with deploy. It stops short of explicitly naming the sibling tools it substitutes for, but the contrast is unambiguous.

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

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

Annotations already declare non-read-only, non-destructive, non-idempotent, and closed-world behavior. The description adds substantial context beyond annotations: it copies the lambda's files, documentation, tests, and data; creates a separate preview address; and leaves the live version serving visitors throughout.

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 purpose is front-loaded in the first clause, and the remaining sentences explain the workflow and safety guarantee without filler. Despite being dense, every sentence contributes useful context for a multi-step feature workflow.

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?

The description covers the creation behavior, isolation guarantee, and subsequent lifecycle steps well. With no output schema, it would be stronger if it explicitly stated what create_feature returns, such as the feature identifier or preview address needed by later calls.

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 meaning of base, name, privateKey, and specification is already fully documented. The description aligns with those definitions but does not add syntax, constraints, or semantics beyond what the schema provides.

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 and resource: starting a feature that branches from a version, copies files and data, and gives a preview address. It clearly distinguishes this from changing a live lambda and names related tools such as change_code, write_code, deploy, and merge_feature.

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 gives strong contextual guidance: use this to change a lambda without affecting what is online, then use change_code/write_code, test the preview, and merge when ready. However, it does not explicitly contrast this with directly updating the live lambda via update_lambda or update_feature, so it is clear without full when-not routing.

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

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

Annotations supply the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description is free to add higher-value context: the private editor key is "the only way back in" (a critical warning), what version it starts at, and that nothing is live until deploy. This goes well beyond the structured hints and is consistent with them.

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?

Four short sentences, front-loaded with the core action and return values, then lifecycle notes. The key warning is stated early and each sentence carries content; no filler.

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?

For a creation tool with no output schema, the description covers what is returned (public address, private key), the initial version state, and the deploy gating. It does not spell out auth/permission nuances, but annotations carry the safety profile and acceptTerms covers the terms gate, so the picture is largely complete.

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 coverage is 100%, so the schema already documents all four parameters, including the view modes, demo ids, key format, and the acceptTerms requirement. The description's "empty starter or a copy of a demo" echoes the template parameter but adds no syntax or rules beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource ("Create a lambda") and adds scope detail: it returns a public address and private editor key, and starts at version 1 as either an empty starter or a demo copy. It is clearly distinguishable from read_lambda/update_lambda/delete by the create verb, though it does not explicitly name those siblings.

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?

Usage is implied (call this when the user wants a new lambda), and the closing note "Nothing is online until deploy" usefully routes the agent to the deploy sibling. But there is no explicit when-to-use/when-not statement or mention of prerequisites tied to the alternatives.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered; the description adds real value beyond that by detailing the destruction scope (files, preview, data copy) and explicitly excluding the lambda. It does not mention irreversibility or confirmation requirements, which would have made it a 5.

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?

Three short sentences; the scope of destruction is front-loaded and each sentence carries distinct information (what is deleted, what is spared, when to use it). No filler.

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?

For a two-parameter destructive tool with no output schema and full annotation coverage, the description is nearly sufficient: it clarifies destruction scope, the lambda carve-out, and intent. Only a note on irreversibility or required authorization is missing.

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% for both parameters ('The feature.', 'The editor key.'), so the schema carries parameter semantics. The description adds no format or selection guidance for 'feature' or 'privateKey', leaving the baseline 3 appropriate.

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 gives a concrete verb ('throw a feature away') and enumerates exactly what is removed: files, preview, and the data copy. It also states a boundary ('the lambda is not touched'), which helps distinguish it from delete_file and delete_lambda-style operations, though it never names a sibling explicitly.

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?

The phrase 'For a feature the user does not want after all' implies the use case but states no alternatives, prerequisites, or exclusions. It gives a soft when-to-use signal while leaving the agent to infer how this differs from delete_file.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: the deletion is permanent ('No deploy or rollback brings it back') and workspace data is shared across every version. It does not discuss permissions or rate limits, but the editor-key auth is documented in the schema.

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?

Three compact sentences, zero waste, with the destructive scope and permanence front-loaded ahead of the optional feature behavior. Every clause carries information the agent needs.

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?

For a destructive, non-read-only tool with no output schema, the description covers scope, permanence, and the feature override, and annotations cover safety and idempotency. What is missing is minor: no statement of required permissions beyond the schema's editor key, and no note on folder-recursion behavior beyond 'with its contents'.

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 coverage is 100%, so all three parameters are already documented. The description reinforces the meaning of `feature` (delete from that feature's copy) and clarifies that `path` is relative to a workspace shared by all versions, but adds no format or syntax detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb (Remove) and resource (a file, or a folder with its contents) plus the exact scope: the workspace / lambda's data, shared by every version. An agent can distinguish this from upload_file, list_files, or delete_feature without opening any schema.

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?

Gives an explicit routing condition: 'With feature, from that feature's copy instead,' which tells the agent when the optional parameter changes the target. It stops short of naming sibling alternatives or stating when-not to use it (e.g. prefer delete_feature for features), so it is clear context without full exclusions.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds a consequence annotations cannot express: readers using Secret.Read will fail from their next call onward, which is meaningful impact context.

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?

Highly economical and front-loaded: consequence of deletion is stated before the usage caveat. Some sentences are telegraphic fragments ('With feature, from that feature's copy instead'), which slightly hurts readability.

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?

For a destructive tool with no output schema, the description covers the effect on readers, the usage constraint, and the feature-copy option, which is enough to call it correctly. It omits auth/permission detail, though the schema supplies the editor key.

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 coverage is 100%, so name, feature, and privateKey are all documented in the schema. The description adds only a light gloss on 'feature' ('from that feature's copy instead'), matching the schema text rather than extending it, so baseline 3 applies.

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?

States a specific verb+resource ('Remove a secret') and immediately qualifies scope with the feature-copy variant. It does not name sibling tools like set_secret or delete_feature to route between them, but the operation is unambiguous.

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?

Explicitly constrains when to use it ('Only when the user asks for it, or a secret you stored yourself is no longer used'), which is real use/when-not guidance rarely seen. It does not name an alternative tool, only the feature-parameter variant.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety bar is lower, but the description adds real behavior: feature deploys run against the feature's own copy of the data and leave the lambda alone, and failures return diagnostics while the current live state is retained. It does not spell out permissions beyond the schema's 'editor key', which keeps it from a 5.

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?

Two dense sentences with no filler; the primary behavior and the default are front-loaded, and the alternative feature mode and failure behavior follow in the same compact block.

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?

For a mutating, non-read-only tool with no output schema, the description covers both operating modes, the default target, failure behavior, and downstream safety. It leaves only minor details (auth expectations, what a successful response looks like) implicit, which is acceptable given there is no output schema to rely on.

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 coverage is 100%, so the baseline is 3, but the description adds meaning beyond the terse schema text: using 'feature' targets a preview address, runs against that feature's copy of the data, and explicitly does not touch the lambda. That isolation semantic is not conveyed by the parameter description alone.

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?

States a specific verb and resource ('Deploy (publish) a saved version') plus the two distinct modes (version to the lambda's public address vs. feature to its preview address) and the default. An agent can distinguish this from siblings like merge_feature and create_feature without opening their schemas.

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?

Explicitly says what happens with the 'feature' argument versus without it, and states the default behavior when 'version' is omitted. It stops short of naming which sibling to use instead for related operations (e.g. merge_feature for merging a feature), so it is clear context rather than explicit alternatives.

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

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

Beyond the annotations it discloses non-obvious behavior: changes take effect immediately without a deploy, enabling the database restarts the lambda on its next request so migrations run, enabling the database yields an empty store, and deactivation is owner-only and destructive. This substantiates the destructiveHint and idempotentHint rather than restating them.

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?

Front-loaded with the purpose and sized proportionally to a tool with meaningful side effects, but the kind enumeration is buried in a long parenthetical with awkward phrasing ('off until switched on, which makes it, empty') that slightly impedes scanning.

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?

For a two-parameter action tool with annotations covering the safety profile and no output schema, the description covers the kinds, timing of effects, restart/migration consequences, and the absence of an inverse operation — everything needed to invoke it correctly.

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 coverage is 100%, so the schema already defines 'kind' and 'privateKey'. The description still adds real semantics per kind (defaults and side effects for database/secrets/workspace) that the flat schema strings do not convey, though it says nothing extra about the 'privateKey' editor key parameter.

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 precise verb+resource (switch on a kind of data) and then enumerates the three valid kinds ('database', 'secrets', 'workspace') with their default states, so an agent can distinguish this from siblings like set_secret or list_secrets 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.

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

It gives explicit when-to-use criteria with concrete examples ('records need the database, an API key for a service it calls needs secrets') and an explicit exclusion ('There is no tool to switch one off: that deletes what it held, and is the owner's to do in the editor'), routing the agent away from an impossible action.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world. The description adds meaningful context beyond them: the demo keys are public and read-only, and the demos serve as canonical reference implementations. It does not characterize the return shape or ordering, but for a zero-param read that is minor.

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?

Three sentences, front-loaded with what demos are, then the read path, then the template path. The mid-sentence enumeration of demo categories is slightly listy but earns its place by telling the agent what kinds of reference code exist.

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?

No output schema exists, so the description carries the burden of previewing return content, and it does so by describing demos as finished lambdas with concrete types and public read-only keys. An agent knows what it will get and what to do next; only explicit pagination/ordering detail is absent, which is negligible here.

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?

There are zero parameters and schema coverage is 100%, so the baseline is 4. The description correctly adds no parameter commentary since there is nothing to parameterize.

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 the resource (demos, each a finished lambda) and characterizes what they are with concrete examples (REST API, login, websocket game, uploads). It is clear the tool surfaces this catalog, though it never literally says 'returns a list', leaning on the name/title for the verb. It implicitly distinguishes itself from siblings by framing demos as read-only reference code.

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?

Explicit routing: read the closest demo with read_lambda (plus list_files, read_logs) before writing similar code, and use create_lambda with a demo's id as template to start from a copy. This tells the agent both the follow-up action and the alternative path, which is exactly what a catalog tool needs.

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

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.

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real value by disclosing what the listing reports: enabled state, stored value/timestamp, 'missing' names read via Secret.Read, and 'optional' names checked via Secret.Exists. That category breakdown is meaningful behavior beyond 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?

It is a single front-loaded sentence with no filler, but the heavy dash-and-parenthetical construction makes it dense and hard to parse on a first read, and the nesting of two categories (missing/optional) inside the run-on sentence costs clarity.

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?

There is no output schema, so the description correctly carries the return-value burden by enumerating the status categories returned. Combined with complete annotation coverage and fully described parameters, an agent has enough to call it correctly; only the absence of any write-scenario routing keeps it short of 5.

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 baseline is 3. The description's 'With feature, that feature's copy' loosely reinforces the schema's own 'List this feature's copy instead,' but adds no syntax, default, or format detail beyond it, and says nothing about the required privateKey.

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?

States a specific verb+resource ('list the lambda's secrets') and immediately scopes the output ('by name - never their values'), which cleanly separates it from value-returning or mutating siblings. However, it never names the relevant siblings (set_secret, delete_secret), so the differentiation is inferred rather than explicit.

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?

Usage is only implied: an agent can infer you'd call this to inspect secret state, and 'With feature, that feature's copy' hints at the feature-scoping use case. There is no explicit when/when-not guidance and no routing to set_secret or delete_secret for write operations.

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

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

Exceeds the annotations (destructiveHint=true, readOnlyHint=false) by specifying exactly what is destroyed (feature, preview, its data copy) and what is preserved (the lambda's own data). Adds refusal conditions, the docs/tests handoff requirement, and deploy timing — rich behavior beyond the structured hints.

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?

Three dense sentences, purpose front-loaded, no filler. Sentences are long and clause-heavy, but virtually every clause carries actionable information rather than restating the name.

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?

For a destructive, non-idempotent mutation with no output schema, the description covers destruction scope, preserved state, refusal conditions, the update_feature remedy, and deploy semantics. Nothing an agent needs to invoke it safely is missing.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning for deploy ('puts the new version online at once; otherwise deploy it when the user wants it live') and contextualizes change/specification through the docs/tests framing.

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?

States a precise verb+resource: makes a feature's files the next lambda version and deletes the feature with its preview and data copy. This clearly distinguishes it from siblings like update_feature, deploy, and delete_feature, which it explicitly avoids overlapping with.

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?

Gives explicit preconditions and refusals: refused while the feature is not based on the newest version (naming update_feature as the remedy) and while its code does not compile. Also routes deploy:true vs. deferred deployment, so the agent knows exactly when to call it and how.

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

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

The description adds significant behavioral context beyond the annotations: it details what data is never published (database, workspace, secrets), warns that older versions become public, and advises keeping secrets out. It also covers the read-only query behavior when only privateKey is provided. Annotations already flag destructiveHint and idempotentHint, but the description enriches with privacy and scope warnings.

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 description is dense but front-loads the core action and then layers on important caveats. It avoids unnecessary repetition, though the long final sentence about public versions and secrets is somewhat packed. Overall it is well-structured and every sentence adds value.

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?

Given the complexity of this mutation tool (publishing, unpublishing, license changes) and the absence of an output schema, the description covers all critical aspects: what gets published, privacy implications, license handling, and the read-only mode. Nothing essential for correct invocation is missing.

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 coverage is 100%, so the schema fully documents each parameter's meaning and defaults. The description adds a little extra context for the license default and the effect of omitting author/remove, but mostly repeats what is in the schema. The baseline 3 is appropriate when the schema does the heavy lifting.

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 and resource ('Publish a lambda's source code at /source/{publicKey}') and enumerates the full scope of what is published. It also clearly distinguishes the tool from siblings like deploy or write_code by emphasizing that it is 'not part of building' and is a separate publication action.

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 explicitly states when to use the tool ('only do this when the user asks for it'), provides a fallback behavior (ask which license if not specified, default MIT), and describes the no-op case with only privateKey. This gives clear operational guidance without needing to check other tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered by structured data. The description adds real value by enumerating the guide's subject matter but says nothing about return format, length, or how to consume it, so it is useful but not rich.

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 lead clause is well front-loaded, but the remainder is a dense comma-chained list of topics ('what a version... what is code... what is imported, what is refused...') that is harder to scan than it needs to be. Nothing is explicitly wasted, but structure could be tighter.

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?

For a zero-parameter, read-only reference tool with no output schema, the description gives an adequate inventory of what the guide covers. An agent knows this is a safe read that orients it before using the operational siblings; only return shape is unspecified, which is minor here.

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?

The tool takes zero parameters with 100% schema coverage, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter guidance is needed or missing.

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 makes clear this is a conceptual reference tool ('How this platform works') that explains versions, features, data, code vs resource, docs/tests, and limits. It distinguishes itself from the operational siblings (deploy, create_feature, write_code) by being purely explanatory, though no explicit verb such as 'read' or 'returns' leads the sentence.

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?

'read it first' gives explicit ordering guidance telling the agent to consult this before acting on siblings. It stops short of naming any alternative, but a reference document has no real competing tool, so the guidance is sufficient for its class.

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

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

Annotations already cover readOnly/idempotent/destructive, so the bar is lowered, yet the description still adds real context: the database is shared by every version, the lambda itself is the writer (via Database.GetConnection()), and feature mode reads a copy rather than the shared store. That shared-vs-copy distinction is a genuinely useful behavioral trait. It omits write-permission/auth friction but this is a read tool.

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?

Information-dense with no filler, but the opening sentence is a long semicolon run-on that buries mode behavior inside a single breath. A mildly restructured version would scan better for an agent.

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 reasonably: it says what the database summary contains (on/off state, fullness, tables and views with columns and row counts) and what table mode returns. Pagination cues (offset/limit) exist in the schema. It is complete enough to invoke confidently, with only minor gaps around large-result behavior.

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 coverage is 100%, so the baseline is 3 and the schema already documents every parameter including defaults. The description reinforces table/feature/limit semantics but adds little beyond the schema, and its 'newest first' default for ordered pages sits awkwardly against the schema's 'order the rows were written in' default.

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 names the concrete resource (the lambda's database) and enumerates its modes: table listings, a page of a table's rows, feature copies. This is unmistakably more than a restatement of the name. It stops short of a 5 because it never positions itself against siblings like read_lambda or read_logs.

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?

'Use it to see that migrations were applied and records were written' gives a concrete motivating scenario. There is no explicit when-not guidance or named alternative, so it does not reach the top band.

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

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

Annotations already cover readOnly, idempotent, openWorld=false, and destructive=false. The description adds substantial output behavior beyond those annotations: documentation is returned first up to 20,000 characters, files are returned in a specific order while they fit within 30,000 characters, and the file parameter can return a single file up to 1,048,576 characters before falling back to a zip. Auth and rate-limit behavior are not described, but the return-shaping details are strong.

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 description is a single, dense, run-on paragraph of about 170 words. While much of the content is relevant for a tool without an output schema, it is not front-loaded or structured for quick scanning, and many clauses are packed into one unwieldy sentence.

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?

There is no output schema, so the description must explain return values and limits. It comprehensively describes the status, features, versions, data, secrets, documentation, tests, and files that are returned, including ordering and truncation rules. It also covers how demo lambdas are read.

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 input schema already documents all four parameters. The description largely restates file, feature, and version behavior and adds only a small amount of context for privateKey by noting that demo keys come from list_demos. With full schema coverage, this meets the baseline of 3.

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?

States a specific verb and resource: reading a lambda's status, features, versions, data, and version/feature files. It is clear what the tool does, though it does not explicitly differentiate itself from all sibling read tools such as read_logs or read_database.

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?

The description gives one explicit usage cue: read documentation and history before changing code you did not write. It also notes that demo access uses a key from list_demos. It does not state when not to use this tool or name alternative read tools for other contexts.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds real context beyond them: it explains the scope of returned data and that feature preview output is kept separate from the lambda's visitors, which is a non-obvious behavioral detail.

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?

Two sentences, front-loaded with the payload description before the usage cues, and no filler. The phrasing is somewhat wordy ('what a deployed lambda has been doing') but each clause carries information.

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 does the work of explaining what comes back (requests, prints, errors, traffic), and it covers the feature-preview mode. Only minor gaps remain, such as pagination/cursor behavior, which the schema partially handles.

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 level, limit, since, and feature are already documented in the schema; baseline is 3. The description adds the semantic point that feature output is 'kept apart from the lambda's visitors,' which slightly clarifies the feature parameter, but no extra syntax or default detail is supplied.

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?

States a specific verb and resource and enumerates what the logs contain: requests and responses, prints, errors with stack traces, and traffic volume. An agent can tell this is a log-reading tool rather than a metadata reader, though it never names the nearest sibling (read_lambda) to sharpen the distinction.

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?

Gives concrete triggers: 'Call it after deploying to see that it works, and first when something is reported broken.' That is clear when-to-use guidance, but there is no explicit when-not or named alternative (e.g., read_lambda for status/health).

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

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

Goes well beyond the annotations: the value is sealed and never readable back, only the lambda reads it starting from its next call, no deploy is required, secrets must be enabled first via enable_data, feature scoping writes to a feature's copy, and there is a 100-secret / 32 KB quota. This is exactly the kind of operational detail annotations cannot carry.

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?

Dense but front-loaded: the primary action and its contract come first, then caveats and quota. The feature/sandbox sentence is slightly telegraphic ('With feature, into that feature's copy'), but overall each sentence earns its place.

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?

No output schema exists, and the description compensates by stating that the value cannot be read back, implying a write-only acknowledgement. Prerequisites, scoping, and limits are all covered; only the exact success/failure response shape is left implicit.

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 coverage is 100%, so the schema carries the baseline, but the description still adds meaning: it explains why the name matters (read via Secret.Read("NAME")), that feature stores a sandbox copy for trying things out, and that the value is the user-supplied one. Modest but genuine value beyond the schema.

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?

States a specific verb and resource ('Store a secret') plus the exact code-level contract (Secret.Read("NAME")), and it is trivially distinguishable from delete_secret and list_secrets in the sibling set. An agent knows what this tool does 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.

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

Explicit when-to-use and when-not-to-use: 'Only set a value the user gave you for this: when you do not have it, write the code with Secret.Read and tell the user to set it under Data > Secrets'. It also names the relevant alternatives (read_lambda, list_secrets) and the prerequisite (enable_data).

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

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

Annotations declare destructiveHint=true and readOnlyHint=false but say nothing about modes, prerequisites, or side effects; the description fills exactly those gaps. It discloses the read-only mode (privateKey alone returns the current entry), the content requirements for a new entry, the condition under which the listing persists ('listed while the lambda is online'), and the expected writing style.

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?

Front-loaded with what the tool does, then the gating condition, then the read mode, then entry requirements. Reasonably tight, though the style-prescription sentence ('no marketing language, no superlatives, no exclamation marks, no emoji') is somewhat verbose relative to the functional content.

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 ('returns the current entry'). All five parameters are covered, prerequisites are stated, and the destructive/online-listing behavior is clear, leaving nothing an agent needs before invoking it.

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 coverage is 100%, so the baseline is 3; the description exceeds it by explaining parameter-combination semantics that the schema cannot express on its own (privateKey alone = read; title/description/picture required for a new entry; remove takes it off). It does not add format details for image beyond what the schema already documents.

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?

States a specific verb stack and resource ('List a lambda on the public showcase page, change its entry, or take it off') that is unmistakably distinct from siblings like create_lambda, deploy, or write_code. An agent can identify both the resource and the three modes of operation 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.

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

Explicit when-to-use and when-not: 'Not part of building: only do this when the user asks for it', which clearly separates it from the build/deploy workflow siblings. It also implies mode selection ('With only privateKey it returns the current entry'), though no sibling alternative is named for the listing itself.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered structurally. The description adds real value beyond them by warning that pointing base at an un-merged version would undo post-branch work, and by stating 'nothing checks that the changes really are in - that is up to you' – a non-obvious caveat about the tool's trust model.

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?

Purpose is front-loaded in the first sentence, followed by the merge/base interaction and the caveat. Three sentences with no filler, though the middle sentence is dense and could be split for readability.

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?

For a six-parameter mutation tool with no output schema, the description covers the highest-risk behavior (base reassignment and its interaction with merge_feature) and the lack of validation. It omits what happens to unrelated fields on update and any permission requirements, but the critical operational context is present.

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 all six parameters, making 3 the baseline. The prose loosely maps to base and the self-description fields but adds no naming, format, or validation detail beyond what the schema provides.

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 opening sentence names the specific verbs and fields: rename, change its self-description, and move its base. It explicitly distinguishes itself from merge_feature, so an agent can tell which tool owns the merge versus the attribute-edit operation without opening either schema.

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 gives the crucial prerequisite for the risky path: bring the newer version's changes into the feature before moving base, and implies merging is merge_feature's job. It does not spell out when a plain rename is preferable to change_code or other edit siblings, so guidance is clear but not exhaustive.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds the crucial non-obvious trait: this changes only the default view, while whoever opens the editor can still switch for themselves and keep that choice — which explains why the write is idempotent but affects other users. It does not state permission requirements or the response shape.

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?

Purpose is front-loaded in the first clause, and the default-vs-personal semantics plus the caution are placed after it. However, the middle run-on sentence restates the enum values that the input schema already documents verbatim, adding length without new information.

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 only two parameters, no output schema, and annotations carrying the safety hints, the description supplies the missing behavioral nuance (scope of the default change) and the usage gate. Nothing essential for a correct call is absent, though permission/persistence details would round it out.

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%, and the view parameter is documented in the schema with the same 'Full'/'Simple' explanation the description repeats. The description adds no syntax, defaults, or edge-case handling beyond the schema, so baseline 3 applies; privateKey is left unexplained in both places.

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?

Names a specific verb and resource ('Change how a lambda's editor opens') and the setting affected, so an agent can tell it apart from siblings like change_code or update_feature. It never generalizes to 'lambda settings' even though the title does, which slightly narrows the perceived scope but keeps it precise.

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?

Gives a clear gating rule ('Only do this when the user asks for it') and the schema reinforces the trigger ('use it when the user asks for a simple editor, or says they are not a developer'). It does not name a sibling alternative (e.g. read_lambda to inspect current state), but the when-to-use condition is explicit rather than implied.

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

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

Adds real behavioral context beyond the annotations: changes take effect immediately without a deploy, and the data survives deploys, rollbacks and merges. It also clarifies that the feature variant avoids mutating the real copy. It does not state what happens to an existing file at the same path (overwrite vs. version), which is the one gap relative to destructiveHint=true.

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?

Front-loaded with the core action in the opening clause, and the remaining sentences each carry routing or behavioral information. The prose is dense and dash-heavy, slightly longer than needed, but no sentence is filler.

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, annotations covering safety flags, and full schema coverage for five parameters, the description supplies the missing pieces: persistence semantics, immediacy, and tool selection. Only overwrite behavior and any size limits are left unspecified.

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 coverage is 100%, so the baseline is 3. The description still adds semantic meaning the schema lacks: it explains the workspace-relative root and that the feature parameter redirects the write to an isolated copy, framing the parameter's intent rather than just restating it.

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?

States a concrete verb+resource ('Write a file to the lambda's workspace') and immediately scopes it to shared, deploy-independent data. It also names what it is NOT for (front-end pages/scripts/styles, database records), so an agent can separate it from write_code and database tools without opening schemas.

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?

Explicit when-to-use (runtime assets like images, and large non-program inputs such as models, datasets, media) and when-not (front-end code belongs in the version's resources via write_code; records belong in the database). The feature parameter's purpose is also explained as a scratch copy for experimentation.

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

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.

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.

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.

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.

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.

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.