AceDataCloud API를 통해 Sora를 사용하는 AI 비디오 생성용 Model Context Protocol (MCP) 서버입니다.
Claude, VS Code 또는 MCP 호환 클라이언트에서 직접 AI 비디오를 생성하세요.
텍스트-비디오 - 텍스트 설명으로 비디오 생성
이미지-비디오 - 이미지를 애니메이션화하고 참조 이미지로 비디오 생성
캐릭터 비디오 - 서로 다른 장면에서 캐릭터 재사용
비동기 생성 - 프로덕션 워크플로우를 위한 웹훅 콜백
다양한 방향 - 가로 및 세로 비디오 지원
작업 추적 - 생성 진행 상황 모니터링 및 결과 검색
Related MCP server: Sora2 MCP
도구 | 설명 |
| Sora를 사용하여 텍스트 프롬프트에서 AI 비디오를 생성합니다. |
| Sora를 사용하여 참조 이미지에서 AI 비디오를 생성합니다 (이미지-비디오). |
| 참조 비디오의 캐릭터를 포함하는 AI 비디오를 생성합니다. |
| 콜백 알림과 함께 비동기적으로 AI 비디오를 생성합니다. |
| Sora 버전 2(파트너 채널)를 사용하여 AI 비디오를 생성합니다. |
| 콜백과 함께 Sora 버전 2를 사용하여 비동기적으로 AI 비디오를 생성합니다. |
| 비디오 생성 작업의 상태와 결과를 조회합니다. |
| 여러 비디오 생성 작업을 한 번에 조회합니다. |
| 사용 가능한 모든 Sora 모델과 기능을 나열합니다. |
| 사용 가능한 모든 Sora API 작업과 해당 도구를 나열합니다. |
AceDataCloud 플랫폼에 가입하세요.
API 문서 페이지로 이동하세요.
**"Acquire"**를 클릭하여 API 토큰을 받으세요.
아래에서 사용할 토큰을 복사하세요.
AceDataCloud는 관리형 MCP 서버를 호스팅하므로 별도의 로컬 설치가 필요하지 않습니다.
엔드포인트: https://sora.mcp.acedata.cloud/mcp
모든 요청에는 Bearer 토큰이 필요합니다. 1단계에서 받은 API 토큰을 사용하세요.
OAuth를 사용하여 Claude.ai에 직접 연결하세요 (API 토큰 불필요):
Claude.ai 설정 → 통합 → 더 추가하기로 이동하세요.
서버 URL 입력: https://sora.mcp.acedata.cloud/mcp
OAuth 로그인 절차를 완료하세요.
대화에서 도구를 사용하기 시작하세요.
설정 파일에 추가하세요 (~/Library/Application Support/Claude/claude_desktop_config.json - macOS 기준):
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}MCP 설정에 추가하세요 (.cursor/mcp.json 또는 .windsurf/mcp.json):
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}VS Code MCP 설정에 추가하세요 (.vscode/mcp.json):
{
"servers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}또는 VS Code용 Ace Data Cloud MCP 확장 프로그램을 설치하세요. 15개의 모든 MCP 서버를 클릭 한 번으로 설정할 수 있습니다.
**설정 → 도구 → AI Assistant → Model Context Protocol (MCP)**로 이동하세요.
추가 → HTTP를 클릭하세요.
다음을 붙여넣으세요:
{
"mcpServers": {
"sora": {
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Claude Code는 MCP 서버를 기본적으로 지원합니다:
claude mcp add sora --transport http https://sora.mcp.acedata.cloud/mcp \
-h "Authorization: Bearer YOUR_API_TOKEN"또는 프로젝트의 .mcp.json에 추가하세요:
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Cline의 MCP 설정에 추가하세요 (.cline/mcp_settings.json):
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}MCP 구성에 추가하세요:
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Roo Code MCP 설정에 추가하세요:
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}.continue/config.yaml에 추가하세요:
mcpServers:
- name: sora
type: streamable-http
url: https://sora.mcp.acedata.cloud/mcp
headers:
Authorization: "Bearer YOUR_API_TOKEN"Zed 설정에 추가하세요 (~/.config/zed/settings.json):
{
"language_models": {
"mcp_servers": {
"sora": {
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}
}# Health check (no auth required)
curl https://sora.mcp.acedata.cloud/health
# MCP initialize
curl -X POST https://sora.mcp.acedata.cloud/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'자신의 컴퓨터에서 서버를 실행하려면:
# Install from PyPI
pip install mcp-sora
# or
uvx mcp-sora
# Set your API token
export ACEDATACLOUD_API_TOKEN="your_token_here"
# Run (stdio mode for Claude Desktop / local clients)
mcp-sora
# Run (HTTP mode for remote access)
mcp-sora --transport http --port 8000{
"mcpServers": {
"sora": {
"command": "uvx",
"args": ["mcp-sora"],
"env": {
"ACEDATACLOUD_API_TOKEN": "your_token_here"
}
}
}
}docker pull ghcr.io/acedatacloud/mcp-sora:latest
docker run -p 8000:8000 ghcr.io/acedatacloud/mcp-sora:latest클라이언트는 자신의 Bearer 토큰으로 연결하며, 서버는 각 요청의 Authorization 헤더에서 토큰을 추출합니다.
도구 | 설명 |
| 텍스트 프롬프트에서 비디오 생성 |
| 참조 이미지에서 비디오 생성 |
| 참조 비디오의 캐릭터로 비디오 생성 |
| 콜백 알림과 함께 비디오 생성 |
도구 | 설명 |
| 단일 작업 상태 조회 |
| 여러 작업 한 번에 조회 |
도구 | 설명 |
| 사용 가능한 Sora 모델 나열 |
| 사용 가능한 API 작업 나열 |
User: Create a video of a sunset over mountains
Claude: I'll generate a sunset video for you.
[Calls sora_generate_video with prompt="A beautiful sunset over mountains..."]User: Animate this image of a city skyline
Claude: I'll bring this image to life.
[Calls sora_generate_video_from_image with image_urls and prompt]User: Use the robot character in a new scene
Claude: I'll create a new scene with the robot character.
[Calls sora_generate_video_with_character with character_url and prompt]모델 | 최대 지속 시간 | 품질 | 기능 |
| 15초 | 좋음 | 표준 생성 |
| 25초 | 최고 | 더 높은 품질, 더 긴 비디오 |
크기:
small - 낮은 해상도, 빠른 생성
large - 높은 해상도 (권장)
방향:
landscape - 16:9 (YouTube, 프레젠테이션)
portrait - 9:16 (TikTok, Instagram Stories)
지속 시간:
10초 - 모든 모델
15초 - 모든 모델
25초 - sora-2-pro 전용
변수 | 설명 | 기본값 |
| AceDataCloud API 토큰 | 필수 |
| API 기본 URL |
|
| OAuth 클라이언트 ID (호스팅 모드) | — |
| 플랫폼 기본 URL |
|
| 기본 모델 |
|
| 기본 비디오 크기 |
|
| 기본 지속 시간 (초) |
|
| 기본 방향 |
|
| 요청 타임아웃 (초) |
|
| 로깅 레벨 |
|
mcp-sora --help
Options:
--version Show version
--transport Transport mode: stdio (default) or http
--port Port for HTTP transport (default: 8000)# Clone repository
git clone https://github.com/AceDataCloud/SoraMCP.git
cd SoraMCP
# Create virtual environment
python -m venv .venv
source .venv/bin/activate # or `.venv\Scripts\activate` on Windows
# Install with dev dependencies
pip install -e ".[dev,test]"# Run unit tests
pytest
# Run with coverage
pytest --cov=core --cov=tools
# Run integration tests (requires API token)
pytest tests/test_integration.py -m integration# Format code
ruff format .
# Lint code
ruff check .
# Type check
mypy core tools# Install build dependencies
pip install -e ".[release]"
# Build package
python -m build
# Upload to PyPI
twine upload dist/*SoraMCP/
├── core/ # Core modules
│ ├── __init__.py
│ ├── client.py # HTTP client for Sora API
│ ├── config.py # Configuration management
│ ├── exceptions.py # Custom exceptions
│ ├── server.py # MCP server initialization
│ ├── types.py # Type definitions
│ └── utils.py # Utility functions
├── tools/ # MCP tool definitions
│ ├── __init__.py
│ ├── video_tools.py # Video generation tools
│ ├── task_tools.py # Task query tools
│ └── info_tools.py # Information tools
├── prompts/ # MCP prompt templates
│ └── __init__.py
├── tests/ # Test suite
│ ├── conftest.py
│ ├── test_client.py
│ ├── test_config.py
│ ├── test_integration.py
│ └── test_utils.py
├── deploy/ # Deployment configs
│ └── production/
│ ├── deployment.yaml
│ ├── ingress.yaml
│ └── service.yaml
├── .env.example # Environment template
├── .gitignore
├── CHANGELOG.md
├── Dockerfile # Docker image for HTTP mode
├── docker-compose.yaml # Docker Compose config
├── LICENSE
├── main.py # Entry point
├── pyproject.toml # Project configuration
└── README.md이 서버는 AceDataCloud Sora API를 래핑합니다:
Sora Videos API - 비디오 생성
Sora Tasks API - 작업 쿼리
기여를 환영합니다! 다음 단계를 따라주세요:
저장소를 포크하세요.
기능 브랜치를 만드세요 (git checkout -b feature/amazing).
변경 사항을 커밋하세요 (git commit -m 'Add amazing feature').
브랜치에 푸시하세요 (git push origin feature/amazing).
풀 리퀘스트를 여세요.
MIT 라이선스 - 자세한 내용은 LICENSE를 참조하세요.
AceDataCloud에서 사랑을 담아 제작함
Generate an AI video from a text prompt using Sora.
This is the primary way to create videos - describe what you want and Sora
will generate a video matching your description.
Use this when:
- You want to generate a video from a text description
- You don't have reference images
- You want creative AI-generated video content
For image-to-video generation, use sora_generate_video_from_image instead.
For character-based video generation, use sora_generate_video_with_character.
Returns:
Task ID and generated video information including URLs and state.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Video resolution. 'small' for lower resolution, 'large' for higher resolution. | large |
| model | No | Sora model version. 'sora-2' is the standard model. 'sora-2-pro' offers higher quality and supports 25-second videos. | sora-2 |
| prompt | Yes | Description of the video to generate. Be descriptive about the scene, action, style, and mood. Examples: 'A cat running on the river', 'A futuristic cityscape with flying cars at sunset', 'A person walking through a snowy forest' | |
| duration | No | Video duration in seconds. Options: 10, 15, or 25 (25 only available with sora-2-pro model). | |
| orientation | No | Video orientation. 'landscape' for horizontal (16:9), 'portrait' for vertical (9:16). | landscape |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool creates a video, which implies a non-read action, and mentions it returns task ID and video info. It could note that generation may take time, but the transparency is adequate.
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 well-structured with sections and front-loaded with the main action. It is slightly long but each section adds value. No unnecessary sentences.
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 (5 parameters, many siblings, output schema exists), the description covers purpose, usage guidelines, and parameter context thoroughly. The output schema handles return value details, so no gap.
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 100%, so baseline is 3. The description does not add parameter-level detail beyond the schema, but the schema already provides sufficient descriptions for all 5 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 it generates an AI video from a text prompt using Sora, a specific verb+resource. It distinguishes from siblings like sora_generate_video_from_image and sora_generate_video_with_character by specifying when to use each.
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 lists when to use this tool (e.g., 'when you want to generate a video from a text description') and when not to, with direct references to alternative tools for image-to-video and character-based generation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an AI video asynchronously with callback notification.
This is useful for long-running video generation tasks. Instead of waiting
for the video to complete, you'll receive a callback at your specified URL
when the generation is finished.
Use this when:
- You don't want to wait for the generation to complete
- You have a webhook endpoint to receive results
- You're integrating with an async workflow
The callback will receive a POST request with the same response format
as the synchronous generation tools.
Returns:
Task ID that you can use to correlate with the callback.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Video resolution. | large |
| model | No | Sora model version. | sora-2 |
| prompt | Yes | Description of the video to generate. | |
| duration | No | Video duration in seconds. | |
| image_urls | No | Optional list of reference image URLs for image-to-video generation. | |
| orientation | No | Video orientation. | landscape |
| callback_url | Yes | URL to receive the callback when video generation is complete. The result will be POSTed to this URL as JSON. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses async behavior, callback POST with response format, and return of Task ID. Does not mention potential failures or retry behavior, but covers key operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with a lead sentence, a usage section with bullet points, and a return statement. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and existence of output schema, the description covers async behavior, callback, and task ID. It does not explicitly differentiate from siblings like sora_generate_video_v2_async, but is otherwise complete for the tool's 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?
Schema coverage is 100%, so baseline is 3. The description does not add significant new semantics beyond what the schema provides. The callback_url parameter is explained in context of async, but this is minimal enhancement.
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 AI video asynchronously with callback notification.' It distinguishes itself from synchronous siblings like sora_generate_video by emphasizing the async nature and callback mechanism.
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 'Use this when' bullet points (don't want to wait, have webhook, async workflow). It lacks explicit 'when not to use' or direct sibling comparisons, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an AI video from reference images using Sora (Image-to-Video).
This allows you to animate or create videos based on provided images.
The AI will use the images as visual references for the generated video.
Use this when:
- You have reference images you want to animate
- You want the video to match a specific visual style
- You want to bring static images to life
Returns:
Task ID and generated video information including URLs and state.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Video resolution. 'small' for lower resolution, 'large' for higher resolution. | large |
| model | No | Sora model version. 'sora-2' or 'sora-2-pro' for higher quality. | sora-2 |
| prompt | Yes | Description of the video to generate based on the image. Describe the action or motion you want to see. | |
| duration | No | Video duration in seconds. Options: 10, 15, or 25 (25 only for sora-2-pro). | |
| image_urls | Yes | List of reference image URLs to use for video generation. Can be image URLs or Base64 encoded images. | |
| orientation | No | Video orientation. 'landscape', 'portrait'. | landscape |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions the return format (Task ID, URLs, state) but lacks info on rate limits, authentication, or side effects. Adequate but not rich.
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?
Description is well-structured: first paragraph states core function, second paragraph explains usage, and last line summarizes return. Every sentence earns its place, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 2 required, 4 enums, and an output schema (mentioned in description), the description covers purpose, usage, and returns. Could add more detail on async behavior or limitations, but 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 description coverage is 100%, so baseline is 3. Description adds high-level context but no extra meaning beyond what the schema already provides.
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?
Description clearly states 'Generate an AI video from reference images using Sora (Image-to-Video)' and explains it animates images, distinguishing from siblings like sora_generate_video which likely doesn't use 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?
Provides explicit 'Use this when:' list with three clear scenarios, but does not explicitly mention when not to use or alternatives. Still offers clear guidance on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an AI video using Sora Version 2 (partner channel).
Version 2 offers shorter video durations (4/8/12 seconds) with
precise pixel-based resolution control. This is ideal for quick
video generation with specific resolution requirements.
Use this when:
- You need precise pixel resolution control (e.g., 1280x720)
- You want shorter videos (4, 8, or 12 seconds)
- You want to use the partner channel for generation
For longer videos (10-25 seconds) or character-based generation,
use the version 1 tools (sora_generate_video, etc.) instead.
Returns:
Task ID and generated video information including URLs and state.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Video resolution in pixels. Options: '720x1280' (vertical), '1280x720' (horizontal), '1024x1792' (tall vertical), '1792x1024' (wide horizontal). | 1280x720 |
| model | No | Sora model version. 'sora-2' is standard, 'sora-2-pro' offers higher quality. | sora-2 |
| prompt | Yes | Description of the video to generate. Be descriptive about the scene, action, style, and mood. | |
| duration | No | Video duration in seconds. Options: 4, 8, or 12. | |
| image_urls | No | Optional list of reference image URLs. Only the first image is used for version 2. Image dimensions should match the size parameter. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes return value (Task ID and video info) but lacks details on limitations, auth requirements, or potential side effects. Adequate but not comprehensive.
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?
Well-structured with a concise intro, bullet-pointed use cases, alternative suggestion, and return statement. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose, usage, and return value. Lacks explicit mention of async behavior (though async sibling exists) and could clarify that generation might be asynchronous. Output schema helps but description leaves some 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?
Schema coverage is 100% with good descriptions, and description adds extra context (e.g., only first image used for v2, resolution options). Provides meaningful interpretation beyond 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?
Clearly states it generates AI videos using Sora Version 2 with specific characteristics (shorter durations, pixel resolution control). Distinguishes from sibling tools by mentioning version 1 for longer/character 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?
Explicitly lists when to use (precise resolution, shorter videos, partner channel) and when not to use (longer videos, character generation) with direct references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an AI video asynchronously using Sora Version 2 with callback.
Similar to sora_generate_video_v2 but returns immediately with a task ID.
The result will be POSTed to your callback URL when generation completes.
Use this when:
- You don't want to wait for the generation to complete
- You have a webhook endpoint to receive results
- You're integrating with an async workflow
Returns:
Task ID that you can use to correlate with the callback.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Video resolution in pixels. | 1280x720 |
| model | No | Sora model version. | sora-2 |
| prompt | Yes | Description of the video to generate. | |
| duration | No | Video duration in seconds. Options: 4, 8, or 12. | |
| image_urls | No | Optional list of reference image URLs. Only the first image is used. | |
| callback_url | Yes | URL to receive the callback when video generation is complete. The result will be POSTed to this URL as JSON. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly explains the async behavior, immediate return of task ID, and the callback mechanism. However, it does not disclose potential side effects or limitations like 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 concise and well-structured: a one-line purpose, a comparison to the sync version, a list of use cases, and the return value. No unnecessary 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 6 parameters, full schema coverage, and the presence of an output schema (mentioned in context), the description adequately covers the tool's functionality and return value. Missing details about error handling or rate limits, but still 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 description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema, only emphasizing the async nature and callback usage.
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 it generates an AI video asynchronously using Sora Version 2 with a callback, distinguishing it from the synchronous sibling sora_generate_video_v2.
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 lists three use cases: when you don't want to wait, have a webhook endpoint, or are integrating with an async workflow. This provides clear guidance on when to use this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an AI video featuring a character from a reference video.
This allows you to create new videos featuring a specific character
extracted from another video. The character will be placed in the
new scene described by the prompt.
IMPORTANT: The reference video must NOT contain real people.
Only animated or digital characters are supported.
Use this when:
- You want to reuse a character in different scenes
- You're creating a series with the same character
- You want consistent character appearance across videos
Returns:
Task ID and generated video information including URLs and state.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Video resolution. 'small' for lower resolution, 'large' for higher resolution. | large |
| model | No | Sora model version. 'sora-2' or 'sora-2-pro' for higher quality. | sora-2 |
| prompt | Yes | Description of the video to generate featuring the character. Describe the scene and action. | |
| duration | No | Video duration in seconds. Options: 10, 15, or 25 (25 only for sora-2-pro). | |
| orientation | No | Video orientation. 'landscape', 'portrait'. | landscape |
| character_end | No | End position of the character in the reference video (0-1 range). For example, 0.8 means the character ends at 80% of the video. | |
| character_url | Yes | URL of the video containing the character to use. IMPORTANT: The video must NOT contain real people, only animated/digital characters. | |
| character_start | No | Start position of the character in the reference video (0-1 range). For example, 0.2 means the character appears at 20% from the start. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the return includes Task ID and video info, and the limitation about real people. But it doesn't detail behavior like character selection from multi-character videos or potential mutation of the reference.
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?
Description is short and front-loaded with key purpose, followed by an important constraint and usage guidance. It is efficient but could be slightly more compact.
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 presence of an output schema and high schema coverage, the description covers essential context. However, it lacks guidance on parameter choices (model, size, orientation) and does not fully address potential edge cases.
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 100%, so parameters are already well-documented. The description adds no new parameter semantics beyond the schema; it only weakly contextualizes prompt and character_url.
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 it generates AI videos featuring a character from a reference video, distinguishing it from sibling tools like sora_generate_video. It specifies the resource (video with character) and strongly implies the extraction process.
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 'Use this when' bullet points provide clear scenarios (reusing characters, creating series, consistent appearance). However, it lacks explicit mention of when NOT to use it versus alternatives like sora_generate_video.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the status and result of a video generation task.
Use this to check if a generation is complete and retrieve the resulting
video URLs and metadata.
Use this when:
- You want to check if a generation has completed
- You need to retrieve video URLs from a previous generation
- You want to get the full details of a generated video
Task states:
- 'pending': Generation is still in progress
- 'succeeded': Generation finished successfully
- 'failed': Generation failed (check error message)
Returns:
Task status and generated video information including URLs and state.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | The task ID returned from a video generation request. This is the 'task_id' field from any sora_generate_* tool response. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses task states (pending, succeeded, failed) and return of URLs/metadata. Could mention idempotency or rate limits, but sufficient for polling 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?
Well-structured with bullet points for use cases and states. Every sentence adds value; 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?
Output schema exists, so return values are covered. Description explains use cases and states, fully adequate for a simple polling tool with one parameter.
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% with clear parameter description. Description adds no extra meaning beyond schema, so baseline 3 applies.
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 'Query the status and result of a video generation task' with specific verb and resource. It lists distinct use cases, differentiating it from sibling generation 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?
Explicit 'Use this when' list with three scenarios. While no explicit when-not or alternatives, the use cases imply context. Slight lack of exclusion guidance keeps from 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query multiple video generation tasks at once.
Efficiently check the status of multiple tasks in a single request.
More efficient than calling sora_get_task multiple times.
Use this when:
- You have multiple pending generations to check
- You want to get status of several videos at once
- You're tracking a batch of generations
Returns:
Status and video information for all queried tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| task_ids | Yes | List of task IDs to query. Maximum recommended batch size is 50 tasks. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions efficiency and returns but lacks details on rate limits, auth, or errors. Adequate but not rich.
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?
Well-structured with bulleted usage list. Could be more concise but no 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?
Output schema exists, so description doesn't need to detail returns. With one parameter and clear operation, it's complete enough.
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 covers 100% of parameters with good description including max batch size. Description adds minimal extra value.
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?
Description clearly states it queries multiple video generation tasks efficiently, distinguishing it from sibling sora_get_task.
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 lists when to use: multiple pending generations, status of several videos, tracking batch. Implies single-task use should go to sora_get_task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Sora API actions and corresponding tools.
Reference guide for what each action does and which tool to use.
Helpful for understanding the full capabilities of the Sora MCP.
Returns:
Categorized list of all actions and their corresponding tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the return is a 'Categorized list of all actions and their corresponding tools,' which is transparent. However, it does not mention any behavioral traits like idempotency, rate limits, or authentication requirements. For a simple read-only tool, this is minimally acceptable.
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 with no extraneous information. The first sentence front-loads the primary purpose. Every sentence serves a purpose: stating action, explaining utility, and describing output. No 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 simplicity (zero parameters) and the presence of an output schema, the description fully covers what an agent needs to know: it lists actions and tools, serves as a reference, and returns categorized output. No gaps remain.
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 zero parameters, so schema coverage is trivially 100%. The description adds value by detailing the return structure ('Categorized list'), which is beyond what the schema provides. No parameter explanation is needed, so the description is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all available Sora API actions and corresponding tools.' The verb 'list' combined with the resource 'actions and tools' makes the function unambiguous. It distinguishes itself from sibling tools like sora_generate_video by being a meta-discovery tool.
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 this tool should be used as a 'Reference guide' to understand capabilities before using other tools. While it doesn't explicitly state when not to use it, the context makes it clear that it's for exploration, not execution. No alternative tools are mentioned, but the distinction from siblings is inherent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Sora models and their capabilities.
Shows all available model versions with their limits, features, and
recommended use cases. Use this to understand which model to choose
for your video generation.
Returns:
Table of all models with their version, limits, and features.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 explains that the tool 'shows all available model versions with their limits, features, and recommended use cases,' accurately describing the read-only behavior without contradictions.
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 concise sentences, front-loaded with the purpose. Every sentence adds meaningful information with no 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 zero parameters and an output schema exists (so return values are documented), the description is complete. It explains the tool's purpose and what is returned.
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?
There are no parameters (0), so schema coverage is 100% by default. The description adds value by stating what information is shown (limits, features, use cases), which is beyond what the empty schema provides.
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 'List all available Sora models and their capabilities,' specifying the resource (models) and action (list). It is distinct from sibling tools like sora_generate_video and sora_get_task.
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 advises using it 'to understand which model to choose for your video generation,' providing clear context. It doesn't explicitly mention when not to use it, but the guidance is sufficient.
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.4sora_generate_videosora_generate_video_asyncsora_generate_video_from_imagesora_generate_video_v2sora_generate_video_v2_asyncsora_generate_video_with_charactersora_get_tasksora_get_tasks_batchsora_list_actionssora_list_modelsv0.1.2sora_generate_videosora_generate_video_asyncsora_generate_video_from_imagesora_generate_video_v2sora_generate_video_v2_asyncsora_generate_video_with_charactersora_get_tasksora_get_tasks_batchsora_list_actionssora_list_modelsv0.1.0sora_generate_videosora_generate_video_asyncsora_generate_video_from_imagesora_generate_video_v2sora_generate_video_v2_asyncsora_generate_video_with_charactersora_get_tasksora_get_tasks_batchsora_list_actionssora_list_modelsScored across 10 tools
Each generation tool targets a distinct input method (text, image, character, v2) and synchronous/asynchronous modes are clearly separated. Descriptions explicitly note differences, so an agent can easily select the appropriate tool.
All tools follow a consistent sora_verb_noun pattern in snake_case (e.g., sora_generate_video, sora_get_task). The version suffixes (_v2) are appended uniformly, maintaining predictability.
With 10 tools, the set is well-scoped for a video generation service. It covers generation variants, status checks, and listing actions/models without being bloated or too sparse.
The tool surface covers generation, status retrieval (single and batch), and informational queries. A minor gap is the lack of a cancellation tool for pending tasks, but it's not critical for core workflows.
OpenAI Sora: Sora & Sora 2 (new social media like TikTok) API by ChatGPT creator OpenAI. Access.
Generate images, video, music, voice and 3D through one API. 30 tools, 200+ models.
Image, video, music and text generation across 100+ models through one endpoint.
One API for 100+ AI video, image, music and speech models.
