jimeng-web-mcp

Server Quality Checklist

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

Latest release: v2.1.2
Disambiguation4/5
Each tool serves a distinct purpose: ping checks connectivity, image and image_batch handle single vs. series generation, query fetches task status, and video, video_frame, video_multi, and video_mix cover different video generation modes. The video tools could cause some confusion since they all generate videos, but their input differences are clearly described.
Naming Consistency3/5
Video tools share a consistent 'video' prefix, and image tools have a clear 'image' base. However, ping and query are verbs while image and video are nouns, and video_mix uses a verb suffix, causing a mix of conventions that is still readable but not fully predictable.
Tool Count5/5
With 8 tools covering both image and video generation plus a status query, the server is well-scoped. Each tool has a distinct role, and the count is within the ideal 3-15 range, neither too sparse nor overloaded.
Completeness4/5
The core lifecycle of generation and result retrieval is covered for both images and videos. Minor gaps exist, such as no explicit tool for image editing (e.g., inpainting) or listing available models, but these are non-essential for a basic generation workflow.
Average 3/5 across 8 of 8 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for disclosing behavioral traits. It does not mention whether the tool generates video, operates asynchronously, requires specific input formats, or what side effects or return values to expect. The single phrase reveals nothing about actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase, but it is under-specified rather than concise. It does not provide essential information and could be expanded meaningfully without adding waste, so it does not earn high marks for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema, no annotations) the description is grossly incomplete. It fails to explain the core operation, usage context, or expected result, making it inadequate for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both required and optional parameters have individual descriptions. The tool description adds no extra meaning beyond the schema, which already adequately explains each parameter, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description '首尾帧控制视频' hints at using first/last frames to control video, but lacks a specific verb (e.g., generate, edit) and does not distinguish it from sibling tools like 'video' or 'video_multi'. It is a vague purpose statement, not a clear action-resource description.
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?
No guidance is provided on when to use this tool versus alternatives such as 'video', 'video_multi', or 'video_mix'. The description gives no context for scenarios where first/last frame conditioning is appropriate, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits, but it only restates the purpose. It does not mention side effects (though likely none), return behavior, success/failure indication, or whether the operation is read-only. This is functionally a tautology of the tool name 'ping'.
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 sentence with no wasted words. It front-loads the verb and purpose, making it immediately clear what the tool does. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description is too sparse. There is no output schema, so the description should explain what the tool returns (e.g., round-trip time, success status). It also omits any usage examples or preconditions. The description lacks enough context to use the tool effectively, especially given the ambiguous parameter.
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?
Although schema coverage is 100%, the parameter description '姓名' (name) is generic and misaligned with the tool's purpose of testing a server connection. The description does not clarify what 'name' refers to (e.g., server hostname, connection identifier). This semantic gap makes the parameter ambiguous and the description fails to compensate.
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 tests a server connection, which is a specific action on a specific resource. It distinguishes itself from sibling tools like image or video by indicating a network connectivity check. However, it does not explicitly detail what kind of test (e.g., ICMP ping) or the exact resource being tested.
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?
No guidance is given about when to use this tool or how it compares to alternatives. The description simply states what it does but offers no context for selection, such as implying a health check or network troubleshooting scenario. Sibling tools are unrelated, so no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fails to disclose key behavioral traits such as async processing (the 'async' parameter defaults to true), potential long execution times, or response format (e.g., task ID). The one-line description adds no depth beyond the basic operation.
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 short phrase, extremely concise and front-loaded. It wastes no words, though it might benefit from more detail. Conciseness is high, but it borders on under-specification.
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?
With 7 parameters, no output schema, and no annotations, the description is insufficiently complete. It lacks context on how to handle asynchronous mode, how to retrieve generated video results, and potential constraints. The one-line description is inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have descriptions in the schema (100% coverage), so the schema already documents parameters fully. The description adds no additional parameter meaning, making the baseline 3 appropriate.
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 '纯文字生成视频' (generate video from pure text) clearly states the tool's function with a specific verb and resource, and differentiates from siblings like video_multi or video_mix which imply different use cases. However, it doesn't explicitly name alternatives, so it's clear but not fully distinguishing.
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 such as video_multi or video_mix. It is a bare statement of function without context, prerequisites, or exclusions.
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 only states a high-level purpose and fails to mention async behavior, model selection, potential side effects, or output format. For a video generation tool, this is a significant transparency gap.
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, short sentence with no redundancy or filler. It is front-loaded and easy to parse. It is appropriately concise, though it sacrifices detail for brevity, which is a minor drawback but not a structural issue.
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?
With 8 parameters and no output schema, the description is insufficient for complete contextual understanding. It does not mention return values, how to handle async mode, or required prompt syntax. The description relies entirely on the schema, which is rich but still leaves the agent without high-level context about the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters, so the baseline is 3. The description adds minimal semantic context by referencing 'multiple images' (referenceImages) and 'one scene' (prompt), but it does not explain the [图N] syntax or other parameter constraints. It stays at baseline.
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 function: merging subjects from multiple images into one scene. This is a specific verb+resource combination that conveys the core purpose. However, it does not differentiate from sibling tools like video_multi, which likely has a similar function, so it loses one point.
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 such as video, video_multi, or video_frame. There are no exclusions, prerequisites, or contextual examples, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the core function without disclosing behavioral traits such as async mode, model selection, side effects, return format, or error handling. This leaves the agent with critical safety and 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, concise sentence that is front-loaded and immediately communicates the tool's purpose without any fluff. While it is very brief, it is appropriately concise and free of unnecessary detail.
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 the tool's complexity (9 parameters, no annotations, no output schema), the one-sentence description is insufficient to understand invocation context, return values, or behavioral expectations. The description needs more context to be 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?
The input schema provides descriptions for all 9 parameters, including defaults and enums, achieving 100% coverage. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '生成单张图像' clearly states the tool's function: generate a single image. It uses a specific verb and resource, and the word 'single' distinguishes it from sibling tool 'image_batch' which handles multiple images.
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 for generating a single image but does not explicitly state when to use it versus alternatives like image_batch or video tools. There is no mention of exclusions or preferred contexts, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the tool queries status and results, but does not disclose return format, polling behavior, or that results might be pending. This gives the agent minimal behavioral insight beyond the literal function.
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?
One short sentence that is front-loaded with the action and resource. There is no wasted wording, and the structure is efficient for the amount of information provided.
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?
The tool is simple (1 param, no output schema), but the description lacks essential context such as how it relates to sibling generation tools, how to handle pending results, and any assumptions about the historyId (e.g., from a prior submission). These gaps leave the agent under-informed for correct usage.
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 coverage is 100%, with historyId described as '任务ID' (task ID) and a pattern. The tool description adds no further parameter meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询任务状态和结果' (Query task status and results) clearly states a specific verb and resource. The sibling tools are generation tools (image, video, etc.), so this tool is distinctly a retrieval/status-check operation.
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?
No explicit guidance on when to use this tool versus alternatives. The description does not mention that it should be used to poll after submitting a task via the generation tools, nor does it state any exclusions or conditions. Usage is only implied by the sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the burden of behavioral disclosure. It mentions 'highly relevant' but does not reveal asynchronous behavior, return format, or any side effects. The schema already documents parameters, so the description adds only a quality trait.
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, concise sentence with illustrative examples, placing the core purpose upfront. It is efficient but perhaps too brief to fully convey operational expectations.
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?
The tool has 10 parameters and no output schema, yet the description never clarifies what the tool returns, how to handle async results, or any constraints on batch generation. This leaves an agent without critical operational context for a complex generation task.
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 coverage is 100% with descriptions for all parameters, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a series of highly relevant continuous images, with concrete examples like room series, storyboards, and product angles. This distinguishes it from the sibling 'image' tool, which likely handles single images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific use cases (room series, storyboards, picture books, product multi-angle) that indicate when this tool is appropriate. However, it does not explicitly contrast with alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core behavior (generating smooth transitions between keyframes) but does not mention other behavioral aspects such as asynchronous processing, duration limits, or that the last frame's prompt is ignored (these are only in the schema). With no annotations, the description carries the burden but provides minimal 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, concise sentence that immediately states the tool's purpose. It is front-loaded and contains no filler, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description is quite minimal. While the schema is extensive, the description lacks information about the expected output, how to retrieve results, or how this tool fits with siblings like video_frame. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of parameter descriptions with detailed explanations, examples, and constraints. The description does not add any parameter semantics beyond what the schema already contains, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates keyframe animation videos by taking 2-10 keyframe images and producing smooth transitions. This identifies the specific function and distinguishes it from sibling tools like video_mix or video_frame.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you have 2-10 keyframe images) but does not provide explicit exclusions or mention alternative tools. It gives clear context but lacks explicit alternatives.
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:

[![jimeng-web-mcp MCP server](https://glama.ai/mcp/servers/LupinLin1/jimeng-web-mcp/badges/card.svg)](https://glama.ai/mcp/servers/LupinLin1/jimeng-web-mcp)

Score Badge

Copy to your README.md:

[![jimeng-web-mcp MCP server](https://glama.ai/mcp/servers/LupinLin1/jimeng-web-mcp/badges/score.svg)](https://glama.ai/mcp/servers/LupinLin1/jimeng-web-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/LupinLin1/jimeng-web-mcp'

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