Which integrations are available for this server?

Allows fetching the latest Gluestack UI components directly from the GitHub repository, providing up-to-date access to components without needing a local installation.

How do I use gluestack-ui-mcp-server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gluestack-ui-mcp-server Give me an example of a Gluestack UI Button component with the outline variant in React Native." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

gluestack-ui-mcp-server

by gauravsaini

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Gluestack UI MCP Server 📱

npm version License: MIT React Native Expo

📱 The definitive MCP server for React Native development with Gluestack UI - Build universal apps with AI assistance!

This Model Context Protocol (MCP) server provides AI assistants with comprehensive access to Gluestack UI - the premier React Native-first component library that delivers true cross-platform experiences. Whether you're building for iOS, Android, or the web, this server intelligently provides components, source code, and examples optimized for React Native development workflows.

Key Features

📱 React Native-First Development

70+ React Native Components: Production-ready components optimized for mobile-first development
Universal Platform Support: Single codebase runs on iOS, Android, and Web seamlessly
Expo Integration: Perfect compatibility with Expo workflows and managed builds
React Native Navigation: Built-in support for stack, tab, and drawer navigation patterns
Platform-Specific Optimizations: Components automatically adapt to iOS and Android design guidelines

🎨 Multi-Variant Architecture for React Native

Go beyond basic styling with variants designed for different React Native use cases:

🎨 NativeWind: Tailwind CSS components optimized for React Native with react-native-css-interop
🎭 Themed: Native styling with Gluestack's design token system - perfect for branded apps
🔧 Unstyled: Headless components for maximum customization in React Native projects

📋 React Native-Optimized Intelligence

TypeScript-First: Complete TypeScript definitions for React Native component props
Platform Detection: Smart handling of Platform.OS checks and platform-specific code
Expo Examples: Real-world usage patterns for Expo Router, EAS Build, and Expo dev workflows
Performance Patterns: React Native performance best practices baked into component examples

🔄 Cross-Platform Excellence

Universal Components: Write once, run on iOS, Android, and Web
Responsive Design: Built-in support for different screen sizes and orientations
Native Feel: Components follow platform-specific design guidelines automatically
Web Compatibility: Seamless React Native Web integration for responsive web apps

⚡ Development Acceleration

GitHub Mode: Access the latest React Native components directly from the repository
Local Development: Work with local Gluestack UI installations for rapid iteration
AI-Powered: Generate React Native screens, components, and navigation flows with AI assistance
Testing Ready: Components come with accessibility labels and test IDs for React Native testing

Related MCP server: shadcn MCP Server

Quick Start

Prerequisites

Node.js 18+
React Native Development Environment:
- React Native CLI or Expo CLI
- iOS Simulator (Mac) and/or Android Emulator
- Metro bundler for React Native
Component Source (choose one):
- A local Gluestack UI installation or clone, OR
- A GitHub Personal Access Token for fetching the latest React Native components

Installation Options

Option 1: From npm (when published)

npm install -g gluestack-ui-mcp-server

Option 2: Local Development Setup

# Clone this repository
git clone https://github.com/gluestack/gluestack-ui-mcp-server
cd gluestack-ui-mcp-server

# Install dependencies
npm install

# Build the project
npm run build

# Set your Gluestack UI path
export GLUESTACK_PATH="/path/to/your/gluestack-ui"

# Test the server
npm test

Usage with Claude Desktop

For Published Package

Add to your Claude Desktop configuration file (~/.config/claude/config.json):

{
  "mcpServers": {
    "gluestack-ui": {
      "command": "npx",
      "args": ["gluestack-ui-mcp-server"],
      "env": {
        "GLUESTACK_PATH": "/path/to/your/gluestack-ui"
      }
    }
  }
}

Or for GitHub mode:

{
  "mcpServers": {
    "gluestack-ui": {
      "command": "npx", 
      "args": ["gluestack-ui-mcp-server"],
      "env": {
        "GITHUB_TOKEN": "ghp_your_token_here"
      }
    }
  }
}

For Local Development

Add to your Claude Desktop configuration file (~/.config/claude/config.json):

{
  "mcpServers": {
    "gluestack-ui": {
      "command": "node",
      "args": ["/path/to/gluestack-ui-mcp-server/build/index.js"],
      "env": {
        "GLUESTACK_PATH": "/path/to/your/gluestack-ui"
      }
    }
  }
}

Or for GitHub mode:

