Just Publish

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

Annotations set destructiveHint=false and readOnlyHint=false. The description adds critical behavioral context: 'deploy REPLACES the whole site — any file you leave out is DELETED.' It also explains the edit_token's role as the only way to update later. This goes beyond the annotations to inform the agent about the tool's behavior, though the annotations already provide a basic safety profile.

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 well-structured: purpose first, then usage scenarios, then detailed instructions for first/later calls, a warning about replacement, and finally alternatives. Each sentence adds value without redundancy. It is front-loaded with the primary action.

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 return values (url, site_id, edit_token) and notes the requirement for index.html. It also explains the replacement behavior. However, it could briefly mention what happens to the site during update (e.g., immediate effect) or error cases, but given the presence of an output schema, it 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?

The input schema has 100% description coverage. The description adds meaningful context beyond the schema: first call omit site_id and edit_token, later calls require them; keep edit_token for future changes. This helps the agent understand the lifecycle of parameters.

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 clearly states the tool's purpose: 'Put a website live at a public URL.' It specifies the verb 'put live', resource 'website', and provides concrete examples of user intents like 'I need a website'. It also distinguishes from siblings by mentioning get_site_files and update_site_file for viewing and partial updates.

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 explicitly says when to use the tool (publishing, launching) and when not to (for changing a few files, use update_site_file; to see current live content, use get_site_files). It also explains the first call vs later call pattern, providing clear context for the agent.

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 readOnlyHint and destructiveHint annotations, the description reveals that the tool returns a complete manifest (every file's path, size, content-type, sha256) plus contents of text files. It also notes the site's current 'version' and its role in preventing overwrites. This adds significant 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?

The description is succinct at five sentences, each serving a distinct purpose: stating the tool's utility, describing the return values, introducing the version field, explaining the paths parameter, and listing required inputs. No wasted words.

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 tool's moderate complexity (3 parameters, optional paths, output schema present), the description completely covers the purpose, usage, return values, and safety mechanism (version). It provides all necessary context for correct invocation.

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 input schema has 100% description coverage, so each parameter is already documented. The description adds value by clarifying that 'paths' is optional and that the manifest always lists all files regardless, and that 'site_id' and 'edit_token' are obtained at publish time. This supplements the schema well.

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 clearly states the tool reads files of a published site for targeted edits. It distinguishes itself from siblings 'deploy' (publishing) and 'update_site_file' (modifying a single file) by emphasizing the read-only nature and the scope of returning a complete manifest and text file contents.

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 explicitly says when to use: 'so you can make a targeted edit instead of rebuilding the whole site from memory.' It also explains how to use the optional 'paths' parameter and the 'version' field for safe updates, and lists required parameters: site_id + edit_token.

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 indicate readOnlyHint=false, destructiveHint=false, but the description adds critical behavioral details: merge semantics (not a replace), conflict detection via expected_version, the requirement for edit_token, and explicit limitations (cannot delete files, cannot remove index.html). No contradictions with 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 description is concise, front-loaded with the core action, and each sentence adds unique value (usage, best practice, limitations). No fluff or repetition.

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 tool's moderate complexity, the description covers all essential aspects: purpose, best practice, prerequisites, limitations, and conflict handling. An output schema exists, so return values need not be described. The description is fully self-contained.

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?

With 100% schema description coverage, the baseline is 3. The description adds value beyond the schema by explaining the purpose of expected_version (conflict protection) and reinforcing the merge behavior of files. This elevates it to a 4.

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 clearly states it changes one or a few files of a published site without touching others, contrasting with deploy which replaces the whole site. The verb 'change' and specific resource 'files of an already-published site' are precise, and the distinction from sibling tools is 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?

The description explicitly advises when to use (small edits) and when not (cannot delete files). It provides best practice: call get_site_files first and use expected_version for conflict detection. Alternatives are named (deploy for deletion, get_site_files for reading).

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