klaket-mcp

klaket_ingest

Submit a video URL or file path to begin processing into LLM-ready data. Returns a job ID for status polling.

Instructions

Start processing a video (URL or server-side file path) into LLM-ready data. Returns a job id — poll klaket_job_status until status is 'done', then call klaket_get_result.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "klaket_ingest"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes	Video URL (YouTube, direct file) or a path visible to the Klaket worker

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.7.1Jul 16, 2026

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It correctly indicates the tool is non-blocking and returns a job id, but fails to mention potential side effects (e.g., compute usage, storage requirements, error handling). The transparency is adequate but not thorough for an agent.

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?

Two sentences with zero waste. The first sentence states the purpose and output, the second provides the follow-up workflow. Information is front-loaded and easy to parse.

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 simplicity (one param, async, no output schema), the description covers the essential workflow and references sibling tools. It lacks details on error states or job id format, but these are minor omissions for a straightforward ingestion tool.

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 already describes the single 'url' parameter thoroughly (100% coverage). The tool description adds that the URL can be a YouTube link, direct file, or server-side path, which is useful but not critical. Overall, the description does not significantly augment the schema's parameter documentation beyond context.

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 verb 'Start processing' and the resource 'a video', specifying the transformation into 'LLM-ready data'. It distinguishes from siblings by outlining the async workflow that follows, making the tool's role in the pipeline explicit.

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 direct guidance: poll klaket_job_status until done, then call klaket_get_result. It also clarifies valid inputs (URL or server-side path). However, it does not explicitly state when not to use this tool or scenarios where alternatives like klaket_find_moment would be more appropriate.

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

Deploy Server