{
  "mcpServers": {
    "gluestack-ui": {
      "command": "node",
      "args": ["/path/to/gluestack-ui-mcp-server/build/index.js"], 
      "env": {
        "GITHUB_TOKEN": "ghp_your_token_here"
      }
    }
  }
}

Available Tools

`list_components`

Get a full inventory of all 126+ available Gluestack UI components, including which variants are available for each.

`list_component_variants`

Compare and choose the perfect variant by getting detailed information and features for a specific component's NativeWind, Themed, and Unstyled versions.

`get_directory_structure`

Navigate the entire gluestack-ui monorepo from your AI assistant with a powerful directory browsing tool.

📄 Code, Demos & Metadata

`get_component`

Retrieve the complete, unmodified source code for any component variant, providing perfect context for code generation.

`get_component_demo`

Access battle-tested usage examples directly from Storybook to understand how components are meant to be used in practice.

`get_component_metadata`

Go beyond the code to understand its API. This tool extracts TypeScript props, dependencies from import statements, and documentation from comments.

Configuration Options

Environment Variables

GLUESTACK_PATH: Path to local Gluestack UI installation.
GITHUB_TOKEN: GitHub Personal Access Token for API access.
LOG_LEVEL: Logging level (debug, info, warn, error).

Command Line Arguments

# Local mode
gluestack-mcp --gluestack-path /path/to/gluestack-ui --log-level debug

# GitHub mode 
gluestack-mcp --github-token ghp_xxxxxxxxxxxx --log-level debug

GitHub Mode (Fetch Latest Components)

Instead of requiring a local Gluestack UI installation, you can use GitHub mode to fetch the latest components directly from the official repository.

Setting up GitHub Mode

Step 1: Get a GitHub Personal Access Token

Go to GitHub Settings → Developer settings → Personal access tokens
Generate a new token (classic) with public_repo scope
Copy the token (starts with ghp_)

Step 2: Configure Your MCP Client

For Claude Desktop:

{
  "mcpServers": {
    "gluestack-ui": {
      "command": "npx",
      "args": ["gluestack-ui-mcp-server"],
      "env": {
        "GITHUB_TOKEN": "ghp_your_token_here"
      }
    }
  }
}

For Command Line:

export GITHUB_TOKEN="ghp_your_token_here"
gluestack-mcp

Benefits of GitHub Mode

🚀 Always Up-to-Date: Access the latest components directly from the main branch
📦 No Local Setup: No need to clone or maintain a local Gluestack UI repository
🔄 Automatic Updates: Components are fetched fresh from GitHub on each request
📊 Rate Limit Friendly: Authenticated requests get higher GitHub API limits (5000/hour vs 60/hour)

Supported Components

The server provides access to 126+ Gluestack UI components including:

Layout: Box, Center, HStack, VStack, Grid, Divider Forms: Input, Textarea, Button, Checkbox, Radio, Select, Slider, Switch
Feedback: Alert, Toast, Progress, Spinner, Skeleton Overlay: Modal, AlertDialog, Popover, Tooltip, ActionSheet Data Display: Avatar, Badge, Card, Image, Table Navigation: Tabs, Menu, Link Media: Image, ImageViewer Utilities: Portal, Pressable, SafeAreaView

Testing

The server includes comprehensive tests for both local and GitHub modes:

# Run basic tests
npm test

# Test local mode (requires GLUESTACK_PATH)
npm run test:local

# Test GitHub mode (requires GITHUB_TOKEN)
npm run test:github

# Test both modes
npm run test:both

# Test component discovery
npm run test:components

# Run comprehensive test suite
npm run test:comprehensive

Test Environment Setup

For Local Mode Testing:

export GLUESTACK_PATH=/path/to/gluestack-ui
npm run test:local

For GitHub Mode Testing:

export GITHUB_TOKEN=ghp_your_token_here
npm run test:github

Requirements

Node.js 18+
Either:
- Local Gluestack UI installation/clone (for local mode), OR
- GitHub Personal Access Token (for GitHub mode)
MCP-compatible AI client (Claude Desktop, Continue.dev, etc.)

Contributing

We welcome contributions! Please see our Contributing Guide for details.

Gluestack UI MCP Server Implementation Summary

🎉 Implementation Complete

The Gluestack UI MCP Server has been successfully implemented with all planned features and capabilities.

✅ Completed Features

1. Project Foundation

✅ Complete TypeScript project setup with proper configuration
✅ NPM package configuration with all necessary dependencies
✅ Build system with TypeScript compilation
✅ Executable binary setup with proper shebang

2. Core MCP Server Infrastructure

