Rast Creator Tools

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

Annotations already cover the read-only, idempotent, closed-world safety profile, and the description goes well beyond them: the 2% safety margin on target-size calculations, the specific reference sources (YouTube/Vimeo recs, Apple ProRes data rates, Rast for Instagram/TikTok), and the extra outputs (size-limit warnings for Meta 4 GB and TikTok 500 MB/516 kbps, plus an ffmpeg two-pass command).

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 sentences, front-loaded with the primary calculation and immediately followed by the inverse mode. Dense but every clause carries information the agent needs; 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 no output schema, the description carries the return-value burden and does so: numeric result, size-limit warnings, and an ffmpeg command are all disclosed. For a 7-parameter calculation tool with full schema coverage, nothing needed 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 3 baseline is met by the schema alone. The description adds genuine value by explaining where the default bitrate comes from per platform/resolution/frame rate and by making the mutual exclusivity of target_size_mb and video_bitrate_mbps operationally clear, which the schema only implies.

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 and covers both directions of the calculation: file size from duration+bitrate, or max bitrate from target_size_mb. It also names the fallback source of the bitrate (platform/resolution/fps reference tables), so the agent knows exactly what the tool produces and what it derives it from.

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 explains the mode switch: pass target_size_mb for the inverse calculation, omit video_bitrate_mbps to use the reference value. Sibling tools (check_text_position, validate_srt, etc.) are unrelated, so no alternative routing is required, but no explicit when-not guidance is given.

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 closed-world, so the safety profile is covered. The description adds real value beyond that by disclosing output behavior: which overlapping UI element is reported and that a nearest-clearing position is suggested. It stops short of stating what is returned when there is no overlap.

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 sentences, front-loaded with the core check, followed by the reported outcome and the coordinate convention. Every sentence carries information an agent needs and there is 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 no output schema, the description does the work of explaining the two return components and the 'all' platform option is spelled out in the schema. Only the no-overlap case and the boundary of the comment-sticker option (already in schema) are unaddressed, which is minor for a read-only validation 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 all eight parameters including the platform enum and the comment-sticker band are already documented. The description only restates the pixel/top-left coordinate convention and clarifies that the box represents a caption, title or logo — marginal added meaning, 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 specific verb and resource ('Checks whether a rectangular text box ... stays inside the safe zone'), names the four platforms, and describes the two-part outcome (overlap report + suggested position). An agent can distinguish this from get_safe_zone, which by name returns zone geometry rather than validating a specific box.

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 description (validate a caption/title/logo rectangle before export), but there is no explicit when-to-use or when-not-to-use guidance and no reference to get_safe_zone or export_settings as alternatives. Nothing is misleading, but the routing decision 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 already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety needs no restating. The description adds genuinely non-structured information about the payload — container, codec, resolution, frame rate, bitrate, colour, audio, official spec links, and an editor-agnostic step list — which matters 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?

A single sentence, but front-loaded with purpose and then layered with audience and payload detail; nothing is padding. Slight density cost from the long cumulative list of returned fields, though each item earns its place given no output schema.

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 spends its budget enumerating what comes back and covers every platform option. The only shortfall is silent handling of resolution/orientation defaults and whether the step list is editor-specific, which the schema partially implies.

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% with enums on all three parameters, so the schema already defines platform, resolution and orientation fully. The description mentions SDR vs HDR (mapping to the youtube/youtube_hdr split) but says nothing about orientation or default values, so it adds little beyond the schema baseline.

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?

Opens with a specific verb and resource ("Returns recommended export settings") and narrows the domain to platform upload targets plus a ProRes archive master. The enumerated outputs and platform list make it unmistakable versus siblings like calculate_bitrate or get_safe_zone, which address adjacent but different concerns.

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 trigger conditions are clear and concrete: uploading a finished video to YouTube (SDR or HDR), Vimeo, Instagram Reels or TikTok, or mastering a ProRes archive. It never names a sibling alternative or an explicit when-not case, so an agent must infer that bitrate math belongs to calculate_bitrate rather than 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 already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavior: values are measured on a 1080x1920 reference and scaled to the requested frame size, which tells an agent results are approximate and scale-dependent rather than exact device measurements.

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?

One dense but well-ordered sentence with the primary output (unsafe margins) leading and secondary details trailing. No filler, though the colon-separated list makes it heavier than it needs to be for a single-sentence description.

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?

There is no output schema, so the description carries the return shape, and it does so by naming each returned field. Combined with annotations covering safety and a fully documented three-parameter schema, this is close to complete; only the units/precision caveats beyond "approximate" and the distinction between 'all' and per-platform calls are left implicit.

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 meaning for width/height by explaining the 1080x1920 measurement basis and scaling relationship. Platform enumeration is repeated from the schema rather than extended.

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?

Opens with a specific verb and resource ("Returns the approximate areas of a vertical (9:16) video frame that the app interface covers") and names the exact platforms supported. The output contents (margins in px/percent, safe rectangle, button column position, guidance) are enumerated, so an agent can tell this apart from siblings like check_text_position without inspecting 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 intended use — knowing where UI overlays occlude a vertical frame — is implied but never stated as guidance ("use this when..."). No alternative is named; in particular the relationship to check_text_position, which presumably consumes these zones, is not explained.

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, closed-world, so the safety profile is covered. The description adds genuine beyond-schema context: 'The text is only processed for this response' (statelessness/privacy) and that the corrected SRT is optional and what it fixes (encoding, overlaps trimmed, long lines split, short subtitles extended). It omits the 200k character input ceiling, which is a real practical constraint.

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 sentences, front-loaded with the verb and outcome, with the check list consolidated into one dense enumeration rather than scattered. The long middle sentence is list-heavy but every item is a distinct check the agent may need to interpret results against.

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?

There is no output schema, so the description must convey the return shape, and it does at a high level ('lists problems per subtitle', plus an optional corrected SRT). An agent knows what comes back and why, though the exact issue-object structure (field names, per-line references) is left unstated.

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 baseline is 3; the description earns an extra point by tying checks to parameters — 'gaps shorter than the minimum frame gap', 'reading speed (characters per second)', 'line length, line count' — and by explaining what include_fixed_srt actually returns. It does not mention fps or the preset rule sets, but the schema documents those thoroughly.

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 (checks/validates) and resource (pasted SRT or WebVTT subtitle text) and enumerates exactly what classes of problems it reports: timing overlaps, gaps, CPS, line length/count, duration, and encoding mojibake. The purpose is unmistakable and clearly distinct from the sibling tools (bitrate, safe zone, text position).

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 implies usage ('pasted SRT or WebVTT subtitle text') and notes the optional corrected-SRT output, so an agent can infer this is the validation entry point. But it never states when to prefer it over an alternative, nor any exclusion such as file-path input vs pasted text, or when to enable the preset/fps tuning.

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