How do I use TanStack MCP Server?

1. Click on "Install 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., "@TanStack MCP Server search the TanStack Query docs for cache invalidation examples" 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.

TanStack MCP Server

by zPeppOz

Overview Schema Related Servers Score Discussions

JavaScript

Remote

MCP Badge

@g7aro/tanstack-mcp

MCP server that wraps the TanStack CLI to provide programmatic access to TanStack documentation, libraries, add-ons, ecosystem partners, and project scaffolding.

Built as a drop-in replacement after TanStack removed the built-in MCP server from @tanstack/cli.

Tools

Tool	Description
`listTanStackAddOns`	List all available TanStack Start add-ons for a given framework
`getAddOnDetails`	Get detailed info about a specific add-on (files, deps, options, routes)
`createTanStackApplication`	Scaffold a new TanStack Start app with add-ons and options
`tanstack_list_libraries`	List all TanStack libraries with descriptions and links
`tanstack_doc`	Fetch the full content of a TanStack documentation page
`tanstack_search_docs`	Search across TanStack documentation
`tanstack_ecosystem`	List TanStack ecosystem partners with optional filters

Related MCP server: Salt MCP

Quick Install

Auto-detect installed AI clients and register the MCP server in one command:

npx @g7aro/tanstack-mcp --install

This will detect and configure all supported clients on your machine.

Options

npx @g7aro/tanstack-mcp --install              # Interactive — pick which clients
npx @g7aro/tanstack-mcp --install --all         # Install into all detected clients
npx @g7aro/tanstack-mcp --install cursor codex   # Install into specific clients only
npx @g7aro/tanstack-mcp --uninstall              # Remove from all clients

Supported clients

Client	Detection	Config method
Claude Code	`claude` CLI	`claude mcp add`
Codex (OpenAI)	`codex` CLI	`codex mcp add`
Cursor	`~/.cursor/` dir	`~/.cursor/mcp.json`
Windsurf	`~/.windsurf/` dir	`~/.windsurf/mcp.json`
Trae	`~/.trae/` dir	`~/.trae/mcp.json`
Antigravity	`~/.gemini/antigravity/` dir	`mcp_config.json`
OpenCode	`~/.config/opencode/` dir	`opencode.json`
Zed	`~/.config/zed/settings.json`	`settings.json`
VS Code (Copilot)	`settings.json` / `code` CLI	`settings.json`

Manual Setup

If you prefer to configure manually, add to your client's MCP config:

{
  "mcpServers": {
    "tanstack": {
      "command": "npx",
      "args": ["-y", "@g7aro/tanstack-mcp"]
    }
  }
}

Tools

Tool	Description
`listTanStackAddOns`	List all available TanStack Start add-ons for a given framework
`getAddOnDetails`	Get detailed info about a specific add-on (files, deps, options, routes)
`createTanStackApplication`	Scaffold a new TanStack Start app with add-ons and options
`tanstack_list_libraries`	List all TanStack libraries with descriptions and links
`tanstack_doc`	Fetch the full content of a TanStack documentation page
`tanstack_search_docs`	Search across TanStack documentation
`tanstack_ecosystem`	List TanStack ecosystem partners with optional filters

Prerequisites

Node.js >= 18
npx available in PATH (ships with npm)

How it works

Each MCP tool maps to a @tanstack/cli command with --json output:

listTanStackAddOns       -> tanstack create --list-add-ons --framework <f> --json
getAddOnDetails          -> tanstack create --addon-details <id> --framework <f> --json
createTanStackApplication -> tanstack create <name> --framework <f> --add-ons <a,b> ...
tanstack_list_libraries  -> tanstack libraries --json
tanstack_doc             -> tanstack doc <library> <path> --json
tanstack_search_docs     -> tanstack search-docs "<query>" --json
tanstack_ecosystem       -> tanstack ecosystem --json

The server spawns npx @tanstack/cli for each invocation, parses the JSON output, and returns it through the MCP protocol over stdio.

Development

npm install
npm run build   # compile TypeScript -> dist/
npm start       # run the server (stdio)
npm run dev     # watch mode

