Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OriginUI MCP Server find payment components and show me how to install them"
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.
A Model Context Protocol (MCP) server that provides access to OriginUI components, enabling Claude Code agents to search, browse, and install OriginUI components seamlessly.
Component Search: Search components by name, category, or tags
Component Details: Get comprehensive information about specific components
Installation Commands: Generate proper pnpm dlx shadcn@latest add commands
Visual Previews: Get component screenshots and visual descriptions to assess fit
Component Preview: View styling information and usage examples
Category Filtering: Browse components by category (buttons, inputs, forms, etc.)
Related MCP server: shadcn-ui MCP Server
TL;DR: Add this to your ~/.claude-code/mcp.json file:
{
"mcpServers": {
"origin-ui": {
"command": "npx",
"args": ["--yes", "github:kelvinchng/origin-ui-mcp"],
"env": {}
}
}
}Restart Claude Code and ask: "What OriginUI button components are available?"
No installation needed! You can use the MCP server directly from the GitHub repository with npx.
git clone https://github.com/kelvinchng/origin-ui-mcp.git
cd origin-ui-mcp
npm install
npm run buildnpm install -g origin-ui-mcpCreate or edit your Claude Code MCP configuration file at ~/.claude-code/mcp.json:
{
"mcpServers": {
"origin-ui": {
"command": "npx",
"args": ["--yes", "github:kelvinchng/origin-ui-mcp"],
"env": {}
}
}
}{
"mcpServers": {
"origin-ui": {
"command": "node",
"args": ["/absolute/path/to/origin-ui-mcp/dist/index.js"],
"env": {}
}
}
}Note: With Option A (npx), no manual installation or path configuration is needed!
After adding the MCP configuration, restart Claude Code to load the OriginUI MCP server.
You can verify the integration is working by asking Claude Code:
"What OriginUI components are available for buttons?"Claude Code should now be able to search, describe, and provide installation commands for OriginUI components.
Once integrated with Claude Code, you can ask questions like:
"Find me payment-related components"
"How do I install the button component?"
"What styling options does the card component have?"
"Show me all navigation components"
"I need a component for user input forms"
Claude Code will use the MCP server to provide accurate information and installation commands.
One of the key features is the ability to get visual previews of components to help LLMs make better recommendations:
"Show me what the payment component looks like"
"Get a screenshot of the button component"
"I want to see the visual style of navigation components"The MCP server will provide:
Visual descriptions of component appearance
Links to live examples on OriginUI
Theme-specific information (light/dark modes)
Mobile responsiveness details
Use case recommendations based on visual style
search_componentsSearch for OriginUI components by name, category, or tags.
Parameters:
query (string, required): Search query
category (string, optional): Filter by category
limit (number, optional): Maximum results (default: 10)
Example:
search_components({
query: "payment",
category: "form",
limit: 5
})get_component_detailsGet detailed information about a specific component.
Parameters:
componentId (string, required): Component ID (e.g., "comp-163")
Example:
get_component_details({
componentId: "comp-163"
})list_componentsList all available components with basic information.
Parameters:
category (string, optional): Filter by category
limit (number, optional): Maximum results (default: 50)
get_install_commandGet the installation command for a specific component.
Parameters:
componentId (string, required): Component ID
Returns:
pnpm dlx shadcn@latest add https://originui.com/r/comp-163.jsonget_component_previewGet component preview with styling information and usage examples.
Parameters:
componentId (string, required): Component ID
get_component_screenshotGet component visual preview to help assess if it fits your project.
Parameters:
componentId (string, required): Component ID
theme (string, optional): Theme preference ("light", "dark", "both")
Returns:
Visual descriptions of component appearance
Screenshots when available
Links to live examples
Use case recommendations
Installation instructions
button - Button components
input - Input and form controls
select - Select and dropdown components
navbar - Navigation components
card - Card and container components
form - Form-related components
layout - Layout components
navigation - Navigation elements
feedback - Feedback and status components
data-display - Data display components
overlay - Modal and overlay components
typography - Text and typography components
media - Media components
// Search for button components
const buttons = await search_components({
query: "button",
category: "button",
limit: 10
});
// Get details for a specific component
const details = await get_component_details({
componentId: "comp-163"
});
// Get installation command
const installCmd = await get_install_command({
componentId: "comp-163"
});
// Get visual preview to assess fit
const screenshot = await get_component_screenshot({
componentId: "comp-163",
theme: "both"
});
// Install the component
// pnpm dlx shadcn@latest add https://originui.com/r/comp-163.json# Install dependencies
npm install
# Build the project
npm run build
# Run in development mode
npm run dev
# Start the MCP server
npm startComponent Discovery: The server maintains a registry of OriginUI components with metadata
Dynamic Fetching: Component details are fetched from OriginUI's JSON registry on demand
Caching: Components are cached for 5 minutes to improve performance
Installation: Generates proper pnpm dlx shadcn@latest add commands with correct URLs
Fork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request
MIT License - see LICENSE file for details.
Get detailed information about a specific OriginUI component
| Name | Required | Description | Default |
|---|---|---|---|
| componentId | Yes | Component ID (e.g., 'comp-163') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'gets' information, implying a read-only operation, but doesn't cover aspects like error handling (e.g., what happens if the componentId is invalid), response format, or any rate limits or authentication needs. This leaves significant gaps for an agent to understand the tool's behavior.
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 a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly.
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 the tool's low complexity (single parameter, no output schema, no annotations), the description is minimally adequate but incomplete. It lacks details on behavioral traits and usage context, which are important for an agent to operate effectively, especially with multiple sibling tools available. The absence of an output schema means the description should ideally hint at return values, but it doesn't.
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 has 100% description coverage, with the parameter 'componentId' documented as 'Component ID (e.g., 'comp-163')'. The description adds no additional meaning beyond this, such as format constraints or where to find the ID. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 clearly states the verb ('Get') and resource ('detailed information about a specific OriginUI component'), making the purpose understandable. However, it doesn't differentiate from siblings like 'get_component_preview' or 'list_components' beyond specifying 'detailed information,' which is somewhat vague compared to more specific sibling purposes.
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 provides no guidance on when to use this tool versus alternatives. With siblings like 'list_components' for listing and 'search_components' for searching, there's no indication that this tool is for retrieving details of a known component ID, nor any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get component preview information including styling and usage
| Name | Required | Description | Default |
|---|---|---|---|
| componentId | Yes | Component ID (e.g., 'comp-163') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but lacks details on permissions, rate limits, error handling, or response format. This is inadequate for a tool with no annotation coverage.
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 a single, efficient sentence that front-loads the purpose without unnecessary words. It could be slightly improved by structuring usage hints, but it earns its place by being clear and direct.
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 the lack of annotations and output schema, the description is incomplete. It does not explain what 'preview information' entails, how styling and usage data are formatted, or any behavioral traits, leaving significant gaps for an agent to understand the tool's full context.
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 has 100% description coverage, with the parameter 'componentId' documented as 'Component ID (e.g., 'comp-163')'. The description adds no additional meaning beyond this, such as format constraints or examples, so it meets the baseline for high schema coverage.
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 clearly states the tool's purpose with a specific verb ('Get') and resource ('component preview information'), specifying what information is retrieved ('styling and usage'). It distinguishes from siblings like 'get_component_details' or 'get_component_screenshot' by focusing on preview aspects, though it doesn't explicitly name alternatives.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusions, such as when to choose this over 'get_component_details' for more comprehensive data or 'get_component_screenshot' for visual output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get component screenshot/visual preview to help assess if it fits the project
| Name | Required | Description | Default |
|---|---|---|---|
| componentId | Yes | Component ID (e.g., 'comp-163') | |
| theme | No | Theme preference for screenshot | both |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool gets a screenshot/visual preview but doesn't cover aspects like authentication needs, rate limits, error handling, or what the output looks like (e.g., image format, size). This leaves significant gaps for a tool that likely involves media retrieval.
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 a single, efficient sentence that front-loads the core action ('Get component screenshot/visual preview') and includes the purpose ('to help assess if it fits the project'). There is no wasted verbiage or redundancy.
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 the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like response format (e.g., image data, URL), error cases, or usage constraints. For a tool that retrieves visual content, more context is needed to guide effective use.
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 description coverage is 100%, so the schema fully documents both parameters (componentId and theme). The description adds no additional parameter semantics beyond what's in the schema, such as explaining the 'both' option for theme or providing examples beyond the ID format. Baseline 3 is appropriate when the schema handles parameter documentation.
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 clearly states the tool's purpose: 'Get component screenshot/visual preview' with the goal 'to help assess if it fits the project'. It specifies the resource (component) and outcome (screenshot/visual preview), but doesn't explicitly differentiate from siblings like 'get_component_preview' which might serve a similar purpose.
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 provides no guidance on when to use this tool versus alternatives. It mentions the purpose of assessment but doesn't specify contexts, prerequisites, or exclusions, nor does it reference sibling tools like 'get_component_details' or 'get_component_preview' for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the installation command for a specific component
| Name | Required | Description | Default |
|---|---|---|---|
| componentId | Yes | Component ID (e.g., 'comp-163') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but doesn't reveal any behavioral traits such as whether this is a read-only operation, if it requires authentication, rate limits, or what the output format might be. This leaves significant gaps for an agent to understand how the tool behaves.
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 a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral aspects and usage context, which are needed for a more complete understanding, especially without annotations to fill in gaps.
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 has 100% description coverage, with the parameter 'componentId' clearly documented as 'Component ID (e.g., 'comp-163')'. The description adds no additional meaning beyond this, so it meets the baseline score of 3 where the schema does the heavy lifting.
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 clearly states the tool's purpose with a specific verb ('Get') and resource ('installation command for a specific component'), making it easy to understand what it does. However, it doesn't differentiate from sibling tools like 'get_component_details' or 'get_component_preview' that might also retrieve component-related information, which prevents a perfect score.
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 provides no guidance on when to use this tool versus alternatives. With siblings like 'get_component_details' that might include installation info, there's no indication of when this tool is preferred or necessary, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive statistics about the OriginUI component registry
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify whether this is a lightweight query or resource-intensive, if it requires authentication, rate limits, or what format the statistics are returned in. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 a single, efficient sentence that front-loads the core purpose ('Get comprehensive statistics'). There is zero wasted text, no redundancy, and it directly communicates the tool's function without fluff. Every word earns its place.
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 the lack of annotations and output schema, the description is incomplete for a tool that presumably returns statistical data. It doesn't hint at what 'comprehensive statistics' includes (e.g., numeric counts, JSON structure, visualizations), leaving the agent guessing about the return format. For a stats-focused tool with no structured output documentation, this is a significant gap.
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 tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't waste space on parameters, earning a baseline score of 4 for not adding unnecessary information. It could be a 5 if it explicitly noted 'no parameters required', but this is minor.
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 clearly states the verb 'Get' and resource 'comprehensive statistics about the OriginUI component registry', making the purpose unambiguous. It distinguishes this from sibling tools like 'list_components' or 'search_components' by focusing on statistics rather than listing/searching components. However, it doesn't specify what types of statistics (e.g., counts, usage metrics, trends) are included, preventing a perfect score.
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 provides no guidance on when to use this tool versus alternatives. With siblings like 'list_components' (for listing components) and 'get_component_details' (for detailed component info), there's no indication whether this tool should be used for aggregate data, system monitoring, or other specific contexts. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available OriginUI components with basic information
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category | |
| limit | No | Maximum number of results to return (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it lists components with basic information. It doesn't disclose behavioral traits such as pagination, rate limits, authentication needs, or what 'basic information' entails, leaving significant gaps for a read operation.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
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 read operation with no annotations and no output schema, the description is minimally adequate but incomplete. It lacks details on output format, error handling, or behavioral context, which could hinder an AI agent's ability to use it effectively without additional information.
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 description coverage is 100%, so the schema fully documents the two parameters (category and limit). The description doesn't add any meaning beyond what the schema provides, such as explaining how filtering works or default behaviors, but this is acceptable given the high schema coverage.
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 clearly states the action ('List') and resource ('OriginUI components'), specifying that it provides 'basic information'. However, it doesn't differentiate from siblings like 'search_components' or 'get_registry_stats' that might also list components in different ways.
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?
No guidance is provided on when to use this tool versus alternatives like 'search_components' or 'get_component_details'. The description implies a comprehensive listing but doesn't specify if this is for browsing, filtering, or other contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search OriginUI components by name, category, or tags
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for component name, category, or tags | |
| category | No | Filter by specific category (e.g., 'button', 'input', 'navbar') | |
| limit | No | Maximum number of results to return (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the search functionality but doesn't describe what the tool returns (e.g., list of components with basic info), pagination behavior (implied by 'limit' parameter but not explained), or any constraints like rate limits or authentication needs. The description is too sparse for a tool with no annotation coverage.
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 a single, efficient sentence with zero waste—every word contributes to explaining the tool's purpose. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 the lack of annotations and output schema, the description is incomplete. It doesn't explain what the search returns (e.g., component IDs, names, metadata), how results are ordered, or error handling. For a search tool with no structured output documentation, this leaves significant gaps for an AI agent to understand the tool's behavior.
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 description coverage is 100%, so the schema fully documents all three parameters (query, category, limit). The description adds marginal value by mentioning the searchable fields ('name, category, or tags'), which aligns with the schema but doesn't provide additional syntax or format details. Baseline 3 is appropriate when the schema does the heavy lifting.
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 clearly states the action ('Search') and target resource ('OriginUI components') with specific search criteria ('by name, category, or tags'). It distinguishes itself from siblings like 'list_components' by emphasizing search functionality rather than listing. However, it doesn't explicitly contrast with 'get_component_details' or other retrieval tools.
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?
No explicit guidance on when to use this tool versus alternatives like 'list_components' or 'get_component_details'. The description implies usage for searching rather than listing or retrieving details, but lacks clear when/when-not instructions or named alternatives. Context is minimal beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tool has a clearly distinct purpose with no ambiguity: list_components and search_components handle discovery, get_component_details/preview/screenshot provide different types of component information, get_install_command gives installation instructions, and get_registry_stats offers registry-level data. The descriptions make it easy to differentiate between tools like get_component_details (detailed info) and get_component_preview (styling/usage).
All tools follow a consistent verb_noun pattern with snake_case throughout (e.g., get_component_details, list_components, search_components). The naming is predictable and readable, using clear verbs like 'get', 'list', and 'search' consistently across the toolset.
With 7 tools, this server is well-scoped for its purpose of managing a UI component registry. Each tool earns its place by covering distinct aspects: discovery (list/search), component inspection (details/preview/screenshot), installation (install_command), and registry analytics (stats). This count is neither too thin nor overwhelming.
The tool surface provides comprehensive coverage for the domain of a UI component registry, including discovery, inspection, and installation. Minor gaps exist, such as no tools for managing components (e.g., create/update/delete) or user-specific actions (e.g., favorites), but agents can work around this for core workflows like finding and using components.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Browse and install Crucible's animated React components into shadcn-style projects.
Access and maintain design system docs, tokens, components, skills, and contexts across any project.
Find, inspect and install reviewed reusable AI-agent capabilities from superskill.sh.
Generate, inspect, and manage Flowstep UI designs directly from your AI assistant.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kelvinchng/origin-ui-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
