hydra-mcp

hydra_source

Load an external image, video, camera, or screen stream into a Hydra slot so it can be used in any visual chain with src().

Instructions

Load an external image stream into s0–s3, then read it in any chain with src(s0).

kind: "image" target = an http(s) URL. It must allow cross-origin use (CORS) or WebGL cannot read it — the error says so. "video" target = an http(s) URL, same CORS rule; loops muted. "cam" target = camera index ("0"). The browser asks for permission: expect state "pending_permission" until someone at the machine clicks Allow, and check hydra_state rather than assuming. "screen" screen capture. Browsers only allow it from a click inside the page, so a remote call usually cannot start it; the error explains. "clear" release the slot.

Returns state: "live" (with the media's size), "pending_permission", or an error. It waits up to four seconds for the source to actually deliver frames. Images and video are loaded on mirrors too; cameras and screen capture are not (each would prompt).

Then: src(s0).kaleid(4).out(o1)

Input Schema

TableJSON Schema

Name	Required	Description	Default
`kind`	Yes
`slot`	Yes
`target`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 14, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description goes well beyond the annotations: it discloses that the tool is not read-only (it loads streams and can prompt for permissions), details the return state ('live', 'pending_permission', errors), specifies a four-second timeout, and explains mirror behavior (images/videos load on mirrors; cameras/screen do not). This adds significant behavioral context that annotations do not provide. It fully informs the agent about side effects, such as permission prompts, which is critical for correct usage.

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 detailed, which is necessary given the tool's complexity)Skip. It front-loads the key action ('Load an external image stream... src(s0)') and then organizes kind-specific details in a clear list. It does include a redundant example chain at the end ('Then: src(s0).kaleid(4).out(o1)') that largely repeats the opening usage pattern, adding little value-laden content. Overall it is structured and readable, but the trailing example slightly bloats it without new information.

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?

Given the tool's complexity (multiple kinds, permission prompts, CORS constraints) and the minimal schema (3 params, 2 required, no enums), the description is remarkably complete. It covers all critical behaviors: return states, timeouts, mirror limitations, error scenarios, and usage patterns. The output schema exists, so return details are partly covered, but the description still explains the state values. There are no significant gaps that would prevent an agent from using the tool correctly.

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 input schema is minimal (only names: kind, slot, target) with 0% description coverage. The description compensates by explaining the kind values ('image', 'video', 'cam', 'screen', 'clear') and their target formats (URL, camera index, or empty for clear). However, it does not explicitly explain the 'slot' parameter semantics beyond the s0–s3 reference in the opening line, and 'target' is explained mainly through kind. Since kind and target are well-clarified, but slot is thinner, it scores a 4 rather than 5.

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 opens with a clear, specific statement: 'Load an external image stream into s0–s3, then read it in any chain with src(s0).' This names the exact resource (external image stream), the slot mechanism (s0–s3), and the usage pattern (src(s0)), distinguishing it from generic load tools. It also enumerates the kind field with concrete targets ('image', 'video', 'cam', 'screen', 'clear'), which makes the purpose unmistakable. It clearly differentiates from siblings like hydra_load by focusing on source slots and stream loading.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance per kind, stating when to use each (e.g., for 'screen', it notes browsers require a click, so remote calls likely fail; for 'cam', it warns to expect pending_permission and check hydra_state rather than assuming). It also explains the CORS requirement for image and video, which is a critical condition. While it doesn't name sibling alternatives, it gives concrete operational constraints that help an agent decide when to call this function and how to handle outcomes. This is more actionable than typical sibling-based exclusions.

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