miromiro

Extract Lottie animations

extract_lottie

Read-onlyIdempotent

Use when the user wants a site's Lottie or animation JSON files. Most Lotties are injected at runtime, so pass render=true (+5 credits) when the static call finds none. Returns up to 20 by default; pass limit (up to 200) for more.

Input Schema

Name	Required	Description
`url`	Yes	The website URL
`fresh`	No	Skip the 24-hour cache and re-extract the live page - use when the site just changed and a cached result would be stale. Charged normally; the fresh result replaces the cached copy.
`limit`	No	Max Lottie files to return (default 20, up to 200).
`render`	No	Force a real browser so the page's JavaScript runs before it is read. Slower, and adds 5 credits. Usually not needed: when the plain read comes back as a JavaScript app shell or the site refuses it (401/403/406) or timed out, the server already re-runs the page in a browser by itself at no extra cost, and usage.autoRender says so. Pass it for images, videos or Lottie that only load on scroll, with screenshot=true, or when a result is still thin after that automatic pass. If a 403 says the browser was refused too, the site cannot be extracted - do not retry. extract_code always runs in a real browser at no extra cost, so render=true is not needed there (only together with screenshot=true). On extract_design_tokens, render=true only permits the browser: the plain read still runs first, and the 5 credits are charged only if the browser was actually needed.
`screenshot`	No	Requires render=true. Adds a screenshot field to the result: a public URL of a capture of the page (live 7 days), taken by the same browser that rendered it. Pass true for the 1440x900 viewport or 'full' for the entire page height. No extra credits beyond the render surcharge. Useful for showing the user what the extracted site looks like.
`full_output`	No	Skip long-string trimming. Responses still cap at ~100KB total.
`response_format`	No	How much to return. 'concise' keeps lists to 10 entries and strings short - right for a summary or a chat answer. 'detailed' returns everything the tool has (same as limit=200 + full_output=true). Omit for the default, which fits a typical chat context. The generated code is never trimmed in any mode.

Output Schema

Name	Required	Description
`url`	Yes
`note`	No	Coverage caveat: only Lotties declared in the initial HTML are found
`count`	No
`usage`	No	Credit usage for the authed key (spent, remaining, monthly limit).
`lotties`	No
`truncation_note`	No	Present when the result was trimmed to fit chat context - says what was dropped and how to get more (limit / full_output arguments, or the REST API).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 18, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower. The description still adds behavior annotations don't carry: the +5 credit surcharge for render and the runtime-injection caveat that explains why a static pass may return nothing. It omits any note on caching or output shape, but the credit/cost context is genuinely useful.

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?

Three sentences, front-loaded with the usage trigger, then the render fallback, then the limit caveat. No filler, and the most decision-relevant guidance (when to call, when to escalate to render) comes first.

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 100% schema coverage, an output schema present, and rich annotations, the description needs only the intent trigger and the render-escalation rule, both of which it supplies. It leaves pagination/return-shape explanation to the output schema, which is fine; nothing an agent needs to call correctly is missing.

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% and the render/limit schemas are extremely thorough, so the schema does the heavy lifting. The description only restates the default 20 / up to 200 limit and the render cost, adding no syntax or semantics beyond what the schema already documents. Baseline 3 is appropriate.

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 description frames the tool by intent ("Use when the user wants a site's Lottie or animation JSON files"), which pins the resource as specifically Lottie/animation JSON. That resource is distinct from siblings like extract_svgs, extract_videos and extract_audio, so an agent can tell it apart even though no sibling is named explicitly.

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 a clear triggering condition (user wants Lottie/animation JSON) and a follow-up rule for the common failure mode ("pass render=true when the static call finds none"). It stops short of naming alternative extraction tools or stating when-not-to-use, keeping it at a strong-but-not-exhaustive level.

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

All miromiro tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.