CSS 漸層、動畫與網頁互動效果產生器。
Scored across 8 tools
Most tools have clearly distinct purposes (a11y checklist, browser support, library comparison, generators for easing/gradient/keyframes, spring conversion, video encoding). The only mild overlap is between generate_easing and spring_to_css_linear, both producing easing functions, but descriptions make the distinction clear (cubic-bezier vs. spring physics to linear()).
Names are all snake_case and readable, but conventions are mixed: three use a verb_noun pattern (generate_easing, generate_gradient, generate_keyframes), while others are noun phrases (animation_a11y_checklist, animation_browser_support) or descriptive (spring_to_css_linear, web_video_ffmpeg). This is not a consistent verb_noun pattern throughout.
Eight tools is well-scoped for a web animation toolbox, covering generation, checks, comparisons, and conversion without redundancy. Each tool earns its place, and the count sits comfortably in the ideal 3–15 range.
The surface covers core web animation tasks: accessibility, browser support, library selection, CSS keyframes/easing/gradient generation, spring conversion, and video compression. Minor gaps exist, such as no dedicated generator for scroll-driven animations or View Transitions code (only mentioned in browser support), but agents can work around these.
網頁動畫無障礙與效能檢查清單（WCAG 2.2.2、2.3.1、2.3.3、prefers-reduced-motion、CLS、LCP），附全站減少動態 CSS。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose what the tool returns conceptually (a checklist plus a site-wide reduce-motion CSS snippet), which is useful behavioral context. However, it says nothing about the output format, whether there is any state or side effect, or how the checklist is delivered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the core deliverable and then parenthetically lists the covered criteria. Every clause earns its place; the only mild cost is that the trailing list is information-dense and slightly harder to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter reference/checklist tool with no output schema, the description covers what the tool produces and the scope of standards it checks. It lacks any statement of return format, but the absence of side effects or auth needs keeps the definition essentially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema is empty, so there is no parameter semantics to explain. Baseline 4 applies since nothing is missing or contradictory on the parameter front.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific deliverable (an accessibility and performance checklist for web animations) and enumerates the exact standards it covers (WCAG 2.2.2, 2.3.1, 2.3.3, prefers-reduced-motion, CLS, LCP), which clearly separates it from the generator-oriented siblings. It stops short of an explicit 'this is not the generator' statement, but the verb+resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer you call this when auditing animation accessibility/performance, but there is no explicit when-to-use statement, no prerequisites, and no guidance about when to prefer a sibling tool. Adequate but with clear gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
網頁動畫功能瀏覽器支援版本：View Transitions、捲動驅動動畫、linear()、@starting-style、Web Animations API。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations and no output schema, so the description carries the full burden. It does not disclose what the response actually contains (per-browser version tables? support flags? caveats?) or that it is a static, read-only reference with no side effects. Only the topic list hints at content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with the resource front-loaded. It is efficient, though the naming list occupies most of the text and there is no second sentence to add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter informational tool with no annotations or output schema, the description identifies the subject matter well but omits what the returned data looks like or how comprehensive it is. Adequate but with a clear gap around output expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly avoids inventing parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (browser support versions for web animation features) and enumerates the covered technologies (View Transitions, scroll-driven animations, linear(), @starting-style, Web Animations API), making it distinguishable from siblings like generate_keyframes or generate_easing. No explicit verb (get/list), but the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus the many sibling tools (animation_a11y_checklist, compare_animation_libraries, etc.), nor any prerequisite or exclusion. The agent must infer that it is a reference lookup rather than a generator.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
比較網頁動畫工具：CSS、Web Animations API、GSAP、Motion、Anime.js、Lottie、Rive、Three.js、Lenis 的授權與適用情境。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the comparison dimensions (licensing and applicable scenarios), but does not describe the return format, whether it is a static reference, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that lists the compared tools and aspects without filler. It is appropriately sized for a parameterless comparison tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and is a straightforward comparison resource, the description covers the essential scope. However, it could briefly indicate the form of the output (e.g., a table) to be fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to add parameter semantics and appropriately does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (比較) and resource (網頁動畫工具) and enumerates the libraries and comparison dimensions (授權與適用情境). It clearly distinguishes from sibling tools like animation_a11y_checklist and generate_easing, which are checkers/generators rather than comparisons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description only states what it compares; it does not say when an agent should select it over sibling tools or what prerequisites exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
產生 CSS cubic-bezier 緩動曲線：用名稱（easeOutCubic、easeInOutBack、materialStandard 等 32 種）或四個控制點，回傳 CSS、Web Animations API 範例與取樣點。
| Name | Required | Description | Default |
|---|---|---|---|
| x1 | No | ||
| x2 | No | ||
| y1 | No | ||
| y2 | No | ||
| name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the return artifacts (CSS, Web Animations API sample, sampling points), which is useful output-shaping context for a pure generator. However it says nothing about validation rules, whether unknown names error or fall back, or constraints on control points, so it only partially covers the behavioral burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the verb and the artifact produced, then follows with the input modes and outputs. Nothing is redundant. It is slightly overloaded by packing inputs, outputs, and preset count into one breath, but there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the sole carrier of behavior, and it does state what is returned, which is adequate for a simple generator. It still omits control-point constraints and conflict resolution between the name and coordinate parameters, leaving gaps an agent would need to guess at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 5 parameters, so the description must compensate. It establishes the two input modes (named preset vs. four control points) but never maps these to the schema's x1/x2/y1/y2 fields, omitted preset-name semantics beyond a few examples, or notes the typical [0,1] constraint on x values. It adds some meaning but leaves the schema's cryptic names largely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (產生/generate) and a specific resource (CSS cubic-bezier easing curve), which is clearly distinct from siblings like generate_keyframes and generate_gradient. It even enumerates the output artifacts. It doesn't explicitly contrast itself with any sibling, but the resource is unambiguous enough that an agent can pick it correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over the animation-related siblings (e.g. spring_to_css_linear, generate_keyframes). The only conditional offered — use a name OR four control points — is an input-mode distinction, not tool-selection guidance. An agent gets no help deciding between this and related animation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
產生 CSS 漸層（linear、radial、conic），可選流動動畫與漸層文字。colors 用逗號分隔 HEX。
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| angle | No | ||
| speed | No | ||
| colors | Yes | ||
| animate | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does disclose the gradient types and the optional flowing animation / gradient-text behaviors. However, as a code-generating tool it never states what is actually returned (CSS snippet vs file) or any constraints on the animation, leaving meaningful behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely terse and front-loaded: the core capability comes first, followed by optional features and the format hint. Nothing is padded, though the terseness is partly responsible for the missing parameter detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters at 0% schema coverage, no output schema, and no annotations, the description is too thin to fully specify the tool. It leaves the semantics of angle and speed, and the shape of the returned CSS, undefined for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across five parameters, so the description must compensate. It explains colors as comma-separated HEX and implies valid type values via linear/radial/conic, but angle (numeric) and speed (numeric) are completely undocumented, leaving the meaning of those parameters undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (產生/generate) and resource (CSS 漸層) and enumerates the three gradient types (linear, radial, conic), so the agent can tell it apart from siblings like generate_easing or generate_keyframes. It stops short of explicitly naming which sibling to prefer, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance and no alternative tool is named. The mention of optional animation and gradient text implies capabilities but gives no condition under which an agent should choose this tool over the other generate_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
產生 CSS @keyframes 動畫（含減少動態模式）。preset：fadeIn,fadeInUp,fadeInDown,slideInLeft,slideInRight,zoomIn,pulse,bounce,shake,spin,float,heartbeat,flipIn,blurIn,typing
| Name | Required | Description | Default |
|---|---|---|---|
| delay | No | ||
| easing | No | ||
| preset | Yes | ||
| duration | No | ||
| iterations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose one non-obvious behavioral trait, that the output includes a reduced-motion variant (含減少動態模式), which is genuinely useful. However it says nothing about output format, whether the CSS is returned as a string or file, or how delay/duration/iterations interact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the purpose before the preset list. The preset enumeration is long but earns its place since no enum exists in the schema. Slight redundancy between the name and the opening clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A five-parameter tool with no annotations, no output schema, and no schema descriptions is left largely underspecified. The description covers the preset axis well but omits how the other four parameters behave and what the tool actually returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the schema carries no enums, so the description is the only source of parameter meaning. It usefully enumerates the valid preset values, but says nothing about delay, easing, duration, or iterations, leaving four of five parameters semantically undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: generate CSS @keyframes animations, and adds a scoping detail (reduced-motion mode). It also enumerates every supported preset, which lets an agent confirm capability without opening the schema. It does not, however, distinguish itself from siblings like generate_easing or animation_browser_support.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisite (e.g. that a preset is required), and no routing to alternatives such as generate_easing for timing functions or animation_a11y_checklist for accessibility validation. The agent must infer the trigger conditions entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
把彈簧物理參數（stiffness、damping、mass）模擬後轉成 CSS linear() 緩動函式與建議時間。
| Name | Required | Description | Default |
|---|---|---|---|
| mass | No | ||
| damping | No | ||
| stiffness | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, but for what is evidently a pure stateless computation the risk surface is small. It does disclose the shape of the output (a CSS linear() function and a suggested duration), which is useful context; it does not state defaults, units, or what happens when parameters are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the input-to-output mapping is stated immediately. It is efficient rather than padded, though it is arguably terse given the schema gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description does at least name the returned artifacts, but it omits defaults, units, and the meaning of an omitted mass/damping/stiffness while declaring zero required parameters. Adequate at a minimum-viable level but with clear gaps for a parameterized simulation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and all three parameters are undocumented there, so the description must compensate. It names the three parameters (mass, damping, stiffness) and identifies them as spring-physics quantities, but gives no units, ranges, defaults, or behavior when any of the zero required parameters are left out.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific transformation: simulate spring physics parameters (stiffness, damping, mass) and convert them into a CSS linear() easing function plus a suggested duration. That is a concrete verb+resource an agent can recognize. It stops short of explicitly contrasting with the sibling generate_easing, which an agent might otherwise pick for the same task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus generate_easing or the other animation siblings, and no prerequisites or exclusions. The agent must infer from the name that this is the spring-physics-specific easing path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
產生網頁背景影片壓縮的 ffmpeg 指令（H.264、VP9、AV1、poster）與 HTML video 語法。
| Name | Required | Description | Default |
|---|---|---|---|
| fps | No | ||
| audio | No | ||
| input | No | ||
| width | No | ||
| output | No | ||
| quality | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and leaves the most important question unanswered: whether the tool merely emits a command string or actually runs ffmpeg and writes files. No permission needs, no side effects, no reversibility, and no note on how output is returned are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler; it states the deliverable and the variants in one pass. Nothing is redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter, zero-annotation, no-output-schema tool, the description is far too thin: no parameter mapping, no execution semantics, no return-value shape. It is complete only in identifying the domain, not in enabling a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 6 parameters, so the description must compensate but adds nothing about fps, audio, input, output, width, or quality. Worse, it advertises codecs (H.264, VP9, AV1) that have no corresponding schema parameter, while the one enum (quality: high/balanced/small) is never explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource (generating ffmpeg commands) plus the concrete targets: H.264/VP9/AV1 codecs, a poster, and HTML video markup. No sibling tool does anything similar (they are all CSS/animation helpers), so differentiation is effectively achieved. It stops short of 5 only because it never states the output artifact form (a copy-pasteable command string vs. an executed render).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to reach for this tool versus alternatives, no mention of required inputs or prerequisites (does a source video file already need to exist?), and no exclusions. The agent must infer the workflow entirely from the name and codec list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
animation_a11y_checklistanimation_browser_supportcompare_animation_librariesgenerate_easinggenerate_gradientgenerate_keyframesspring_to_css_linearweb_video_ffmpeg597 motion/3D UI patterns as ready HTML/CSS/JS, served over MCP. The entire library is free.
Neonix compiles HTML and CSS into a real, exportable motion video.
Deterministic procedural SVG/PNG backgrounds: 58 generators, curated palettes, brand kits.
UI design that stands out. Full-screen UI references and design materials for coding agents.
Add one secure layer between your agents and this server.
