Allows the MathMind MCP server to be used as a plugin in Coze, enabling AI agents to perform video and audio creation and editing tasks through natural language commands.
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., "@MathMind MCP Server Create a video from these three images with upbeat background music"
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.
MathMind MCP Server提供了一个基于MCP协议的音视频创作工具箱。用户在任意支持MCP协议的工具中添加MathMind MCP服务，即可实现用自然语言描述进行音视频的创作与剪辑。
序号 | 工具中文名称 | 工具英文名称 | 工具介绍（中文） |
1 | 多张图片合成视频 | imgs2video | 将一张或多张图片合成一个视频，支持添加背景音乐、配音。 |
2 | 多个视频合成视频 | video2video | 将一个或多段视频素材合成一个视频，支持上传背景音乐（非必填）、配音（非必填）合成新的视频。支持单独上传首、尾视频，固定视频首尾。支持设置封面图、支持配音音量控制、支持背景音乐自定义音量。 |
3 | 视频文案提取 | video2txt | 实时提取视频中的文案，用户输入视频链接即可。建议上传5分钟以下的视频 |
4 | 视频字幕识别 | subtitleDynamic | 上传视频，即可识别字幕并输出最终带字幕的视频。字幕支持设置字体与位置等。支持传入text文本。 |
5 | 视频字幕识别任务查询 | taskFetch2 | 输入工具subtitleDynamic输出的traceId即可获得添加了字幕以后的视频地址 |
6 | 视频片段获取 | videoCutRandom | 输入视频链接，输入截取的起始和结束位置，即可截取视频片段 |
7 | 图生视频 | imageGenVideo | 上传图片，输入提示词，即可生成视频，模型为VIDU。支持实时生成和异步生成。当异步生成，则需要调用查询工具：videoTaskFetch实时直接生成URL；异步先只给traceId，用户需要调用videoTaskFetch |
8 | 图片画中画 | imgPip | 输入视频，为视频添加图片，如logo、视频提及内容等图片素材。支持自定义素材的宽高、入场和出场的时间、动画以及显示的位置，非必填，取默认值。 |
9 | 画中画任务查询 | cutTaskFetch | 上述imgPip只会返回ReqId，此时需要使用任务查询工具主动查询结果 |
在MathMind开放平台注册并获取apikey，立即前往
Related MCP server: ffmpeg-mcp
前往 Windsurf > Settings > Cascade > Add Server > Add custom server 添加配置：
{
"mcpServers": {
"mcp-server-mathmind": {
"url": "https://mcp.mathmind.cn/sse?x-api-key=<YOUR_API_KEY>"
}
}
}前往 Cursor -> Preferences -> Cursor Settings -> MCP -> Add new global MCP Server 添加配置:
{
"mcpServers": {
"mcp-server-mathmind": {
"url": "https://mcp.mathmind.cn/sse?x-api-key=<YOUR_API_KEY>"
}
}
}前往 通义灵码 -> MCP工具 -> MCP服务 -> 通过配置文件添加新增MCP服务 -> lingma_mcp.json添加以下配置:
{
"mcpServers": {
"mcp-server-mathmind": {
"url": "https://mcp.mathmind.cn/sse?x-api-key=<YOUR_API_KEY>"
}
}
}邮件联系：ai@mathmind.cn
技术支持：
官网入口：https://mathmind.cn/
免费教程：https://mathmind.feishu.cn/wiki/OtIZwYuxbi1ErQkyovmc07HmnOh
付费空间：https://mathmind.feishu.cn/wiki/GvW8wyv2VithdnkNsVmcqhVNnYb
B站视频讲解：https://space.bilibili.com/87911991/channel/seriesdetail?sid=4634704
帮助中心：https://mathmind.feishu.cn/docx/Q6eodjvPLoq7yDxZaHOcfnFrntg
Coze折扣：https://mathmind.feishu.cn/wiki/D9qSwIoaEixfqmkDupuceF62nFg
基于传入的单张图片链接，将图片里面的内容通过图生视频的模型生成可以动起来的视频 将接口返回的JSON内容输出即可,其中 traceId 任务跟踪id 注意：只需要返回接口 traceId 内容，无需主动调用任务查询接口
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | No | 生成视频的文本提示词（非必填） | |
| imageUrl | Yes | 图片链接地址 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavior disclosure. It reveals the important async nature of the tool by instructing the caller to return the returned JSON and only the traceId, and to avoid querying the task status. This is valuable behavioral context beyond the schema, though failure modes and timing are not discussed.
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 short and front-loaded with the core operation, followed by return-format guidance. There is minor redundancy between 'return the API JSON' and 'only return the traceId', but overall every sentence serves a purpose.
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?
Even though there is no output schema, the description tells the caller exactly what to do with the response and that task polling is unnecessary. This is adequate for a simple async image-to-video tool, though it could mention expected response shape or failure behavior for full 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 100%, so the schema already documents both imageUrl and prompt. The description adds no new parameter-level detail beyond restating the image URL concept, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: take a single image URL and generate an animatable video via an image-to-video model. It also implicitly distinguishes itself from siblings like imgs2video by emphasizing a single image link, though it does not explicitly name alternatives.
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 gives explicit context that the tool should be used for a single image and adds a clear exclusion: do not proactively call the task query interface, only return the traceId from the API response. It does not explicitly contrast with sibling tools like video2video or imgs2video, so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
视频中添加画中画，通过用户提供的在线图片链接将图片以画中画的方式插入到视频中进行合成。比如添加logo等 将接口返回的JSON内容输出即可,其中 traceId 表示任务跟踪id。 注意：只需要返回接口内容，无需主动调用任务查询接口
| Name | Required | Description | Default |
|---|---|---|---|
| mXY | No | 素材坐标（可选、非必填） | |
| mUrl | Yes | 图片素材链接地址 | |
| Width | No | 资源在输出视频画布上的宽度，单位为 pixel。（可选、非必填） | |
| Height | No | 资源在输出视频画布上的高度，单位为 pixel。（可选、非必填） | |
| videoUrl | Yes | 视频链接地址 | |
| mDuration | No | 素材持续时间（可选、非必填） | |
| mEntrAnimo | No | 入场动画id（可选、非必填） | |
| mExitAnimo | No | 出场动画id（可选、非必填） | |
| mStartTime | No | 素材出现时间（可选、非必填） | |
| mEntrAniDuration | No | 入场动画持续时间（可选、非必填） | |
| mExitAniDuration | No | 出场动画持续时间（可选、非必填） |
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 discloses that the response is JSON, that traceId is a tracking ID, and that the agent should not invoke task query APIs—meaningful behavioral guidance. It does not state whether the task is asynchronous, how failures are surfaced, or when the final result will be available, but the traceId reference implies task-based execution.
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 main purpose is front-loaded in the first sentence, and the note about not calling the task query is valuable and placed at the end. There is slight redundancy between '将接口返回的JSON内容输出即可' and '只需要返回接口内容', which keeps it from being perfectly concise.
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 11 parameters, no output schema, and no annotations, the description covers the essential invocation guidance: what the tool does, what inputs to provide, and what to return. It omits details on how optional parameters like mXY, Width, Height, and animation durations affect placement and timing, and it does not describe the response structure beyond traceId, but the full schema coverage compensates for many of these gaps.
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 even without additional parameter explanation. The description adds no new parameter-level meaning beyond restating that mUrl is an online image link and videoUrl is a video link. Since the schema already documents all 11 parameters, the description has little to compensate for.
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 a specific verb and resource: adding a picture-in-picture overlay image into a video using a user-provided online image link, with the logo example clarifying typical use. This clearly distinguishes it from sibling tools like imgs2video, video2video, and videoCutRandom, which perform different video operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear invocation context: use when inserting an image as PiP into a video. It also provides an explicit exclusion: do not call the task query interface, and instead output the returned JSON. It does not explicitly name alternatives among the other sibling video tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据用户输入的req_id来查询 视频中添加画中画功能的任务结果。 将接口返回的JSON内容输出即可
| Name | Required | Description | Default |
|---|---|---|---|
| req_id | Yes | imgPip 视频画中画任务返回的req_id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the output behavior (output the JSON returned by the interface) and implies a read-only query operation. It does not explain what happens if the task is still running, fails, or the req_id is invalid, leaving some behavioral ambiguity.
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?
Two short sentences with no filler. The first sentence states the core purpose and input, and the second gives a direct output instruction. Every clause earns its place.
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?
For a low-complexity tool with a single required parameter and no output schema, the description covers the essential information: what to query, which input to use, and what to return. It is slightly incomplete because it does not mention task lifecycle states or alternative tools, but it is sufficiently actionable.
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 schema already explains that req_id is the ID returned by the imgPip PIP task. The description only repeats this relationship without adding format, syntax, or additional meaning, so the baseline of 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 a specific verb (查询/query) and resource (the result of adding picture-in-picture to a video), and ties it to the req_id input. It does not explicitly distinguish this from the similar sibling taskFetchByTraceID, so it stops short of a 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 implies the usage context: when a user provides a req_id, query the corresponding task result. However, it does not state when to use this tool instead of alternatives like taskFetchByTraceID, nor does it mention any exclusions or prerequisites beyond having the req_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
将一张或多张图片合成一个静态的视频，支持添加背景音乐、配音； 视频时长以配音时长为准，当配音时长小于背景音乐时长时， 会对背景音乐进行裁剪；当配音时长大于背景音乐时，会将背景音乐复制 返回的内容是一个JSON结构，其中 traceId 代表任务查询id，videoUrl 代表生成视频地址，downloadUrl代表下载链接
| Name | Required | Description | Default |
|---|---|---|---|
| bgmUrl | No | 背景音乐URL (可选，非必填) | |
| voiceUrl | No | 配音URL (可选,非必填) | |
| bgmVolume | No | 背景音乐音量(0~100),(可选，非必填) | |
| imageUrls | Yes | 图片URL列表 | |
| coverImageUrl | No | 封面图片链接 (可选,非必填) | |
| coverImageDuration | No | 封面图片展示时长(秒) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the tool returns a JSON with traceId, videoUrl, and downloadUrl, implies an asynchronous task workflow, and explains BGM trimming/looping based on voiceover duration. It does not describe behavior when voiceUrl is absent, but the core behaviors are covered.
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 compact and front-loaded with the purpose, followed by duration rules and return structure. It is slightly run-on in formatting, but each sentence provides meaningful information with no filler.
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?
The return structure is described despite the lack of an output schema, which is good. However, it does not specify what happens when there is no voiceover or no BGM, and it does not explicitly mention polling with taskFetchByTraceID even though traceId strongly implies that. These gaps make it adequate but not fully 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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the relationship between voiceUrl and bgmUrl durations, including trimming and copying behavior. This cross-parameter semantic is genuinely useful to an agent.
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 core action: combining one or more images into a static video with optional background music and voiceover. The verb and resource are specific, but it does not explicitly differentiate itself from sibling tools like imageGenVideo, so it loses the top point.
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 first sentence implies the use case: when you want to turn images into a video. However, there is no explicit guidance about when to choose this tool over alternatives like imageGenVideo or video2video, and no exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据输入的视频地址,给视频添加字幕。如果原视频没有字幕，本接口可以自动识别视频中音频文字内容（无需调用其他接口提取视频中的文字内容），并将输出添加到视频上，形成带字幕的视频。 如果用户同时输入了字幕文本，以提供的文本作为参考，从而提升字幕文本的准确性，形成带字幕的视频。 字幕支持设置字体与位置等。支持传入text文本。 返回的内容是一个JSON结构，其中 taskID 代表任务查询id,traceId 任务跟踪id 注意：只需要返回接口内容，无需主动调用任务查询接口
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | 字幕文本（可选、非必填） | |
| marginV | No | 垂直边距（可选、非必填） | |
| fontSize | No | 字体大小（可选、非必填） | |
| videoUrl | Yes | 需要转换为字幕的视频URL | |
| isFontAuto | No | 是否自动调整字体大小，1自适应，0不自适应（可选、非必填） | |
| isFontBold | No | 是否加粗，1为加粗，0为不加粗，1自适应，0不自适应（可选、非必填） | |
| selectFont | No | 选择字体编码，从1开始（可选、非必填） | |
| textBgColor | No | 字幕背景颜色（可选、非必填） | |
| primaryColor | No | 字体颜色（可选、非必填） | |
| textStrokeColor | No | 描边颜色（可选、非必填） | |
| textStrokeWidth | No | 描边宽度（可选、非必填） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses automatic audio-to-subtitle recognition, the returned JSON structure with taskID and traceId, and instructs the agent not to call the task query interface. It does not explicitly state that processing is asynchronous, but the task IDs strongly imply it.
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 reasonably brief and front-loads the main purpose, but it contains redundancy: '形成带字幕的视频' appears twice, and the support for text input is restated after being implied earlier. A tighter structure would improve clarity.
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 has 11 parameters and no output schema, the description does a solid job by naming the return fields and instructing the agent not to follow up with the query interface. It does not fully describe async completion behavior or style parameter constraints, but the schema covers the parameter-level details.
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?
All 11 parameters already have schema descriptions, so the baseline is 3. The description adds useful functional context, such as text being a reference to improve accuracy and that font/position settings are supported, but it does not clarify formats, units, or allowed values 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?
The description clearly states the core function: add subtitles to a video given a video URL. It also distinguishes itself from sibling tools by explicitly saying no other API is needed to extract speech from the audio when the original video has no subtitles.
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 gives concrete conditions for the two main usage modes: auto speech recognition when no subtitles exist, and using user-provided text as a reference when it is supplied. It also warns not to call an external text-extraction interface, though it does not name alternatives explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据用户已经提交过的任务 traceId 查询提交的任务结果
| Name | Required | Description | Default |
|---|---|---|---|
| traceId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It conveys that the operation is a read-only lookup scoped to tasks '已经提交过' (already submitted), which is useful, but it does not disclose return structure, possible errors, latency, or whether the result is complete or partial.
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 entire description is one focused sentence with no filler. The action, resource, and key parameter are all mentioned in a front-loaded manner.
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?
The tool has no output schema, yet the description does not explain what the returned 'task result' contains. It also lacks usage conditions and doesn't clarify the relationship with imgPipTaskFetchbyReqID, so an agent is missing important context for calling it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and traceId has no description beyond its title. The description does add meaning by identifying traceId as the identifier of a user-submitted task, but it does not explain the traceId format, how to obtain it, or why the schema marks it as not required.
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 a clear action and resource: '查询提交的任务结果' (query submitted task result) keyed by traceId. This distinguishes it from generation tools like imgs2video, but it doesn't explicitly contrast with the sibling imgPipTaskFetchbyReqID, which appears to be a similar fetch-by-request-ID 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?
No guidance is given on when to use this tool versus alternatives, especially imgPipTaskFetchbyReqID. The description only says it queries by traceId; it never states when a traceId is preferred over a reqID or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
提取用户提供的视频链接地址对应视频中的文案，用户输入视频链接即可。建议上传5分钟以下的视频.
| Name | Required | Description | Default |
|---|---|---|---|
| videoUrl | No | 视频链接地址 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full behavioral disclosure responsibility. It reveals that the tool is link-based and includes a duration recommendation, but it does not describe output format, failure behavior, or what happens for videos longer than 5 minutes.
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?
Two short sentences with no filler. The core action is front-loaded, and the length recommendation is the only extra but relevant detail.
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?
For a one-parameter tool this is nearly sufficient, but the absence of an output schema and annotations means the agent is not explicitly told what result to expect, such as extracted transcript text or a downloadable file. The handling of videos over 5 minutes is also left unclear.
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 clarifies that the sole parameter is a user-provided video link and reiterates that no other input is needed, adding meaning beyond the bare property name 'videoUrl'. It stops short of specifying URL formats or access requirements.
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 a specific verb ('提取') and resource ('视频中的文案') and clearly tells the user to input a video link. It differentiates the tool from most siblings like video2video or imageGenVideo, though it does not explicitly name alternatives such as subtitleDynamic.
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?
It provides clear usage context: the user supplies a video link and the recommended video length is under 5 minutes. However, it does not explain when to choose this tool over subtitleDynamic or other text/video-related siblings, nor does it state explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通过视频素材合成新的视频,将一个或多段视频素材合成一个视频，支持上传背景音乐（非必填）、配音（非必填）合成新的视频。 支持单独上传首、尾视频，固定视频首尾。支持设置封面图、支持配音音量控制、支持背景音乐自定义音量。
| Name | Required | Description | Default |
|---|---|---|---|
| bgmUrl | No | 背景音乐URL(可选,非必填) | |
| voiceUrl | No | 配音URL(可选,非必填) | |
| bgmVolume | No | 背景音乐音量(可选,非必填) | |
| videoFiles | Yes | 视频URL列表 | |
| voiceVolume | No | 配音音量(可选,非必填) | |
| coverImageUrl | No | 封面图片URL(可选,非必填) | |
| footerVideoUrl | No | 片尾视频URL(可选,非必填) | |
| headerVideoUrl | No | 片头视频URL(可选,非必填) | |
| coverImageDuration | No | 封面图片时长(可选,非必填) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It does disclose the core operation and optional behaviors: background music, voiceover, head/tail fixation, cover image, and volume control. But it does not disclose whether the operation is asynchronous, what the output/return value is, or any constraints on video count, duration, or format — leaving significant behavioral uncertainty.
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 compact and front-loads the main purpose, then enumerates supported features in the following sentences. It has minor redundancy — '合成新的视频' appears twice — but otherwise every sentence adds relevant capability information and all parameter categories are represented.
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?
For a 9-parameter tool with no annotations and no output schema, the description covers all major features and parameter roles. However, it omits important operational context such as the expected return value, synchronous versus asynchronous processing, input size limits, and supported media formats. The rich schema descriptions compensate partially, making it adequate but not fully 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 100%, with each of the 9 parameters already having its own description, so the baseline is 3. The tool description restates some parameter roles (e.g., optional background music, voiceover volume, cover image) but adds little new meaning beyond the schema — no URL format details, volume ranges, or conditional requirements.
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 a specific verb and resource: '将一个或多个视频素材合成一个视频' — merging video materials into a new video. It clearly differentiates itself from sibling tools like imgs2video (images-to-video) and videoCutRandom by centering on video materials as input and listing concrete capabilities such as fixed head/tail videos, cover image, and volume control.
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 intended use is implied through phrases like '通过视频素材合成新的视频' and '将一个或多个视频素材合成一个视频'. However, there is no explicit guidance on when to choose this tool over siblings, nor any exclusions such as 'use imgs2video when the source is images' or 'use videoCutRandom for random cutting'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
输入视频链接，输入截取的起始和结束位置，即可截取位置获得对应的视频片段
| Name | Required | Description | Default |
|---|---|---|---|
| endPlace | No | 裁剪视频的结束位置，时长的百分比 | |
| videoUrl | Yes | 视频URL地址 | |
| startPlace | No | 裁剪视频的起始位置，时长的百分比 |
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 restates the basic cut behavior and does not explain output format, delivery mechanism, failure modes, or why the tool name includes 'Random'. This leaves important behavioral unknowns.
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, concise sentence with no filler and communicates the core input and output relationship. It is appropriately short, though it does not add secondary structure like numbered steps or result expectations.
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?
For a simple three-parameter tool with a complete schema, the description is minimally adequate, but there is no output schema and no annotations. It does not explain what the returned video clip looks like, how it is delivered, whether processing is asynchronous, or what the 'Random' in the tool name means.
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%, and the schema already documents videoUrl, startPlace, and endPlace, including percentage semantics. The description adds no new parameter meaning beyond saying start and end positions are involved, so the baseline of 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 a specific action—cut a video segment using a URL plus start and end positions. However, it does not distinguish this from sibling video2video, and the 'Random' part of the tool name is never explained, leaving some ambiguity about scope.
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 the tool is for cutting a video based on user-supplied positions, which gives basic usage context. It does not explicitly state when to choose this tool over siblings like video2video, nor are exclusions or prerequisites mentioned.
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.
v0.1.16imageGenVideoimgPipimgPipTaskFetchbyReqIDimgs2videosubtitleDynamictaskFetchByTraceIDvideo2txtvideo2videovideoCutRandomMost tools target clearly distinct operations: image-to-video, video-to-video, video-to-text, subtitles, cutting, and picture-in-picture. However, taskFetchByTraceID and imgPipTaskFetchbyReqID both serve as task-result fetchers and could be confused, and imgs2video vs imageGenVideo may require careful reading to distinguish.
The names follow a mix of conventions: video2video, video2txt, and imgs2video use an input-to-output pattern, while subtitleDynamic, imageGenVideo, videoCutRandom, and imgPip use camelCase verb/noun phrases. There are also capitalization inconsistencies like traceID vs reqID, making the set readable but not uniformly patterned.
With 9 tools, the server is well-scoped for a video/media processing domain. Each tool provides a meaningful operation without excessive redundancy, and the count supports a coherent workflow.
The tool set covers the main lifecycle of creating and retrieving video-processing tasks across generation, editing, transcription, and subtitles. Minor gaps include no explicit cancel operation and only limited task-fetch coverage for some tools, but agents can generally complete core workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
AI image, video, voice and music generation over MCP, routed to Veo 3.1, Seedance 2.0 and more.
Plan, compare, price, generate, and recover AI video from compatible MCP clients.
Remote MCP for AI video, image, music and speech generation.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Runninghcm/MathMind-MCP-SERVER'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