License

MIT

Available Tools

7 tools

createTanStackApplicationB

Scaffold a new TanStack Start application with the specified add-ons and options

ParametersJSON Schema

Name	Required	Description	Default
`projectName`	Yes	Name of the project directory to create
`framework`	No	Project framework	React
`addOns`	No	Comma-separated add-on ids to include (e.g. ['drizzle','clerk'])
`packageManager`	No	Package manager to use
`deployment`	No	Deployment adapter
`toolchain`	No	Linter / formatter toolchain
`routerOnly`	No	Use router-only mode (file-based routing without TanStack Start)
`examples`	No	Include demo/example pages
`targetDir`	No	Target directory for the project root
`addOnConfig`	No	JSON string with add-on configuration options

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It fails to mention side effects, file system changes, required permissions, idempotency, or the nature of the scaffolded output.

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 action and omits any extraneous detail, making it highly efficient.

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?

Given the complexity (10 parameters, no output schema, no annotations), the description is too sparse. It does not explain what the tool returns, how it behaves with different parameters, or potential side effects, leaving the agent with insufficient context.

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%, so the baseline is 3. The description adds no additional meaning beyond the parameter descriptions, though it does hint that add-ons and options customize the scaffold.

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 uses a specific verb 'scaffold' and identifies the resource 'TanStack Start application', clearly distinguishing this creation tool from sibling listing and documentation tools.

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 provides no guidance on when to use this tool versus alternatives like getAddOnDetails or listTanStackAddOns, nor does it state any prerequisites or exclusions.

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

getAddOnDetailsA

Get detailed information about a specific TanStack Start add-on (files, dependencies, options, routes)

ParametersJSON Schema

Name	Required	Description	Default
`addonId`	Yes	Add-on identifier (e.g. drizzle, clerk, shadcn, prisma, sentry)
`framework`	No	Project framework	React

TDQS

A3.6/5.0

Behavior3/5

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

No annotations exist, so the description is the sole source. It indicates a read operation (no destruction), but does not disclose authentication needs, rate limits, or return structure details beyond listing some attributes.

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 one concise sentence with a parenthetical list, front-loading the purpose. Every word is necessary and clear.

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?

Given no output schema, the description should clarify the structure and content of the returned details. It only lists categories (files, dependencies, etc.) without explaining format or behavior in edge cases.

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?

Input schema covers both parameters with descriptions and examples. The tool description does not add meaning beyond what the schema provides, so 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 verb 'Get detailed information', specifies the resource 'TanStack Start add-on', and lists what details (files, dependencies, options, routes). This distinguishes it from sibling tools like listTanStackAddOns.

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 vs. alternatives like listTanStackAddOns. The name and description imply detailed lookup, but no when-not or exclusion criteria are provided.

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

listTanStackAddOnsA

List all available TanStack Start add-ons for a given framework

ParametersJSON Schema

Name	Required	Description	Default
`framework`	No	Project framework	React

TDQS

A3.6/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 fully disclose behavior. It only states the basic action and parameter, omitting details like read-only nature, authentication needs, or return format. Minimal behavioral context is given.

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 sentence with no unnecessary words. It is as concise as possible while conveying the core purpose.

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?

For a simple list tool with one enum parameter and no output schema, the description is largely sufficient. It could be improved by hinting at the return format (e.g., names or IDs), but overall it is adequate for an agent to understand the tool.

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% and describes the parameter as 'Project framework' with enum values. The description adds that the list is 'for a given framework', which is slightly redundant. No additional 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 lists TanStack Start add-ons for a given framework. The verb 'list' and resource 'add-ons' are specific. It distinguishes from siblings like createTanStackApplication (create) and getAddOnDetails (details).

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?

The description implies usage to view available add-ons but does not explicitly state when to use this tool versus alternatives like getAddOnDetails or tanstack_list_libraries. No 'when not to use' guidance is provided.

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

tanstack_docA

Fetch the full content of a specific TanStack documentation page

ParametersJSON Schema

