Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@NoLang MCP Server create a video about sustainable energy using my slideshow template"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Enable any MCP Client like Claude Desktop or Agents to use the NoLang API to generate AI-powered videos
NoLang is an AI-powered video generation service developed by Mavericks that creates videos in real-time. This MCP server provides a standardized interface to interact with the NoLang API.
Related MCP server: PixVerse MCP
Python 3.12+
NoLang API key (Get it from the NoLang dashboard: NoLang API > API Key)
We recommend using uv to manage Python environments and dependencies.
# Using the official installer
curl -LsSf https://astral.sh/uv/install.sh | sh
# Or using Homebrew
brew install uv# Using PowerShell
irm https://astral.sh/uv/install.ps1 | iexSet your NoLang API key to the environment variable:
export NOLANG_API_KEY=your_api_key_hereSTDIO mode is designed for local clients such as Claude Desktop.
Add the following to your Claude Desktop configuration file:
~/Library/Application Support/Claude/claude_desktop_config.json
%APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"nolang": {
"command": "uvx",
"args": ["nolang-mcp-stdio"],
"env": {
"NOLANG_API_KEY": "your_api_key_here"
}
}
}
}# Start in STDIO mode
nolang-mcp-stdio
# or
python -m nolang_mcp.runner.run_stdioHTTP mode supports remote access via web and concurrent connections from multiple clients.
# Start in HTTP mode (default port: 7310)
nolang-mcp-http
# or
python -m nolang_mcp.runner.run_http
# Start with custom port
NOLANG_MCP_PORT=8080 nolang-mcp-httpExpose your local MCP HTTP server instantly using Cloudflare Tunnel Quick Tunnel. This generates a temporary trycloudflare.com URL with no DNS or authentication setup required.
# 1) Install Cloudflare Tunnel CLI (macOS)
brew install cloudflared
# 2) Start the MCP server in another terminal (requires API key)
export NOLANG_API_KEY=your_api_key_here
# Optional: change port (default: 7310)
# export NOLANG_MCP_PORT=7310
nolang-mcp-http
# or
# python -m nolang_mcp.runner.run_http
# 3) Start a Quick Tunnel in a new terminal
cloudflared tunnel --url http://localhost:${NOLANG_MCP_PORT:-7310}
# You will get a URL like: https://xxxxx.trycloudflare.comThe issued URL is random and temporary. For longer-term or access-controlled setups, consider a Named Tunnel or Cloudflare Access.
Consumes paid credits. Start video generation using your VideoSetting ID.
Required Parameters:
video_setting_id (string): UUID of VideoSetting (obtainable via list_video_settings)
Optional Parameters (at least one is required):
text (string): Text prompt (for QUERY modes or slideshow_analysis mode)
pdf_path (string): Absolute path to PDF file (for slideshow_* modes)
pptx_path (string): Absolute path to PPTX file (for slideshow_* modes)
audio_path (string): Absolute path to audio file (for audio_speech mode, MP3/WAV/M4A/AAC)
video_path (string): Absolute path to video file (for audio_video mode, MP4)
image_paths (string): Image file paths (comma-separated, for QUERY modes)
Consumes paid credits. Start video generation using an official template Video ID.
Required Parameters:
video_id (string): ID of generated or generating video
Optional Parameters:
Same parameters as generate_video_with_setting are available
Polls until video generation completes and returns the download URL.
Parameters:
video_id (string, required): Video ID of the generation job
max_wait_time (integer, optional): Maximum wait time in seconds (default: 600)
check_interval (integer, optional): Status check interval in seconds (default: 10)
Return a paginated list of videos you have generated.
Parameters:
page (integer, optional): Page number (default: 1)
Return a paginated list of your VideoSettings.
Parameters:
page (integer, optional): Page number (default: 1)
Recommend official templates based on video mode and optional query.
nolang_mcp/server.py: Common MCP server definition and API client
nolang_mcp/runner/run_stdio.py: Entry point for STDIO
nolang_mcp/runner/run_http.py: Entry point for HTTP
MIT License
Consumes paid credits. Start video generation using your VideoSetting ID. Provide text, pdf_path, pptx_path, audio_path, video_path, or image_paths as required.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes |
| Name | Required | Description |
|---|---|---|
| video_id | Yes | Unique identifier for the queued video |
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. It mentions 'Consumes paid credits' which is valuable cost information, but doesn't address other critical behaviors: whether this is an asynchronous operation (implied by the existence of 'wait_video_generation_and_get_download_url'), what permissions are needed, rate limits, error conditions, or what the output contains. For a paid service with complex inputs, this is insufficient.
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 concise with two sentences that each serve distinct purposes: cost warning and input guidance. It's front-loaded with the most important information (paid credits). However, the second sentence could be structured more clearly to separate the required 'video_setting_id' from the optional media inputs.
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 video generation, multiple input types, paid service nature, and existence of an output schema, the description is minimally adequate. It covers cost and input types but misses critical context about the asynchronous nature (implied by sibling tools), error handling, and workflow integration. The output schema existence reduces the need to describe return values, but more operational context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists the available input types (text, pdf_path, pptx_path, audio_path, video_path, image_paths) which provides semantic context beyond the single 'args' parameter shown in the schema. However, it doesn't explain the relationships between these inputs and the 'video_setting_id' or how they interact. With 0% schema description coverage, the description adds significant value but doesn't fully compensate for the coverage gap.
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 states the tool 'Start video generation using your VideoSetting ID', which provides a clear verb ('Start video generation') and resource ('VideoSetting ID'). However, it doesn't distinguish this from its sibling 'generate_video_with_template' - both appear to initiate video generation but with different configuration sources. The purpose is clear but sibling differentiation is lacking.
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 no guidance on when to use this tool versus alternatives. It mentions 'Provide text, pdf_path, pptx_path, audio_path, video_path, or image_paths as required' but doesn't explain which scenarios require which inputs or when to choose this over 'generate_video_with_template'. There's no mention of prerequisites, timing considerations, or workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consumes paid credits. Start video generation using an official template Video ID. Provide text, pdf_path, pptx_path, audio_path, video_path, or image_paths as required.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes |
| Name | Required | Description |
|---|---|---|
| video_id | Yes | Unique identifier for the queued video |
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 mentions 'Consumes paid credits' which is valuable cost information, but doesn't address critical behaviors like whether this is an asynchronous operation (implied by 'wait_video_generation_and_get_download_url' sibling), what permissions are needed, rate limits, or what happens when generation fails. The description is incomplete for a tool that likely involves significant processing.
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 concise with two sentences. The first sentence provides critical cost information upfront, and the second lists input types efficiently. However, the second sentence could be structured more clearly to indicate these are alternative input options rather than all being required simultaneously.
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 this is a complex video generation tool with 1 parameter (though nested with multiple properties), 0% schema description coverage, no annotations, but with an output schema, the description is inadequate. It doesn't explain the relationship between input types and generation modes, doesn't mention the asynchronous nature implied by sibling tools, and leaves too much undefined for proper 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?
The schema description coverage is 0%, so the description must compensate. It lists parameter types ('text, pdf_path, pptx_path, audio_path, video_path, or image_paths') but provides no semantic context about when each is required, what 'modes' exist, or how they interact with the video_id. The description adds minimal value beyond what can be inferred from parameter names alone.
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 states the tool 'Start video generation using an official template Video ID' which provides a verb ('Start video generation') and resource ('template Video ID'), but it's vague about what 'official template' means and doesn't clearly distinguish from sibling tools like 'generate_video_with_setting'. The mention of consuming credits adds context but doesn't clarify the core purpose.
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 no guidance on when to use this tool versus alternatives like 'generate_video_with_setting' or 'recommend_templates'. It lists input types but doesn't explain which modes or scenarios require which inputs, leaving the agent with insufficient context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a paginated list of videos you have generated.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes |
| Name | Required | Description |
|---|---|---|
| page | Yes | Current page number |
| videos | Yes | List of video summaries |
| has_next | Yes | True if there is another page of results |
| total_videos | Yes | Total number of videos matching the criteria |
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 mentions pagination, which is useful, but lacks details on authentication needs, rate limits, error handling, or what 'videos you have generated' specifically entails (e.g., user-specific scope). This leaves significant gaps for a tool with potential data access implications.
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 a single, efficient sentence that is front-loaded with the core purpose. There is no wasted verbiage, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter) and the presence of an output schema (which handles return values), the description is somewhat complete but lacks critical context. It doesn't address usage guidelines or behavioral aspects like authentication, which are important for a tool that lists user-generated videos.
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 compensate, but it adds no parameter information beyond implying pagination. The schema defines a 'page' parameter with a description, but the tool description doesn't explain this or other potential parameters, resulting in minimal added 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?
The description clearly states the action ('Return a paginated list') and resource ('videos you have generated'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'list_video_settings' or 'wait_video_generation_and_get_download_url', which prevents a score of 5.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_video_settings' for settings or 'wait_video_generation_and_get_download_url' for status checking, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a paginated list of your VideoSettings.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes |
| Name | Required | Description |
|---|---|---|
| page | Yes | Current page number |
| has_next | Yes | True if there is another page of results |
| settings | Yes | List of video setting summaries |
| total_settings | Yes | Total number of video settings |
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. It mentions pagination which is useful, but doesn't describe authentication requirements, rate limits, error conditions, or what happens when no VideoSettings exist. For a listing 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality. It's appropriately sized for a simple listing tool and front-loads the essential information. There's no wasted verbiage or unnecessary elaboration.
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 this is a simple listing tool with 1 parameter and an output schema exists (so return values are documented elsewhere), the description is minimally adequate. However, with no annotations and 0% schema description coverage, it should provide more context about authentication, error handling, and what VideoSettings represent to be truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'paginated list' which implies the page parameter exists, but doesn't explain the parameter's purpose, format, or constraints. This adds minimal value beyond what can be inferred from the tool name and schema structure.
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 states the tool returns a paginated list of VideoSettings, which is a clear verb+resource combination. However, it doesn't distinguish this from sibling tools like 'list_generated_videos' - both list operations but for different resources. The purpose is understandable but lacks sibling differentiation.
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 no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this tool is appropriate versus other listing tools, or any context about what VideoSettings are. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend official templates based on video mode and optional query.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes |
| Name | Required | Description |
|---|---|---|
| templates | Yes | List of recommended template summaries |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but reveals minimal behavioral traits. It mentions 'recommend' but doesn't disclose whether this is a read-only operation, requires authentication, has rate limits, or what the recommendation output entails. The description doesn't contradict annotations (none exist), but offers inadequate behavioral context.
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 a single, efficient sentence that front-loads the core purpose. Every word earns its place with no redundancy or unnecessary elaboration, making it easy to parse quickly.
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 0% schema coverage and no annotations, the description is minimal but covers the primary use case. An output schema exists, so return values needn't be explained. However, for a tool with one parameter object containing three fields, more detail on parameter interactions or behavioral context would improve completeness.
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 compensate. It mentions 'video mode' and 'optional query', aligning with the schema's required 'video_mode' and optional 'query' parameters, but omits 'is_mobile_format'. The description adds basic meaning but doesn't fully compensate for the coverage gap, especially for the boolean parameter.
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 action ('Recommend') and resource ('official templates'), specifying the primary input ('video mode') and optional input ('query'). It distinguishes from siblings by focusing on template recommendation rather than video generation or listing, though it doesn't explicitly contrast with them.
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 usage when template recommendations are needed based on video mode, but provides no explicit guidance on when to use this tool versus alternatives like 'generate_video_with_template' or 'list_video_settings'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Polls until video generation completes and returns the download URL.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes |
| Name | Required | Description |
|---|---|---|
| status | Yes | Current status of the video |
| video_id | Yes | Unique identifier for the video |
| download_url | No | Signed URL for the finished MP4 file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions polling behavior and returns a download URL, but lacks critical details: it doesn't specify what happens on timeout (e.g., error handling), whether it's idempotent or safe to retry, potential rate limits, or authentication requirements. For a polling tool with zero annotation coverage, this is a significant gap in transparency.
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 a single, efficient sentence that front-loads the key action and outcome: 'Polls until video generation completes and returns the download URL.' It wastes no words and directly communicates the tool's core functionality, making it easy for an agent to parse quickly.
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 (a polling tool with potential timeouts and intervals), no annotations, and an output schema (which likely handles return values), the description is minimally adequate. It states the purpose and outcome but lacks details on error conditions, dependencies on sibling tools, or behavioral nuances. The presence of an output schema reduces the need to explain returns, but more context is needed for safe and effective use.
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%, meaning the input schema provides no descriptions for parameters. The description doesn't add any parameter-specific information beyond implying a 'video_id' is needed for polling. It doesn't explain the semantics of 'max_wait_time' or 'check_interval', leaving these critical polling parameters undocumented. However, since there's only one top-level parameter ('args'), the baseline is slightly higher, but the description fails to compensate for the low 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: 'Polls until video generation completes and returns the download URL.' It specifies the action (polling for completion) and the resource (video generation), and indicates the outcome (returning a download URL). However, it doesn't explicitly differentiate from sibling tools like 'list_generated_videos' or 'generate_video_with_setting', which could help an agent understand when to use this specific polling tool versus others.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that a video generation job must already be started, likely via sibling tools like 'generate_video_with_setting'), nor does it specify scenarios where polling is necessary versus checking status with other tools. This lack of context could lead to misuse or confusion for an AI agent.
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. Dates show when Glama detected each change.
v1.0.0generate_video_with_setting1 field changedInput schema / $defsAdded value: +{
+ "VideoGenerationFromSettingArgs": {
+ "description": "Arguments for generating video from video setting ID.",
+ "properties": {
+ "audio_path": {
+ "default": "",
+ "description": "Audio file path for audio_speech mode",
+ "examples": [
+ "/path/to/audio.mp3"
+ ],
+ "title": "Audio Path",
+ "type": "string"
+ },
+ "image_paths": {
+ "default": "",
+ "description": "Comma-separated image file paths for query modes",
+ "examples": [
+ "image1.jpg,image2.png,image3.jpeg"
+ ],
+ "title": "Image Paths",
+ "type": "string"
+ },
+ "pdf_path": {
+ "default": "",
+ "description": "PDF file path for slideshow modes",
+ "examples": [
+ "/path/to/presentation.pdf"
+ ],
+ "title": "Pdf Path",
+ "type": "string"
+ },
+ "pptx_path": {
+ "default": "",
+ "description": "PPTX file path for slideshow modes",
+ "examples": [
+ "/path/to/presentation.pptx"
+ ],
+ "title": "Pptx Path",
+ "type": "string"
+ },
+ "text": {
+ "default": "",
+ "description": "Input text for query modes or slideshow_analysis mode",
+ "title": "Text",
+ "type": "string"
+ },
+ "video_path": {
+ "default": "",
+ "description": "Video file path for audio_video mode",
+ "examples": [
+ "/path/to/video.mp4"
+ ],
+ "title": "Video Path",
+ "type": "string"
+ },
+ "video_setting_id": {
+ "description": "UUID of VideoSetting to use for generation",
+ "format": "uuid",
+ "title": "Video Setting Id",
+ "type": "string"
+ }
+ },
+ "required": [
+ "video_setting_id"
+ ],
+ "title": "VideoGenerationFromSettingArgs",
+ "type": "object"
+ }
+}generate_video_with_template1 field changedInput schema / $defsAdded value: +{
+ "VideoGenerationFromVideoArgs": {
+ "description": "Arguments for generating video from existing video ID.",
+ "properties": {
+ "audio_path": {
+ "default": "",
+ "description": "Audio file path for audio_speech mode",
+ "examples": [
+ "/path/to/audio.mp3"
+ ],
+ "title": "Audio Path",
+ "type": "string"
+ },
+ "image_paths": {
+ "default": "",
+ "description": "Comma-separated image file paths for query modes",
+ "examples": [
+ "image1.jpg,image2.png,image3.jpeg"
+ ],
+ "title": "Image Paths",
+ "type": "string"
+ },
+ "pdf_path": {
+ "default": "",
+ "description": "PDF file path for slideshow modes",
+ "examples": [
+ "/path/to/presentation.pdf"
+ ],
+ "title": "Pdf Path",
+ "type": "string"
+ },
+ "pptx_path": {
+ "default": "",
+ "description": "PPTX file path for slideshow modes",
+ "examples": [
+ "/path/to/presentation.pptx"
+ ],
+ "title": "Pptx Path",
+ "type": "string"
+ },
+ "text": {
+ "default": "",
+ "description": "Input text for query modes or slideshow_analysis mode",
+ "title": "Text",
+ "type": "string"
+ },
+ "video_id": {
+ "description": "ID of existing video to use as template",
+ "format": "uuid",
+ "title": "Video Id",
+ "type": "string"
+ },
+ "video_path": {
+ "default": "",
+ "description": "Video file path for audio_video mode",
+ "examples": [
+ "/path/to/video.mp4"
+ ],
+ "title": "Video Path",
+ "type": "string"
+ }
+ },
+ "required": [
+ "video_id"
+ ],
+ "title": "VideoGenerationFromVideoArgs",
+ "type": "object"
+ }
+}list_generated_videos1 field changedInput schema / $defsAdded value: +{
+ "ListVideosArgs": {
+ "description": "Arguments for listing videos.",
+ "properties": {
+ "page": {
+ "default": 1,
+ "description": "Page number to retrieve",
+ "minimum": 1,
+ "title": "Page",
+ "type": "integer"
+ }
+ },
+ "title": "ListVideosArgs",
+ "type": "object"
+ }
+}list_video_settings1 field changedInput schema / $defsAdded value: +{
+ "ListVideoSettingsArgs": {
+ "description": "Arguments for listing video settings.",
+ "properties": {
+ "page": {
+ "default": 1,
+ "description": "Page number to retrieve",
+ "minimum": 1,
+ "title": "Page",
+ "type": "integer"
+ }
+ },
+ "title": "ListVideoSettingsArgs",
+ "type": "object"
+ }
+}recommend_templates1 field changedInput schema / $defsAdded value: +{
+ "TemplateRecommendationArgs": {
+ "description": "Arguments for getting template recommendations.",
+ "properties": {
+ "is_mobile_format": {
+ "default": false,
+ "description": "Set to True to target mobile format templates",
+ "title": "Is Mobile Format",
+ "type": "boolean"
+ },
+ "query": {
+ "default": "",
+ "description": "User input text for template recommendations",
+ "title": "Query",
+ "type": "string"
+ },
+ "video_mode": {
+ "$ref": "#/$defs/VideoModeEnum",
+ "description": "Target mode for template recommendations"
+ }
+ },
+ "required": [
+ "video_mode"
+ ],
+ "title": "TemplateRecommendationArgs",
+ "type": "object"
+ },
+ "VideoModeEnum": {
+ "description": "Enum representing video generation modes available in NoLang.",
+ "enum": [
+ "query_simple",
+ "query_script",
+ "slideshow_presentation",
+ "slideshow_summary",
+ "slideshow_analysis",
+ "audio_speech",
+ "audio_video"
+ ],
+ "title": "VideoModeEnum",
+ "type": "string"
+ }
+}wait_video_generation_and_get_download_url1 field changedInput schema / $defsAdded value: +{
+ "VideoWaitArgs": {
+ "description": "Arguments for waiting for video generation completion.",
+ "properties": {
+ "check_interval": {
+ "default": 10,
+ "description": "Interval (seconds) to check status",
+ "maximum": 60,
+ "minimum": 1,
+ "title": "Check Interval",
+ "type": "integer"
+ },
+ "max_wait_time": {
+ "default": 600,
+ "description": "Maximum seconds to wait for generation completion",
+ "maximum": 3600,
+ "minimum": 1,
+ "title": "Max Wait Time",
+ "type": "integer"
+ },
+ "video_id": {
+ "description": "Video ID of the generation job",
+ "format": "uuid",
+ "title": "Video Id",
+ "type": "string"
+ }
+ },
+ "required": [
+ "video_id"
+ ],
+ "title": "VideoWaitArgs",
+ "type": "object"
+ }
+}generate_video_with_settinggenerate_video_with_templatelist_generated_videoslist_video_settingsrecommend_templateswait_video_generation_and_get_download_urlThe tools have clear distinctions in purpose, but there is some overlap between 'generate_video_with_setting' and 'generate_video_with_template' as both handle video generation with similar parameters, which could cause confusion. The other tools (list_generated_videos, list_video_settings, recommend_templates, wait_video_generation_and_get_download_url) are distinct and well-defined.
All tool names follow a consistent snake_case pattern with clear verb_noun structures (e.g., generate_video_with_setting, list_generated_videos). The naming is predictable and readable throughout the set, with no deviations in style.
With 6 tools, the count is well-scoped for a video generation server, covering key operations like generation, listing, and monitoring. Each tool appears to earn its place without being overly sparse or bloated.
The tool set covers core video generation workflows, including creation (with settings/templates), listing, and status monitoring. A minor gap exists in lacking explicit update or delete operations for videos or settings, but agents can likely work around this for basic usage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Plan, compare, price, generate, and recover AI video from compatible MCP clients.
AI image, video, voice and music generation over MCP, routed to Veo 3.1, Seedance 2.0 and more.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
MCP server for Google Veo AI video generation
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/team-tissis/nolang-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
