This MCP server lets AI clients browse and inspect the Hyperiux Vault library of React/Next.js animation effects.
List effects (hyperiux_list_effects): search/filter the catalog by name substring or category, with pagination (limit/offset) and metadata like dependencies and version.
Get effect details (hyperiux_get_effect): fetch full metadata for a specific effect slug — description, tier (free/pro), dependencies, changelog, install command, import statement, and optionally full source code when accessible.
List categories (hyperiux_list_categories): see all effect categories with effect counts, useful for discovering what's available or validating a category slug.
A collection of high-quality animation effects and interactive components for Next.js - designed by Hyperiux.
150+ effects in total - 50+ free and open source, 100+ pro effects available with a Pro subscription. The CLI installs source code directly into your project - you own what you install.
npx hyperiux initnpx hyperiux add rectangular-text-revealimport RectangularTextReveal from "@/components/effects/rectangular-text-reveal";
export default function Page() {
return <RectangularTextReveal>Hello, world.</RectangularTextReveal>;
}Related MCP server: MCP Three
Command | Description |
| Initialize config in your project |
| Add an effect to your project |
| List all available effects |
| Connect your Pro account |
| Remove saved credentials |
| Show login status |
add--overwrite - overwrite existing files
--yes - skip confirmation prompts
--dry-run - preview without writing files
50+ free effects - install without any account:
npx hyperiux add rotation-slider
npx hyperiux add spider-particles
npx hyperiux add phantom-image-trail100+ pro effects - require a Pro subscription:
npx hyperiux login # authenticate once
npx hyperiux add grid-tunnelLetter-level and line-level reveal animations - blur, scramble, stagger, perspective flip, mask wipe.
rectangular-text-reveal · blur-text · text-fill-animation · scramble-text · +more
Ambient canvas and particle backgrounds that sit behind content without competing for attention.
dot-transition · dotted-grid · spider-particles
Interactive button treatments - fill sweeps, metallic sheens, shiny highlights, and scramble-on-hover text.
arrow-fill-button · link-button · metallic-button · scramble-link-button · shiny-button
Slider and carousel patterns beyond a plain swipe - arc paths, 3D flips, parallax strips, and zoom transitions.
arc-flow-carousel · dimensional-switch-slider · ellipse-carousel · orbit-flip-slider · +more
Scroll-driven animations built on GSAP ScrollTrigger - parallax galleries, pinned sequences, horizontal storytelling, and stacking cards.
sticky-content-wrapper · horizontal-feature-reveal · infinite-perspective-slider · rotation-slider · circular-split-roll · split-canvas · +more
Small, self-contained UI pieces - accordions, counters, timelines, and hover-driven lists.
animated-faq · border-beam · gooey-counter · gsap-flip-card · +more
Menus and navbars with desktop and mobile interaction patterns.
directional-menu · elevate-navbar · immersive-full-screen-nav
Canvas 2D and Three.js cursor effects - image trails, rope followers, liquid glass, character grids.
phantom-image-trail · pixelated-image-effect · liquid-glass-cursor · magnetic-image-trail · character-trail · rope-cursor · +more
Page and section transitions built from animated grids and block-based motion.
block-transition · chess-grid-transition
Animated loading indicators for numeric, stacked, and motion-heavy states.
numeric-tunnel · stack-loader
Three.js and R3F scenes with custom GLSL shaders - image carousels, pixel grids, frosted glass, GPU particle galaxies, and 3D heroes.
interactive-blur-reveal · mouse-pixelation · grid-tunnel · draggable-canvas · milky-way · fractal-glass
hyperiux.json is created at your project root by init:
{
"$schema": "https://vault.hyperiux.com/schema.json",
"tailwind": {
"config": "tailwind.config.js",
"css": "src/app/globals.css"
},
"aliases": {
"components": "@/components",
"effects": "@/components/effects",
"hooks": "@/hooks",
"lib": "@/lib"
}
}Variable | Purpose |
| Use a CLI token without saving it locally (useful in CI) |
| Override the Hyperiux app URL for self-hosting or testing |
| Override the API URL independently of the app URL |
| Override the registry URL for local development |
| Set to |
This is a pnpm monorepo with Turborepo:
packages/cli - npx hyperiux CLI tool, published to npm as hyperiux
packages/mcp-server - MCP (Model Context Protocol) server that lets AI clients (Claude, Cursor, etc.) browse and install Vault effects; published to npm as hyperiux-mcp-server
registry/effects - Free effect source, organized by category
Pro effect source lives in a private repository and is served via a protected API. The registry index (registry/index.json) lists all effects with metadata - pro file contents are not publicly accessible.
Add it to your client's MCP config via npx:
{
"mcpServers": {
"hyperiux": {
"command": "npx",
"args": ["-y", "hyperiux-mcp-server"]
}
}
}Contributing to the server itself? Point your MCP client at a local build instead - see packages/mcp-server.
See packages/mcp-server/README.md for the full tool list and Pro-effect auth behavior.
Found a bug or want to contribute a free effect? Pull requests are welcome.
git clone https://github.com/Hyperiux-Immersion-Labs/hyperiux-components
cd hyperiux-components
pnpm install
pnpm devTo add a new free effect, follow the Adding a New Effect checklist in CLAUDE.md.
Node.js 18+
Next.js (App Router)
Tailwind CSS
🌐 Agency | |
🎨 UI Library | |
💻 GitHub |
The hyperiux CLI and the hyperiux-mcp-server are licensed under the MIT License. Free effects installed through the CLI are provided under the Hyperiux Effects License. Pro effects require an active Hyperiux Pro subscription and are proprietary - not open source, not redistributable.
Get full details for one Hyperiux Vault effect by its exact slug - description, tier (free/pro), npm dependencies, version, changelog, and install instructions. Optionally includes full source code.
Args:
name (string): exact effect slug
include_source (boolean, default false): also return component source. Free effects: always available. Pro effects: only if authenticated (see below).
Returns JSON: { name, title, description, tier, version, dependencies, changelog, install_command, preview_url, import_path, target, main, import_statement, files: [{ path, content? }] }
changelog: array of { version, date, summary, breaking }, newest first
files[].content is omitted unless include_source=true AND the effect is accessible (free, or Pro with a valid token)
import_statement is the exact import line to use after installing (e.g. import { DottedGrid } from "@/components/effects/dotted-grid";), built from exportKind/exportName/import_path the same way the CLI's own hyperiux add output does - omitted if the registry entry has no import_path
install_limit/install_remaining: present on a normal (non-rate-limited) lookup, telling you how many more distinct effects this identity can fetch today - mention this to the user when remaining is low, same as the website's copy toast and the CLI's own "N of M daily installs left" line
Pro effects without a token: the response still includes metadata (description, dependencies, changelog) but files have no content, and a note explains the effect requires a Hyperiux Pro account - don't treat this as an error, it's expected for unauthenticated Pro lookups.
Free effects past the caller's daily install cap: the response still includes metadata but files have no content, and rate_limited/rate_limit_reason explain the daily limit and when to retry - also not an error, it's expected once the cap is hit.
Examples:
"What does the dotted-grid effect need?" -> name="dotted-grid" (dependencies field)
"Show me the code for circle-text-reveal" -> name="circle-text-reveal", include_source=true
Don't use when: you don't have an exact slug yet - use hyperiux_list_effects first.
Error Handling:
Returns "Effect '' not found" if the slug doesn't exist - check hyperiux_list_effects for the correct spelling.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact effect slug, e.g. 'dotted-grid', 'circle-text-reveal'. Get this from hyperiux_list_effects. | |
| include_source | No | Include full component source in the response. Free-tier effects always include it; Pro-tier effects only include it if a Hyperiux token is available (HYPERIUX_TOKEN env var, or a saved `hyperiux login` session). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations supply readOnly/idempotent/destructive hints, but the description goes far beyond them: it discloses the conditional access for Pro effects, the rate-limit response shape, the install_limit/install_remaining fields, and explicitly states that rate-limited or Pro-without-token responses are not errors. This gives an agent full expectation for all non-happy paths.
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?
Despite being long, every section earns its place: main purpose, args, return structure, auth/rate limit edge cases, examples, and error handling. The bullet/heading structure makes it easy to parse, and the core result is front-loaded before the longer edge-case details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully specifies the return JSON shape, conditionally omitted fields, and the meaning of install_limit/install_remaining. It also covers error handling, examples, and conditions for include_source. An agent has everything needed to invoke and interpret this tool 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?
The input schema already covers both parameters thoroughly, including the default for include_source and the exact meaning of the slug. The description's parameter section restates this with no additional semantic value beyond what schema descriptions already proide, so the baseline of 3 applies.
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 opens with a specific verb and resource: 'Get full details for one Hyperiux Vault effect by its exact slug' and lists the exact fields returned. It also explicitly contrasts with the sibling hyperiux_list_effects via the 'Don't use when' guidance, making the tool's scope immediately 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?
The description explicitly states when to use this tool versus the sibling: 'Don't use when: you don't have an exact slug yet - use hyperiux_list_effects first.' It also gives concrete example queries and covers edge cases like unauthenticated Pro lookups and rate-limited free lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every effect category in the Hyperiux Vault catalog with how many effects are in each - useful before calling hyperiux_list_effects with a category filter, to confirm the exact category slug and see relative size.
Returns JSON: { categories: [{ category, count }] }, sorted by count descending.
Examples:
"What kinds of effects does Hyperiux have?" -> call with no args
Don't use when: you already know the category slug and just want its effects - call hyperiux_list_effects directly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds non-redundant behavioral details: the exact JSON return format, the sort order (count descending), and that it takes no arguments. No contradiction with 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?
Every sentence earns its place: purpose, return shape, sort order, usage example, and a clear don't-use-when rule. The structure front-loads the core behavior and uses compact examples instead of verbose prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with no output schema, the description fully covers what an agent needs: what it returns, in what order, when to call it, and when to choose a sibling instead. Nothing essential is missing.
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?
There are zero parameters, so the schema and context signals already make parameter usage trivial. The description still explicitly confirms invocation with no args, aligning with the baseline for param-free tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List'), a clear resource ('every effect category in the Hyperiux Vault catalog'), and the key detail of per-category effect counts. The differentiation from siblings is explicit by focusing on categories as distinct from effects and individual effect retrieval.
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?
Provides explicit guidance: use before hyperiux_list_effects with a category filter to confirm slugs and sizes, and explicitly says not to use it when the slug is already known and effects are wanted. It names the exact alternative tool and the condition under which to switch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse or search the Hyperiux Vault catalog of React/Next.js interaction effects (scroll systems, cursor trails, WebGL scenes, animated buttons, page transitions, etc).
Each result includes tier ("free" or "pro") - use this to answer "how many free/pro effects are there" or "which of these are free" directly from one call, by filtering/counting the returned list yourself. Don't estimate or guess these counts, and don't call hyperiux_get_effect per-item just to total them up - it's unnecessary here. hyperiux_get_effect is still the right call for one specific effect's full description/props/changelog.
Args:
query (string, optional): substring match against effect name
category (string, optional): filter to one category slug
limit (number, default 30, max 100)
offset (number, default 0)
Returns JSON: { total, count, offset, effects: [{ name, category, categories, dependencies, version, tier }], has_more, next_offset? }
Examples:
"What cursor effects are available?" -> category="cursor"
"Is there anything with 'particles' in the name?" -> query="particles"
"How many free effects are there?" -> call with a limit high enough to cover total (check total/has_more first), then count tier === "free" yourself.
Don't use when: you need one effect's full description/props/changelog - use hyperiux_get_effect instead.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return. | |
| query | No | Case-insensitive substring match against effect name (e.g. 'cursor', 'text-reveal'). Omit to list all. | |
| offset | No | Number of results to skip for pagination. | |
| category | No | Filter to one category, e.g. 'text', 'cursor', 'webgl', 'buttons', 'carousels', 'components', 'navigation', 'backgrounds', 'loaders', 'transitions'. Use hyperiux_list_categories to see all valid values with counts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description adds valuable behavioral context: the response includes total/count/has_more/next_offset, tier filtering must be done client-side, and per-item calls are unnecessary for totals. This goes beyond the structured annotations without contradicting them.
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 long but organized and every section earns its place: purpose, return shape, examples, and explicit exclusions. Important guidance (tier counting, avoid per-item calls) is front-loaded, and the 'Don't use when' clause is a strong disambiguation that prevents costly mistakes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by declaring the exact JSON return shape, pagination fields, and the tier field. It also covers parameter selection, category validation via a sibling tool, and when to delegate to hyperiux_get_effect, making the tool fully self-contained for correct invocation.
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 100%, so the baseline is 3; the description largely restates parameter defaults and meanings. However, it adds practical usage semantics through examples (e.g., 'What cursor effects are available?' -> category='cursor') and guidance to size limit by checking total/has_more for counting questions, which helps agents use the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Browse or search') and resource ('Hyperiux Vault catalog of React/Next.js interaction effects'), and lists concrete effect types. It also explicitly distinguishes itself from hyperiux_get_effect, so an agent can pick the right tool without ambiguity.
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 explains when to use this tool (browsing/searching, counting free/pro tiers) and when not to use it, naming the alternative hyperiux_get_effect for full effect details. It also provides concrete examples mapping questions to parameters and points to hyperiux_list_categories for valid category values.
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.
v0.1.0hyperiux_get_effecthyperiux_list_categorieshyperiux_list_effectsScored across 3 tools
Each tool covers a distinct stage of the catalog workflow: listing categories, listing/searching effects, and fetching one effect's full details. There is no functional overlap between them, and the descriptions explicitly state when to use or avoid each tool.
All tool names follow the same `hyperiux_verb_noun` pattern: `hyperiux_list_categories`, `hyperiux_list_effects`, and `hyperiux_get_effect`. Verb usage is consistent and clearly maps to the action each tool performs.
Three tools is an appropriate, well-scoped count for a read-only catalog server. Each tool earns its place and together they cover browsing, searching, and retrieving detailed information without unnecessary surface area.
The tool set fully covers the natural catalog workflow: discover categories, browse or search effects, then retrieve full details and source for a specific effect. For this server's stated purpose, there are no obvious dead ends or missing operations.
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
Search your knowledge bases from any AI assistant using hybrid RAG.
Find UI components and themes, retrieve code, and generate with hosted 21st AI when enabled.
