Retrieve RunAPI pricing for Recraft models and endpoints, optionally specifying a model slug or action to compare costs before processing images.
Look up RunAPI pricing for the recraft 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: -[
- "recraft-remove-background",
- "recraft-crisp-upscale"
-]v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full behavioral burden and falls short: it doesn't state that this is a read-only, non-billing lookup, whether authentication or credits are required, or what the pricing response represents (units, currency, tiers). 'Look up' implies a safe read, but that is inference, not disclosure.
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 short sentence with the key information front-loaded and no filler. It is efficient, though so terse that the scope clause ('recraft model line') is the only detail it offers.
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 and no annotations, so the description must fill more gaps than it does: return value shape, whether the lookup is free/safe, and how the two optional parameters steer the result are all unaddressed. For a pricing-query tool with zero structured behavioral coverage, this is too thin.
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 parameters (model slug and action enum) are already documented with their defaults; baseline 3 applies. The description adds no parameter-level meaning beyond the schema and never mentions that the model defaults to the line's primary model or that action defaults to the endpoint offering the model.
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 ('look up RunAPI pricing') and scopes it to a model line, which is enough to distinguish it from operational siblings like remove_background, upscale_image, and get_task. However, 'for the recraft model line' sits awkwardly beside a schema that accepts an arbitrary model slug and an action enum, leaving the exact scope slightly ambiguous.
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?
No indication of when to call this versus the sibling tools. It never says whether this is a pre-flight cost check before invoking remove_background/upscale_image, or whether it is required before those calls, and no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.