SORNKan Publish

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

Annotations only cover the generic read/write/idempotency profile; the description goes well beyond them by disclosing the $1 USDC cost, the 402/payment_url card-PromptPay fallback in THB, the PRICE_COMPUTE_FAILED retry rule with 'no USDC taken', and the do-not-retry escalation path for failed settlements. These are exactly the non-obvious behavioral facts an agent needs before triggering a paid, non-idempotent operation.

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 and price, then ordered by decision point (precheck → human → payment → failure branches). It is dense and long, and a few clauses (pretty-name CNAME) sit mid-stream, but essentially every sentence carries operational information rather than 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 paid, mutating tool with no output schema and only one required parameter, the description covers the full lifecycle: preconditions, cost, success URL shape, payment alternatives for wallet-less agents, polling after payment, and the two distinct failure recoveries. Nothing an agent needs to call this correctly 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 semantics: it clarifies uploadId must be the UUID 'not previewUrl' and shows how to extract it from a full preview URL, and it warns the live URL is {slug}.worldsite.workers.dev rather than {slug}.workers.dev. Some of this overlaps the schema text, which keeps it from a 5.

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 (claim/activate) plus resource (inspected preview → live site), and immediately pins the resulting artifact: {slug}.worldsite.workers.dev. It also explicitly differentiates from the sibling publish_website, which 'only returns the plan and never goes live by itself.'

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 prerequisite chain (inspect → preview_status → claim), an exclusion rule ('if claimable is false, do not pay'), a human-confirmation step ('ask which slug they want before paying'), and names the fallback siblings to poll (preview_status/retry). Nothing about when to invoke this vs. neighbors is left to inference.

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 (write, open-world, not idempotent, non-destructive). The description adds substantial behavior: a one-time $1 USDC charge, credit retention if the bind is refused after card payment, the raw HTTP POST retry path with X-Edit-Token, Cloudflare proxying advice, and post-payment polling. None of this is inferable from structured fields.

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-loads the core action and then layers payment, retry, and fallback details efficiently in a few dense sentences. The inline HTTP POST fallback is arguably operational detail rather than tool-invocation guidance, but almost every clause carries needed context.

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 still tells the agent what happens after invocation: poll preview_status/retry until the hostname is live, and how to recover from a refused bind. Payment paths (crypto wallet vs. card/PromptPay) and the credit fallback are all covered, so an agent can complete the workflow.

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 slug, hostname, and editToken are already documented in the schema. The description reinforces when editToken matters (card-paid sites) and the CNAME target, but adds little semantic detail 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: connect an existing hostname via CNAME to sites.sornkan.com. It explicitly scopes itself ('no registrar') and is clearly distinguishable from siblings like claim, renew, and edit.

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 clear when-to-use context: requires a live lease, the same claiming wallet or an editToken for card-paid sites, and routes wallet-less users to the 402 payment_url plus preview_status polling. It names a sibling (preview_status) but never states explicit exclusions versus other hostname-related 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?

