Generate images, video & speech with Nano Banana, Veo, Omni and Gemini TTS. Pay as you go.
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 10 of 10 tools scored. Lowest: 4/5.
Each tool targets a distinct resource and action: generate/edit for each media type, plus account/result/model/generation utilities. No two tools overlap in purpose; even edit_video vs generate_video are clearly differentiated by source requirement.
All tools follow a consistent verb_noun snake_case pattern: generate_*, edit_*, get_*, list_*, top_up. The pattern is predictable across the entire surface, with no mixed conventions or vague verbs.
10 tools is well-scoped for a media generation server: three generation tools, two editing tools, and the supporting utility tools (account, result, listing, models, top-up) each earn their place. Not bloated or thin.
The surface covers the full lifecycle for image/video/speech generation and editing (where applicable), plus account management, cost checking, and job polling. There are no obvious dead ends; the only minor absence (e.g., job cancellation) is easily worked around and not essential.
edit_imageAInspectEdit / refine a previously generated image with a text instruction on Nano Banana 2 Lite / 2 / Pro (multi-turn editing: change colors, remove objects, restyle, etc.). This tool modifies an image that already exists — use generate_image to create a new image from a prompt. 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 | |
| relaxed_filter | No | Switch this call to Google's own permissive presets: safety thresholds OFF and person generation allowed for adults (safetySettings and personGeneration=ALLOW_ADULT — documented Vertex AI parameters, not a way around Google's rules). Google filters in two independent stages and this flag only affects the first: (1) a check on the request before anything is rendered — this is what refuses legitimate prompts about real-looking people, swimwear or sportswear, medical and anatomical subjects, mild fictional violence and edgy artwork (upstream_reason SAFETY_BLOCK), and it is the stage relaxed_filter relaxes; (2) a classifier that scores the finished image, which no parameter can switch off (upstream_reason IMAGE_SAFETY). Stage 2 judges the actual pixels and every run renders a different image, so a borderline but legitimate subject rejected there often passes on a plain retry or with slightly less ambiguous wording — retrying is reasonable (failures are fully refunded, so an attempt costs only time), just don't expect the flag itself to bypass that stage. What Google refuses outright — sexual content, minors, real public figures — stays blocked in every attempt. Both stages surface as error_code SAFETY_FILTERED; upstream_reason in get_result tells them apart. | |
| 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?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: multi-turn editing capability, charging model, and auto-refund on failure. However, it does not clarify whether editing is non-destructive (creates a new output vs modifies original), the effect of changing resolution/aspect_ratio on the edit, or any rate limits. The description adds some value but leaves notable gaps for a mutation tool.
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 approximately 90 words, front-loaded with purpose, then usage guideline, prerequisite, charging info, and a concrete example. Every sentence serves a clear purpose with no redundancy or 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?
Given the tool has 9 parameters, no output schema, and is an editing operation, the description adequately covers the main usage scenario and provides an example. However, it does not explain how to retrieve the resulting edited image (e.g., using get_result), does not mention error conditions beyond auto-refund (e.g., what if source_generation_id is invalid or not completed), and does not summarize the relaxed_filter parameter's safety behavior. The description is usable but leaves operational details unaddressed.
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 only 33% (3 of 9 parameters have descriptions). The description does not compensate for the remaining parameters (seed, model, resolution, aspect_ratio, output_format, idempotency_key) by explaining their purpose or constraints. It mentions 'choose model/resolution' in passing but provides no semantic detail. The example illustrates only the two required parameters. This is insufficient for a tool with 9 parameters.
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 explicitly states 'Edit / refine a previously generated image with a text instruction' with specific models and examples of edits (change colors, remove objects, restyle). It clearly distinguishes from the sibling tool generate_image ('use generate_image to create a new image from a prompt'). This provides a specific verb+resource and differentiates from related 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?
The description gives explicit when-to-use guidance: when an existing image needs modification via text instruction. It directly contrasts with generate_image for new creations. It also specifies a prerequisite (source_generation_id must be from a COMPLETED generation) and mentions charging auto-refund on failure, which helps set expectations. This fully covers usage context and alternatives.
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. The default nano-banana-2-lite model is the cheapest option and produces 1024px images; choose nano-banana-2 explicitly for 512px, 2048px or 4096px output. Optional reference_images provide the model with the actual subject, product, character or style pixels; Nano Banana Pro supports up to 14 references. Costs $0.03–$0.20 per image depending on model and resolution (see list_models). Failed generations are automatically refunded. If a legitimate prompt is rejected by Google's content filter, retry with relaxed_filter: true. 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-lite", "aspect_ratio": "4:5", "resolution": "1024"}
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | For reproducible results. | |
| model | No | nano-banana-2-lite: cheapest default, 1024 only. nano-banana-2: choose for 512, 2048 or 4096 output. nano-banana-pro: top quality, up to 4K. | nano-banana-2-lite |
| prompt | Yes | What to generate. English works best. | |
| resolution | No | Lite requires 1024. Choose nano-banana-2 for 512, 2048 or 4096; 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 | |
| relaxed_filter | No | Switch this call to Google's own permissive presets: safety thresholds OFF and person generation allowed for adults (safetySettings and personGeneration=ALLOW_ADULT — documented Vertex AI parameters, not a way around Google's rules). Google filters in two independent stages and this flag only affects the first: (1) a check on the request before anything is rendered — this is what refuses legitimate prompts about real-looking people, swimwear or sportswear, medical and anatomical subjects, mild fictional violence and edgy artwork (upstream_reason SAFETY_BLOCK), and it is the stage relaxed_filter relaxes; (2) a classifier that scores the finished image, which no parameter can switch off (upstream_reason IMAGE_SAFETY). Stage 2 judges the actual pixels and every run renders a different image, so a borderline but legitimate subject rejected there often passes on a plain retry or with slightly less ambiguous wording — retrying is reasonable (failures are fully refunded, so an attempt costs only time), just don't expect the flag itself to bypass that stage. What Google refuses outright — sexual content, minors, real public figures — stays blocked in every attempt. Both stages surface as error_code SAFETY_FILTERED; upstream_reason in get_result tells them apart. | |
| 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. | |
| reference_images | No | Actual visual references for the generated image. Each item is a job_id of a completed image generation on this account, a public http(s) image URL, or an inline data:image/png|jpeg|webp;base64,... URL (max 10 MB each). For a local file, read and base64-encode its bytes into a data URL; a bare local path such as C:\\photo.jpg cannot be read by this remote server. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels: discloses immediate account charge, async job_id return, 10–60s latency, auto-refunds, the two-stage batch quote flow, and a detailed walkthrough of the two-stage Google content filter and when relaxed_filter actually helps. This is exemplary disclosure of side effects and caveats.
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?
Dense but well-organized: front-loads the async pattern and job_id, then layers cost, models, references, refunds, filtering, and batching — each sentence adds new, actionable information. The trailing JSON example is a high-value reference, and nothing feels like 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?
For a 12-parameter tool with no output schema and no annotations, the description covers everything an agent needs: asynchronous contract, side effects, costs, retry semantics, batch quoting, filter behavior, and a runnable example. It even provides troubleshooting paths (SAFETY_FILTERED, relaxed_filter) that prevent failed invocations.
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 75%, so the baseline is ~3, and the description adds real value: cost ranges by model/resolution, refund policy, retry hints on SAFETY_FILTERED, and the reference_images format guidance (job_id/URL/data URL). Only minor redundancy with the verbose schema descriptions for relaxed_filter and reference_images keeps this from a 5.
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+resource — 'Start an AI image generation (Google Nano Banana family)' — and immediately differentiates from siblings (generate_video, edit_image) by covering the generation workflow, polling via get_result, and model families. The concrete JSON example cements what the tool does.
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?
Strong guidance on when to use: references get_result for polling and list_models for pricing, explains the batching flow with confirm_cost, and gives retry guidance for content-filter false positives. Lacks an explicit 'use edit_image instead for edits' or a when-not-to-use for generation, but the practical context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_speechAInspectGenerate natural speech with Gemini 3.1 Flash TTS Preview. This synchronous tool returns a hosted WAV URL directly (no get_result polling). Supports one voice or an exactly two-speaker dialogue, automatic language detection or a BCP-47 language_code, natural-language direction for accent/tone/pace, and inline performance tags such as [whispers], [laughs], [very slow] and [excited]. Price is $0.01 per started 200 transcript characters; the account is charged only after Google has returned valid audio. Example: {"text":"[cheerfully] Welcome to BananaBanana!","voice":"Kore","style":"Warm product announcement, medium pace."}
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Exact transcript to speak. For dialogue, prefix every turn with the matching speaker name, e.g. Sam: Hello. | |
| style | No | Optional overall direction: persona, scene, emotion, accent, pace, pronunciation and delivery notes. | |
| voice | No | Single-speaker voice. Ignored when speakers is provided. | Kore |
| speakers | No | Exactly two dialogue speakers. Their names must prefix the turns in text. | |
| language_code | No | Optional language/locale such as en-US, ru-RU, ja-JP or es-MX. Omit for automatic detection. | |
| idempotency_key | No | Optional unique key; retries with the same key never double-charge. |
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 the synchronous nature, direct URL return, per-character pricing and the fact that charging happens only after valid audio is returned. It also mentions inline performance tags and language auto-detection. It does not mention URL expiration or error handling, but it covers key behavioral aspects unusually well for a TTS tool.
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 compact and information-dense, covering purpose, sync/async behavior, return type, supported features, pricing, and an example in just four sentences. Every sentence earns its place, with no repetition of schema content. The example is well-chosen and aids understanding.
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 no output schema, the description adequately explains the return value ('hosted WAV URL') and adds pricing details that are important for decision-making. It also covers the main usage modes and constraints. It could mention potential error cases or whether URLs expire, but for a tool with this complexity and rich schema, it is sufficiently 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?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by providing a concrete example of how to pass 'text', 'voice', and 'style', and by explaining the two-speaker dialogue pattern and performance tags. This enhances the agent's ability to construct valid and effective calls, justifying a score above baseline.
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 begins with 'Generate natural speech,' which clearly specifies the verb (generate) and resource (speech), distinguishing this from sibling image/video tools. It further clarifies it is synchronous and returns a hosted WAV URL, making its purpose unambiguous even without the context of sibling names.
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 contrasts with async tools by noting 'no get_result polling,' guiding the agent to expect an immediate result. It also explains supported scenarios like single voice or exactly two-speaker dialogue, language detection or explicit BCP-47 codes, and pricing rules, which help the agent decide when to use this tool. It lacks an explicit 'when not to use' statement but the differentiation is clear.
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). Content filtering differs by model: omni-flash is by far the strictest, so a clip rejected as SAFETY_FILTERED on omni-flash is often produced by veo-3.1-fast without changing a word. Video has no configurable safety settings on Google's side (relaxed_filter is accepted for Veo but only pins its default personGeneration=allow_adult), and refused clips are refunded, so a retry is cheap in money and expensive only in time. 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, a public image URL, or inline base64 image data, 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), a public http(s) image URL, or an inline data:image/png|jpeg|webp;base64,... URL for a local file (max 10 MB; a bare local filesystem path cannot be read by this remote server). This includes 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. | |
| relaxed_filter | No | Veo only (omni-flash ignores it), and much weaker than its image counterpart: Google's video API exposes no configurable safety settings at all, so this flag can do only one thing — pin personGeneration=allow_adult, which is already the default for Veo 3.1 here. Expect it to change little. Video is filtered both before generation and again on the finished clip (rai_media_filtered_reasons), and neither check can be turned off. When a clip is refused, the levers that actually work are: retry (each run renders different footage, and failures are fully refunded), reword the people-related part of the prompt, or move an omni-flash idea to veo-3.1-fast, whose filter is noticeably looser. | |
| 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, a public http(s) image URL, or an inline data:image/png|jpeg|webp;base64,... URL. For a local file, pass a base64 data URL rather than its filesystem path. 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, the description bears full burden and delivers comprehensively. It discloses cost range ($0.10–$4.40), cost confirmation protocol, auto-refund for failures, model-specific filtering differences, safety settings limitations (relaxed_filter's minimal effect), idempotency, and image input constraints. No behavioral surprises remain.
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 thorough but lengthy (~500 words). It is well-structured: purpose, cost, polling, models, filtering, image inputs, then an example. Every sentence adds value, but some sections (e.g., relaxed_filter) could be tightened without losing clarity. Still, for a complex tool with 15 parameters, the detail is justified.
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 complexity (15 parameters, multiple models, cost, filtering, image inputs), the description covers every dimension: usage flow, model selection, parameter interactions, error handling, and return value (job_id). It even references related tools (get_result, edit_video). No output schema exists, but the description explains what to expect.
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 80% schema coverage, the description adds significant value: model-specific behavior (e.g., duration limits per model), cost confirmation workflow, image input format variations (job_id, URL, base64), and nuanced interactions (first_frame+reference_images combo on omni-flash, edit_from_generation_id inheriting scene). This far exceeds the schema's 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 clear verb+resource ("Start an AI video generation") and immediately names the specific model families (Google Veo 3.1, Gemini Omni Flash). This distinguishes it from sibling tools like generate_image or generate_speech. 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 provides explicit guidance: mandatory cost confirmation flow, when to poll get_result, model-specific recommendations (e.g., omni-flash strictness, veo-3.1-fast as default), and retry/refund behavior. It even tells the agent when to use edit_video for shortening clips, which is a separate sibling tool.
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, video and speech 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?
No annotations are present, so the description must carry the behavioral transparency burden. It discloses that the tool is free and that prices come from the same source as the website, but it does not explicitly state whether it is read-only, requires authentication, or has side effects. For a simple list tool, this is adequate but not exhaustive.
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-loads the main function, and every sentence adds value. It is concise and well-structured.
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?
The tool has no parameters and no output schema, but the description summarizes the return content (models, prices, resolutions, durations, constraints) and provides usage timing. It is sufficiently complete for a simple list operation, though a note on authentication or response format could push it higher.
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 has zero parameters, so the description does not need to explain parameter semantics. The baseline of 4 applies, and the description adds no parameter-related ambiguity.
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 function: listing available image, video, and speech generation models with pricing, resolutions, durations, and constraints. It uses a specific verb ('List') and resource, and distinguishes it from sibling generate/edit 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?
Explicitly instructs to call this before quoting costs or choosing a model, providing a clear use case. It does not mention alternatives, but no sibling tool serves this purpose, so the guidance is effective.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
top_upAInspectGet a balance top-up link. OAuth connections receive a one-time deposit-only link valid for 30 minutes; opening it cannot expose API keys, profile data or generation history. Bearer API-key users receive the normal profile link. 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 fully carries the burden of behavioral disclosure. It explicitly states security-relevant behavior: the link is one-time, deposit-only, valid for 30 minutes, and cannot expose sensitive data. It also clarifies the free/no-charge aspect for OAuth users, which is valuable context beyond a simple CRUD 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?
Three sentences, each earning its place: first states the primary purpose, second explains security properties, third clarifies the free tier. No wasted words, fully front-loaded with the most important information.
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 zero parameters and no output schema, the description covers all necessary behavioral aspects: what it does, its security model, its limitations, and its user-type variations. Nothing missing for a tool of this complexity.
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 description appropriately handles this by focusing entirely on behavior. The description adds meaning by explaining the different link types (OAuth vs Bearer) without any parameter baggage, which is exactly what a zero-param tool needs.
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 what the tool does ('Get a balance top-up link') and differentiates two types of users (OAuth vs Bearer API-key). It goes beyond a generic phrase by specifying the link's validity and what it cannot expose, distinguishing it from sibling tools that handle media generation or account info.
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 implies when to use this tool (when you need to top up balance) and includes a clear exclusion: OAuth users get a deposit-only link, while Bearer API-key users get the normal profile link. However, it doesn't explicitly name alternative tools, though the sibling list suggests these are unrelated media/account tools.
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!
Sign in to create a connector for this server.