Skip to main content
Glama

Search effects

search_effects
Read-onlyIdempotent

Search Vidova's effects: ready-made moments to put over a clip. People: a glowing frozen copy of the person rising out of them (Clone rise), an emoji pinned beside a face (Emoji tag). Layouts: two photos split by torn paper. Intros, looks and hits: a slanted panel reveal, a donut bokeh focus pull, a negative strobe, HDR and sepia looks, an explosion, a screen shatter, cracked glass, a shockwave, an impact frame, a flash, a shake, lightning, a comic burst with a word, speed lines, fire, fireworks, confetti. An empty query lists every effect, a page at a time: the answer says the offset to read on from. Use one to three words (explosion, face, intro). Each result has the id apply_effect takes, what the effect needs, how long it runs and when it works. It also lists the transitions between two shots that match: the engine's and the library's shader transitions (a whip, a zoom blur, a cube turn, a lens wipe), each written as one or line on the cut, not with apply_effect.

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": {
      "query": "<query>",
      "offset": "<offset>",
      "limit": "<limit>",
      "projectId": "<projectId>"
    },
    "name": "search_effects"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitYesMost effects on the page, 1 to 60. null means 15.
queryYesWords for the effect you want, such as explosion, face or intro. Empty lists every effect.
offsetYeseffects to skip: the offset the page before says to call again with. null starts at the first.
projectIdYesThe project this call runs on without changing the open project. null (or leaving it out) uses the open project. wait_for_jobs takes the projectId of the calls that started the jobs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / limit
      Added value: +{
      +  "anyOf": [
      +    {
      +      "maximum": 60,
      +      "minimum": 1,
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "Most effects on the page, 1 to 60. null means 15."
      +}
    • addedInput schema / properties / offset
      Added value: +{
      +  "anyOf": [
      +    {
      +      "maximum": 9007199254740991,
      +      "minimum": 0,
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "effects to skip: the offset the page before says to call again with. null starts at the first."
      +}
    • changedInput schema / required
      Previous value: -[
      -  "query",
      -  "projectId"
      -]New value: +[
      +  "query",
      +  "offset",
      +  "limit",
      +  "projectId"
      +]
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real value beyond that: it explains pagination behavior (the response says which offset to read on from) and what each result row contains (id, requirements, duration, timing). It does not mention error cases or whether transition entries can be paged out of a result set.

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, but the middle is a long comma-run of effect names (explosion, screen shatter, cracked glass, shockwave, impact frame, flash, shake, lightning, comic burst, speed lines, fire, fireworks, confetti) that is far longer than needed to convey the domain. The genuinely important pagination and transitions caveats are buried after that enumeration.

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 carries the burden of explaining returns and does so (id, requirements, duration, timing, plus transition lines). For a paginated, four-parameter search tool this is nearly complete; only the exact response envelope shape and what 'when it works' means operationally are left implicit.

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 the schema already explains query, offset, limit and projectId, including that null limit means 15 and null offset starts at the first page. The description reiterates the empty-query behavior and adds a light constraint on query length, which is marginal over what the schema already provides; 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?

The opening sentence gives a specific verb and resource ('Search Vidova's effects') plus a functional gloss ('ready-made moments to put over a clip'), then enumerates categories (People, Layouts, Intros/looks/hits) with named examples. It also distinguishes itself from apply_effect by stating that each result carries the id apply_effect takes, and carves out transitions as a separate application path.

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 concrete query guidance ('Use one to three words (explosion, face, intro)') and the empty-query fallback ('An empty query lists every effect, a page at a time'), and it explicitly says matching transitions are written as <enter>/<exit> lines rather than applied via apply_effect. It stops short of comparing itself against the many sibling search tools (search_library, search_elements, search_templates), so alternatives are only partially addressed.

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.