Name	Required	Description
`library`	Yes	Library ID (e.g. query, router, table, start, form, virtual)
`path`	Yes	Documentation path (e.g. framework/react/overview, guide/server-functions)
`docsVersion`	No	Docs version (default: latest)

TDQS

A4/5.0

Behavior3/5

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

Without annotations, the description relies on implying a read operation. 'Fetch full content' suggests no destructive behavior, but no explicit disclosure of potential side effects or prerequisites. Adequate but minimal.

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, clear sentence with no unnecessary words. It effectively communicates the tool's purpose in a concise manner.

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?

For a simple fetch tool with well-described parameters, the description is sufficient. However, it lacks details about the output format (e.g., markdown, HTML), which would improve completeness.

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 has 100% description coverage with clear parameter meanings. The description adds no extra semantics beyond 'full content' context. Baseline score 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 verb 'Fetch' and the resource 'full content of a specific TanStack documentation page'. It is specific and distinguishes from siblings like 'tanstack_search_docs' which is for search.

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 (to fetch full doc content) but does not explicitly state when not to use or mention alternatives. It is adequate for a straightforward fetch tool.

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

tanstack_ecosystemB

List TanStack ecosystem partners (auth, database, deployment, monitoring, etc.) with optional category/library filters

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Filter by category (e.g. auth, database, deployment, monitoring, api, code-review)
`library`	No	Filter by TanStack library (e.g. start, query, table)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, and the description only says 'List' without disclosing behavioral traits like read-only nature, rate limits, pagination, or what happens with no filters. The agent is left guessing about operation safety and side effects.

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 with main action, no unnecessary words. Every part earns its place.

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?

Adequate for a simple list tool with filters, but missing output description (e.g., what fields are returned). No output schema, so description should clarify return format. Otherwise complete enough for basic 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 description coverage is 100% (both params described in schema). The description adds no extra meaning beyond the schema; baseline 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 verb 'List' and resource 'TanStack ecosystem partners' with optional filters, distinguishing it from sibling tools like listTanStackAddOns and tanstack_search_docs which target different resources.

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 when-to-use or when-not-to-use guidance relative to sibling tools. The description does not mention alternatives or context for choosing this tool over listTanStackAddOns or other list tools.

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

tanstack_list_librariesA

List all TanStack libraries with their descriptions, supported frameworks, and links

ParametersJSON Schema

Name	Required	Description	Default
`group`	No	Filter by library group

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description must cover behavioral traits. It describes the output but does not explicitly state that the operation is read-only or any other constraints. However, 'list' implies non-destructive behavior, which is acceptable for a simple tool.

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 sentence that is front-loaded with the verb and resource. It communicates the essential information without any 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 lists libraries with one optional parameter and no output schema, the description adequately specifies the output content (descriptions, frameworks, links). It is sufficiently complete for a simple listing tool.

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 has one parameter (group) with 100% coverage, including a description and enum values. The description does not add significant meaning beyond the schema, so the 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 the tool lists all TanStack libraries with specific details (descriptions, frameworks, links). The verb 'list' and resource 'TanStack libraries' are precise, and it distinguishes itself from sibling tools like createTanStackApplication and listTanStackAddOns.

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?

The description implies usage for general library listing but does not explicitly state when to use this tool versus siblings like tanstack_doc or tanstack_search_docs. No when-not or alternatives are mentioned.

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

tanstack_search_docsA

Search across TanStack documentation for a query string. Returns matching pages with titles, URLs, and breadcrumbs.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query (e.g. 'server functions', 'loaders', 'mutations')
`library`	No	Filter to a specific library (e.g. start, router, query)
`framework`	No	Filter to a specific framework (e.g. react, vue, solid)
`limit`	No	Max results to return (default 10, max 50)

TDQS

