Claude Code가 Google의 Gemini API(정지 영상용 Imagen 4, 비디오용 Veo 3.1)를 통해 이미지와 짧은 비디오를 생성할 수 있게 해주는 MCP 서버입니다.
Claude Code로 웹사이트를 만들면서 계속 같은 문제에 부딪혔습니다. Claude가 훌륭한 레이아웃을 설계한 다음 "여기에 히어로 이미지를 추가하세요"라고 말하는 식이었죠. 저는 다른 곳에서 이미지를 생성하고, 돌아와서 연결하고, 반복하고, 또 반복해야 했습니다. 컨텍스트 전환이 가장 큰 비용이었습니다. 그래서 이 루프를 닫기 위해 이 MCP 서버를 만들었습니다. Claude가 프롬프트를 작성하면 서버가 Veo나 Imagen을 호출하고, 파일이 프로젝트 디렉토리에 저장되며, Claude가 이미 작성 중인 코드에서 해당 파일을 참조합니다. 한 세션 내에서 모든 것이 이루어지며, 별도의 전달 과정이 없습니다.
다른 사람들도 같은 문제를 해결하고 있고, 누구도 이 작업을 두 번 반복해서 만들 필요가 없다고 생각하여 오픈 소스로 공개합니다.
Related MCP server: Gemini Image & Video Generation MCP
Claude Code가 visualgen-mcp를 사용하여 비주얼을 생성하고 페이지에 연결하는 모습.
https://github.com/user-attachments/assets/34d25755-cd4c-47b0-a0cb-056b9ed8b783
stdio를 통해 노출되는 6가지 도구:
submit_video(prompt, model, aspect_ratio, resolution, negative_prompt?, image_path?) — Veo 3.1 작업을 제출합니다. 즉시 job_id를 반환합니다.
check_video(job_id) — 작업을 폴링합니다. 비디오가 준비되면 서버가 다운로드하고 경로를 반환합니다.
list_videos() — 출력 디렉토리의 MP4 파일을 최신순으로 나열합니다.
generate_image(prompt, model, aspect_ratio, negative_prompt?) — 동기식 이미지 생성(보통 10초 미만). PNG 경로를 반환합니다.
list_images() — 출력 디렉토리의 PNG 파일을 나열합니다.
get_pricing() — 현재 Gemini 요금을 반환하여 Claude가 비용이 많이 드는 작업을 실행하기 전에 경고할 수 있도록 합니다.
2026년 4월 22일 기준 Gemini API 요금입니다. 프로덕션 환경에서 사용하기 전에 공식 요금 페이지에서 확인하세요.
모델 | 비용 |
Veo 3.1 Standard (720p / 1080p) | $0.40 / 초 |
Veo 3.1 Standard (4k) | $0.60 / 초 |
Veo 3.1 Fast (720p) | $0.10 / 초 |
Veo 3.1 Fast (1080p) | $0.12 / 초 |
Veo 3.1 Fast (4k) | $0.30 / 초 |
Veo 3.1 Lite (720p) | $0.05 / 초 |
Veo 3.1 Lite (1080p) | $0.08 / 초 |
Imagen 4 Fast | $0.02 / 이미지 |
Imagen 4 Standard | $0.04 / 이미지 |
Imagen 4 Ultra | $0.06 / 이미지 |
Gemini 2.5 Flash Image (Nano Banana) | $0.039 / 이미지 |
일반 사용자:
uvx visualgen-mcp기여자(소스에서 빌드):
git clone https://github.com/1RaghavM/visualgen-mcp.git
cd visualgen-mcp
uv sync
uv run python -m visualgen_mcp대화형 설정을 한 번 실행하세요. 프로필이 ~/.config/visualgen-mcp/config.toml(chmod 600)에 저장되며, 선택적으로 현재 프로젝트 디렉토리에 .mcp.json을 설정합니다.
uvx visualgen-mcp init다음 항목을 입력하라는 메시지가 표시됩니다:
Gemini API 키 — aistudio.google.com/apikey에서 발급받으세요. Veo는 유료 플랜이 필요하며, Imagen과 Nano Banana는 무료 티어에서도 작동하지만 더 엄격한 속도 제한이 적용됩니다.
출력 디렉토리 — 생성된 PNG 및 MP4 파일이 저장될 위치입니다. 기본값은 ~/visualgen-output입니다. 서버가 존재하지 않으면 생성하며, 도구 응답은 절대 경로를 반환하므로 Claude가 작성하는 코드에서 파일을 참조할 수 있습니다.
기본 비디오 티어, 이미지 모델 및 종횡비 — Claude가 이를 지정하지 않고 도구를 호출할 때 사용됩니다.
프로필을 업데이트하려면 언제든지 visualgen-mcp init를 다시 실행하세요. 프로젝트별 재정의도 가능합니다. 로컬 .env 파일이나 .mcp.json의 env 블록에 설정된 GEMINI_API_KEY 또는 OUTPUT_DIR이 프로필보다 우선합니다.
프로젝트 내에서 visualgen-mcp init를 실행하거나(자동으로 작성 제안), 프로젝트 루트의 .mcp.json에 다음을 추가하세요:
{
"mcpServers": {
"visualgen": {
"command": "uvx",
"args": ["visualgen-mcp"]
}
}
}서버는 ~/.config/visualgen-mcp/config.toml에서 API 키와 기본값을 읽습니다. 특정 프로젝트에 대해 이를 재정의하려면 .mcp.json의 env 블록에 GEMINI_API_KEY 또는 OUTPUT_DIR을 설정하세요. 환경 변수가 프로필보다 우선합니다.
Claude Code 내에서 /mcp를 실행하여 서버가 연결되었는지 확인하세요. 6개의 도구가 포함된 visualgen이 나열되어야 합니다.
/visualgen 스킬이 서버는 Claude에게 각 도구를 언제 사용해야 하는지, 일반적인 웹 디자인 요청에 대해 프롬프트를 어떻게 구성해야 하는지, 언제 비용을 확인해야 하는지 알려주는 Claude Code 스킬과 함께 제공됩니다. visualgen-mcp init를 실행했다면 이미 설치 제안을 받았을 것입니다. 그렇지 않은 경우:
cd your-project
cp -r /path/to/visualgen-mcp/.claude/skills/visualgen ./.claude/skills/visualgen설치 후 /visualgen hero video, modern SaaS landing, calm mood를 입력하면 전체 파이프라인이 한 번에 시작됩니다. Claude가 템플릿을 선택하고, 프롬프트를 작성하고, 작업을 제출하고, 반환된 파일을 코드에 연결합니다. 자연어로 비주얼을 요청할 수도 있습니다. Claude가 visualgen-mcp 도구를 호출하기 직전에 스킬이 자동으로 로드됩니다.
이 스킬은 비용에 대해 엄격합니다. Veo standard 및 모든 이미지-비디오 변환 호출은 비용 발생 전 항상 확인을 요청합니다. 그 외의 모든 작업(모든 이미지 생성 및 Veo lite/fast 텍스트-비디오 변환)은 자동으로 진행됩니다.
Claude Desktop도 동일한 패턴을 사용합니다. ~/Library/Application Support/Claude/claude_desktop_config.json(macOS) 또는 %APPDATA%\Claude\claude_desktop_config.json(Windows)의 mcpServers 아래에 항목을 추가하세요. 도구 호출을 지원하는 모든 stdio 전송 MCP 클라이언트가 작동합니다. HTTP나 인증 계층은 없으며, 서버는 로컬 사용을 목적으로 합니다.
랜딩 페이지 프로젝트에서의 실제 실행 예시입니다. 생략된 줄은 ...로 표시되었습니다.
> Build me a hero video loop for the top of the page. Something that suggests "city at night, calm, slow."
I'll generate that with the visualgen server.
submit_video(
prompt="A slow drone shot over a city skyline at night, warm window lights,
occasional headlights tracing streets below, calm mood, cinematic",
model="fast",
aspect_ratio="16:9",
resolution="1080p"
)
→ { "job_id": "f3c1...", "status": "submitted", "model": "veo-3.1-fast-generate-preview",
"estimated_seconds": 60 }
I'll check back in a minute.
check_video("f3c1...")
→ { "status": "pending", "elapsed_seconds": 25 }
... wait ...
check_video("f3c1...")
→ { "status": "complete",
"path": "/Users/.../landing/generated/veo-fast-20260422T191203Z.mp4",
"duration_seconds": 8.0 }
Writing it into the hero section:
Edit: src/components/Hero.tsx
<video
autoPlay
muted
loop
playsInline
className="absolute inset-0 h-full w-full object-cover"
src="/generated/veo-fast-20260422T191203Z.mp4"
/>하나의 프롬프트, 하나의 생성, 프로젝트 내 파일 저장, 코드 업데이트가 완료되었습니다.
submit_video매개변수 | 유형 | 기본값 | 참고 |
|
| (필수) | 비디오 설명. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 피해야 할 요소에 대한 텍스트. |
|
|
| 시작 프레임으로 사용할 PNG/JPEG/WebP의 절대 경로. |
{"job_id": str, "status": "submitted", "model": str, "estimated_seconds": int}를 반환합니다.
check_video매개변수 | 유형 | 기본값 |
|
| (필수) |
다음 중 하나를 반환합니다:
{"status": "pending", "elapsed_seconds": int}
{"status": "complete", "path": str, "duration_seconds": float}
{"status": "failed", "error": str}
list_videos매개변수 없음. list[{"path": str, "size_bytes": int, "created_at": str}]를 최신순으로 반환합니다.
generate_image매개변수 | 유형 | 기본값 | 참고 |
|
| (필수) | 이미지 설명. |
|
|
|
|
|
|
|
|
|
|
| Nano Banana에서는 무시됨. |
{"path": str, "model_used": str}를 반환합니다.
list_images매개변수 없음. list[{"path": str, "size_bytes": int, "created_at": str}]를 최신순으로 반환합니다.
get_pricing매개변수 없음. 모델별 현재 요금, last_updated 날짜, 소스 링크가 포함된 딕셔너리를 반환합니다. 하드코딩되어 있으며 서버가 이를 위해 API를 호출하지는 않습니다.
Veo 클립은 8초로 제한됩니다. 이 서버는 항상 8초를 요청합니다.
Veo에는 무료 티어가 없습니다. 성공적인 모든 생성은 요금이 청구됩니다.
생성된 비디오는 생성 후 48시간이 지나면 Google 서버에서 삭제됩니다. 해당 기간 내에(check_video를 통해) 다운로드하세요.
작업 저장소는 메모리 내에 있습니다. 서버를 재시작하면 보류 중인 작업은 손실됩니다. SQLite 마이그레이션 경로는 src/visualgen_mcp/jobs.py의 TODO를 참조하세요.
일부 프롬프트는 Google의 콘텐츠 필터에 의해 거부될 수 있습니다. 이 경우 충돌이 아닌 {"status": "failed", ...} 응답을 받게 됩니다.
Nano Banana(gemini-2.5-flash-image)는 Imagen 4보다 빠르고 저렴하지만 negative_prompt를 허용하지 않습니다. 필요할 경우 Imagen 4를 사용하세요.
list_videos와 list_images는 OUTPUT_DIR에 있는 파일만 확인합니다. 재귀적으로 탐색하거나 디렉토리를 넘나들지 않습니다.
CONTRIBUTING.md를 참조하세요.
MIT. LICENSE를 참조하세요.
Check a video generation job. Downloads the file when ready.
Returns one of three shapes:
{"status": "pending", "elapsed_seconds": int}
{"status": "complete", "path": str, "duration_seconds": float}
{"status": "failed", "error": str}
Safe to call repeatedly. Once a job is complete or failed, subsequent calls return the cached terminal state without re-polling.
Args: job_id: The id returned by submit_video.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 and excels. It reveals key traits: polling behavior ('Downloads the file when ready'), idempotency ('Safe to call repeatedly'), caching ('returns the cached terminal state'), and the three possible return shapes with their semantics. This goes well beyond basic parameter documentation.
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 perfectly structured and concise. It front-loads the core purpose, then details return shapes, behavioral notes, and parameters in logical order. Every sentence earns its place with essential information, and there is no wasted verbiage.
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 complexity (stateful job monitoring), lack of annotations, and presence of an output schema (which covers return values), the description is complete. It explains the tool's role in a workflow, behavioral guarantees, parameter semantics, and output interpretation, leaving no significant gaps for an AI agent.
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 0%, so the description must compensate. It adds crucial semantic context for the single parameter: 'job_id: The id returned by submit_video' clarifies the parameter's origin and relationship to another tool. However, it doesn't specify format constraints (e.g., UUID, string length) that might be in an unannotated schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Check', 'Downloads') and resource ('video generation job'), distinguishing it from siblings like 'submit_video' (which creates jobs) and 'list_videos' (which lists existing videos). It explicitly describes the monitoring and file retrieval functionality.
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 on when to use this tool: 'Check a video generation job' implies it's for monitoring jobs created by 'submit_video'. It also specifies 'Safe to call repeatedly' and explains terminal state behavior, giving clear operational context without misleading exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image synchronously. Blocks until the file is on disk.
Typical latency is under 10 seconds. The PNG is written to the configured OUTPUT_DIR and the absolute path is returned.
Args: prompt: Text description of the image to generate. model: "nano-banana" (Gemini 2.5 Flash Image, the default — cheapest and fastest) or "imagen" (Imagen 4, higher quality, higher cost). aspect_ratio: "1:1", "16:9", "9:16", "4:3", or "3:4". negative_prompt: Optional text describing what to avoid. Ignored by Nano Banana; used by Imagen 4 when supplied.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| model | No | nano-banana | |
| aspect_ratio | No | 16:9 | |
| negative_prompt | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 behavioral traits: synchronous operation ('Blocks until the file is on disk'), typical latency ('under 10 seconds'), file handling ('PNG is written to OUTPUT_DIR'), and return value ('absolute path is returned'). It also notes model-specific behavior differences (e.g., negative_prompt ignored by Nano Banana). However, it lacks details on error handling or rate limits.
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 appropriately sized and front-loaded: the first sentence states the core purpose and key behavioral trait (synchronous blocking). Subsequent sentences efficiently cover latency, output details, and parameter explanations in a structured format with bullet-like clarity. Every sentence adds value without redundancy.
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 (image generation with multiple parameters), no annotations, and the presence of an output schema (which handles return value documentation), the description is complete enough. It covers purpose, behavior, parameters, and output location, leaving the output schema to detail the return structure. No critical gaps remain for agent understanding.
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 0%, so the description must fully compensate. It provides comprehensive parameter semantics: 'prompt' as the text description, 'model' with two options and cost/quality trade-offs, 'aspect_ratio' with five specific options, and 'negative_prompt' with optional usage and model-specific behavior. This adds significant meaning beyond the bare schema, fully documenting all four 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 clearly states the tool's purpose: 'Generate an image synchronously' with specific details about the output format (PNG) and location (OUTPUT_DIR). It distinguishes from sibling tools like 'list_images' (which retrieves existing images) and 'submit_video' (which handles video generation), making the verb+resource combination 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.
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: for synchronous image generation with latency under 10 seconds. It distinguishes from alternatives by specifying the output format (PNG) and location (OUTPUT_DIR), but does not explicitly state when NOT to use it or compare it to other image-related tools beyond the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return current published Gemini API pricing for the models this server uses.
Rates are per-image for images and per-second for video. Pricing is
hardcoded from the official docs (see the source field) and may drift;
always verify before expensive operations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 traits: it returns 'current published' pricing, notes that rates vary by media type (images vs. video), mentions the data source ('hardcoded from the official docs'), and warns about potential drift and the need for verification. This covers most behavioral aspects for a read-only pricing 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 front-loaded with the core purpose in the first sentence, followed by supporting details. Every sentence earns its place by clarifying pricing units, data source, and reliability warnings. It is appropriately sized with no wasted words.
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 simplicity (0 parameters, no annotations, but with an output schema), the description is complete. It covers purpose, usage context, behavioral details like data source and limitations, and output semantics. The presence of an output schema means the description doesn't need to explain return values, so 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by explaining the semantics of the returned pricing data (e.g., 'per-image for images and per-second for video'), which goes beyond the schema. A baseline of 4 is appropriate for zero-parameter tools with high schema coverage.
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: 'Return current published Gemini API pricing for the models this server uses.' It specifies the verb ('Return'), resource ('Gemini API pricing'), and scope ('models this server uses'), distinguishing it from sibling tools like generate_image or submit_video that perform different operations.
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: to get pricing information for API operations. It implies usage before 'expensive operations' but does not explicitly state when not to use it or name alternatives among sibling tools, which would be needed for a score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every PNG file in the configured OUTPUT_DIR, newest first.
Each entry has absolute path, size in bytes, and creation timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it lists files from a specific directory (OUTPUT_DIR), sorts them (newest first), and describes the return format (absolute path, size, creation timestamp). It doesn't mention permissions, rate limits, or error conditions, but covers the core behavior adequately.
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 perfectly concise with two sentences that each earn their place. The first sentence states the core action and scope, while the second provides essential output details. No wasted words, well-structured and front-loaded.
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 simplicity (0 parameters, no annotations, but has output schema), the description is complete enough. It explains what the tool does, how results are sorted, and what data each entry contains. The output schema will handle return value details, so the description doesn't need to explain return values further.
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 0 parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to add parameter information, and it appropriately focuses on the tool's behavior rather than 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 clearly states the tool's purpose with specific verbs ('List every PNG file') and resources ('in the configured OUTPUT_DIR'), including sorting order ('newest first'). It distinguishes from sibling tools like 'list_videos' by specifying PNG files rather than 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 (listing PNG files in OUTPUT_DIR), but doesn't explicitly state when not to use it or name alternatives. It implies usage for PNG files specifically, which helps differentiate from 'list_videos' for video files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every MP4 file in the configured OUTPUT_DIR, newest first.
Each entry has absolute path, size in bytes, and creation timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it lists files 'newest first', specifies the exact fields in each entry (path, size, timestamp), and mentions the configured OUTPUT_DIR as the source. It lacks details on permissions or error handling, but covers core behavior adequately.
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 perfectly concise and front-loaded: the first sentence states the core purpose and key details (MP4 files, OUTPUT_DIR, ordering), and the second sentence adds essential output structure. Every sentence earns its place with zero waste.
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 low complexity (0 parameters, simple list operation), no annotations, and the presence of an output schema (which handles return values), the description is complete enough. It covers purpose, behavior, and output fields, leaving no significant gaps for this context.
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 0 parameters with 100% schema description coverage, so the baseline is 4. The description adds no parameter information, which is appropriate since there are no parameters to document, maintaining clarity without redundancy.
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 specific action ('List every MP4 file') and resource ('in the configured OUTPUT_DIR'), with explicit scope details. It distinguishes from sibling tools like 'list_images' by specifying MP4 files only, not images.
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 about when to use this tool (to list MP4 files in OUTPUT_DIR), but does not explicitly state when not to use it or name alternatives like 'list_images' for non-MP4 files or 'check_video' for individual video inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a Veo 3.1 video generation job. Returns immediately with a job_id.
Videos typically take 30-120 seconds. Call check_video(job_id) to poll for completion. The final MP4 is written to the configured OUTPUT_DIR and its absolute path is returned by check_video once ready.
Args: prompt: Text description of the video to generate. model: "lite" (cheapest), "fast" (default, good balance), or "standard" (highest quality, most expensive). See get_pricing for rates. aspect_ratio: "16:9" (landscape) or "9:16" (portrait). resolution: "720p", "1080p", or "4k". "4k" is rejected for model="lite". negative_prompt: Optional text describing what to avoid. image_path: Optional absolute path to a PNG/JPEG/WebP file to use as the starting frame for image-to-video generation.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| model | No | fast | |
| aspect_ratio | No | 16:9 | |
| resolution | No | 720p | |
| negative_prompt | No | ||
| image_path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 behavioral traits: the asynchronous nature (returns immediately with job_id), typical processing time (30-120 seconds), polling mechanism (call check_video), output location (written to OUTPUT_DIR), and format (MP4). This covers execution flow, timing, and output handling beyond basic functionality.
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 appropriately sized and well-structured: it starts with the core purpose and immediate return, then explains the asynchronous workflow, and finally details each parameter in a clear Args section. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 of an asynchronous video generation tool with 6 parameters, no annotations, and an output schema (implied by 'Returns immediately with a job_id'), the description is complete. It covers the tool's purpose, behavioral workflow, parameter semantics, and integration with sibling tools, providing all necessary context for an agent to use it 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?
Schema description coverage is 0%, so the description must fully compensate. It provides detailed semantic explanations for all 6 parameters: purpose of prompt, model options with cost/quality trade-offs, aspect ratio meanings, resolution options with constraints (4k rejected for lite), optional negative_prompt usage, and image_path for image-to-video. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Submit a Veo 3.1 video generation job') and resource ('video'), distinguishing it from siblings like check_video (polling), generate_image (image creation), and list_videos (listing). It uses precise verbs and identifies the exact resource being created.
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 (to start a video generation job) and explicitly mentions check_video as the follow-up for polling completion. However, it doesn't explicitly state when NOT to use it or compare it to alternatives like generate_image for image generation, leaving some sibling differentiation implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_videogenerate_imageget_pricinglist_imageslist_videossubmit_videoScored across 6 tools
Each tool has a clearly distinct purpose with no ambiguity. check_video monitors video jobs, generate_image creates images, get_pricing provides cost information, list_images and list_videos enumerate outputs, and submit_video initiates video generation. The separation between image and video operations is particularly clear.
All tools follow a consistent verb_noun pattern with snake_case throughout. The naming is predictable and readable: check_video, generate_image, get_pricing, list_images, list_videos, and submit_video. This consistency makes the tool set easy to understand at a glance.
Six tools is well-scoped for a visual generation server. This provides complete coverage for both image and video workflows without being overwhelming. Each tool earns its place by addressing a specific need in the generation, monitoring, listing, or pricing aspects of the service.
The tool set covers the core visual generation domain comprehensively with create, check, and list operations for both images and videos, plus pricing information. The only minor gap is the lack of a tool to delete or manage generated files, but agents can work around this using system file operations.
MCP server for Google Veo AI video generation
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
MCP server for Qwen Image 3 AI image generation
MCP server for Grok Imagine AI video generation
