Skip to main content
Glama

Apply an effect

apply_effect

Run an effect from list_effects on pictures or a video, with Tesseract (charged to the signed-in account). Returns a job_id; call check_job until it is done.

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": {
      "effect_id": "<effect_id>"
    },
    "name": "apply_effect"
  }
}

Input Schema

NameRequiredDescriptionDefault
styleNoOne of the effect's looks (its `styles`).
videoNoA public https:// URL of the source video, for an effect that needs one.
imagesNoThe pictures it needs, in order (for a duo: [you, the other person]).
promptNoExtra direction, for effects that take words.
max_usdNoThe most this may cost, in US dollars: a dearer job is not started.
secondsNoA transition only: its length.
effect_idYesThe effect id from list_effects (e.g. "ai-hug").
rights_okNoWith a source video of someone else's: true only when the person says the video and its sound belong to their makers, and the result is for their own use unless they hold the rights.
aspect_ratioNoA transition only: its shape.
likeness_consentNoOnly when the person asked for it themselves, about who is shown: "self" (them), "consented" (an adult who agreed to it) or "made-up" (a made-up person) — and only when nobody shown is under 18 or a public figure, and there is no nudity or sexual content. Needed by the effects that put a person in, talking or lip-synced people, headshots and try-ons.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / likeness_consent
      Added value: +{
      +  "description": "Only when the person asked for it themselves, about who is shown: \"self\" (them), \"consented\" (an adult who agreed to it) or \"made-up\" (a made-up person) — and only when nobody shown is under 18 or a public figure, and there is no nudity or sexual content. Needed by the effects that put a person in, talking or lip-synced people, headshots and try-ons.",
      +  "enum": [
      +    "self",
      +    "consented",
      +    "made-up"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / rights_ok
      Added value: +{
      +  "description": "With a source video of someone else's: true only when the person says the video and its sound belong to their makers, and the result is for their own use unless they hold the rights.",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false, idempotentHint=false), the description discloses two important traits: the call is billed to the signed-in account and it is asynchronous, returning a job_id that must be polled with check_job. It does not explain failure modes or what happens when max_usd blocks a job, but the cost and async behavior are the material additions.

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 short sentences, front-loaded with the core action and followed by the follow-up polling requirement. No filler, and the cost caveat is embedded efficiently in a parenthetical.

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?

For a complex, ten-parameter, asynchronous, paid job-launching tool with no output schema, the description covers the essentials an agent needs: cost charging, the returned job_id, and the poll loop. Detailed parameter gating (consent, rights, cost caps) is fully handled by the schema, so the remaining gap is minor.

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?

Schema description coverage is 100%, so every one of the ten parameters is already documented in the schema, including rights_ok, likeness_consent, max_usd and the media URL formats. The description adds essentially nothing beyond that except tying effect_id back to list_effects, so the baseline 3 applies.

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?

Uses a specific verb ('Run an effect') with the resource and its source ('from list_effects'), and states the input media types (pictures or a video). It also names the sibling that supplies the effect_id and the one that must be polled afterwards, so an agent can place it in the workflow without opening a schema.

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 clear sequencing: pick an effect from list_effects, run it here, then call check_job until finished. It does not explicitly exclude alternative siblings (edit_image, generate_image, generate_video) or state when a caller should prefer those over an effect, which keeps it short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources