NoLang MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 2.9/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries 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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose3/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose3/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose3/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It 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.
Conciseness5/5
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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![nolang-mcp MCP server](https://glama.ai/mcp/servers/team-tissis/nolang-mcp/badges/card.svg)](https://glama.ai/mcp/servers/team-tissis/nolang-mcp)

Score Badge

Copy to your README.md:

[![nolang-mcp MCP server](https://glama.ai/mcp/servers/team-tissis/nolang-mcp/badges/score.svg)](https://glama.ai/mcp/servers/team-tissis/nolang-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/team-tissis/nolang-mcp'

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