Look up RunAPI pricing for Midjourney image and video models or specific endpoints before generating content. Helps agents estimate costs and choose the right model or action.
Look up RunAPI pricing for the midjourney 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.4.0Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / model / enumRemoved value: -[
- "midjourney-edit-image",
- "midjourney-image-to-video",
- "midjourney-v8.1"
-]v0.3.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, yet it says nothing about whether this is a safe read-only call, whether it hits a live API or cached data, or what the response contains. Since no output schema exists either, the description should have filled this gap and does not.
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 wasted words, appropriate for a simple lookup tool. It is efficient, though its brevity is partly the source of the missing behavioral and usage detail.
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 is the only place an agent could learn what pricing information comes back (per-call cost, credits, currency, model/action granularity), and it omits all of that. It also fails to disambiguate the midjourney-plus-video-action scope mismatch against the video siblings.
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 and action) are already documented in the schema, establishing a baseline of 3. The description adds only the 'midjourney model line' scope hint, which loosely connects to the model parameter but provides no syntax or default-behavior detail beyond 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?
States a specific verb and resource ("look up RunAPI pricing") and scopes it to the midjourney model line, which distinguishes it from the sibling action endpoints like edit_image and get_seed. It is clear what the tool does, though it does not explicitly name which sibling it substitutes for.
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 or when-not-to-use guidance; it never says when an agent should call this versus executing one of the sibling action endpoints. Only the implied 'need a price, look it up' reading provides any direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.