agent-cloud-tools

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

Annotations already declare the full safety profile (destructiveHint=true, idempotentHint=true, openWorldHint=true), so the bar is lower. The description confirms removal and adds the deploy_site -> manage_key dependency chain, but says nothing about reversibility, cleanup of associated resources, or auth requirements beyond the key.

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 short sentences, zero padding, and the action is front-loaded with the required inputs following immediately. Every 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?

For a two-parameter destructive tool with no output schema, the description plus annotations cover what an agent needs to invoke it correctly, including the upstream dependency. It stops short of stating irreversibility or what happens after removal, which would be the last missing piece.

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 both parameters are fully documented in the schema itself; the description's 'site url/host/slug' merely restates that. The only added meaning is the provenance of manage_key, which the schema already notes as 'returned when the site was deployed'. Baseline 3 is 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?

States a specific verb and resource ('Remove a site you deployed') tied to the tool's actual effect, which is clear and non-tautological. It is distinguishable from the deploy_site sibling by being its inverse, though it never names an alternative to disambiguate 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?

It supplies a real prerequisite - the manage_key 'returned by deploy_site' - which tells the agent the tool must come after a deployment. However, there is no when-not-to-use guidance, no note that this is irreversible, and no mention of alternatives such as leaving a site up.

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 only cover the generic safety profile (readOnly=false, openWorld=true, idempotent=false, destructive=false). The description adds substantive behavior: no signup/account required, a live URL and manage_key are returned, server-side code is never executed, sites auto-expire after 30 days, and limits of 50 MB / 300 files apply.

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 dense paragraph is front-loaded with purpose, then return value, then the critical relative-path warning. It is long but nearly every sentence carries a constraint an agent needs; the emphasis on RELATIVE paths is well placed.

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?

Even without an output schema, the description explains exactly what comes back (https URL plus manage_key) and covers the destructive/mutating aspects, expiry, and hosting limits. 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 parameter baseline is 3, but the description adds real constraints beyond the schema: index.html must exist at the root, the relative-path rule for assets, file-count/size caps, and the requirement that manage_key be paired with the same slug to update in place.

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 ('put a static website ... onto the public web') along with scope (static files only, no account/config). It is clearly distinguishable from sibling tools like delete_site and list_sites, which manage rather than publish.

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 triggering contexts ('Ideal when a person asks you to build them a website, landing page, demo, prototype or report and wants to see it live') and signals the update path via manage_key plus the same slug. An agent knows both when to reach for it and how to re-use it instead of redeploying.

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 (readOnlyHint=true, openWorldHint=true). The description adds the returned field set, which is useful context, but says nothing about failure behavior when a site is not found or access scope. With annotations doing the heavy lifting, a 3 is appropriate.

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: the return fields first, the input hint second. No filler, every clause 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?

Complete for a one-parameter read tool with annotations covering safety and no output schema needed beyond the listed fields. Only a not-found or access-scope note 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% and the single parameter already documents url, path, and bare-name forms. The description reinforces the three accepted input forms ('url, host or slug'), adding a mildly useful restatement, so slightly above the baseline 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 (return) and resource (a deployed site), and enumerates the returned fields (status, address, size, expiry), distinguishing it from siblings like deploy_site and delete_site which perform separate operations.

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 by the resource (you look up a site you deployed), but there is no explicit when-to-use versus alternatives and no exclusions. Siblings make the routing unambiguous enough that implied usage is adequate.

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=true and openWorldHint=true, covering the safety profile. The description adds useful behavioral context beyond annotations: it distinguishes capability urls (no password) from share urls (password required), which is an authentication detail. It does not cover error cases or return format, but with annotations the bar is lower.

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 front-loaded with the core action and resource before moving to usage guidance. The final sentence listing aliases adds some length but likely helps agents recognize the tool under alternative names. Overall it is efficient, though the parenthetical slightly interrupts the first 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?

Given the annotations (readOnly, openWorld) and the fully documented schema, the description covers what the tool does, when to use it, and the key authentication distinction. It does not explicitly describe the return format, but the schema's 'max_inline_bytes' field implies inline text content, and no output schema exists, so the description is largely complete 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?

Schema coverage is 100%, so the baseline is 3. The description still adds value by clarifying that the token can be either a capability url or a share url plus password, explaining the relationship between 'url_or_token' and 'password' that the schema only partially captures. The 'max_inline_bytes' parameter is not elaborated, but the schema documents it fully.

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 ('Fetch back') and resources ('durable memory', 'shared file/text') and names the source format (83blue url or token). It distinguishes itself from the storage sibling 'remember' and from generic fetch tools by tying recall to previously stored memory. An agent can identify the tool's function 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 provides clear usage contexts: recalling memory stored with 'remember' in an earlier session, or downloading a file another agent shared. It does not explicitly state when not to use the tool or name alternative tools like 'receive_file' or 'share_file', so it falls short of a full 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?

With readOnlyHint and openWorldHint already covering safety and network scope, the description adds substantial behavioral detail beyond those annotations: it explains the return shape (sha256 metadata, zip file list, inline text within max_inline_bytes) and the fallback behavior (a ready-made curl command when content is not inlined). This is especially valuable because there is no output 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?

The description is three tightly written sentences, front-loaded with the usage trigger, then input forms, then return behavior. Every sentence contributes useful information without 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?

No output schema exists, so the description must carry the return-value burden, and it does: it names metadata, sha256, zip bundle listing, inline text behavior, and the curl-command fallback. Combined with the annotations and fully described schema, an agent has what it needs to invoke the 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 description coverage is 100%, so each parameter is already well documented. The description reinforces the capability URL vs. share URL plus password distinction and the effect of max_inline_bytes, but it does not add syntax or format meaning beyond what the schema already provides. 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?

