Skip to main content
Glama

Create the image

create_image
DestructiveIdempotent

Use this when the user accepted the price from quote_image: makes the image with Deepnia from that quote_id and credits, paid with the user's Deepnia credits and saved in their Deepnia account. Refunded if it fails; the same quote_id never charges twice. Then follow it with get_creation.

Input Schema

NameRequiredDescriptionDefault
creditsYesThe price in credits from quote_image, as shown to and accepted by the user.
quote_idYesThe quote_id returned by quote_image.

Output Schema

NameRequiredDescriptionDefault
idYes
noteYes
typeYes
stateYes
creditsYes
resultsYes
open_in_deepniaYes
check_again_in_secondsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations it discloses that the call spends the user's Deepnia credits, persists the result to their account, and is automatically refunded on failure, plus the concrete idempotency guarantee keyed on quote_id. That is precisely the cost and recovery information an agent needs before triggering a destructiveHint=true, credits-consuming operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the 'use this when' trigger, then tacks on the get_creation follow-up, which is good ordering with no filler. It is slightly run-on and repeats 'Deepnia' three times in one sentence, which costs a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter, output-schema-backed creation tool, everything an agent needs is present: prerequisite, cost, persistence, failure/refund behavior, idempotency, and next step. Return values are correctly left to the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both properties already document that quote_id comes from quote_image and credits is the accepted price, so the description adds little on that front. The one piece of added meaning is 'the same quote_id never charges twice', which characterizes quote_id as a de-duplication key rather than just an identifier.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource ('makes the image') and pins the inputs to the prior quote step ('from that quote_id and credits'). An agent can distinguish this from quote_image (pricing) and create_video (different medium) without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger condition ('when the user accepted the price from quote_image') and names the alternative that must precede it. It also prescribes the follow-up call ('Then follow it with get_creation'), closing the loop on the workflow.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.