Generates GSAP animation code tailored for Angular components, leveraging Angular's animation system integration.
Generates GSAP animation code tailored for React components, including hooks and integration patterns.
Generates GSAP animation code tailored for Svelte components, utilizing Svelte's reactive statements and actions.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gsap-mcp Generate a fadeIn preset for .hero"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for generating GSAP animation code — no runtime dependency, pure static code generation.
npm install
npm run buildRelated MCP server: Ultimate GSAP Master MCP Server
Add to your Claude Desktop config (~/.claude/claude_desktop_config.json):
{
"mcpServers": {
"gsap": {
"command": "node",
"args": ["/absolute/path/to/gsap-mcp/dist/index.js"]
}
}
}Tool | Description | Example Input |
| Generate gsap.to/from/fromTo tweens |
|
| Build multi-step GSAP timelines |
|
| Look up and preview GSAP easing functions |
|
| Generate common animation presets (fadeIn, slideUp, etc.) |
|
Tool | Description | Example Input |
| ScrollTrigger-powered scroll animations |
|
| SplitText character/word/line animations |
|
| SVG shape morphing with MorphSVGPlugin |
|
| SVG stroke drawing animations |
|
| Animate elements along motion paths |
|
| FLIP animation state transitions |
|
| Text replacement and scramble effects |
|
Tool | Description | Example Input |
| Static analysis for performance, best practices, accessibility |
|
| Play/pause/reverse/seek control code |
|
| GSAP utility methods (clamp, mapRange, snap, etc.) |
|
| Responsive animations with gsap.matchMedia() |
|
| Debug utilities: markers, GSDevTools, logging, slow-motion |
|
| FPS monitoring, code optimization, frame profiling |
|
| Framework-specific code for React/Vue/Angular/Svelte |
|
gsap-mcp/
├── src/
│ ├── index.ts # Entry point — registers all 18 tools
│ ├── generators/
│ │ ├── code-builder.ts # Fluent builder for imports + body assembly
│ │ └── templates.ts # formatGsapVars, formatPosition, wrapInFunction
│ ├── knowledge/
│ │ ├── easings.ts # Easing function database
│ │ ├── properties.ts # CSS/GSAP property mappings + performance data
│ │ └── best-practices.ts # Optimization rules, performance tips, pitfalls
│ └── tools/
│ ├── core/ # Tween, timeline, easing, presets
│ ├── plugins/ # ScrollTrigger, SplitText, MorphSVG, etc.
│ └── dev/ # Analyze, controls, utilities, debug, etc.
├── tests/ # Mirrors src/ structure, 23 test files
├── dist/ # Built output (tsc)
├── package.json
└── tsconfig.jsonKey design decisions:
No GSAP runtime dependency — the server generates code strings using static knowledge bases and template builders. It never imports or executes GSAP itself.
Testable core functions — every tool exports a generateXxxCode(params) function that is directly testable without MCP infrastructure.
MCP SDK pattern — each tool exports a registerXxxTool(server) function that calls server.registerTool() with Zod v4 input schemas.
CodeBuilder — fluent builder that manages imports, plugin registration, and body lines, then assembles them with build() (full) or buildSnippet() (body only).
# Run all tests
npx vitest run
# Watch mode
npx vitest
# Type-check
npx tsc --noEmit
# Build
npx tsc
# Dev mode (tsx)
npx tsx src/index.tsCreate src/tools/<category>/<name>.ts
Export generateXxxCode(params): XxxResult (testable core logic)
Export registerXxxTool(server: McpServer) (MCP registration)
Add import + register call in src/index.ts
Create tests/tools/<name>.test.ts
Run npx tsc --noEmit && npx vitest run
MIT
Audit existing GSAP animation code for performance, optimization, and accessibility issues. Use when you want to check code before delivering it — detects layout-triggering properties, GSAP v2 syntax, missing registerPlugin(), stagger risks, and missing prefers-reduced-motion handling. Returns scored issues with severity and fix suggestions. For generating new animation code use gsap_tween or gsap_timeline instead.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The GSAP code to analyze | |
| checkPerformance | No | ||
| checkAccessibility | No | ||
| suggestOptimizations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses the types of issues detected (layout-triggering properties, v2 syntax, missing registerPlugin(), etc.) and the return format (scored issues with severity and fix suggestions). However, it does not mention if the tool modifies code or requires authentication, but given it's an audit tool, likely read-only.
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?
The description is only two sentences: the first clearly states the purpose, and the second provides usage guidance and alternatives. It is front-loaded with the most important information and contains no unnecessary words.
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 4 parameters, no output schema, and no annotations, the description provides a good overview of what the tool does and returns. It could be more complete by specifying the output format or how the code input should be structured, but it is adequate for an analysis 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 coverage is only 25% (only 'code' has a description). The description adds context by listing the categories of issues it checks (performance, optimization, accessibility), which partially maps to the boolean parameters checkPerformance and checkAccessibility. However, it does not explicitly explain 'suggestOptimizations' or the default values, leaving some gaps.
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 clearly states the verb 'audit', the resource 'existing GSAP animation code', and the scope 'performance, optimization, and accessibility issues'. It distinguishes itself from sibling tools by specifying that gsap_tween or gsap_timeline should be used for generating new code.
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?
Explicit guidance: 'Use when you want to check code before delivering it' and lists specific issues detected. It also provides alternatives for generating new code, making it clear when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate playback control code for an existing tween or timeline variable (play, pause, reverse, seek, timeScale, kill, progress). Use when you need runtime control over an animation you have already created. Provide the JS variable name (e.g. tl, heroAnimation) in variableName — NOT a CSS selector. For generating the animation itself use gsap_tween or gsap_timeline instead.
| Name | Required | Description | Default |
|---|---|---|---|
| value | No | Value for seek (seconds or label), timeScale (multiplier), or progress (0–1) | |
| action | Yes | The control action to generate | |
| target | No | Target type: tween, timeline, or global | timeline |
| selector | No | Deprecated: use variableName instead. Accepted for backward compatibility. | |
| generateUI | No | Generate an HTML control panel | |
| variableName | No | JavaScript variable name of the tween or timeline to control, e.g. tl, heroAnimation. NOT a CSS selector. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full responsibility. It explains it outputs control code, requires a variable name, and lists actions. Could be more specific about output format (e.g., returns JavaScript string), but adequately covers core behavior.
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?
Three concise sentences front-load purpose, usage, and key clarifications. No wasted content.
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?
Description plus schema sufficiently cover purpose, parameters, and usage. Missing explicit return value description (no output schema), but the phrase 'Generate... code' implies the output. Overall adequate for an agent to select and invoke correctly.
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 covers 100% of parameters with descriptions. Description adds minimal value, e.g., examples for variableName and emphasis that it is not a CSS selector, but overall aligns with schema baseline.
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?
Description clearly states it generates playback control code for existing tweens/timelines, listing specific actions (play, pause, etc.). It distinguishes from sibling tools by directing users to gsap_tween/gsap_timeline for animation creation.
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?
Explicitly states when to use ('when you need runtime control over an animation you have already created') and when not to use (pointing to alternatives). No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate debugging utilities for GSAP animations during development. Modes: visualize (ScrollTrigger markers + timeline info log), gsdevtools (GSDevTools panel — requires Club GSAP membership), log (onUpdate progress/time logging), slowmo (slow down all animations via globalTimeline.timeScale), labelDump (print all timeline labels). Use only during development — remove all debug code before production.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Debug action to generate | |
| target | No | Timeline variable name | tl |
| options | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and thoroughly explains each mode's behavior: visualize enables markers and logging, gsdevtools requires Club GSAP membership, log tracks progress/time, slowmo scales global timeline speed, and labelDump prints labels. It also warns about production cleanup.
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?
The description is concise: one paragraph efficiently lists modes with brief explanations and ends with a critical usage guideline. Every sentence adds value, and there is no redundancy.
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?
The description covers purpose, usage, and behavioral details adequately for a debug tool, but lacks explicit mention of output format (e.g., generated code snippets). With no output schema, some additional context about return values would improve completeness.
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 description adds value by explaining the action modes beyond the schema's enum listing, but does not elaborate on the 'target' or 'options' parameters. Given schema description coverage is 67%, the description partially compensates with action details, justifying a score of 4.
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 clearly states the tool generates debugging utilities for GSAP animations, listing specific modes (visualize, gsdevtools, log, slowmo, labelDump) with brief explanations. It distinguishes itself from sibling tools by focusing on development-specific debugging actions.
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?
The description explicitly advises using this tool only during development and removing debug code before production, providing clear when-to-use guidance. However, it does not directly contrast with siblings like gsap_analyze or gsap_performance, which could be considered related.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Animate SVG stroke drawing progress using DrawSVGPlugin. Use for line-drawing and reveal effects on SVG paths. For morphing between shapes use gsap_morphsvg instead.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End position | 100% |
| from | No | Start position (e.g. "0%", "50% 50%") | 0% |
| target | Yes | CSS selector for SVG path(s) | |
| options | No | ||
| duration | No | ||
| useTimeline | No | ||
| includeImports | 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. However, it does not disclose any behavioral traits beyond the basic purpose, such as side effects, permissions, or return values. The description is minimal and lacks transparency about tool behavior.
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?
The description is extremely concise with two sentences, front-loading the main purpose and usage guidance. Every sentence earns its place, and no extraneous information is included.
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's complexity (7 parameters, nested object, no output schema, low parameter coverage), the description is incomplete. It does not explain how to use the parameters effectively, what the tool returns, or provide examples. The brief description is insufficient for full context.
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 schema description coverage is 43% (low), and the description does not add any meaning beyond what the schema provides. It does not explain the parameters or their usage in more detail, leaving the agent to rely solely on the schema for parameter understanding.
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 clearly states the tool's purpose: 'Animate SVG stroke drawing progress using DrawSVGPlugin.' It also distinguishes it from a sibling tool by specifying 'For morphing between shapes use gsap_morphsvg instead.' This provides a specific verb (animate), resource (SVG stroke), and differentiation.
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?
The description explicitly states when to use this tool: 'Use for line-drawing and reveal effects on SVG paths.' It also provides an alternative: 'For morphing between shapes use gsap_morphsvg instead.' This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up GSAP easing functions by name or category. Returns descriptions, parameters, and preview code. Use this to explore available easings — not to generate animations (use gsap_tween or gsap_timeline for that).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Specific easing to look up (e.g. "elastic.out", "power2.inOut") | |
| preview | No | Include preview code snippets | |
| category | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions return types (descriptions, parameters, preview code) but does not disclose any behavioral traits like side effects, rate limits, or authorization needs. Adequate but not comprehensive.
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 sentences deliver essential information: purpose, output, and usage boundaries. No unnecessary words, perfectly front-loaded.
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 simple lookup tool with 3 optional parameters and no output schema, the description covers purpose, distinction from siblings, and output. Could be improved by specifying what 'category' includes, but given the enum in schema, it's sufficient.
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 67% (2 of 3 parameters have descriptions). Description adds no extra meaning beyond what schema already provides. Baseline 3 is appropriate.
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?
Description uses specific verb 'look up' with clear resource 'easing functions', and distinguishes from sibling tools gsap_tween and gsap_timeline by noting this tool is for exploration, not animation generation.
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?
Explicitly states when to use (explore available easings) and when not to (generate animations), providing clear alternatives (gsap_tween or gsap_timeline).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Animate smooth layout transitions using GSAP Flip (capture-change-animate). Use for reordering, reparenting, or class-toggle DOM changes. For regular positional animations use gsap_tween instead.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Flip workflow action — "full" generates complete capture-change-animate flow, "state"/"getState" captures current state, "from" animates from captured state, "fit" scales/positions element to match another | full |
| options | No | ||
| targets | Yes | CSS selector | |
| stateChange | No | Description of DOM change (comment for full; destination selector for fit) | |
| includeImports | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions 'capture-change-animate' pattern but lacks details on side effects, limitations, or prerequisites. Adequate but not thorough.
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 sentences, front-loaded with key verb and resource, no extraneous words. Highly efficient.
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 5 parameters, a nested object, and no output schema, the description is brief and doesn't cover action enum values or options object details. Adequate for basic understanding but incomplete for complex usage.
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 60%, but description adds no parameter-level information beyond what's in the schema. Core workflow concept is conveyed, but parameters like 'action' and 'options' are not elaborated.
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 clearly states the verb 'Animate' and the resource 'layout transitions using GSAP Flip'. It lists specific use cases (reordering, reparenting, class-toggle) and distinguishes from sibling gsap_tween.
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?
Explicitly states when to use (for reordering, reparenting, class-toggle DOM changes) and when not to use (for regular positional animations, use gsap_tween instead), providing a clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate framework-specific GSAP integration boilerplate with proper animation cleanup. Frameworks: react (hook or component — uses useLayoutEffect + gsap.context for scoped cleanup), vue (composable or component — uses onMounted/onUnmounted + gsap.context), angular (directive or component — uses ngAfterViewInit/ngOnDestroy), svelte (action or component — uses onMount/onDestroy). Always includes cleanup to prevent memory leaks on component unmount.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Integration type (defaults to framework idiom: react→hook, vue→hook, angular→directive, svelte→action) | |
| options | No | Generation options | |
| plugins | No | Plugin names to include (e.g. ["ScrollTrigger"]) | |
| animation | No | Animation configuration | |
| framework | Yes | Target framework |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: it includes cleanup to prevent memory leaks, uses framework-specific lifecycle hooks (e.g., useLayoutEffect for React), and always generates code with cleanup. Since no annotations are provided, the description carries the full burden and does so adequately, though it could mention that it outputs code rather than modifying anything.
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?
The description is highly concise with two sentences: the first states the core purpose, and the second lists frameworks and patterns. Every sentence is informative, and no extraneous information is included.
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 nested parameters and complexity, the description covers the essential behavior thoroughly. It does not detail every option (e.g., scrollTrigger), but the schema covers those. It could mention the output format (e.g., returns code string), but overall it is sufficiently 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?
With 100% schema coverage, the description adds meaning beyond the schema by explaining default integration types per framework (e.g., react defaults to hook) and the cleanup guarantee. This aids understanding without repeating schema details.
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 clearly states the tool generates framework-specific GSAP integration boilerplate with proper cleanup, specifying the verb 'generate' and resource 'boilerplate'. It distinguishes itself from sibling tools like gsap_tween or gsap_timeline, which focus on animation logic, by being explicitly about integration setup.
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?
The description provides clear context on when to use the tool (for integrating GSAP into React, Vue, Angular, or Svelte) and lists the integration types. However, it does not explicitly state when not to use it or mention alternative tools, though the sibling context makes the purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate gsap.matchMedia() code that runs different animations per breakpoint or media query. Use when animations need to change based on screen size or prefers-reduced-motion. Each breakpoint specifies a CSS media query string (e.g. '(max-width: 768px)') and its own animations — GSAP auto-reverts them when the breakpoint stops matching. For a single animation without breakpoints use gsap_tween instead.
| Name | Required | Description | Default |
|---|---|---|---|
| breakpoints | Yes | Array of breakpoints with media queries and animations | |
| includeImports | 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 discloses that GSAP auto-reverts animations when the breakpoint stops matching, which is a key behavioral trait. However, it does not mention any side effects, permission requirements, or performance implications. Overall, it adds useful but not exhaustive behavioral context.
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?
The description is three well-structured sentences with no wasted words. It front-loads the purpose, then provides usage guidance, then distinguishes from a sibling. Every sentence adds 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?
Given no output schema, the description covers the main use case and behavior (auto-revert). It does not explain what happens when no breakpoints match or how the generated code is output. For a code generation tool with simple parameters, it is nearly complete but lacks a minor detail.
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 input schema has 2 parameters with 50% schema description coverage. The description mentions breakpoints and media queries but does not explain the 'includeImports' parameter or provide additional semantics beyond the schema. The description adds minimal value over the schema definitions.
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 clearly states the tool generates gsap.matchMedia() code for running different animations per breakpoint/media query. It explicitly distinguishes from the sibling tool gsap_tween by noting 'For a single animation without breakpoints use gsap_tween.'
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?
The description provides explicit guidance on when to use this tool ('Use when animations need to change based on screen size or prefers-reduced-motion') and when not ('For a single animation without breakpoints use gsap_tween'). No alternative tools are mentioned but the direct sibling differentiation is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Morph one SVG path into another using MorphSVGPlugin. Target and endShape must be SVG path elements or path data strings. For drawing SVG strokes use gsap_drawsvg instead.
| Name | Required | Description | Default |
|---|---|---|---|
| ease | No | power1.inOut | |
| target | Yes | CSS selector for the source SVG path/shape | |
| options | No | ||
| duration | No | ||
| endShape | Yes | CSS selector or raw SVG path data string for the target shape | |
| useTimeline | No | ||
| includeImports | 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 only mentions input type requirements (SVG path elements or data strings) but does not disclose side effects, DOM modifications, or error handling. This is a significant gap.
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?
The description is two sentences, front-loading the core purpose and a usage hint. Every sentence is valuable and there is no waste.
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 7 parameters, low schema coverage, no output schema, and no annotations, the description is too minimal. It fails to explain the complex options object or other parameters, making it incomplete for an 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 low (29%), and the description adds no parameter-specific semantics beyond mentioning target and endShape. Parameters like ease, duration, options, useTimeline, includeImports remain 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?
Description clearly states it morphs one SVG path into another using MorphSVGPlugin, specifying the required inputs (target and endShape) and their types. It distinguishes from gsap_drawsvg, aiding correct tool selection.
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?
Description provides an explicit alternative (gsap_drawsvg) for drawing SVG strokes, but does not elaborate on when to use morphsvg vs other sibling tools like gsap_motionpath or gsap_flip. The context is implied but limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Animate an element along an SVG path or array of points using MotionPathPlugin. Use for curved movement paths. For straight-line positional animation use gsap_tween instead.
| Name | Required | Description | Default |
|---|---|---|---|
| ease | No | none | |
| path | Yes | SVG path selector or points array | |
| target | Yes | CSS selector for the element to animate | |
| options | No | ||
| duration | No | ||
| includeImports | 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 mentions using MotionPathPlugin but does not disclose prerequisites (e.g., library loaded), side effects, or whether the animation is reversible. However, for a simple animation tool, the basic behavior is implied.
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 sentences front-loaded with purpose and usage guidance. Every word adds value; no fluff. The structure is ideal for quick skimming.
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 6 parameters including a complex 'options' object, and no output schema, the description is too minimal. It fails to explain key parameters like 'ease', 'duration', or the structure of 'options', leaving the agent with insufficient context to invoke the tool correctly without referring to external documentation.
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 only 33% (2/6 parameters described). The tool description does not compensate: it only alludes to 'target' and 'path' without adding detail, and ignores parameters like 'ease', 'duration', 'options', and 'includeImports'. Users get no extra context for the majority of 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 uses a specific verb ('Animate') and resource ('element along an SVG path or array of points'), clearly stating the tool's function. It also distinguishes itself from the sibling tool 'gsap_tween' by mentioning curved vs straight-line animation.
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?
Explicitly states when to use this tool ('for curved movement paths') and when not to, providing an alternative ('use gsap_tween instead'). This is clear and helpful for choosing between related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate performance measurement and optimization code for GSAP animations. Three modes: monitor (FPS counter, memory logger, or reflow detector — provide options.metrics), optimize (analyze existing code and annotate performance issues inline — requires code param), profile (measure animation creation time and per-frame render timings). Use monitor and profile during development only.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | Code to optimize (for optimize action) | |
| action | Yes | Performance action to generate | |
| options | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It reveals that monitor and profile are for development only, suggesting no side effects, but fails to describe the tool's output format (e.g., returns code as a string), whether it modifies anything, or any potential performance impact. This is insufficient for an agent to understand 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?
The description is two sentences, front-loading the purpose and then listing modes concisely. It contains no filler or redundancy, though adopting a bulleted or more structured format could improve readability for an agent.
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 absence of an output schema, the description should explain what the tool returns (e.g., generated code snippet, annotations). It also lacks details on error handling, prerequisites (e.g., GSAP version), or any limitations. The description is incomplete for an agent to fully understand the tool's behavior and output.
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 description adds meaning beyond the schema by explaining each mode's parameter usage (e.g., 'monitor ... provide options.metrics'). However, schema coverage is 67% (options lacks a top-level description), and the description does not detail the 'options' object or the possible values for 'action' beyond listing them, leaving some semantic gaps.
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 clearly states it generates performance measurement and optimization code for GSAP animations, listing three distinct modes. This provides a specific verb and resource, but does not explicitly differentiate from sibling tools like 'gsap_analyze' or 'gsap_debug', which could have overlapping purposes.
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?
The description gives context for each mode (e.g., 'requires code param' for optimize, 'provide options.metrics' for monitor) and advises to use monitor and profile only during development. However, it does not explicitly state when to avoid this tool or mention alternatives among the 17 sibling tools, leaving the agent to infer usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate ready-to-use code for common animation patterns (fadeIn, slideUp, bounceIn, staggerReveal, parallax, etc.). Use when the animation matches a standard pattern. For custom animations with specific properties use gsap_tween instead.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| target | No | .element | |
| options | No | ||
| includeImports | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full burden. It states the tool generates 'ready-to-use code' but does not elaborate on the output format, side effects, or limitations. While the core behavior is clear, more detail would be beneficial for a tool with no annotations.
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?
The description is only two sentences: the first states purpose, the second provides usage guidelines. It is tightly written with no unnecessary words, earning its place.
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 output schema, 0% parameter documentation, and moderate complexity (many presets, nested options), the description provides adequate usage guidance but lacks details on return values, errors, or parameter behavior, making it incomplete for full autonomous use.
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 coverage is 0% (no descriptions on properties except one nested 'text' field). The description only lists some preset types but does not explain the purpose of parameters like target, options, includeImports, or the options sub-properties. This leaves agents guessing what most parameters mean.
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 clearly states the tool generates ready-to-use code for common animation patterns like fadeIn, slideUp, etc., and distinguishes itself from gsap_tween for custom animations, making the purpose specific and clear.
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?
Explicitly tells when to use the tool ('when the animation matches a standard pattern') and when not to, directing to gsap_tween for custom animations. This provides clear guidance and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Animate elements based on scroll position using ScrollTrigger. Use for scroll-driven animations (scrub), pin sections, or trigger-on-scroll effects. For scroll-independent animations use gsap_tween or gsap_timeline instead.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | standalone | |
| trigger | Yes | ||
| animation | Yes | ||
| batchOptions | No | ||
| includeImports | 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 of behavioral disclosure. However, it only states what the tool does (animate on scroll) without revealing any behavioral traits such as DOM mutation, side effects, permission requirements, or rate limits. Key operational details are missing.
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?
The description is concise (3 sentences) and front-loaded with the core purpose. However, it could add brief parameter hints without becoming verbose. Minor deduction for not including any parameter guidance where schema coverage is zero.
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?
The tool is complex with 5 parameters, nested objects, and required fields, yet the description provides virtually no context on how to structure the animation, trigger, or batchOptions. Without an output schema, return behavior is also omitted. For this complexity, the description is severely incomplete.
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?
With 0% schema description coverage, the description must compensate by explaining parameters. It does not; only the term 'scrub' is implied. No parameter syntax, allowed values, or usage examples are given. The description adds no semantic value over the bare schema.
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 clearly identifies the tool's purpose as animating elements based on scroll position using ScrollTrigger. It lists three specific use cases (scrub, pin, trigger-on-scroll) and explicitly distinguishes it from sibling tools (gsap_tween/gsap_timeline) for scroll-independent animations.
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?
The description provides explicit guidance on when to use this tool ('scroll-driven animations, pin sections, trigger-on-scroll effects') and directs users to alternatives ('For scroll-independent animations use gsap_tween or gsap_timeline instead'). This provides clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split text into chars, words, or lines then animate with stagger using SplitText. Use when animating individual characters or words. For plain text replacement use gsap_textplugin instead.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Comma-separated: "chars", "words", "lines" | chars,words |
| revert | No | Revert split after animation completes | |
| target | Yes | CSS selector for the text element | |
| animation | Yes | ||
| charsClass | No | ||
| linesClass | No | ||
| wordsClass | No | ||
| useTimeline | No | Wrap in timeline for control | |
| includeImports | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only mentions splitting and animating with stagger. It does not disclose behavioral traits such as DOM modification, revert behavior (though revert parameter exists), class additions, or whether the split is temporary. No annotations provided, so the description carries the full 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?
Two sentences, no wasted words. Could be slightly improved by briefly noting revert or class parameters, but overall efficient.
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?
The tool has 9 parameters, including nested objects, and no output schema. The description is minimal and does not explain important parameters like animation object structure, class options, or revert. It is incomplete for such a complex 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 44%. The description adds no meaningful parameter information beyond what the schema already provides (e.g., mentioning chars/words/lines matches the type parameter default). It does not explain required parameters target or animation structure.
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 clearly states the tool splits text into chars/words/lines and animates with stagger. It differentiates from gsap_textplugin for plain text replacement, but does not differentiate from other text-related siblings like gsap_morphsvg or gsap_drawsvg.
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?
Explicit instructions: 'Use when animating individual characters or words.' and 'For plain text replacement use gsap_textplugin instead.' Provides clear when-to-use and alternative for a common case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Animate text content replacement character-by-character using TextPlugin or ScrambleTextPlugin. Use type 'replace' for typewriter effect, 'scramble' for randomized scramble reveal. For animating split characters use gsap_splittext instead.
| Name | Required | Description | Default |
|---|---|---|---|
| ease | No | none | |
| text | Yes | The target text content | |
| type | No | replace | |
| target | Yes | CSS selector for the text element | |
| options | No | ||
| duration | No | ||
| includeImports | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description is minimal. It does not disclose behavioral traits like DOM modification, library dependencies, or side effects beyond text replacement. Lacks depth for a tool with complex options.
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?
Three sentences, front-loaded with purpose, no redundancy. Every sentence adds 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?
Despite complexity (7 params, nested objects, no output schema, no annotations), the description is too brief. Does not cover parameter details, output behavior, or import requirements. Completeness is insufficient.
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 coverage is low (29%); description adds meaning to 'type' parameter (replace vs scramble) but does not explain 'options', 'ease', 'duration', or 'includeImports'. Partially compensates for low coverage.
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 clearly states it animates text content replacement character-by-character using TextPlugin or ScrambleTextPlugin, with specific verbs and resources. It distinguishes from sibling gsap_splittext for split characters.
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?
Explicitly states when to use 'replace' for typewriter effect and 'scramble' for scramble reveal, and directly advises using gsap_splittext for animating split characters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a GSAP timeline with multiple sequenced or overlapping tweens, labels, and position parameters. Use when you need 2+ animations coordinated together. For a single animation use gsap_tween instead.
| Name | Required | Description | Default |
|---|---|---|---|
| labels | No | ||
| settings | No | ||
| animations | Yes | ||
| variableName | No | tl | |
| includeImports | 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. However, it only mentions building a timeline with tweens and labels, without disclosing any behavioral traits such as side effects, error handling, or what the output looks like. The agent is left without understanding what happens on invocation (e.g., whether code is generated or executed, or if there are any restrictions).
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?
The description is two sentences, front-loaded with the primary action and usage context. No unnecessary words, and it efficiently conveys the core purpose and differentiation.
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?
Despite the tool having a complex nested input schema with 5 parameters (including arrays and objects) and no output schema, the description provides minimal context. It doesn't explain the return value (likely generated GSAP code), nor does it give enough information for an agent to construct a valid timeline with the various sub-properties.
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%, so the description must compensate, but it only generically mentions 'tweens, labels, and position parameters.' It does not explain specific parameters like 'variableName', 'includeImports', 'settings', or the structure of 'animations'. The agent cannot infer parameter meaning from the description alone.
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 clearly states the tool's purpose: building a GSAP timeline with multiple sequenced or overlapping tweens, labels, and position parameters. It explicitly distinguishes from the sibling tool gsap_tween by noting when to use this tool (2+ animations) vs. a single animation.
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?
The description gives explicit guidance on when to use this tool (for 2+ animations coordinated together) and when not to (for a single animation, use gsap_tween). This is sufficient for an agent to decide between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a single GSAP tween (gsap.to, gsap.from, gsap.fromTo, gsap.set). Use for one-off animations on a single target. For sequenced multi-step animations use gsap_timeline instead. For common patterns like fadeIn or slideUp use gsap_preset instead.
| Name | Required | Description | Default |
|---|---|---|---|
| ease | No | Easing function name, e.g. 'power2.out', 'elastic.inOut', 'back.out(1.7)'. Use gsap_easing tool to browse available easings. | power1.out |
| yoyo | No | ||
| delay | No | ||
| method | Yes | 'to' animates TO the given values (most common). 'from' animates FROM the given values to current state. 'fromTo' animates between two explicit states. 'set' applies values instantly with no animation. | |
| repeat | No | ||
| target | Yes | CSS selector or target description | |
| stagger | No | ||
| duration | No | ||
| overwrite | No | ||
| onComplete | No | Function name to call on complete | |
| properties | Yes | GSAP animation properties. Use transform shorthands (x, y, scale, rotation) not CSS transform. Use autoAlpha instead of opacity+visibility. Values can be numbers, strings ('+=100', '50%'), or arrays for keyframes. | |
| fromProperties | No | Starting properties — required for fromTo method | |
| includeImports | No | Set to false when generating a snippet to insert into existing code that already has GSAP imported. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool generates a tween but does not specify output format (e.g., returns code?, applies to DOM?). Lacks detail on side effects or exact behavior beyond the methods listed. Adequate but not rich.
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 sentences, no fluff. Gets straight to purpose and usage guidance. Highly concise.
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 13 parameters, nested objects, and no output schema, the description is too minimal. It does not explain what the tool produces (e.g., a code snippet, a function call, logs to console?) or how the result is delivered. Incomplete for such a complex 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 coverage is 54% (low), but description does not add any parameter meanings beyond what's already in the schema. The description is separate and does not compensate for undocumented parameters. Falls short of adding value.
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?
Description clearly states 'generate a single GSAP tween' and lists the specific methods (gsap.to, from, fromTo, set). It distinguishes from sibling tools like gsap_timeline and gsap_preset by explicitly noting they are for sequenced or common patterns.
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?
Explicitly states when to use this tool ('one-off animations on a single target') and when not to ('sequenced multi-step animations' - use gsap_timeline; 'common patterns like fadeIn' - use gsap_preset). Provides clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate code using GSAP utility functions for math, range mapping, and DOM helpers. Use for value interpolation, clamping, wrapping, snapping, and scoped DOM selection within animation logic. Not for generating animations — use gsap_tween or gsap_timeline for that.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | The GSAP utility method to generate | |
| params | Yes | Method-specific parameters (keys vary by method): interpolate → {start, end, progress}; mapRange → {inMin, inMax, outMin, outMax, value}; clamp → {min, max, value}; wrap → {min, max, value} or {array, index}; wrapYoyo → {min, max, value}; distribute → {amount, base?, from?, ease?}; random → {min, max, snap?}; snap → {snap, value} or {array, value}; normalize → {min, max, value}; pipe → {functions: string[]}; unitize → {func, unit}; toArray → {selector}; selector → {scope}; shuffle → {array} | |
| example | No | Include usage example comment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It correctly characterizes the tool as a code generator with no apparent side effects. However, it does not specify the output format or whether results are deterministic.
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?
The description is extremely concise, with two sentences that front-load the purpose and then clearly state exclusions. Every sentence adds value without redundancy.
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 complexity of the input schema (3 params, nested object) and the lack of output schema or annotations, the description covers the main aspects: purpose, when to use/not use, and parameter details. It could mention the return type (generated code string) but is largely sufficient.
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 coverage is 100%, but the description adds significant value by listing method-specific parameter shapes (e.g., interpolate → {start, end, progress}), providing concrete guidance beyond the schema properties.
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 clearly states the tool generates code using GSAP utility functions for math, range mapping, and DOM helpers, and explicitly distinguishes it from animation generation tools by referencing gsap_tween or gsap_timeline.
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?
The description explicitly lists use cases (value interpolation, clamping, wrapping, etc.) and provides direct guidance on when not to use it, with alternatives (gsap_tween, gsap_timeline).
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.
v1.0.0gsap_analyzegsap_controlsgsap_debuggsap_drawsvggsap_easinggsap_flipgsap_framework_integrationgsap_matchmediagsap_morphsvggsap_motionpathgsap_performancegsap_presetgsap_scrolltriggergsap_splittextgsap_textplugingsap_timelinegsap_tweengsap_utilitiesScored across 18 tools
Each tool targets a distinct GSAP feature or operation, with cross-references to guide agents away from overlapping choices. For example, gsap_tween is for single tweens, gsap_timeline for sequenced animations, and gsap_preset for standard patterns, eliminating ambiguity.
All tools follow a uniform gsap_<noun> pattern, using snake_case. The names are descriptive and predictable, e.g., gsap_tween, gsap_timeline, gsap_scrolltrigger, gsap_preset.
At 18 tools, the set is slightly above the typical range but warranted given the breadth of GSAP features (tweens, timelines, SVG, text, scroll, frameworks, debugging). Each tool serves a well-defined purpose, so the count feels justified rather than bloated.
The tool surface covers nearly all major GSAP capabilities: basic animations, timelines, presets, easing, scroll-driven effects, SVG manipulation, text effects, framework integration, matchMedia, performance monitoring, and debugging. No obvious gaps for typical GSAP use cases.
Game-dev sprite tools: PNG/GIF to spritesheet, split, trim, animate. OAuth-authenticated MCP server.
16 AI-native tools with dual SSE + streamable-http transport. Free tier available.
Turn any live website into brand colors, fonts, design tokens, SVGs, Lottie and paste-ready code.
48-hour HTTPS previews of prebuilt static sites and HTML slides. No server builds or backends.
