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

Annotations only cover the safety profile (readOnly=false, openWorld=true, idempotent=false, destructive=false); the description goes well beyond that with upload-link lifetime (45 min), URL reachability (7 days, justified by Google's async fetch), file caps (10 files, 5 MB each, 250px min edge, JPG/PNG), and what the ticket read returns. No contradiction with the declared 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?

Front-loads the core purpose and the mode ordering, and each mode earns its place given the genuinely multi-path interface. It loses a point for redundancy ('a public image URL you can pass to any tool that needs one' appears twice) and for the length of the local-files preamble, which could be compressed.

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-required-param, four-mode tool with an output schema, the description supplies the prerequisites (shell access, user-attached files), the branching logic, the format/size constraints, and the lifetime semantics needed to invoke it correctly. Return values are covered by the output schema and the ticket-mode note.

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 0%, so the description carries the full burden; it does define the semantics of source_url, ticket, and image_base64, including the caveat that base64 will not fit camera-sized photos. The fourth parameter, filename, is never explained (only implicitly via the curl example), so coverage is strong but incomplete.

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 ('turns an image into a public image URL') and explicitly frames the output as an input to downstream tools, naming several siblings that consume it (gbp_create_post, gbp_upload_photo, upload_image_asset, upload_meta_image). An agent can tell this is the generic image-hosting utility, distinct from the platform-specific upload_* 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?

Gives an explicit, ordered decision procedure across four modes, including a stated preference ('Use this first whenever a URL exists') and when-not guidance ('only for a SMALL image already in the conversation... for anything camera-sized use mode 1 or 2'). Alternatives and the conditions that select each are spelled out rather than inferred.

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