Razi Media Tools

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses lossy behavior below quality 1.0, HEIC/SVG conversion, the 5MB threshold that changes the return shape (bytes vs JSON), the rate limit of 30 calls/hour/IP, and the rejection of third-party URLs.

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 core purpose is front-loaded in the first sentence, and every subsequent sentence adds a distinct operational constraint: input format handling, quality semantics, size-based output switching, rate limits, and upload workflow. The description is dense but each 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?

The description compensates well for the missing output schema by spelling out both possible return shapes, plus input restrictions and rate limits. However, it instructs the agent to 'pass `fileUrl`' while the input schema has no such property, leaving the central invocation mechanism unresolved.

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 the baseline of 3 applies. The description adds useful nuance (e.g., 'Lossy for webp, jpeg and avif at any quality below 1.0'), but most parameter meaning already comes from 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?

The opening sentence states a specific verb and resource: 'Re-encode a single raster image to webp, jpeg, png or avif, optionally resizing it and/or converting it to grayscale.' This clearly distinguishes compress_image from the sibling generation and QR-code tools, and the scope is unambiguous.

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?

Provides clear context for when to use the tool: 'Raster images only' with PDF/video explicitly rejected, and a mandatory prerequisite of passing a razi.pro-hosted fileUrl obtained via REST. It does not explicitly name alternatives, but the exclusionary guidance is strong enough for an agent to route correctly.

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 zero annotations provided, the description carries the full burden of disclosure and does so exceptionally well. It reveals the return format (PNG inline under 1MB, otherwise a 24-hour stored URL), auth requirement (signed-in account, 401 for anonymous), rate limit (20 images/hour), latency (tens of seconds), provider fallback chain, non-determinism, absence of seed/size control, and lack of permanent hosting. This is rich behavior context beyond any structured field.

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 long but every sentence earns its place given there are no annotations and no output schema to lean on. It is front-loaded with the core purpose, followed by return format, exclusions, alternatives, auth, rate limits, latency, and provider behavior. Minor redundancy exists between 'no two calls give identical output' and 'not automatically hosted anywhere permanent,' but both convey distinct 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 tool with no annotations and no output schema, the description is nearly complete: purpose, return format, retention, exclusions, alternative tool, auth requirements, rate limits, latency, provider variability, and determinism are all covered. Minor gaps include specific error responses beyond 401 and exact pricing for 'paid compute,' but these fall outside typical MCP description expectations.

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 the schema fully documents both prompt and negativePrompt, including the caveat that negativePrompt only works on the Replicate fallback. The description adds no parameter-specific semantics beyond reinforcing that provider variation exists, which the schema already notes. Baseline 3 is appropriate since 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 first sentence states a specific verb and resource: 'Generate a new image from a text description with a diffusion model.' It further distinguishes itself by explicitly stating what it cannot do ('cannot edit, upscale or restyle a picture you already have') and naming compress_image as the sibling for existing files, so an agent can tell it apart from all three siblings without opening their schemas.

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 guides routing: 'Use compress_image to re-encode or resize an existing file,' which covers the most likely confusion since both tools handle images. It gives clear when-not-to-use context ('invents an image from scratch'). However, it does not explicitly compare against generate_qr_code or split_image, leaving that differentiation to inference from tool names.

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 no annotations provided, the description carries the full burden and does so thoroughly. It discloses the exact return shape, that the image is a base64 data URI rather than a hosted link, that nothing is stored, that it runs locally and costs nothing, and that it cannot read or decode QR codes — all behavior beyond what a schema could 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?

Every sentence earns its place: purpose, return format, storage behavior, local execution, read/write limitation, and payload advice. The description is dense but structured, front-loading the core purpose and then layering important behavioral details without redundancy.

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?

Despite having no annotations and no output schema, the description fully compensates by specifying the response format, data URI behavior, side-effect-free execution, and the ignored errorCorrection parameter. An agent has enough context to invoke the tool correctly and interpret its result.

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 the baseline is 3. The input schema already documents text, size, and errorCorrection well. The description adds useful context about payload length affecting density, but does not significantly expand parameter semantics beyond what the schema already provides.

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 opens with a specific verb and resource: 'Render text or a URL as a QR code image.' This clearly identifies the tool's function and differentiates it from sibling image tools like compress_image, generate_image, and split_image, which operate on images rather than generating scannable QR codes.

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 not to use the tool: 'Writing only — it cannot read or decode an existing QR code.' It also gives practical guidance to shorten long payloads for better scannability, helping the agent decide whether to preprocess input before calling the 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?

With no annotations, the description carries the full behavioral disclosure burden and does so thoroughly: ZIP is not inlined, URL expires in ~24 hours, automatic mode is paid and variable, 400 on no detection, panels are cropped not resized, jpeg/webp use quality 90, 20 calls/hour/IP, third-party URLs rejected, and REST upload is required first.

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 dense and every sentence carries useful information, with the core purpose front-loaded. However, it is a long single paragraph that could be more scannable if modes, limitations, and rate limits were split into bullets, though the length is largely justified by the number of critical caveats.

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 no annotations and no output schema, the description is exceptionally complete: it covers return format, retention, failure behavior, cost, variability, rate limiting, input restrictions, and the upload flow. Almost nothing an agent needs to invoke the tool correctly is left to guesswork.

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 schema already documents all three parameters, and the description adds meaningful semantics: rows/cols only take effect together, omitting both enables automatic detection, and format defaults to lossless PNG with quality-90 lossy options. The description also mentions passing 'fileUrl' even though that parameter is absent from the schema, which is a minor inconsistency.

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 opening sentence states a specific verb and resource: cut a storyboard, collage, or grid image into separate panels and return them as a ZIP in reading order. It also explicitly distinguishes itself from compress_image by saying it does not shrink a file and cannot take a PDF apart.

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 explicit mode-selection guidance: provide both rows and cols for a deterministic free division, or omit both for vision-based detection with tradeoffs. It names compress_image as the alternative for shrinking files and states the paid-compute rate limit and upload prerequisite.

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