Annotations only cover the safety profile (non-read-only, non-idempotent, open-world, not destructive), so the description carries real weight: it discloses flat $0.50 pricing across both rails, wallet-to-site ownership binding, the one-time editToken requirement, and that the edit does not extend the lease. It stops short of describing the failure modes beyond the 402 flow.

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 action, then pricing, then ownership rules, then the no-wallet fallback — a sensible order. It is dense and packed into a single paragraph with several parentheticals, which slightly hurts scannability.

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 still tells the agent what to expect back (a 402 with payment_url) and how to confirm completion (poll preview_status/retry until live). Payment, ownership, and completion signals are all covered, so nothing needed to call this correctly 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 per-parameter descriptions already define slug, uploadId, editToken, and tokens. The description adds genuine conditional meaning on top, clarifying when editToken is required (card/PromptPay sites) and confirming tokens is informational only.

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: scan the uploaded zip, then redeploy the live Worker for a slug. It also implicitly separates itself from siblings by noting it 'does not extend lease days' (vs. renew) and by pointing at upload_url/preview_status as adjacent steps.

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 selection conditions: wallet-claimed sites must pay from the same wallet, card/PromptPay sites need an editToken, and agents with no wallet should surface the 402 payment_url to a human and then poll preview_status/retry. Both the happy path and the fallback path are spelled out.

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 declare the generic safety profile; the description adds substantial behavior: quota semantics (first 3/day free, then $0.10), the two payment paths (x402 retry with USDC on Base, or hand the 402's payment_url to the human), and the edge case for claimable=false (re-upload, do not pay for the old id). This is far beyond what readOnlyHint/destructiveHint convey.

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 first sentence, and the dense billing/retry detail is all actionable rather than filler. It runs long, and the pricing/retry mechanics could be tightened, 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 side-effecting, quota-metered deploy tool with no output schema, the description covers the risk surface an agent needs: cost, quota reset, the 402 retry path, and the claimable=false fallback. Only the exact success/failure response shape is unstated, which is a minor gap.

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 there is only one parameter, so the schema already documents uploadId fully. The description reinforces the source ('from upload_url') but adds no syntax or format detail beyond the schema, so the 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 ('Deploys a throwaway preview Worker at preview-*.worldsite.workers.dev') and explicitly frames it as the DEPLOY step, distinguishing it from scan (free, nothing deployed) and preview_status. An agent can tell exactly what this does and how it differs from every nearby sibling despite the misleading 'inspect' name.

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 when-to-use ('call inspect only when the human wants to see a preview'), when-not-to-use ('Do NOT inspect again just to read remaining time — use preview_status'), and names the alternative for iteration (scan, free, nothing deployed). The post-approval workflow (ask slug, then claim with UUID and slug) is also spelled out.

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 the description adds genuinely non-inferable behavior: it does not scan, does not reset the preview clock, never returns 402 (i.e. triggers no payment), and claimable=false means the preview was deleted and the id is dead. That is real disclosure beyond the annotation block.

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, then constraints, then the failure recovery path, then the alternative. Every sentence carries a distinct operator decision; nothing is filler, and the terse style ('never 402') is efficient for an agent audience.

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 must carry return semantics, and it does partly by naming the claimable flag and framing the result as remaining time. It does not describe the shape/units of that remaining time, which is a minor residual gap for a read 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 coverage is 100% for the single uploadId parameter, and its schema description already covers the 'part after /preview/' URL case. The description's 'uploadId is the UUID (a preview URL is OK)' largely restates that, so baseline 3 applies with no compensating added 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?

States a specific verb and resource — 'Read remaining preview time' — and immediately distinguishes itself from siblings by negation ('Does not scan, does not reset the clock') and by substitution ('Use this instead of inspect when you only need the clock'). An agent can route between preview_status, inspect, and scan 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 explicit use-cases and exclusions, plus a full recovery procedure for the deleted-preview case naming the sibling tools in order (upload_url → PUT zip → inspect → claim) and two hard prohibitions ('Do not inspect or claim the old id', 'Do not pay'). This is a rare case of complete routing guidance.

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/idempotent/destructive=false, and the description reinforces that ('never uploads, deploys, or goes live') without contradicting it. Beyond that it discloses pricing ($1 USDC, first 30 days), the legal check, and failure semantics: PRICE_COMPUTE_FAILED means retry with no charge, whereas a failed signed settlement requires contacting support and no retry. That is substantial behavioural context 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?

Front-loaded with 'START HERE' and the read-only caveat, and nearly every clause is an actionable instruction. However, the arrow-chained workflow is dense and mixes procedural steps with edge-case error handling and URL-format trivia, which makes it harder to scan than a cleanly segmented list.

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 input params and no output schema, the description must carry the full burden, and it does: entry condition, human-approval gate, sequence of sibling calls, slug/claim handling, URL format, and two distinct failure modes. An agent has everything needed to act 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 tool takes zero parameters, so there is nothing to disambiguate; baseline is 4. The description does not need to add parameter meaning, and it correctly stays focused on workflow rather than arguments.

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 deliverable — a step-by-step publishing plan — and explicitly negates what it is not ('never uploads, deploys, or goes live by itself'), which cleanly separates it from siblings like upload_url, scan, inspect, and claim. An agent can tell this is the read-only entry point 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?

Explicitly says 'START HERE' and lays out the full ordered workflow (upload_url → PUT putUrl → inspect → previewUrl → preview_status → claim), names when to use an alternative ('preview_status to read remaining time, never inspect again just for the clock'), and mandates asking the human first. This is textbook when/when-not/alternatives guidance.

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 the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description nonetheless adds genuinely non-obvious behavior: per-call cost, that payment requires an x402 wallet with no signup/API key, and that the output is markdown plus a screenshot URL and a human-checkable evidence page. It omits runtime traits like timeouts or JS-heavy page failure modes.

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 compact sentences, front-loaded with the core capability and followed by returns, price, and payment mode. Every sentence carries information, though the pricing is stated twice (once as '$0.005 per call' and again as 'same price' for fullPage) which is mildly redundant given the schema repeats it too.

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 enumerates the return artifacts (markdown, screenshot URL, evidence page URL) and covers the auth/payment path, which is the main thing an agent needs to call successfully. Missing only edge-case behavior such as blocked URLs, timeouts, or per-domain limits for a low-parameter 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 both url and fullPage are already documented, making 3 the baseline. The description adds only the marginal note that fullPage captures the entire scrollable page at the same price, which duplicates the schema's own 'Capture entire scrollable page (same $0.005)' 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?

States a specific verb and resource ('Render any public URL in a real browser (Chromium)') and even names the exact deliverables (markdown text, screenshot URL, evidence page URL). It is far from a tautology, but it never distinguishes itself from ambiguous siblings like scan, inspect, or preview_status, which an agent would plausibly confuse with page rendering.

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 front-loads practical constraints ('$0.005 per call', 'No signup, no API key', 'x402 wallet required'), which tells the agent whether it can call the tool at all. However, it gives no when-to-use / when-not-to-use guidance and never routes the agent to or away from the sibling tools (scan, inspect, preview_status).

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 non-read-only, non-idempotent and open-world, and the description adds real context beyond them: the $1 USDC cost, the wallet requirement and editToken fallback, the 90-day stacking cap, the consequence of lapse (site deleted, slug freed), and a card/PromptPay fallback via the 402 payment_url with a poll-preview_status recovery loop. It is consistent with, not contradictory to, the annotations (each call adds 30 days, so non-idempotent fits).

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, price and credential are front-loaded in the first clause, and every following sentence adds a distinct rule (eligibility window, expiry consequence, payment fallback). It is dense and slightly long, with the support email and payment walkthrough adding some bulk, but nothing is truly 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 paid mutation tool with no output schema and no local-state annotations, this covers cost, credentials, eligibility, lapse consequences and the non-crypto payment path with recovery polling. The only remaining gap is what a successful renewal returns or how the added days are confirmed.

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 slug and editToken are already documented in the schema, and the description largely restates them ('Same claiming wallet (or editToken for a card-paid site)'). The baseline of 3 applies because the schema carries the parameter semantics.

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 first sentence states a specific verb and resource with the exact effect and price: 'Renew hosting +30 days for $1 USDC'. It also names the credential options (same claiming wallet or editToken), which clearly separates it from the sibling claim tool that creates a site.

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 preconditions are given ('only while the site is live and remaining < 90 days, stacked cap 90') and an explicit exclusion with the alternative named ('after expiry renew is unavailable — claim again as a new site'). An agent knows exactly when to call this versus claim.

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), and the description adds genuinely new operational context: free, never 402, no preview quota consumed, and that the verdict is advisory because inspect re-checks. It does not describe the failure shape (what a dirty zip returns), which is the main remaining gap.

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, front-loaded with purpose before the quota/alternative rationale. Every clause carries actionable information (cost behavior, workflow loop, sibling routing, advisory semantics) with 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?

