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

Beyond the annotations (which flag non-read-only, open-world, non-idempotent), the description adds meaningful behavioral context: it performs a remote download, rejects private-network URLs, and rejects embedded credentials in URLs. Those are security/side-effect details an agent cannot get from the structured fields. It stops short of describing rate limits, failure modes, or what happens to the fetched media afterward.

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 operational flow first, the URL restrictions second. No filler. The slightly muddled 'MP4 or supported media URL' phrasing costs a point but the structure is well front-loaded.

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?

An output schema exists, so return values need not be explained, and the safety profile is carried by annotations. Still, for a 9-parameter conversion tool with zero schema descriptions, the omission of the sizing, quality, and metadata-stripping parameters leaves real gaps for an agent trying to configure a conversion 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 0% across 9 parameters, so the description must carry the load. It explains only source_url (public accessibility, no credentials, no private networks), converter (slug), and wait_for_completion (optional). Six parameters — width, height, quality, strip_metadata, timeout_seconds, background_color — get no mention at all, leaving their purpose and interaction (e.g., how width/height/background_color relate to resizing vs. video) undocumented.

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 concrete verb chain (download a media URL, submit to MP4.now with a converter slug) and the resource being converted, which is more than the tool name alone conveys. It implicitly separates itself from get_conversion_status by offering an inline wait option. However, the name says 'image' while the title and description say 'MP4 video', which creates ambiguity about what media types are actually accepted.

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?

"Optionally wait for the result" implies the alternative path (fire-and-poll via get_conversion_status), and "using a converter slug" hints that list_converters is a prerequisite, but neither sibling is named. An agent must infer both the slug-discovery step and the polling fallback rather than being told explicitly.

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