✅ MCP Protocol server implementation using @modelcontextprotocol/sdk
✅ STDIO transport for communication with AI clients
✅ Request/response handlers for tool calls
✅ Comprehensive error handling and logging
✅ Server capabilities registration

3. CLI & Configuration

✅ Command-line argument parsing (--gluestack-path, --log-level, --help)
✅ Environment variable support (GLUESTACK_PATH, LOG_LEVEL)
✅ Winston-based logging system with configurable levels
✅ Help system with usage examples

4. Component Discovery System

✅ Intelligent component detection across multiple variants
✅ Support for NativeWind, Themed, and Unstyled component variants
✅ Automatic detection of component features (demos, stories, docs)
✅ Metadata extraction from package.json and source files
✅ Component relationship analysis and dependency tracking

5. MCP Tools Implementation

✅ list_components - Lists all 70+ available components
✅ get_component - Retrieves component source code
✅ get_component_demo - Gets component examples and stories
✅ get_component_metadata - Extracts props, dependencies, examples
✅ list_component_variants - Shows all variants for a component

6. TypeScript Integration

✅ Advanced TypeScript interface parsing for component props
✅ Dependency extraction from import statements
✅ JSDoc comment extraction for component documentation
✅ Type-safe API with comprehensive schemas

7. Multi-Variant Support

✅ NativeWind Variant - Modern Tailwind CSS styling (primary)
✅ Themed Variant - Gluestack design system tokens
✅ Unstyled Variant - Headless components for custom styling
✅ Intelligent variant selection with fallbacks

8. Documentation & Testing

✅ Comprehensive README with usage examples
✅ API documentation for all tools
✅ Integration guides for Claude Desktop, Continue.dev, etc.
✅ Test scripts and validation
✅ MIT License and contribution guidelines

🏗️ Architecture Overview

gluestack-ui-mcp-server/
├── src/
│   ├── index.ts                    # Entry point
│   ├── server/                     # MCP server core
│   │   ├── index.ts               # Server startup logic
│   │   ├── createServer.ts        # Server instance creation
│   │   ├── handler.ts             # Request handlers
│   │   ├── capabilities.ts        # Server capabilities
│   │   └── version.ts             # Version management
│   ├── tools/                      # MCP tool implementations
│   │   └── components/            # Component-related tools
│   │       ├── list-components.ts
│   │       ├── get-component.ts
│   │       ├── get-component-demo.ts
│   │       ├── get-component-metadata.ts
│   │       └── list-component-variants.ts
│   ├── utils/                      # Utilities and helpers
│   │   ├── component-discovery.ts  # Component detection engine
│   │   └── logger.ts              # Logging system
│   └── cli/                       # Command-line interface
│       └── args.ts                # Argument parsing
├── build/                          # Compiled JavaScript
└── README.md                      # Complete documentation

🚀 Key Capabilities

Component Library Support

126 Components: Complete Gluestack UI component library coverage
Cross-Platform: React Native components that work on iOS, Android, Web
Modern Styling: NativeWind (Tailwind) integration
Design System: Themed variant with design tokens
Flexibility: Unstyled variant for complete customization

AI Integration Features

Rich Context: Provides complete component source code with TypeScript types
Usage Examples: Real working examples from Storybook demos
Metadata Extraction: Props interfaces, dependencies, documentation
Intelligent Search: Component discovery by name or category
Variant Awareness: Automatically selects best variant for use case

Developer Experience

Zero Configuration: Works with default paths and settings
Flexible Setup: Supports custom Gluestack UI installations
Comprehensive Logging: Detailed debugging and monitoring
Error Handling: Graceful failures with helpful error messages
Security Hardened: Package overrides and dependency locking for enhanced security
Type Safety: Full TypeScript support throughout

🎯 Usage Examples

Basic Component Retrieval

# List all components
echo '{"method": "tools/call", "params": {"name": "list_components"}}' | npx gluestack-ui-mcp-server

# Get Button component source
echo '{"method": "tools/call", "params": {"name": "get_component", "arguments": {"componentName": "Button"}}}' | npx gluestack-ui-mcp-server

Claude Desktop Integration

{
  "mcpServers": {
    "gluestack-ui": {
      "command": "npx",
      "args": ["gluestack-ui-mcp-server"],
      "env": {
        "GLUESTACK_PATH": "/path/to/gluestack-ui"
      }
    }
  }
}

🔧 Technical Decisions

Component Discovery Strategy

Primary Source: example/storybook-nativewind/src/components/ for rich examples
Fallback Sources: Core packages for implementation details
Caching: In-memory component registry for performance
Multi-Variant: Concurrent discovery across all variant types

TypeScript Parsing

Regex-Based: Lightweight interface parsing without AST complexity
Prop Extraction: Automatic detection of component props and types
Import Analysis: Dependency tracking from import statements
JSDoc Support: Comment extraction for documentation

Error Handling

Graceful Degradation: Continue operation even if some components fail
Detailed Logging: Comprehensive error context for debugging
User-Friendly Messages: Clear error messages for common issues
Circuit Breaker: Prevent cascading failures in component discovery

🌟 Benefits for AI Development

Accelerated Development

Instant Access: Components available to AI assistants immediately
Best Practices: Examples show proper component usage patterns
Type Safety: TypeScript interfaces ensure correct prop usage
Variant Selection: Automatic selection of most appropriate variant

Enhanced Code Quality

Consistent Styling: Gluestack UI design system principles
Accessibility: Components built with accessibility best practices
Cross-Platform: Write once, run on iOS, Android, Web
Modern Stack: Latest React Native and styling approaches

Productivity Boost

Reduced Lookup: No need to manually browse documentation
Complete Context: Source code, examples, and metadata in one request
Intelligent Discovery: Find components by functionality or name
Rapid Prototyping: Quickly scaffold UI components

🎊 Ready for Production

The Gluestack UI MCP Server is now complete and ready for:

AI Assistant Integration (Claude Desktop, Continue.dev, Cursor, etc.)
NPM Package Publication (gluestack-ui-mcp-server)
Community Use (Open source with MIT license)
Enterprise Deployment (Supports custom installations and configurations)

This implementation provides AI assistants with comprehensive access to the Gluestack UI ecosystem, enabling rapid development of high-quality React Native applications with modern styling and cross-platform compatibility.

License

MIT

Built in Melbourne with ❤️ for the Gluestack and AI development communities

Available Tools

6 tools

get_componentB

Get the source code for a specific Gluestack UI component

ParametersJSON Schema

Name	Required	Description	Default
`componentName`	Yes	Name of the Gluestack UI component (e.g., 'Button', 'Input', 'Modal')
`variant`	No	Component variant to retrieve (defaults to nativewind if available)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It only states a read operation ('Get') but does not confirm non-destructive nature or mention any side effects, authentication, or limits. Minimal disclosure.

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?

Single sentence, front-loaded, no unnecessary words. Efficient and to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and only one sentence. Does not describe the return format (e.g., string of source code). Suitable for a simple tool but lacks clarity on what the agent will receive.

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 description adds no extra meaning beyond what the schema already provides for componentName and variant. 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 the tool retrieves the source code for a specific Gluestack UI component. It distinguishes from sibling tools like get_component_demo or get_component_metadata by specifying 'source code'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. With siblings like get_component_demo and get_component_metadata, the description should indicate scenarios for each but does not.

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

get_component_demoB

Get demo code illustrating how a Gluestack UI component should be used

ParametersJSON Schema

Name	Required	Description	Default
`componentName`	Yes	Name of the Gluestack UI component (e.g., 'Button', 'Input', 'Modal')
`variant`	No	Component variant to retrieve demo for (defaults to nativewind)

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, and the description lacks detail on what exactly is returned (e.g., code snippet, file path), side effects, or authorization needs. It only says 'Get demo code', which is insufficient for transparency.

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

Conciseness4/5

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

Description is a single sentence with no filler, front-loading the purpose. However, it is slightly too concise given the lack of behavioral details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with two well-described parameters and no output schema, the description gives the minimum viable context. It could mention the return format or constraints (e.g., componentName must exist).

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 has 100% description coverage for both parameters, including the default for 'variant'. The description adds no new semantic meaning beyond what is in 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?

Description clearly states the tool retrieves demo code for a Gluestack UI component, specifying the resource (demo code) and purpose (illustrating usage). It distinguishes from siblings like 'get_component' which likely gets the component itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like 'get_component_metadata' or 'list_component_variants'. The usage context is implied but not stated.

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

get_component_metadataB

Get metadata for a specific Gluestack UI component including props, dependencies, and examples

ParametersJSON Schema

Name	Required	Description	Default
`componentName`	Yes	Name of the Gluestack UI component (e.g., 'Button', 'Input', 'Modal')
`variant`	No	Component variant to get metadata for (defaults to nativewind)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must convey behavioral traits. It only states the tool retrieves metadata, but does not disclose whether it is read-only, requires authentication, has rate limits, or any side effects. This is insufficient for a tool with no annotations.

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 a single, well-structured sentence that efficiently conveys the tool's purpose without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description minimally covers what the tool returns (props, dependencies, examples) but lacks details on output format, error handling, or prerequisites. It is adequate but incomplete.

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 coverage is 100% with clear parameter descriptions for componentName and variant. The tool description adds no additional meaning beyond the schema, so baseline score 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?

Description clearly states the verb 'Get' and resource 'metadata for a specific Gluestack UI component', and specifies what is included (props, dependencies, examples). This distinguishes it from sibling tools like get_component (likely returns component code) and get_component_demo (returns demo).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like get_component or list_components. The description does not mention when-not or provide context for selection beyond the tool's purpose.

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

get_directory_structureB

Get the directory structure of the Gluestack UI repository or a specific path within it

ParametersJSON Schema

Name	Required	Description
`path`	No	Path within the Gluestack UI repository (relative to root). Leave empty for full structure.
`depth`	No	Maximum depth to traverse (default: 3)
`includeFiles`	No	Whether to include files in the structure (default: true)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided; the description does not mention error handling, auth requirements, or response format. It only states the basic function without behavioral details.

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

Conciseness4/5

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

Single sentence that is front-loaded with purpose. Efficient but could be slightly more structured with separate usage notes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 3 optional parameters and no output schema, the description is minimal. It lacks details on depth behavior, file inclusion semantics, and error cases, making it incomplete for confident use.

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 covers all 3 parameters with descriptions. The tool description adds no extra meaning beyond the schema, so baseline score 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 clearly states it retrieves the directory structure of the Gluestack UI repository, optionally filtered by path. This distinguishes it from sibling tools which deal with components and variants.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use or not, but the context from sibling tool names implies it is for exploring file structure rather than components.

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

list_componentsA

List all available Gluestack UI components with their variants and features

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/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 full burden. It discloses that the tool lists all components with variants and features, which is straightforward. However, it does not describe return format, side effects, or other behavioral details beyond the basic listing.

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 a single well-structured sentence that front-loads the core action. 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 the tool's simplicity (no parameters, no output schema), the description is adequate. It covers the purpose and scope (all components with variants and features). Minor gap: could mention if authentication or context is needed, but overall sufficient.

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 no parameters (schema coverage 100%). The description adds meaning by stating what the listing includes (variants and features), which is a baseline 4 for zero-parameter tools.

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 'List all available Gluestack UI components with their variants and features', using a specific verb and resource. It distinguishes from sibling tools like get_component which focuses on a single component, and list_component_variants which lists only variants.

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?

While the description implies using this tool to get a comprehensive list of all components, it does not explicitly state when to use alternatives or provide exclusion criteria. The context is clear but lacks explicit guidance.

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

list_component_variantsA

List all available variants (nativewind, themed, unstyled) for a specific Gluestack UI component

ParametersJSON Schema

Name	Required	Description	Default
`componentName`	Yes	Name of the Gluestack UI component to list variants for (e.g., 'Button', 'Input', 'Modal')

TDQS

A3.9/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 of behavioral disclosure. While it accurately describes a read-only listing operation, it does not explicitly state that it is non-destructive or that it requires no special permissions. The description is not misleading but adds no extra behavioral context beyond the stated action.

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 a single, well-structured sentence that front-loads the verb and resource, then provides specific details. Every word is informative and there is no redundancy. It is an optimal length for a simple tool.

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?

Given the tool's simplicity (single parameter, no output schema, no nested objects), the description is fully complete. It explains the purpose, parameter, and what the output represents (a list of variant names). No additional context is needed for an agent to correctly select and invoke this tool.

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 input schema already describes the parameter componentName with 100% coverage, but the description adds value by providing examples (e.g., 'Button', 'Input', 'Modal') and clarifying that it refers to Gluestack UI components. This extra context helps the agent understand the expected format and domain, going beyond the schema's brief 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 states the action 'List', the resource 'all available variants for a specific Gluestack UI component', and even enumerates the variant types (nativewind, themed, unstyled). It distinguishes this tool from siblings like list_components (which lists components) and get_component (which gets component details).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives. It only states what it does, without specifying prerequisites, context where it is appropriate, or when not to use it. For example, it could mention that this tool is useful for discovering available styling variants before using a component.

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.

6 tool updatesv1.0.4Jun 17, 2026
- First observedget_component
- First observedget_component_demo
- First observedget_component_metadata
- First observedget_directory_structure
- First observedlist_component_variants
- First observedlist_components

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Scored 2026-06-17 10:45 across 6 tools

Disambiguation5/5

Each tool targets a distinct aspect: source code, demo, metadata, directory structure, list of components, and variants. No two tools overlap in purpose.

Naming Consistency5/5

All tool names use a consistent verb_noun pattern with lowercase underscores (e.g., get_component, list_components). Perfectly predictable.

Tool Count5/5

With 6 tools, the server covers the necessary operations without bloat. It is well-scoped for retrieving component information.

Completeness4/5

The tool set covers retrieval of component source, demo, metadata, variants, and directory structure. A minor gap might be a search or filter tool, but core needs are met.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

21st.dev AOAuth
dev.21st
Find UI components and themes, retrieve code, and generate with hosted 21st AI when enabled.
Design Tools Developer Tools AI & Machine Learning
2
Hint-Services-obsidian-github-mcp
ai.smithery
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Note Taking Version Control File Systems
29
marmo-ui A
io.github.mahmoudilyan
Live React design-system APIs, patterns, and code validation so AI agents build real UI, not slop.
Design Tools Developer Tools
142
Expo A
io.github.mcp-dir
Your Expo and EAS project in natural language: up to date SDK docs, cloud builds (status, logs, trig
CI/CD & DevOps Documentation Access
251

Related MCP Servers

Component Library MCP Server
Documentation Access Developer Tools Code Analysis
alex-abrams711
F
license
Not graded
quality
D
maintenance
Provides AI assistants with access to private React component library documentation, props, and code examples through type-safe TypeScript integration.
Updated 10 months ago (2025-11-04 14:34 UTC)
-
shadcn MCP Server
Developer Tools Code Analysis Documentation Access
krutikkkkkkkkk
A
license
Not graded
quality
D
maintenance
Enables AI assistants to discover, install, and generate code examples for shadcn/ui components, providing installation commands and usage examples for 37+ React UI components.
Updated a year ago (2025-08-06 16:50 UTC)
MIT
shadcn MCP Server
Developer Tools Documentation Access
magnusrodseth
F
license
A
quality
D
maintenance
Provides AI assistants with direct access to shadcn/ui components and blocks, enabling real-time fetching of component source code, documentation, and implementation examples.
Updated a year ago (2025-07-22 10:55 UTC)
4
22
4
-
Gluestack Components MCPofficial
Developer Tools Design Tools
gluestack
A
license
Not graded
quality
F
maintenance
Enables integration of Gluestack components with Claude Desktop and Cursor IDE for UI development.
Updated a year ago (2025-05-26 07:01 UTC)
801
46
MIT

Gluestack UI MCP Server 📱

Key Features

📱 React Native-First Development

🎨 Multi-Variant Architecture for React Native

📋 React Native-Optimized Intelligence

🔄 Cross-Platform Excellence

⚡ Development Acceleration

Quick Start

Prerequisites

Installation Options

Option 1: From npm (when published)

Option 2: Local Development Setup

Usage with Claude Desktop

For Published Package

For Local Development

Available Tools

🔍 Component Discovery & Navigation

list_components

list_component_variants

get_directory_structure

📄 Code, Demos & Metadata

get_component

get_component_demo

get_component_metadata

Configuration Options

Environment Variables

Command Line Arguments

GitHub Mode (Fetch Latest Components)

Setting up GitHub Mode

Step 1: Get a GitHub Personal Access Token

Step 2: Configure Your MCP Client

Benefits of GitHub Mode

Supported Components

Testing

Test Environment Setup

Requirements

Contributing

Gluestack UI MCP Server Implementation Summary

🎉 Implementation Complete

✅ Completed Features

1. Project Foundation

2. Core MCP Server Infrastructure

3. CLI & Configuration

4. Component Discovery System

5. MCP Tools Implementation

6. TypeScript Integration

7. Multi-Variant Support

8. Documentation & Testing

🏗️ Architecture Overview

🚀 Key Capabilities

Component Library Support

AI Integration Features

Developer Experience

🎯 Usage Examples

Basic Component Retrieval

Claude Desktop Integration

🔧 Technical Decisions

Component Discovery Strategy

TypeScript Parsing

Error Handling

🌟 Benefits for AI Development

Accelerated Development

Enhanced Code Quality

Productivity Boost

🎊 Ready for Production

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Gluestack Components MCPofficial

`list_components`

`list_component_variants`

`get_directory_structure`

`get_component`

`get_component_demo`

`get_component_metadata`