With one simple parameter, full schema coverage, and no output schema, the description supplies what the structured fields cannot: cost/quota behavior, the advisory nature of the verdict, and how it composes with inspect and upload_url. Nothing needed to call this correctly 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% and there is a single required parameter, so the schema already explains uploadId fully. The description reinforces the provenance ('the uploaded zip', 'upload_url again') but adds no syntax or format detail, 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 and resource ('Check an uploaded zip for unsafe files') and immediately bounds the scope with 'WITHOUT deploying anything'. This clearly separates it from inspect, which deploys a preview Worker, so an agent can discriminate among siblings 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?

Explicitly prescribes the iteration loop (scan → fix → upload_url again → scan) and names the alternative ('call inspect to deploy a throwaway preview Worker') with the condition that selects it ('when the content is clean and the human wants to SEE it'). It also frames the verdict's role in that workflow.

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=false, destructiveHint=false, idempotentHint=false and openWorldHint=false. The description adds a concrete behavioral constraint beyond those — a 3MB size cap and a 'do not put zip in chat' policy — which is genuine extra value, but it never discloses what the tool returns or how putUrl/dropUrl come into existence.

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 with no filler, but they are front-loaded with instructions rather than the tool's function, and the undeclared putUrl/dropUrl identifiers make the opening sentence hard to parse without prior context.

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 must explain the return contract, and it only obliquely hints at putUrl/dropUrl without saying the tool produces them. An agent cannot tell from the definition what it will receive back or why it should call this tool at all.

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, so per the baseline the schema carries no burden and a 4 applies. The description references putUrl and dropUrl, which are outputs rather than inputs, so it does not clarify parameters — but there are none to clarify.

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 name says upload_url and the text talks about PUT-ing to a putUrl and sending a dropUrl to a human, but it never states what the tool itself does (e.g. 'generate pre-signed upload/download URLs'). It reads as downstream instructions rather than a statement of purpose, and no sibling (claim, publish_website, render_page, etc.) is distinguished.

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 does give conditional routing advice: 'If you have the zip, PUT putUrl yourself' versus 'Only send dropUrl to the human if you have no file.' That is useful flow guidance, but it addresses what to do with the results, not when to call this tool versus its siblings.

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