MIT
appCN
by Salah-XD
appCN
Copy-paste mobile components for React Native + Expo.
A shadcn-philosophy library: you own the source, NativeWind styles the surface, Reanimated drives the motion — and the featured AI-native collection ships streaming bubbles, prompt composers, reasoning traces, and a reactive 3D voice orb.
Browse components · CLI docs · Mobile app · Live showcase · GitHub
Quick start
The CLI handles NativeWind + Reanimated wiring and registers the @app-cn
shadcn namespace for you. One command to set up, one to add a component.
# 1. (Recommended) One-shot project setup
npx @app-cn/cli@latest init
# 2. Add any component by slug
npx @app-cn/cli@latest add voice-spherePrefer your own pipeline? appcn add is a thin wrapper around shadcn — you can
skip the CLI entirely:
# Copy a single component via shadcn (no setup, one-off)
npx shadcn@latest add https://appcn.vercel.app/r/voice-sphere.json
# Or pull the whole library as a managed dep
npm install @app-cn/uiBuilding with an AI agent? Add the appCN MCP server so Claude Code, Cursor, or Windsurf can discover and install components for you — and write new code in appCN's motion/haptic style:
# Claude Code
claude mcp add appcn -- npx -y @app-cn/mcpSee MCP docs for Cursor / Windsurf / VS Code config.
Status: v0.1.0 live on npm. Five components shipped — the AI collection is the marketed wedge and is the first place to land new work.
Related MCP server: bunge-ds-mcp
What's in the box
New: appCN is live on real phones — scan a QR with Expo Go and the entire component gallery loads on Android or iPhone in seconds. No emulator, no developer account. Standalone Play Store APK is in review — shipping soon.
Base
Component | Delight |
| Spring-y press scale to 0.96, settles in 140 ms — feels weighted, never twitchy |
AI-native
Component | Delight |
| Three-phase thinking → token stream → settle |
| Send morphs into a stop with a spinning ring |
| Auto-collapses the instant the answer lands |
| Reactive 3D orb that breathes with voice level |
Every component has an interactive web preview, a QR you can scan with Expo Go to run it live on your phone, and a video — same code path on every surface. → appcn.vercel.app/components
Why appCN
Real-phone previews. Scan a QR with Expo Go and the component runs live on your device with native gestures. No emulator gymnastics.
AI-native flagship. The AI collection is the wedge — components built for AI apps that nobody else ships well.
Quadruple distribution. The
appcnCLI, the shadcn registry,@app-cn/uifrom npm — or the MCP server, so your AI coding agent installs components for you. Same primitives, your call.Motion-first defaults. Reanimated + gesture-handler, shared motion tokens (
duration/easing/spring), one delight detail per component.Dark-mode first. Designed dark, then derived to light. Premium reads as depth, not rainbows.
You own the source. Copy-paste philosophy means no lock-in — once a component lands in your repo, edit freely.
Documentation
Surface | What's there |
Live docs site — landing, every component, live previews | |
| |
Play Store + Expo Go install paths, deep-link contract | |
Architecture, monorepo map, commands, Metro/Reanimated gotchas | |
Taste layer — motion rules, the "one delight detail" rule, the 8-step SOP | |
Dev setup, the Changesets release flow, PR conventions | |
Cross-tool guide for AI coding agents (Claude / Cursor / Windsurf / Codex / Aider) |
Contributing
Every new component ships through the 8-step SOP in DESIGN.md → Component checklist. Don't skip steps — the PR template enforces them and a missing changeset blocks the release pipeline.
Working with an AI agent? Invoke the /new-component Claude skill — it
walks the checklist, drops a typed <slug>.meta.ts template ready to fill,
wires the registry + showcase entries, and verifies with typecheck + registry
build.
Full guide: CONTRIBUTING.md.
Releases
Releases are driven by Changesets and published to npm via OIDC Trusted Publishing — zero long-lived secrets.
pnpm changeset # describe what changed + pick a bump
git commit -am "..." # commit the changeset alongside your code
# Open a PR. After merge to main, a "Version Packages" PR opens automatically.
# Merge that PR → CI publishes via OIDC.Every published version gets a verified provenance badge on npm.
Deploying
Project | Vercel root directory | What it serves |
Docs |
| Landing, |
Showcase |
| Expo web export — the iframe target for interactive previews |
Deploy order (matters):
Deploy the showcase first (
apps/showcase) so you have a URL.Deploy the docs, setting
NEXT_PUBLIC_SHOWCASE_WEB_URLto that URL.Optional: custom domains (
appcn.vercel.app→ docs,appcn-showcase.vercel.app→ showcase).
Required env vars (docs project):
Variable | Value |
|
|
| (empty for v1 — needs EAS Update for the QR tab) |
|
|
The showcase project needs no env vars. Defaults live in
apps/web/.env.example.
Acknowledgments
Inspired by shadcn/ui's copy-paste philosophy and react-native-reusables's docs-site polish. Built on top of NativeWind, Reanimated, and Expo.
License
MIT — you own the code.
Available Tools
5 toolsget_componentGet an appCN componentA
Everything an agent needs to add and correctly use one appCN component: its docs (anatomy, delight detail, props, usage examples, accessibility notes), the actual source file contents, the npm packages and registry helpers it depends on, and the install command. Prefer installing via the install command rather than pasting files by hand — that resolves dependencies for you.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Component slug, e.g. 'button', 'stream-bubble', 'voice-sphere'. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
As no annotations are provided, the description carries the full burden. It discloses that the tool returns comprehensive component details and recommends installation practices. No contradictions or hidden side effects are present.
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 (two sentences) yet informative, front-loading the main purpose and including usage advice without extraneous content.
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?
For a simple tool with one parameter and no output schema or annotations, the description covers purpose, behavior, and usage guidance, making it fully sufficient for correct agent invocation.
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 description coverage, the description adds value by providing examples of valid slugs and clarifying it is a unique identifier, going beyond the schema's minimal description.
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 defines what the tool does: it provides everything needed to add and correctly use one appCN component, including docs, source files, dependencies, and install command. This distinguishes it from sibling tools like list_components and search_components.
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 advises preferring the install command over manual file pasting to resolve dependencies, offering actionable guidance. However, it does not explicitly contrast with alternatives like get_install_command.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_design_guideGet the appCN design guideA
appCN's taste layer: the motion duration/easing/spring tokens, the press-scale and haptics conventions, the variant API rules, accessibility requirements, and the explicit 'what NOT to do' list. Read this before writing or modifying any React Native component so the code feels like appCN — never hand-type durations or easings, reach for these tokens.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully carries the burden. It discloses the exact contents of the guide (motion, haptics, rules, etc.) and implies it is purely a read operation. There is no mention of side effects or permissions, but the tool is a simple reference document.
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: first lists the detailed contents, second provides actionable guidance. No filler or redundancy. Information is front-loaded and every sentence adds value.
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 parameters, no output schema, and straightforward purpose, the description fully defines the tool's scope and output. It covers all necessary aspects for an agent to understand when and how to use it.
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 has zero parameters, and schema coverage is complete. The description does not need to add parameter semantics. Baseline score of 4 for no-parameter tools 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 clearly states the tool provides appCN's design guide including motion tokens, press-scale, haptics, variant API rules, accessibility requirements, and a 'what NOT to do' list. It distinguishes from sibling tools like get_component by specifying it is about the design system for React Native components.
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 tells the agent to read this before writing or modifying any React Native component, and advises to never hand-type durations or easings but to use these tokens. It provides clear context on when to use this tool, though it does not mention specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_install_commandGet an appCN install commandA
The exact command to add an appCN component to a project. Returns three install methods — the appCN CLI (recommended; handles NativeWind + Reanimated setup), shadcn namespaced, and shadcn by URL (zero setup) — for the requested package manager (or all of them).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Component slug, e.g. 'button' or 'voice-sphere'. | |
| manager | No | Package manager: npm, pnpm, yarn, or bun. Omit to get commands for all four. |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It describes what is returned (three install methods) but does not explicitly state that it is a read-only, non-destructive operation. Given the nature of a 'get' command, this is adequate but not fully transparent.
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 with no fluff. The key information (purpose, return format, options) is front-loaded and efficient.
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 explains the three install methods and the optional package manager parameter. There is no output schema, but the description covers the return content adequately. Minor gap: no mention of error handling or edge cases like invalid slug.
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 100%, so the input schema already documents both parameters well. The description adds context about the return format but not much beyond the schema. Baseline of 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?
The description clearly states it returns the exact install command for an appCN component, specifying three methods and the context of adding to a project. It distinguishes from sibling tools like get_component or list_components by focusing on installation.
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 implies when to use this tool (when needing the install command) and mentions the three methods but does not explicitly state when not to use it or name alternatives. However, the context is clear enough for an agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_componentsList appCN componentsA
List every appCN component, optionally filtered by category. Returns each component's slug, title, category, one-line description, and its signature 'delight' detail. Start here to see what's available, then call get_component for the full source and docs.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter to 'base' (the broad mobile library) or 'ai' (the featured AI-native collection). Omit for all. |
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only operation by stating 'List', but does not explicitly confirm safety or disclose any behavioral traits beyond the return format. For a list tool, this is adequate but not exceptional.
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 action, and every sentence adds value: first sentence states purpose and output, second sentence gives usage context with sibling tool.
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 tool's simplicity (list with one optional filter), the description is complete in terms of purpose, output, and sibling relationship. It could mention ordering or empty results, but these are minor omissions.
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% and the schema already describes the category parameter. The description adds value by explaining the enum values ('base' for broad mobile library, 'ai' for AI-native collection), providing context beyond the 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 states it lists every appCN component, optionally filtered by category, and specifies the returned fields. It distinguishes from the sibling get_component by suggesting to start here and then call get_component for full details.
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 explicit guidance: 'Start here to see what's available, then call get_component' indicates when to use this tool and when to use an alternative. It could be more thorough about other siblings like search_components, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_componentsSearch appCN componentsA
Find appCN components by intent or keyword — e.g. 'chat input', 'voice indicator', 'streaming message', 'reasoning'. Returns ranked matches with their delight detail. Use get_component on the best match for the full source and docs.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What you're looking for, in plain words (intent or keywords). |
TDQS
A4.7/5.0
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 states that the tool returns 'ranked matches with their delight detail,' implying a safe read operation. However, it does not disclose any potential limitations like result count, pagination, or response structure. A bit more detail on behavior would be beneficial.
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 that front-load the core purpose with examples. Every sentence adds value: the first defines the action and scope, the second provides workflow guidance. No wasted 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?
Given that the tool has a single required parameter and no output schema, the description is complete. It explains the input (intent/keywords), output (ranked matches with delight detail), and next step (use get_component). It lacks mention of result limits or sorting, but overall it's sufficient for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'query' is fully described in the schema. The description adds value by providing example intents/keywords ('chat input', 'voice indicator'), which helps the agent formulate proper queries. Schema coverage is 100%, and the examples enrich meaning beyond the 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 states the tool's function: 'Find appCN components by intent or keyword' with concrete examples ('chat input', 'voice indicator'). It explicitly differentiates from sibling tool 'get_component' by directing the agent to use that for full source/docs.
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: 'Use get_component on the best match for the full source and docs.' This tells the agent exactly when to use this tool versus the sibling, showing the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
5 tool updates
v1.0.0- First observed
get_component - First observed
get_design_guide - First observed
get_install_command - First observed
list_components - First observed
search_components
TDQS
A4.4/5.0
Scored across 5 tools
Disambiguation5/5
Each tool has a clearly distinct purpose: listing, searching, retrieving full component details, getting install commands, and reading design guidance. There is no meaningful overlap—even list_components and search_components differ explicitly by browse vs. intent-based discovery.
Naming Consistency5/5
All tool names follow a consistent lowercase snake_case verb_noun convention: get_install_command, get_design_guide, list_components, search_components, get_component. The pattern is uniform and predictable.
Tool Count5/5
Five tools is well-scoped for a component library server: discovery via list/search, detailed retrieval, install support, and design guidance. Each tool earns its place without redundancy or bloat.
Completeness5/5
The tool surface covers the full workflow of discovering, selecting, retrieving, installing, and correctly styling a component. With list, search, get, install, and design-guide tools, agents have everything needed to integrate appCN components without dead ends.
Maintenance
ActivityInactive
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Search and install 4,000+ security-scanned MCP servers from inside any MCP-aware AI client.
- UnifAPIOAuthcom.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Registry of MCP servers, agent skills and plugins: search, filter, comments, likes, publish.
Related MCP Servers
- AlicenseAqualityCmaintenanceMCP server that exposes the @bunge/ds-components design system catalog, allowing AI assistants to list, search, and retrieve component details including inputs, outputs, usage examples, and import instructions.4MIT
- AlicenseNot gradedqualityDmaintenanceUnified MCP server for searching, analyzing, and managing packages across npm, JSR, Deno, and multiple CDN providers with auto-detection.MIT
- AlicenseAqualityDmaintenanceMCP server that gives LLMs access to up-to-date mobile SDK documentation, package registry info, and GitHub issues.612MIT