Generate images & video (Nano Banana, Veo, Omni) pay-as-you-go. No subscription, crypto payments.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 8 of 8 tools scored.
Each tool targets a distinct operation on a distinct resource: generate/edit for images and videos, plus account, result, model listing, and generation history. No two tools have overlapping purposes.
All tool names follow a consistent verb_noun pattern (generate_image, edit_video, get_result, list_models, etc.). The naming is uniform, predictable, and clearly conveys each tool's function.
With 8 tools, the server is well-scoped for an image/video generation service. Each tool has a clear purpose, and the count is within the ideal range, neither bloated nor thin.
The toolset covers the full generation, editing, and retrieval lifecycle, including model and account information. Minor gaps such as a job cancellation tool or direct single-generation lookup are absent, but agents can work around these using list_generations and get_result.
edit_imageAInspectEdit / refine a previously generated image with a text instruction (multi-turn editing: change colors, remove objects, restyle, etc.). Pass the job_id of a COMPLETED image generation as source_generation_id. Charged like a single image of the chosen model/resolution; auto-refund on failure. Example: {"source_generation_id": "cmxyz...", "prompt": "make the background pure white and add soft shadow"}
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| model | No | nano-banana-2 | |
| prompt | Yes | The edit instruction. | |
| resolution | No | 1024 | |
| aspect_ratio | No | 1:1 | |
| output_format | No | jpeg | |
| idempotency_key | No | ||
| source_generation_id | Yes | job_id of a completed image generation owned by this account. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses charging behavior ('Charged like a single image of the chosen model/resolution') and refund policy ('auto-refund on failure'). It also clarifies that the source must be from a COMPLETED generation, which is a notable constraint. It does not detail other side effects, but given no annotations, this is a strong 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?
The description is concise: two sentences plus an example, with no wasted words. It front-loads the core action and follows with essential prerequisites and a concrete usage example. Every sentence adds value, making it highly efficient.
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?
Given the tool's moderate complexity and lack of output schema, the description covers the essential workflow (source generation, edit prompt), cost implications, and failure refund. It does not describe the response format or elaborate on edge cases (e.g., unsupported image states), but the sibling tools like get_result likely handle retrieval, and the example makes the input format clear. Overall, it is largely complete for an image editing 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?
The schema description coverage is only 25%, so the description must compensate. It adds meaning for the two required parameters: source_generation_id (must be a completed generation's job_id) and prompt (text instruction), and provides a concrete example. However, it does not explain other parameters like seed, aspect_ratio, output_format, or idempotency_key beyond what the schema's enums/defaults imply, leaving some gaps.
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?
The description clearly states the tool edits or refines a previously generated image using a text instruction, with concrete examples (change colors, remove objects, restyle). It distinguishes itself from sibling tools by explicitly referencing 'previously generated image' and 'source_generation_id', making it clear this is not for generating new images or editing videos.
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 provides clear context for when to use this tool: it is for multi-turn editing of an existing image, and the user must pass a completed generation's job ID. It implies prerequisites (a completed image generation) and explains cost/refund behavior, but it does not explicitly name alternatives or state when not to use it, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edit_videoAInspectEdit an EXISTING video with Gemini Omni Flash (video-to-video): restyle it, replace or add objects, relight the scene, change the mood — motion and composition of the source clip are preserved. Billed by output length at $0.10/s; cost confirmation is mandatory (first call returns the quote and charges nothing). Source: either source_generation_id (a completed video from this account — see list_generations) or video_url (public http(s) link, max 200 MB). The source is normalised to MP4 720p and the FIRST 10 SECONDS (model limit); output is 720p with sound, aspect ratio follows the source. OUTPUT LENGTH ALWAYS EQUALS SOURCE LENGTH (the model cannot stretch or shorten a clip), so duration only works downwards: it trims the source to the first N seconds. Omit duration to edit the whole clip — the quote tells you the resolved length. Returns a job_id; poll get_result. Failed edits are auto-refunded. Example: {"prompt": "make the whole scene look like a pencil sketch, keep the motion identical", "source_generation_id": "clx…", "confirm_cost": 1}
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | What to change in the video. | |
| duration | No | Optional: trim the source to the first N seconds and edit only that part ($0.10/s). Values above the source length are ignored — the clip cannot be made longer. | |
| video_url | No | Public http(s) URL of the source video (mp4/mov/webm/mkv/avi/wmv/flv/3gpp, max 200 MB). Use instead of source_generation_id. | |
| source_ref | No | Returned by the quote when video_url is used: pass it back with confirm_cost to reuse the already downloaded clip instead of downloading it again. | |
| audio_prompt | No | Describe the desired sound — Omni Flash always generates audio. | |
| confirm_cost | No | The quoted USD cost you accept. Omit on the first call to get the quote. | |
| idempotency_key | No | Optional unique key; retries with the same key never double-charge. | |
| source_generation_id | No | job_id of a completed video generation on this account. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and does so thoroughly: billing per second, mandatory cost confirmation, quote-first flow, normalization to 720p/10s limit, output length equals source length, duration only trims, job_id polling, and auto-refund on failure. These are critical operational behaviors disclosed upfront.
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?
The description is long but packed with necessary details for a complex, billing-aware tool. It front-loads the core purpose while folding edge cases (max input size, 10s cap, aspect ratio) and a concrete example at the end. Each sentence earns its place; minor redundancy (e.g., 'output length always equals source length' could be tighter) keeps it from a 5.
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?
Given 8 parameters, no output schema, and no annotations, the description covers the full workflow: quote, confirmation, job_id, polling, refund policy, source constraints, and parameter relationships. An example ties everything together. It is fully self-contained for an agent to invoke the tool correctly.
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?
Despite 100% schema coverage, the description adds significant meaning: duration's 'downwards-only' behavior, confirm_cost's quote-and-then-pay flow, source_ref as a reuse token, idempotency_key preventing double charges, and the interaction between duration and source length. This goes well beyond the schema's per-parameter descriptions.
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?
The description opens with a specific verb and resource: 'Edit an EXISTING video with Gemini Omni Flash (video-to-video)' and enumerates concrete use cases (restyle, replace/add objects, relight, change mood). It explicitly states what is preserved (motion and composition), distinguishing it clearly from video generation tools like generate_video.
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 clearly explains the two source pathways (source_generation_id or video_url) and refers to list_generations for finding completed videos. It also implies when to use generation instead (if you need different motion/composition), though it does not explicitly state 'use generate_video for new videos'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_imageAInspectStart an AI image generation (Google Nano Banana family). Charges the account balance immediately and returns a job_id — poll get_result for the finished image URLs. Typical completion: 10–60 seconds. Costs $0.03–$0.20 per image depending on model and resolution (see list_models). Failed generations are automatically refunded. Generating several images at once (number_of_images > 1) is a batch: the first call returns a price quote and charges nothing — repeat the call with confirm_cost set to the quoted amount to start. Example: {"prompt": "studio photo of a ceramic mug on linen, soft daylight", "model": "nano-banana-2", "aspect_ratio": "4:5", "resolution": "1024"}
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | For reproducible results. | |
| model | No | nano-banana-2-lite: cheapest, 1K only. nano-banana-2: balanced default. nano-banana-pro: top quality, up to 4K. | nano-banana-2 |
| prompt | Yes | What to generate. English works best. | |
| resolution | No | 512 only on nano-banana-2; 1024 only on lite; 4096 costs the most. | 1024 |
| aspect_ratio | No | 1:1 | |
| confirm_cost | No | Required for batches (number_of_images > 1): the quoted total USD cost you accept. | |
| output_format | No | jpeg | |
| idempotency_key | No | Optional unique key; retries with the same key never double-charge. | |
| negative_prompt | No | ||
| number_of_images | No | Variants per call. >1 requires confirm_cost. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, this description carries full disclosure burden. It exposes immediate billing, async job return, cost range, refunds on failures, and the batch quote/confirm flow—beyond any schema detail.
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 dense sentences plus a concrete JSON example. Every sentence contributes: purpose, side effects, timing/cost, failure policy, batch flow, and a illustrative payload. No fluff.
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?
Covers async behavior (job_id, polling), cost implications, refunds, batch special handling, and a realistic example. Despite no output schema, it points to get_result for results—adequate for a complex 10-param 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?
The description explains the semantic interplay of confirm_cost and number_of_images (quote vs charge) beyond the schema. Schema covers 70% of params; the example adds practical clarity, though a few params like negative_prompt are unaddressed.
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 ('Start an AI image generation') and names the family (Google Nano Banana). Distinguishes from siblings like generate_video and edit_image by focusing on generation and referencing get_result for results.
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?
Provides clear usage context: start generation, then poll get_result; points to list_models for pricing. Does not explicitly contrast with alternatives, but the flow is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_videoAInspectStart an AI video generation (Google Veo 3.1 family or Gemini Omni Flash). EXPENSIVE: $0.10–$4.40 per clip. Cost confirmation is mandatory: the first call always returns a USD quote and charges nothing — repeat the call with confirm_cost set to the quoted amount to actually start. Returns a job_id; poll get_result (videos take 1–10+ minutes). Failed generations are auto-refunded. Models: veo-3.1-fast (default, good quality/price), veo-3.1 (best Veo quality), veo-3.1-lite (cheapest, 720p/1080p), omni-flash (always has sound, any duration from 3 to 10 s at $0.10/s, supports conversational editing via edit_from_generation_id). Image inputs: first_frame animates a still picture, reference_images keep a subject/style consistent — both accept a job_id of a completed image generation on this account or a public image URL, and on omni-flash they can be combined (up to 10 images total). Example: {"prompt": "drone shot over a misty pine forest at sunrise", "model": "veo-3.1-fast", "duration": 8, "resolution": "720p", "confirm_cost": 0.70}
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Veo only. | |
| model | No | veo-3.1-fast | |
| prompt | Yes | ||
| duration | No | Clip length in seconds. Veo accepts only 4, 6 or 8; omni-flash accepts any value from 3 to 10. | |
| resolution | No | 4k only on veo-3.1 / veo-3.1-fast; omni-flash is 720p only. | 720p |
| with_audio | No | Native audio for Veo models (costs more). omni-flash always has audio. | |
| first_frame | No | Start the clip from a still image, which is then animated. Either a job_id of a completed image generation on this account (see list_generations) or a public http(s) image URL — including a signed url returned by get_result, which is how you pick one variant of a multi-image generation. On omni-flash it can be combined with reference_images; on Veo it cannot. | |
| aspect_ratio | No | 16:9 | |
| audio_prompt | No | Describe the desired sound (used when audio is on). | |
| confirm_cost | No | The quoted USD cost you accept. Omit on the first call to get the quote. | |
| idempotency_key | No | Optional unique key; retries with the same key never double-charge. | |
| negative_prompt | No | What to avoid. On omni-flash it is appended to the prompt as plain text (the model has no separate negative field). | |
| reference_images | No | Reference images that keep a subject, character or style consistent (they are NOT used as literal frames). Each item is a job_id of a completed image generation on this account or a public http(s) image URL. omni-flash: up to 10 images in total together with first_frame. Veo: at most 3, only with duration 8 and without first_frame. | |
| edit_from_generation_id | No | omni-flash only: job_id of a completed omni video to refine conversationally; prompt describes the changes. Duration, aspect ratio and the scene are inherited from that clip — duration is ignored here (use edit_video to shorten a clip). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description assumes full responsibility and delivers extensively: it warns about cost ($0.10–$4.40), explains auto-refunds on failure, states video generation takes 1–10+ minutes, and details model-specific behaviors like audio availability and image input restrictions. It also discloses that omni-flash inherits scene/duration from edit_from_generation_id and that negative_prompt is just appended text on omni-flash. This goes far beyond a simple 'generates a video' statement.
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?
The description is dense but every sentence earns its place: it front-loads the critical cost warning, then flows from general workflow to model details to image inputs, ending with a concrete JSON example. Despite its length, it avoids redundancy and is well-organized for a complex tool with 14 parameters and 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?
This is a high-complexity tool (14 parameters, no output schema, no annotations), and the description is remarkably complete. It covers purpose, cost model, two-step confirmation, job_id return, polling, fail handling, all model variants, duration/resolution/audio constraints, image input semantics, editing workflow, and provides an example. There are no major gaps for an agent to safely invoke this 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?
Although schema coverage is 79%, the description adds meaning well beyond the schema. It explains the confirm_cost workflow with a concrete example, clarifies that first_frame and reference_images accept job_id or public URL, and specifies combination limits (omni-flash up to 10 total, Veo at most 3 without first_frame). It also notes that edit_from_generation_id ignores duration and that duration is inherited—details not in the schema. This significantly enriches parameter understanding.
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?
The description uses specific verbs and resource: "Start an AI video generation (Google Veo 3.1 family or Gemini Omni Flash)". It clearly distinguishes the tool from siblings like generate_image, edit_image, and edit_video by focusing on new video generation with named model families. The scope is unambiguous.
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 explicitly states the mandatory two-step cost confirmation flow: first call returns a USD quote and charges nothing, then repeat with confirm_cost set to the quoted amount. It names the alternative for a related action: "use edit_video to shorten a clip" for duration inheritance. It also points to get_result for polling and list_generations for image job IDs, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_accountAInspectGet the current account balance (USD), this API key's name, optional daily spend cap and how much of it is used today. Free, no charge. Use it to check affordability before starting expensive generations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses 'Free, no charge' and lists exactly what data is returned (balance, name, cap, usage). It doesn't discuss rate limits or side effects, but as a simple read-only tool, this is reasonably transparent.
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?
Two sentences with no redundancy. The first sentence lists the key data points; the second provides a concrete use case. Every word earns its place.
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?
For a tool with no parameters and no output schema, the description fully covers what it does, the data returned, cost implications, and recommended usage context. The sibling tools are all about generation/editing, so this description leaves no ambiguity.
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?
The tool has zero parameters and the schema is an empty object (100% schema coverage). The description adds context about the return values (balance, name, cap, usage), which goes beyond the schema. Baseline for 0 params is 4.
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?
The description uses the specific verb 'Get' and clearly identifies the resources: account balance, API key name, daily spend cap, and usage. It is distinct from sibling generation/edit/list tools by focusing on account affordability checks.
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 explicitly states 'Use it to check affordability before starting expensive generations', giving a clear when-to-use context. It doesn't name alternatives or exclusions, but the purpose alone differentiates it from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_resultAInspectGet the status and result of a generation job started with generate_image / edit_image / generate_video / edit_video. Waits up to wait_seconds for completion before returning (long-poll). On success returns hosted media URLs (valid 24 h — call again for fresh links), cost_charged_usd and balance_remaining_usd, plus a small inline preview for images. Free, no charge. Poll roughly every 10–15 s for videos.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| wait_seconds | No | How long to wait server-side before answering. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels. It discloses long-polling behavior, URL validity ('valid 24 h — call again for fresh links'), return fields (cost_charged_usd, balance_remaining_usd), inline preview for images, and that the call is 'Free, no charge.' This goes far beyond a basic description.
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?
The description is three sentences, each earning its place: purpose, return details/URL validity, and cost/polling advice. It is front-loaded with the primary action and contains 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?
Despite having no output schema, the description thoroughly explains return values (hosted media URLs, cost/balance, preview) and behavioral details such as URL expiry and long-polling. For a two-parameter tool, this is fully complete.
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?
The schema covers 50% of parameters (wait_seconds has a description, job_id does not). The description adds meaning by explaining wait_seconds as a long-poll timeout ('Waits up to wait_seconds for completion') and provides additional polling guidance. It also implies that job_id is the ID returned from a generation job via the phrase 'started with generate_image / edit_image / generate_video / edit_video.'
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?
The description clearly states the tool's purpose: 'Get the status and result of a generation job started with generate_image / edit_image / generate_video / edit_video.' This specifies the exact verb and resource, and distinguishes it from sibling tools that initiate generation jobs.
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 explicitly identifies when to use the tool: after a generation job has been started with one of the four generation tools. It also provides practical guidance on polling intervals for videos ('Poll roughly every 10–15 s for videos') and explains the long-polling behavior, giving clear context for timing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_generationsAInspectList this account's recent generations (both MCP and website) — id, type, model, status, cost and prompt preview. Use it to find a job_id to re-download results or to pick a source for edit_image / edit_video / generate_video edit_from_generation_id. Free, no charge.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by media type. | |
| limit | No | ||
| status | No | Filter by status. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behaviour: it lists both MCP and website generations, includes a prompt preview (implying truncation), and is free. However, it does not explicitly state that the operation is read-only or safe, and it omits details about pagination or sorting.
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?
Two sentences, action-oriented and front-loaded. However, the phrase 'Free, no charge' is redundant, and the description could have been slightly tighter without losing clarity.
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?
Although there is no output schema, the description lists the return fields (id, type, model, status, cost, prompt preview) and gives practical use cases. It does not cover pagination or error conditions, but for a simple listing tool with a limit parameter, this is sufficient.
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 67% with two parameters having descriptions for their enums. The description does not explain the 'limit' parameter beyond the schema's default/min/max, and it does not elaborate on filtering behaviour; it merely reinforces that the list is recent.
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?
The description uses a specific verb ('List') and clearly identifies the resource ('this account's recent generations') while enumerating returned fields. It also distinguishes from siblings by noting it covers both MCP and website generations, setting it apart from list_models and generate_* tools.
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?
Provides explicit use cases: finding a job_id to re-download results or picking a source for edit_image / edit_video / generate_video. It also mentions 'Free, no charge' as a cost guideline, and the 'recent' scope implies when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_modelsAInspectList all available image and video generation models with current per-unit USD prices, supported resolutions, durations and constraints. Prices come from the same source as the website — call this before quoting costs to a user or choosing a model. Free, no charge.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds useful context such as 'Free, no charge' and 'Prices come from the same source as the website,' but it does not disclose other behavioral traits like return format or potential latency. This is acceptable for a simple list operation but not fully transparent.
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?
The description is two sentences, front-loaded with the core purpose, then adds pricing and usage context. Every word earns its place with zero redundancy or fluff.
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?
For a simple list tool with no output schema and no annotations, the description adequately covers what the tool does and when to invoke it. It does not explicitly mention the return format, but 'List all' implies a list response, and the tool's simplicity keeps completeness high.
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?
The tool has zero parameters, so the baseline is 4. The description adds no param-specific details (none needed) and the empty schema is fully self-explanatory. No deduction is warranted.
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?
The description clearly states the tool's purpose: 'List all available image and video generation models' with specific details (prices, resolutions, durations, constraints). It is distinct from sibling tools like generate_image or edit_video, and the listing nature is unambiguous.
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 provides explicit usage guidance: 'call this before quoting costs to a user or choosing a model.' This clearly indicates when to use the tool, though it does not mention alternatives or when not to use it, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!