Skip to main content
Glama

APIClaw

by io.apiclaw.api
OverviewDiscussionsAdmin

poll_video_task

Poll a video generation task

Retrieve the status and result of a video generation task.

Call with the taskId returned by the submit endpoint and poll periodically (e.g. every 5-10 seconds) until status is terminal. On succeeded, output.video_url holds the generated video; on failed, error holds the reason.

Available to CONTRACT-tier API keys only. The task cost is settled against the submit-time hold when success is first observed — by this poll or by our background finalizer, so a task is billed whether or not you poll it. Terminal polls return the provider token usage in meta.tokensUsage; polls of an already-terminal task return the cached result and never bill again. The per-call response carries no USD amount — derive cost from meta.tokensUsage and your contracted per-token rate, or call GET /openapi/v2/account/balance.

Path parameter:

  • task_id (string, required): the taskId from the submit call. Returns 404 if it does not exist or belongs to another account.

Response data:

  • taskId (string): the polled task id.

  • status (string): one of pending, running, succeeded, failed, cancelled. The last three are terminal.

  • output (object | null): on succeeded, an object with video_url plus any additional provider fields; null otherwise.

  • error (object | null): on failed, a {code, message} object with the provider failure reason; null otherwise.

Response meta:

  • tokensUsage (object | null): provider token usage (completionTokens, totalTokens, ...) on any terminal poll; null while pending / running.

Responses:

200: Successful Response (Success Response) Content-Type: application/json

Example Response:

{
  "success": true,
  "meta": {
    "requestId": "Requestid",
    "timestamp": "Timestamp"
  }
}

Output Schema:

{
  "properties": {
    "success": {
      "type": "boolean",
      "title": "Success",
      "description": "Whether the request was successful",
      "default": true
    },
    "data": {
      "description": "Response data payload"
    },
    "error": {
      "description": "Error details if request failed"
    },
    "meta": {
      "description": "Metadata for API responses.\n\nCredit fields follow the ADR-0003 parallel-fields strategy (Option 3):\n- `credits_remaining` / `credits_consumed` (int): legacy fields, rounded\n  to whole credits, kept for zero-breaking-change to existing SDK clients.\n- `credits_remaining_exact` / `credits_consumed_exact` (float): new\n  precision-aware fields for clients that opt in to decimal credits.\n\nSee ADR-0003 decision 5 and the \u00a78 deprecation timeline.\n\nTODO(2026-11, ADR-0003 \u00a78 +6mo): mark `credits_remaining` /\n`credits_consumed` as `deprecated=True` in their Field() definitions\nand announce in customer changelog.\nTODO(2027-05, ADR-0003 \u00a78 +12mo): remove the legacy int fields via a\nmajor-version bump of the OpenAPI surface.",
      "properties": {
        "requestId": {
          "type": "string",
          "title": "Requestid",
          "description": "Unique request identifier"
        },
        "timestamp": {
          "type": "string",
          "title": "Timestamp",
          "description": "Response timestamp in ISO 8601 format"
        },
        "total": {
          "title": "Total",
          "description": "Total number of records"
        },
        "page": {
          "title": "Page",
          "description": "Current page number"
        },
        "pageSize": {
          "title": "Pagesize",
          "description": "Number of records per page"
        },
        "totalPages": {
          "title": "Totalpages",
          "description": "Total number of pages"
        },
        "creditsRemaining": {
          "title": "Creditsremaining",
          "description": "Remaining API credits (rounded to whole credits; see creditsRemainingExact for precise value)"
        },
        "creditsConsumed": {
          "title": "Creditsconsumed",
          "description": "Credits consumed by this request (rounded; see creditsConsumedExact for precise value)"
        },
        "creditsRemainingExact": {
          "title": "Creditsremainingexact",
          "description": "Remaining API credits, precise to 1 decimal place"
        },
        "creditsConsumedExact": {
          "title": "Creditsconsumedexact",
          "description": "Credits consumed by this request, precise to 1 decimal place"
        },
        "tokensUsage": {
          "description": "Provider token-usage block \u2014 populated on terminal video polls only, null on every non-video endpoint. See TokensUsage for its fields."
        }
      },
      "type": "object",
      "required": [
        "requestId",
        "timestamp"
      ],
      "title": "ResponseMeta"
    }
  },
  "type": "object",
  "required": [
    "meta"
  ],
  "title": "OpenApiResponse[VideoTaskData]",
  "examples": []
}

422: Validation Error Content-Type: application/json

Example Response:

{
  "detail": [
    {
      "loc": [],
      "msg": "Message",
      "type": "Error Type",
      "ctx": {}
    }
  ]
}

Output Schema:

{
  "properties": {
    "detail": {
      "items": {
        "properties": {
          "loc": {
            "items": {},
            "type": "array",
            "title": "Location"
          },
          "msg": {
            "type": "string",
            "title": "Message"
          },
          "type": {
            "type": "string",
            "title": "Error Type"
          },
          "input": {
            "title": "Input"
          },
          "ctx": {
            "type": "object",
            "title": "Context"
          }
        },
        "type": "object",
        "required": [
          "loc",
          "msg",
          "type"
        ],
        "title": "ValidationError"
      },
      "type": "array",
      "title": "Detail"
    }
  },
  "type": "object",
  "title": "HTTPValidationError"
}

Input Schema

NameRequiredDescriptionDefault
task_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the entire disclosure burden and does so thoroughly: tier restriction (CONTRACT keys only), billing semantics (cost settled against the submit-time hold at first observed success, and billed even if never polled because of the background finalizer), no double-billing on cached terminal polls, no USD amount in the response, and the 404 condition. This is exactly the kind of billing and auth detail annotations would never convey.

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?

Front-loaded with a one-line purpose, then usage, then structured parameter and response blocks, so scanning is easy. It is somewhat long, but almost every line (billing, 404, terminal semantics, token usage) carries non-obvious information rather than filler.

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

Completeness5/5

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

The 200 output schema shown is generic (success/meta) and does not actually expose status, output.video_url, error, or meta.tokensUsage, so the description's response documentation is non-redundant and necessary. Combined with the polling cadence, terminal state list, billing behavior and auth tier, an agent has everything needed to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single task_id parameter, so the description must compensate, and it does: it defines the value's provenance (the taskId returned by the submit call) and a failure mode (404 if it does not exist or belongs to another account). That is meaning well beyond the bare 'string' in the schema.

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?

States a specific verb ('poll', 'retrieve the status and result') and resource ('a video generation task'), and implicitly distinguishes itself from the sibling submit_video_generation by framing itself as the follow-up to 'the submit endpoint'. An agent cannot confuse it with list_video_assets or get_video_asset.

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?

Gives explicit invocation context: call with the taskId from the submit endpoint, poll every 5-10 seconds, stop when status is terminal, and read output.video_url on succeeded vs error on failed. It also states the CONTRACT-tier key requirement. It lacks an explicit when-not/exclusion statement, so a 4 rather than 5.

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

All APIClaw toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources