UI Kit Aggregator MCP

List UI sources

list_sources

Read-only

Lists eight UI and motion component sources with each site's specialty, license summary, and required environment variables so you can choose the right catalog for your needs.

Instructions

List the eight animation/UI sources with each site's specialty, license summary, and which environment variables unlock paid official registries. Use the specialties to pick a source: MotionSites (motionsites): AI website prompt library for conceptual sites such as landing pages, SaaS marketing pages, and portfolios. Choose this for full-page design prompts, not drop-in components. React Bits (react-bits): React animation components: text effects, backgrounds, and UI micro-interactions, in JavaScript or TypeScript with CSS or Tailwind. Choose this for copy-and-paste React components. Uiverse (uiverse): Community HTML, CSS, Tailwind, and React snippets, including hover effects, buttons, and cards. Choose this for small, standalone UI widgets. Anime.js (anime): Lightweight JavaScript animation engine for timelines, easing, and animating DOM, CSS, or SVG elements. Choose this when you need an animation library or its official docs and examples, not a component kit. Aceternity UI (aceternity): React and Tailwind component library with advanced visual effects, including 3D, parallax, spotlight, aurora, glow, and shader-based visuals. Choose this for polished, cinematic UI blocks. Motion Prompt (motion-prompt): Motion vocabulary and prompt library for describing animations, camera moves, and page transitions to AI. Choose this for named effect terms, copyable prompts, and motion demos, not drop-in UI components. Cult UI (cult-ui): Distinctive React / shadcn-style UI components from the official Cult UI registry. Choose this for copy-and-paste Cult components, not a general animation engine. Magic UI (magic-ui): Free React and Tailwind animated components (official free / MIT catalog only). Choose this for copy-and-paste Magic UI free blocks; do not use this source for Magic UI Pro. Does not return component source or MotionSites prompt text. When a source or item requires a token or license key that is not configured, the result status is "needs_token" (not "blocked" and not "allowed"). Do not treat that as a quiet failure. Tell the user that this specific content needs a token, name the product (for example Aceternity All-Access or React Bits Pro) and the environment variable (for example ACETERNITY_PRO_TOKEN or REACTBITS_LICENSE_KEY), point them to the official register URLs in the result, and ask whether to configure/add the token or skip this item. Only retry or fetch after the user confirms and the token is in place; if they skip, stop and do not fetch. This server does not collect the secret in the tool call. If the required token is already configured, fetch proceeds when the license otherwise allows it. Hard compliance blocks stay "blocked" with the body omitted: unclear licenses, disallowed scrape or prompt types, MotionSites prompt bodies, Magic UI Pro and other paid catalogs this server does not support, and redistribution the license forbids. Magic UI Pro is not a missing-token case and must not be offered as "add a token". There is no skip_license_check.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_sources"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 12, 2026

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=true, so the description carries the behavioral burden and adds substantial value to the safety profile: it defines the 'needs_token' status semantics, explicitly says the server does not collect the secret in the tool call, and hard-blocks unclear licenses, disallowed scrapes, and Magic UI Pro. However, it does not state pagination, return shape, or the format of license summaries and register URLs beyond naming them, so it remains a partial disclosure of observable behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence is well front-loaded, but the body is long and repeats the same 'Choose this for ...' template eight times, then appends a dense operational policy block about tokens and blocked statuses. That policy is genuinely useful, yet a large portion could be compressed or delegated to a shared conventions section; the result is a wall of text with little structural separation.

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?

There is no output schema, so the description must explain the return values and it does: per-source specialty, license summary, unlocking env vars, and the status vocabulary ('needs_token', 'blocked', no 'skip_license_check'). Combined with the explicit handling instructions for each status, an agent has everything needed to call this correctly and react to its results.

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 tool takes zero parameters, so the baseline is 4. The description correctly implies no input is needed and instead explains what the (parameterless) invocation yields, which is the right trade-off for a no-arg catalog tool.

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 first sentence names a specific verb and resource ('List the eight animation/UI sources') and states exactly what each entry contains: specialty, license summary, and unlocking environment variables. It is immediately distinguishable from search_ui_kits or get_item, which act on individual sources/items rather than enumerating the catalog.

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?

Every source entry pairs a description with an explicit selection rule ('Choose this for copy-and-paste React components', 'Choose this when you need an animation library ... not a component kit'), and it names negative cases such as Magic UI Pro and MotionSites prompt bodies. It also specifies a full protocol for the needs_token case: notify the user, name the product and env var, ask before retrying, do not fetch if skipped.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server