A4/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It explains that the tool returns 'matching pages with titles, URLs, and breadcrumbs', which is useful. However, it does not disclose other behaviors such as whether it is read-only, whether authentication is needed, or any rate limits. For a simple search tool, the description is reasonably transparent but could be improved.

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 sentence with 15 words, containing no extraneous information. It front-loads the action and clearly states the output. Every word earns its place.

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 no output schema, the description explains what is returned (titles, URLs, breadcrumbs), which partially covers completeness. However, it does not mention relevance ranking, default behavior of filters, or whether results are from all libraries. For a search tool with 4 parameters and no output schema, the description provides adequate but not exhaustive context.

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 has 100% description coverage for all 4 parameters, so the schema already documents each parameter's meaning. The tool description adds no extra semantic value beyond the schema. Baseline score of 3 is appropriate given high schema coverage.

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 verb 'Search' and resource 'TanStack documentation', specifying the output includes titles, URLs, and breadcrumbs. This distinguishes it from sibling tools like 'tanstack_doc' which likely retrieves a specific document, and 'tanstack_ecosystem' which provides an overview.

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?

The description does not explicitly state when to use this tool versus alternatives. It only describes what it does, not when it's appropriate or when not to use it. Implied usage is for broad searches, but no guidance on exclusions or comparisons to siblings like 'tanstack_doc' or 'listTanStackAddOns'.

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

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a distinct purpose: scaffolding (create, list add-ons, get add-on details), documentation (fetch page, search, list libraries, list ecosystem partners). No overlap.

Naming Consistency2/5

First three tools use camelCase (createTanStackApplication, getAddOnDetails, listTanStackAddOns) while last four use lowercase underscores (tanstack_doc, etc.). Also, the first three include verb-noun pattern but the last four lack clear action verbs in names (e.g., tanstack_doc is just a noun).

Tool Count5/5

Seven tools is well-scoped for a server covering TanStack Start scaffolding and documentation reference. Not too many, not too few.

Completeness5/5

The set covers key scaffolding operations (create, list, get details) and comprehensive documentation access (search, fetch, list libraries, list ecosystem). No obvious gaps for the intended domain.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Supernova
io.supernova
Access and maintain design system docs, tokens, components, skills, and contexts across any project.
Design Tools Documentation Access Developer Tools
1
llmref A
org.llmref
Versioned documentation registry and semantic search for AI tools and coding assistants.
Documentation Access Search Developer Tools
42
@imqueue A
org.imqueue
Search @imqueue docs and scaffold typed services & clients from your AI coding agent.
Developer Tools Documentation Access
711
AI Worlds CLI Knowledge A
com.claude-world
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
Command Line Developer Tools Documentation Access
121

Related MCP Servers

GitHub Copilot CLI MCP Server
Developer Tools Command Line Code Execution
wminson
A
license
Not graded
quality
D
maintenance
Wraps the GitHub Copilot CLI to provide natural language command suggestions, explanations, and shell configuration for shell, git, and GitHub CLI commands through the Model Context Protocol.
Updated 9 months ago (2025-12-11 01:41 UTC)
1
MIT
Salt MCP
Developer Tools Documentation Access Code Analysis
feesch
A
license
A
quality
D
maintenance
Enables AI agents to build React applications using JP Morgan Chase's Salt Design System by providing real-time access to component APIs, documentation, and accessibility guidelines. It supports tasks such as scaffolding new projects, building UI patterns, and converting Figma designs into Salt code via the Model Context Protocol.
Updated 7 months ago (2026-02-17 03:59 UTC)
6
6
1
MIT
Pulumi MCP Server
Cloud Platforms CI/CD & DevOps
VenelinMartinov
A
license
D
quality
D
maintenance
Enables AI assistants to manage cloud infrastructure using Pulumi by running commands like preview, deploy, and stack output retrieval through the Model Context Protocol.
Updated a year ago (2025-04-07 13:48 UTC)
5
9,758
Apache 2.0
Radix UI MCP Server
Developer Tools Design Tools Documentation Access
gianpieropuleo
A
license
A
quality
D
maintenance
Enables AI assistants to access and work with Radix UI libraries (Themes, Primitives, Colors) by retrieving components, documentation, and installation guides through the Model Context Protocol.
Updated a year ago (2025-08-14 17:28 UTC)
11
129
8
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zPeppOz/tanstack-mcp'

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