Skip to main content
Glama

query_video_status

Check the status and retrieve results of video generation tasks in the edu_video_gen system. Use this tool to monitor progress and access completed videos and images with properly formatted links.

Instructions

查询视频生成状态

Args: task_id: 视频生成任务ID

Returns: 包含任务状态信息与任务结果的字典,任务结果中的视频链接请用"链接文本"形式展示给用户,图片链接请用"链接文本"形式展示给用户

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
task_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The primary handler function for the 'query_video_status' MCP tool. It extracts the API key from HTTP headers, queries the Scenext API for the video task status, and returns the result or error.
    @mcp.tool()
    async def query_video_status(task_id: str) -> Dict[str, Any]:
        """
        查询视频生成状态
        
        Args:
            task_id: 视频生成任务ID
        
        Returns:
            包含任务状态信息与任务结果的字典,任务结果中的视频链接请用"[链接文本](视频URL)"形式展示给用户,图片链接请用"![链接文本](图片URL)"形式展示给用户
        """
        
        # 从请求头获取API KEY
        api_key = get_api_key_from_headers()
        
        if not api_key or api_key == "YOUR_API_KEY":
            return {"error": "请在请求头中提供有效的API Key,支持Authorization: Bearer <token>或X-API-Key: <token>"}
        
        if not task_id.strip():
            return {"error": "任务ID不能为空"}
        
        url = f"{API_BASE_URL}/get_status/{task_id}"
        headers = {
            "Authorization": f"Bearer {api_key}"
        }
        
        try:
            async with aiohttp.ClientSession() as session:
                async with session.get(url, headers=headers) as response:
                    if response.status == 200:
                        result = await response.json()
                        logger.info(f"状态查询成功: {result}")
                        
                        if result.get("status") == "success":
                            return result.get("data", {})
                        else:
                            return {
                                "error": "API返回错误状态",
                                "details": result
                            }
                    else:
                        error_text = await response.text()
                        logger.error(f"状态查询失败: {response.status} - {error_text}")
                        return {
                            "error": f"状态查询失败: {response.status}",
                            "details": error_text
                        }
        except aiohttp.ClientError as e:
            logger.error(f"网络请求错误: {e}")
            return {"error": f"网络请求错误: {str(e)}"}
        except Exception as e:
            logger.error(f"未知错误: {e}")
            return {"error": f"未知错误: {str(e)}"}
  • Helper utility function used by the query_video_status tool (and gen_video) to retrieve the API key from HTTP request headers or fallback to environment variable.
    def get_api_key_from_headers() -> str:
        """从HTTP请求头中获取API KEY"""
        try:
            headers = get_http_headers(include_all=True)
            
            # 尝试从Authorization header获取Bearer token
            auth_header = headers.get("authorization", "")
            if auth_header.startswith("Bearer "):
                return auth_header[7:]  # 移除 "Bearer " 前缀
            
            # 尝试从自定义header获取
            api_key = headers.get("x-api-key", "")
            if api_key:
                return api_key
                
            # 如果都没有,返回环境变量中的默认值
            return os.getenv("SCENEXT_API_KEY", "")
            
        except RuntimeError:
            # 如果不在HTTP请求上下文中,使用环境变量
            return os.getenv("SCENEXT_API_KEY", "")
  • Test code verifying that the 'query_video_status' tool is properly registered in the MCP server alongside 'gen_video'.
    # 检查工具是否正确注册
    expected_tools = ['gen_video', 'query_video_status']
    
    # 获取注册的工具(这需要访问内部 API)
    tools = mcp._tool_manager.list_tools()
    tool_names = [tool.name for tool in tools]
    
    for expected_tool in expected_tools:
        assert expected_tool in tool_names, f"工具 {expected_tool} 未注册"
    
    print(f"工具注册测试通过 - 注册工具: {tool_names}")
Behavior3/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 describes the return format and how to present links, which adds useful context beyond basic functionality. However, it doesn't mention error handling, rate limits, authentication needs, or whether this is a read-only operation (though implied by '查询' - query).

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 sized with three sentences: purpose statement, parameter explanation, and return format guidance. It's front-loaded with the core purpose and efficiently covers necessary information without wasted words. The bilingual presentation is slightly less structured but remains clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (status query with one parameter), no annotations, but with output schema present, the description provides good coverage. It explains the parameter meaning and return format specifics (including link presentation instructions), which complements the structured output schema well. The main gap is lack of error/edge case handling information.

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 schema description coverage is 0%, so the description must compensate. It clearly explains that 'task_id' is a '视频生成任务ID' (video generation task ID), adding essential semantic meaning not present in the bare schema. This adequately documents the single parameter's purpose.

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 as '查询视频生成状态' (query video generation status), which is a specific verb+resource combination. It distinguishes from the sibling 'gen_video' by focusing on status checking rather than video generation. However, it doesn't explicitly contrast with the sibling tool in the description text itself.

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 context through the parameter 'task_id' and the mention of '视频生成任务ID' (video generation task ID), suggesting this tool should be used after initiating a video generation task. However, it doesn't provide explicit guidance on when to use this versus alternatives or any prerequisites beyond needing a task ID.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/typing233/scenext-mcp'

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