The description states a specific verb and resource: receiving a file that another agent shared, keyed to 83blue links. It clearly distinguishes this from sibling tools like share_file, share_text, and share_conversation by focusing on retrieval from a capability or share URL.

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 trigger: 'Use this when you have been given an 83blue link and need the file.' It also clarifies the two input modes (capability URL alone vs. share URL plus password), but it does not explicitly name alternatives or when-not to use this tool.

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 only cover the safety profile (write, open-world, non-idempotent, non-destructive). The description adds real behavioral context: no signup/account/API key, a url is returned, and it is reachable later from another machine. It omits an important trait for an open-world shared store — whether anyone holding the url can read the content — 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 tight sentences, front-loaded with the core purpose and payoff. The alias list ('save_memory, store_memory, save_note, stash') is slightly bulky but plausibly aids tool-selection matching, so it does not warrant a penalty below 4.

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 usefully states the return value (a url) and the recall path. All four parameters are schema-documented, so nothing critical is missing, though privacy/visibility of stored content and overwrite behavior on a repeated filename are left unaddressed.

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 content, filename, password, and expires_days are already documented with defaults and bounds. The description adds no syntax, format, or trade-off detail beyond 'text or JSON' and the url retrieval path, 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 concrete verb (store) plus resource (notes, context, text, JSON) and the retrieval counterpart explicitly: 'recall it in a later session or from another machine by url.' Naming the recall sibling lets an agent separate this write-side tool from the read-side one without opening a 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 a clear triggering condition (durable cross-session memory, later session, different machine) and points to the alternative recall for fetching back. It stops short of naming when NOT to use it — e.g., versus share_text/share_file siblings for human-facing sharing — so the routing guidance is strong 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?

The description goes beyond annotations by explaining the internal packaging: HANDOFF.md at the root of a zip, inclusion of files, and a single handoff URL. It also describes what the receiving model experiences (briefing, file manifest, download commands). Annotations already indicate external side effects, so the added specificity is useful.

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 one solid paragraph that is fairly detailed but front-loaded with the main purpose. Every sentence contributes to explaining the mechanism and how to use the URL, though it could be trimmed slightly without loss.

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 fully explains the result: a handoff URL that the next agent fetches to receive briefing and download commands. It also covers the key parameters (files, transcript) in context, creating a complete mental model for the 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?

The input schema provides 100% coverage with detailed descriptions for all parameters. The tool description mostly restates that the transcript becomes HANDOFF.md and files are included, which the schema already says. It doesn't add substantial new parameter-level meaning.

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 specific purpose: to hand a full working context to another model, packaging a transcript and files into a zip and returning a handoff URL. It explicitly mentions the key elements (instructions, conversation summary, task state) and distinguishes itself from sibling tools that share files or text.

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 clear context for when to use the tool ('to hand your full working context to another AI') and details the handoff flow, but it doesn't explicitly mention alternatives or when NOT to use it. Since siblings are share_file/share_text, the usage context is reasonably clear.

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 mark it as non-read-only and non-idempotent, so the description's job is lighter. It adds meaningful behavioral context: multiple files are zipped server-side into one bundle, both text and base64 are accepted, and the result travels as a single capability URL. It does not discuss authentication or expiration behavior, but those are partially covered 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 tight sentences front-load the trigger condition, then cover the two behavioral essentials (encoding support and zip behavior) and the most important alternative. The docs link is inline and unobtrusive; no word 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 file-sharing tool with four well-documented parameters and annotations, the description plus schema covers trigger, payload encoding, bundle behavior, output as a capability URL, and the large-file alternative. No output schema exists, so the explicit mention of the URL result is valuable and sufficient.

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 75%, so the baseline is 3. The description adds value by clarifying the intended use of content_text versus content_base64 and explaining why bundle_name matters (multi-file zipping into one handoff). It does not deeply explain password or expires_days, but the schema already does that.

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 (share), a concrete resource (one or more files), and the target audience (another agent or person). It naturally separates from siblings like share_text and share_conversation by focusing on file bundles rather than text snippets or conversation histories.

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 opens with 'Use this when another AI agent... or a person needs access to one or more files' and then names the preferred alternative for large local files (HTTP API with link). This gives the agent a clear selection rule and an exclusion condition.

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?

With annotations already indicating non-read-only behavior, the description adds valuable context: 'Uploads it as a downloadable file and returns a capability url (one GET fetches it) plus a share url and password. No account or API key needed.' This clarifies the operational behavior and authentication requirements beyond what annotations convey. It does not contradict any 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 exceptionally concise and well-structured: two sentences that front-load the use case and then describe the mechanism and return values. Every word contributes value, with no redundancy or unnecessary detail.

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 (4 parameters, no output schema), the description adequately explains the return values (capability URL, share URL, password) and the core behavior. It doesn't explicitly mention expiration, but that is covered in the schema's parameter description for expires_days. Overall, it provides enough context for an agent to invoke the 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?

The input schema has 100% coverage for all four parameters, providing full descriptions for content, filename, password, and expires_days. The description does not add additional parameter-specific details beyond the schema, so the baseline score of 3 is 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 clearly states the tool's function: sharing text content with another agent or person by uploading it and returning a capability URL, share URL, and password. It uses specific verbs ('Uploads', 'returns') and distinguishes from siblings like share_file and share_conversation by focusing on text content you already have.

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 states when to use the tool ('when another AI agent, chat session or person needs text you have'), providing clear context. It also notes 'No account or API key needed,' which is a useful prerequisite. However, it does not explicitly mention alternatives or when not to use it, so it falls 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.