This server lets AI clients browse, search, and inspect the Hyperiux Vault library of React/Next.js animation effects and install them into projects.
Browse/search effects: List or search the Vault catalog by name or category (hyperiux_list_effects)
See effect categories: Get all available categories with effect counts (hyperiux_list_categories)
Get effect details: Fetch full metadata for a specific effect — description, tier (free/pro), dependencies, version, changelog, install command, import path, and preview URL (hyperiux_get_effect)
Retrieve source code: Optionally include full component source for free effects, or Pro effects when authenticated
Check install limits: See how many daily installs remain and whether an effect is rate-limited or requires a Pro account
Install guidance: Provides exact install commands and import statements so AI clients can add effects to a project
A collection of high-quality animation effects and interactive components for Next.js - designed by Hyperiux.
47 effects are free and open source. 91 pro effects are 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
47 free effects - install without any account: 47 free effects - install without any account:
npx hyperiux add rotation-slider
npx hyperiux add spider-particles
npx hyperiux add phantom-image-trail91 pro effects - require a Pro subscription:
npx hyperiux login # authenticate once
npx hyperiux add grid-tunnelScroll-driven animations built on GSAP ScrollTrigger - parallax galleries, pinned sequences, horizontal storytelling, stacking cards, and more.
sticky-content-wrapper · horizontal-feature-reveal · infinite-perspective-slider · parallax-slider · rotation-slider · text-convergence · scroll-distortion · +more
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 · +more
Pointer-following image and pixel effects for expressive cursor interactions.
phantom-image-trail · pixelated-image-effect
Animated loading indicators for numeric, stacked, and motion-heavy states.
numeric-tunnel · stack-loader
Menus and navbars with desktop and mobile interaction patterns.
directional-menu · elevate-navbar · immersive-full-screen-nav
Scroll-driven animations built on GSAP ScrollTrigger - pinned sequences, perspective sliders, split canvases, and content reveals.
circular-split-roll · horizontal-feature-reveal · infinite-perspective-slider · rotation-slider · split-canvas · sticky-content-wrapper · text-convergence
Letter-level and line-level reveal animations - blur, scramble, stagger, perspective flip, mask wipe.
blur-text · rectangular-text-reveal · text-fill-animation · scramble-text · +more
Page and section transitions built from animated grids and block-based motion.
block-transition · chess-grid-transition
Three.js, R3F, and shader-driven effects for frosted glass, image reveal, and particle galaxies.
fractal-glass · interactive-blur-reveal · milky-way
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 as hyperiux-mcp-server (not yet published to npm as of this writing - see packages/mcp-server for local usage)
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 (public/r/index.json) lists all effects with metadata - pro file contents are not publicly accessible.
packages/mcp-server isn't on npm yet, so point your MCP client at a local build instead of npx:
pnpm --filter hyperiux-mcp-server buildThen add it to your client's MCP config using an absolute path to the built entrypoint:
{
"mcpServers": {
"hyperiux": {
"command": "node",
"args": ["/absolute/path/to/hyperiux-components/packages/mcp-server/dist/index.js"]
}
}
}See packages/mcp-server/README.md for the full tool list and Pro-effect auth behavior. npm publishing is future work, not the current install path.
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 CLI and free effects are licensed under the Mozilla Public License 2.0 (MPL-2.0). 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).
Does NOT return which effects are Pro vs Free - the catalog index this reads from doesn't carry that field today. Use hyperiux_get_effect on a specific slug to check its tier before assuming it's installable without a Hyperiux Pro account.
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 }], has_more, next_offset? }
Examples:
"What cursor effects are available?" -> category="cursor"
"Is there anything with 'particles' in the name?" -> query="particles"
Don't use when: you need one effect's full description/props/tier - 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 mark this as read-only and idempotent, so the safety profile is covered. The description adds important behavioral context beyond annotations: it discloses that the listing does NOT include Pro vs Free status and warns agents not to assume installability. It also documents the exact JSON return shape since no output schema exists.
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 well-structured with clear sections: purpose, key limitation, args, return shape, examples, and when-not-to-use. Every sentence adds information an agent needs, and the critical caveat about Pro vs Free is 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?
Given there is no output schema, the description fully covers the return format including pagination fields like total, count, offset, has_more, and next_offset. It also handles the main ambiguity (tier status) and guides the agent to sibling tools for missing information, making it complete 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 coverage is 100%, so the baseline is 3. The description adds value by pairing natural-language intents with parameter usage ('What cursor effects are available?' -> category='cursor'), which helps an agent translate user requests into correct arguments. It also summarizes defaults, though most details are already in the 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 states a specific verb ('browse or search') and a clear resource ('Hyperiux Vault catalog of React/Next.js interaction effects'), and it enumerates representative effect types. It also distinguishes itself from siblings by explicitly directing detail/tier lookups to hyperiux_get_effect and category discovery to hyperiux_list_categories.
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 concrete natural-language usage examples, explains when to use query vs category, and explicitly says 'Don't use when: you need one effect's full description/props/tier - use hyperiux_get_effect instead.' This is explicit routing with alternatives and conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: list_effects searches the catalog, get_effect fetches details for one known slug, and list_categories provides category metadata. The descriptions also include explicit 'don't use when' guidance that prevents confusion.
All tools follow the same hyperiux_verb_noun pattern: hyperiux_list_effects, hyperiux_get_effect, and hyperiux_list_categories. The naming is predictable and makes the resource and action immediately clear.
Three tools is appropriately scoped for a read-only catalog server: one to browse/search effects, one to fetch details, and one to list categories. Each tool has a distinct role and none feel redundant.
The catalog lifecycle is well covered: list categories, search/browse effects, then retrieve full details including dependencies, install instructions, and source code when accessible. The lack of a tier field in list results is noted and workable via get_effect, and no write/install tools are expected for this read-only discovery surface.
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.
Give AI coding agents access to your Vynix visual feedback, bug reports, and AI diagnosis.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Hyperiux-Immersion-Labs/hyperiux-components'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
