Skip to main content
Glama
Hyperiux-Immersion-Labs

Hyperiux MCP Server

Official

Get Hyperiux Effect Details

hyperiux_get_effect
Read-onlyIdempotent

Look up a specific Hyperiux Vault effect by slug to get its description, tier, dependencies, install instructions, and optional source code. Includes import statement and version details.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesExact effect slug, e.g. 'dotted-grid', 'circle-text-reveal'. Get this from hyperiux_list_effects.
include_sourceNoInclude 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).
Install Server

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

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 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.

Other Tools

Latest Blog Posts

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/Hyperiux-Immersion-Labs/hyperiux-components'

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