Veo 3.1 MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: cost estimation, video extension, job status checking, batch generation, single generation, and image upload. The descriptions reinforce distinct workflows (e.g., 'extend_video' specifically requires Veo-generated input, while 'upload_image' handles image preparation).
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with snake_case (e.g., 'estimate_veo_cost', 'extend_video', 'get_video_job'). The naming is predictable and readable, using clear verbs like 'estimate', 'extend', 'get', 'start', and 'upload' paired with relevant nouns.
Tool Count5/5
Six tools are well-scoped for a video generation server, covering core operations from initiation to status checking and cost management. This count avoids bloat while ensuring each tool earns its place, such as separate tools for single and batch generation to handle different use cases efficiently.
Completeness5/5
The toolset provides complete coverage for the video generation domain: starting jobs (single and batch), checking status, extending videos, uploading images for reference, and estimating costs. There are no obvious gaps; agents can handle the full lifecycle from planning to retrieval without dead ends.
Average 3.8/5 across 6 of 6 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the tool's purpose and timing, it doesn't describe what the estimation process entails, whether it requires authentication, if it has rate limits, what the return format looks like, or any error conditions. For a cost estimation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that each earn their place. The first sentence states the core purpose and timing, while the second explains the value proposition. There's zero wasted text, and the information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a cost estimation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the estimation returns (just 'cost in USD' without format details), doesn't mention whether this is a real API call or local calculation, and provides minimal behavioral context. The description should do more to compensate for the lack of structured metadata.
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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. However, it does provide context about why parameters matter ('Helps plan budgets and batch sizes'), which adds marginal value. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: estimating cost in USD for video generation requests. It specifies the action ('estimate cost'), resource ('video generation request'), and context ('before starting it'). However, it doesn't explicitly differentiate from sibling tools like 'start_video_generation' beyond the 'before starting' timing hint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context: 'Helps plan budgets and batch sizes' and 'before starting it' suggests this should be used prior to actual generation tools. However, it doesn't explicitly state when to use this versus alternatives or mention specific prerequisites beyond the timing suggestion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the input constraint (Veo-generated video only) but lacks details on permissions, rate limits, whether the extension is reversible, or what the output looks like (e.g., file format, processing time). For a mutation tool with zero annotation coverage, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste, front-loaded with the core purpose and followed by a key constraint. Every sentence earns its place by adding essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and no output schema, the description is adequate but incomplete. It covers the purpose and input constraint but lacks behavioral details (e.g., mutation effects, error handling) and output information, which are important for a video extension tool with multiple parameters.
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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by hinting at the input constraint ('from a previous Veo generation'), but doesn't provide additional syntax, format details, or usage examples for parameters. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('extend') and resource ('Veo-generated video'), specifying it adds seconds to a video. It distinguishes from arbitrary video processing by noting the input must be from previous Veo generation, but doesn't explicitly differentiate from sibling tools like 'start_video_generation' or 'get_video_job'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the input video must be from a previous Veo generation, which provides some context. However, it doesn't specify when to use this tool versus alternatives like 'start_video_generation' for new videos or 'get_video_job' for checking status, nor does it mention prerequisites or exclusions beyond the input requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 behavioral traits: it starts multiple jobs with concurrency control, returns operation names, and respects rate limits. However, it lacks details on error handling, timeouts, or what 'operation names' entail, leaving 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by usage guidance. Every sentence earns its place by adding value (e.g., return values and rate limit context), with no wasted words, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a batch mutation tool with no annotations and no output schema, the description is moderately complete. It covers the purpose and high-level behavior but lacks details on output format, error scenarios, or prerequisites, which are important for such an operation.
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 description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema, mentioning 'controlled concurrency' which aligns with the 'concurrency' parameter but doesn't provide additional syntax or format details. Baseline 3 is appropriate as the schema does the heavy lifting.
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?
The description clearly states the verb ('Start multiple video generation jobs') and resource ('video generation jobs'), distinguishing it from siblings like 'start_video_generation' (singular) and 'get_video_job' (retrieval). It specifies the concurrency control aspect, making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 ('to generate multiple videos efficiently while respecting rate limits'), but it does not explicitly state when not to use it or name alternatives. For example, it doesn't clarify whether to use this over 'start_video_generation' for single jobs or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 effectively describes the asynchronous nature ('returns an operation ID immediately') and polling requirement, which is crucial. However, it lacks information about costs, rate limits, authentication needs, or error handling, which are important for a complex video generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with three sentences that each earn their place: the core purpose, the polling requirement, and the key capabilities. It's front-loaded with the most critical information and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, nested objects) and lack of both annotations and output schema, the description is somewhat incomplete. While it covers the asynchronous behavior and key features, it doesn't address costs, permissions, or what the operation ID represents. For such a rich tool, more contextual guidance would be helpful.
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?
The schema description coverage is 100%, so the schema already documents all 13 parameters thoroughly. The description adds minimal value by mentioning 'reference images (up to 3)' and 'first/last frame interpolation', which are already covered in the schema. This meets the baseline of 3 when schema does the heavy lifting.
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?
The description clearly states the specific action ('Start a Veo 3.1 video generation job') and resource ('video generation job'), distinguishing it from siblings like 'extend_video' or 'start_batch_video_generation'. It also mentions the immediate return type ('operation ID') and key capabilities ('text-to-video, reference images, first/last frame interpolation').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool by stating it 'returns an operation ID immediately - use get_video_job to poll for completion', which implicitly guides the agent to follow up with the sibling tool. However, it doesn't explicitly mention when NOT to use it or alternatives like 'start_batch_video_generation' for batch jobs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 adds useful context by describing the return format (status and video URLs as download URLs) and usage options (save locally or share links), but it does not cover potential errors, rate limits, or authentication needs, leaving gaps for a mutation-free tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with two sentences that efficiently convey the tool's purpose, return values, and usage without wasted words. Each sentence adds distinct value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is mostly complete, covering purpose, return format, and usage. However, it lacks details on error handling or response structure, which could be helpful for an AI agent, though not critical for this simple tool.
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 description coverage is 100%, so the schema already documents the single parameter (operationName from start_video_generation). The description does not add any parameter-specific details beyond what the schema provides, such as format examples or constraints, meeting the baseline for high schema coverage.
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?
The description clearly states the tool's purpose with a specific verb ('Check') and resource ('video generation job'), distinguishing it from siblings like start_video_generation (which initiates jobs) and extend_video (which modifies videos). It explicitly mentions what it returns (status and video URLs), making the function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by specifying that it checks job status and returns results when complete, implying it should be used after starting a job. However, it does not explicitly state when not to use it or name alternatives, such as using start_video_generation for new jobs instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively describes key behaviors: the tool returns a 'fileUri that can be reused for 48 hours' (temporal constraint) and is 'the most token-efficient way to pass images' (performance characteristic). However, it doesn't mention authentication requirements, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with three sentences that each serve distinct purposes: stating the core function, describing the return value and constraints, and providing performance context. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description does well by explaining the return value ('fileUri') and its 48-hour validity. However, it could be more complete by mentioning what happens with invalid inputs, file size limits, or supported image formats given the tool's complexity.
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?
With 100% schema description coverage, the schema already documents all 4 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline expectation but doesn't provide extra value regarding parameter usage or semantics.
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?
The description clearly states the specific action ('upload an image'), target resource ('Google Files API'), and primary use case ('for use as reference, first frame, or last frame in video generation'). It distinguishes this tool from sibling video generation tools by focusing on image preparation rather than video creation or management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('for use as reference, first frame, or last frame in video generation') and mentions it's 'the most token-efficient way to pass images to video generation.' However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![veo-mcp MCP server](https://glama.ai/mcp/servers/waimakers/veo-mcp/badges/card.svg)](https://glama.ai/mcp/servers/waimakers/veo-mcp)

Score Badge

Copy to your README.md:

[![veo-mcp MCP server](https://glama.ai/mcp/servers/waimakers/veo-mcp/badges/score.svg)](https://glama.ai/mcp/servers/waimakers/veo-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/waimakers/veo-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server