gsap-mcp

by bl00dclot

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count4/5
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.
Completeness5/5
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.
Average 3.9/5 across 18 of 18 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness1/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines5/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![gsap-mcp MCP server](https://glama.ai/mcp/servers/bl00dclot/gsap-mcp/badges/card.svg)](https://glama.ai/mcp/servers/bl00dclot/gsap-mcp)

Score Badge

Copy to your README.md:

[![gsap-mcp MCP server](https://glama.ai/mcp/servers/bl00dclot/gsap-mcp/badges/score.svg)](https://glama.ai/mcp/servers/bl00dclot/gsap-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bl00dclot/gsap-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server