Skip to main content
Glama

addEffect

Apply a custom WGSL shader effect over a timeline span to create looks the built-in settings cannot provide, or reapply a saved project effect by ID.

Instructions

Write a visual effect as a shader and pose it over a span of the edited timeline (virtual seconds), or pose one of this project's effects again (effectId). Use it for a look the settings do not offer. effect.code is WGSL that defines fn effect(uv: vec2<f32>) -> vec4<f32>, called for every pixel; uv is 0..1 with (0,0) top-left. Available inside it: frame(uv) samples the composed picture; params.<name> reads each declared parameter; ctx.time is programme seconds; ctx.region.x goes 0 to 1 across the region (y its length in s, z seconds since it began); ctx.resolution and ctx.aspect; ctx.cursor (xy in uv, z = 1 when on screen); ctx.clicks[0..3], the last four clicks, newest first (xy in uv where it happened, z seconds since, w = 1 when the slot holds one); ctx.footage and ctx.camera, the recording's and the webcam's rects (x, y, w, h in uv; camera zero-sized when absent) — all already placed through zoom and layout; fx_to_footage(uv) and fx_from_footage(p) map between output uv and the recording's own surface (0..1 across the recording) through the warp the compositor draws it with, zoom, layout and 3D camera included, and ctx.footage_aspect is its width over height: the effect works in whichever of the two spaces fits it; fx_px(n), n pixels of a 1080p frame as a fraction of the height; fx_hash(vec2<u32>), a random number in [0,1) identical on every GPU. Rules: the effect is a pure function of those inputs (no state between frames), so the preview and the export show the same pixels; reason in uv or fx_px, never raw pixels; every loop is a for with literal bounds (for (var i = 0; i < 16; i++)), at most 4096 iterations per pixel — the one hard rule. params declares up to 8 (recommended) parameters, each {type: number|toggle|color|point, name, label, default} (number also min, max); declare one only when moving it visibly changes the effect over its whole range. target: image (default: the picture under the annotations and captions), text (the annotations and captions alone, premultiplied alpha), both (everything); use text or both only when asked. One effect runs at a time: to combine two looks, write them in one shader. The result gives the cost tier, in frame() reads per pixel, with what a 1080p frame pays on a fast discrete GPU (RTX 4070 Ti) and on an integrated one (Apple M1): light ≤ 8, up to 0.06 ms and 1.3 ms; medium ≤ 32, 0.14 ms and 4.3 ms; heavy ≤ 128, 0.54 ms and 16 ms; very heavy beyond, 2 ms and 49 ms at 512 reads. It also gives a recommendation when the tier runs long: light anywhere, medium up to a minute, heavy up to 10 s, very heavy a few seconds. It is a recommendation, never a refusal. Code that does not compile is refused with the compiler's error at the line of your code: fix it and call again. Check the result with getFrames.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
effectNo
endSecYes
targetNo
valuesNo
effectIdNo
startSecYes
projectIdNoThe project to act on, from listProjects. Omit it only for the project open in the OpenScreen editor, which works only while the app runs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.1

TDQS

A4.1/5.0
Behavior5/5

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

Far beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false), it discloses the purity rule that guarantees preview/export parity, the hard 4096-iteration-per-pixel loop limit, the exact cost-tier breakdown with device timings, and the failure mode ('Code that does not compile is refused with the compiler's error ... fix it and call again'). It also states that the length recommendation is 'never a refusal', which prevents an agent from misreading the guidance as a gate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded correctly, and most of the shader-contract detail is genuinely load-bearing given no output schema and near-zero schema coverage. However it is delivered as one very long unbroken paragraph mixing tool usage with WGSL reference material, and items like the per-device millisecond cost tables could be compressed or deferred, so it is bulkier than it needs to be.

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?

With no output schema, the description does explain the return ('the cost tier ... with what a 1080p frame pays') and the error path, which is exactly what is needed. It also documents the shader runtime API, target defaults and parameter-declaration constraints. It stops short of defining `values`, the exact meaning of startSec/endSec, and the purpose of effect.name/effect.description in the effect object.

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?

Schema description coverage is only 14% across 7 parameters, so the description carries most of the burden and does well: it details `effect.code`, the `params` declaration schema (type/name/label/default/min/max), the `target` enum defaults and the 'text or both only when asked' rule, `effectId`, and the timeline span. Gaps remain — `values` (how declared parameter values are applied) is never explained, and startSec/endSec semantics are only implied by 'a span of the edited timeline (virtual seconds)'.

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 opening sentence gives a precise verb+resource ('Write a visual effect as a shader and pose it over a span of the edited timeline') and even covers the second mode ('or pose one of this project's effects again (effectId)'). It is unambiguous what the tool creates, but it never names or contrasts the closely related siblings (setEffect, getEffect, setEffectDefinition), so an agent still has to infer the boundary from tool names alone.

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?

It gives real selection guidance: 'Use it for a look the settings do not offer', 'use text or both only when asked', 'to combine two looks, write them in one shader', and 'Check the result with getFrames'. There is no explicit when-not or named-alternative routing (e.g. versus setEffect for existing effects), but the conditions for parameter declaration and target choice are concrete.

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