Look up RunAPI pricing for Runway model lines by model slug and endpoint action, so you can compare text-to-video or video extension costs before creating tasks.
Look up RunAPI pricing for the runway model line.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model slug. Defaults to the line's primary model. | |
| action | No | Endpoint name. Defaults to the endpoint that offers the model. |
Changes observed during successful MCP inspections.
v0.2.0Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / model / enumRemoved value: -[
- "runway"
-]v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Look up' implies a read-only operation, but the description says nothing about whether pricing is live or cached, whether auth is required, or what the response contains. For a zero-annotation tool this is a substantial 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?
A single, front-loaded sentence with no filler. The verb and resource lead immediately, and nothing 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?
With no annotations and no output schema, the description is the only place behavioral and return-value context could live, and it is thin. The parameters are covered by the schema, but an agent gets no sense of what pricing data comes back or under what constraints the lookup succeeds.
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 the 'model' and 'action' parameters are already fully documented in the schema, including their default behavior. The description's mention of the 'runway model line' loosely maps to the model parameter but adds no syntax, format, or enum detail beyond the schema. 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 ('look up') and resource ('RunAPI pricing') scoped to the 'runway model line'. This clearly distinguishes it from siblings (extend_video, text_to_video, get_task, login), none of which relate to pricing, though 'runway model line' is slightly ambiguous without further definition.
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 no when-to-use guidance, no mention of prerequisites (e.g., authentication), and no conditions that would steer an agent toward or away from this tool. It simply states what the tool is.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.