Skip to main content
Glama
jrlingyin888

SwiftForge MCP

by jrlingyin888
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

npm version license MCP SwiftUI

A curated, current, production-grade SwiftUI component library — served straight to your AI coding agent over MCP.

Think 21st.dev (curated React components for AI agents), but for SwiftUI.

See it in action

https://github.com/user-attachments/assets/c2460a1d-fb0d-47e0-9d1b-91e6a784717b

A quick tour of components from the catalog (incl. iOS 26 Liquid Glass), running in the demo app.

Related MCP server: ds-pilot

The problem

Coding agents (Claude Code, Cursor, Copilot) are great at logic and mediocre at SwiftUI. They:

  • reach for deprecated APIs (NavigationView, .foregroundColor, ObservableObject everywhere)

  • have never seen iOS 26 "Liquid Glass" (.glassEffect, GlassEffectContainer, .buttonStyle(.glass)) and guess wrong

  • produce bland, one-off views instead of polished, reusable components

You end up rewriting their SwiftUI by hand. Every time.

What SwiftForge does

SwiftForge is a tiny MCP server that gives your agent on-demand access to a hand-curated catalog of modern, compile-ready SwiftUI components. When you ask your agent to "add a glass card" or "build an onboarding flow," it pulls the real, current component instead of hallucinating one.

The value isn't the server — it's the curated catalog: every component uses current API only, is dark-mode + Dynamic Type friendly, includes a #Preview, and is reviewed for taste.

Quick start

Claude Code

claude mcp add swiftforge -- npx -y swiftforge-mcp

Cursor / Windsurf (~/.cursor/mcp.json or project .cursor/mcp.json)

{
  "mcpServers": {
    "swiftforge": {
      "command": "npx",
      "args": ["-y", "swiftforge-mcp"]
    }
  }
}

Full setup, example prompts, and troubleshooting: docs/USAGE.md.

git clone <this repo> && cd swiftforge-mcp
npm install && npm run smoke
# then point your agent at: node /absolute/path/to/src/index.js

Then just talk to your agent:

"Use swiftforge to add a Liquid Glass stat card to this dashboard." "Search swiftforge for a pull-to-refresh list and wire it to my view model."

Demo app — the closed loop, proven

examples/SwiftForgeDemo is a real iOS app that pulls in all 96 catalog components and builds clean — proof that the full loop works (agent → swiftforge → a compiling iOS app):

npm run demo:gen      # (re)generate the demo project from the catalog
npm run demo:build    # headless xcodebuild for the iOS simulator
# or just open it:
open examples/SwiftForgeDemo/SwiftForgeDemo.xcodeproj

Verified ** BUILD SUCCEEDED ** on Xcode 26 / iOS 26 simulator — including the Liquid Glass components. The app live-renders a couple of components (paywall, OTP) and lists the full catalog.

Tools the agent gets

Tool

What it does

list_categories

See the catalog's categories + counts

list_components

Browse components (optionally by category)

search_components

Free-text search by what you're building

get_component

Fetch one component's full, current SwiftUI source + usage + notes

What's inside

96 curated components across 14 categories: Buttons & Controls · Cards & Containers · Navigation & Bars · Lists & Scroll · Lists & Grids · Forms & Inputs · Charts · Effects & Liquid Glass · Feedback & Overlays · Media · Auth & Account · Animations · Layout & Scaffolding · Onboarding & Hero — including dedicated iOS 26 Liquid Glass components with graceful-fallback notes.

Every component is gated through a syntax check (scripts/validate.js, xcrun swiftc -parse) and a senior-review pass that strips deprecated API.

📖 Browse every component → docs/CATALOG.md

Roadmap

  • New components every release, kept current as iOS evolves.

  • Missing something? Open an issue — requests drive what gets added next.

The catalog here is free and MIT.

License

MIT (server). Catalog content © its authors.

Available Tools

4 tools
get_componentA

Fetch one curated SwiftUI component by id, including full production-ready, current-API source code, usage example, and notes. Paste the returned Swift directly into the project.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesComponent id (see list_components / search_components).

TDQS

A4.3/5.0
Behavior3/5

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

With no annotations, the description must convey behavior. 'Fetch' indicates a read operation, but it does not explicitly state that no data is modified or that there are no side effects. The instruction to paste code is user guidance, not tool behavior, so transparency is adequate but not explicit.

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 concise, with two sentences that fully convey purpose and output without redundancy. It is well-structured and free of fluff.

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?

Even without an output schema, the description explicitly lists what is returned (full source code, usage example, notes), providing complete context for the tool's function. No additional information is needed.

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 single parameter 'id' has a description that explains its meaning and directs users to list_components / search_components for valid values. Schema coverage is 100%, and the description adds useful context, elevating it above the baseline.

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 fetches one curated SwiftUI component by id, including source code, usage example, and notes. It distinguishes from sibling tools by explicitly focusing on retrieval by id rather than listing or searching.

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 usage when a specific component id is known, and the parameter description references list_components / search_components to obtain ids. It also instructs to paste the returned Swift into the project, providing practical guidance. However, it does not explicitly contrast with sibling tools in the main description.

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

list_categoriesA

List the SwiftForge component categories with how many curated SwiftUI components each holds. Call this first to see what's available.

ParametersJSON Schema
NameRequiredDescriptionDefault

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 must carry the behavioral disclosure burden. It states the tool lists categories with counts, implying a read-only operation, but it doesn't mention any potential side effects, sorting order, pagination, or limits. For a simple listing tool, this is adequate, but it does not add context beyond the basic action. Since it's a read operation and the description is straightforward, a 3 is appropriate.

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, concise sentence that front-loads the primary purpose and appends the usage guidance. Every word earns its place, with no redundancy or unnecessary detail. It is exemplary in conciseness.

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 has no parameters, no output schema, and a simple listing function, the description is complete enough for an agent to understand its function and when to call it. It lacks details like return format or potential caveats, but these are not essential for a tool of this simplicity. It could be slightly more comprehensive, but it's 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 zero parameters, so the baseline for parameter semantics is 4. The description does not need to add parameter details because there are none. It adds no parameter-related information, but that's acceptable given the absence of parameters.

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 (SwiftForge component categories), and the specific output (how many curated SwiftUI components each holds). This distinguishes it from siblings like list_components (which lists components) and get_component (which gets a single component). The purpose is unambiguous and differentiates well.

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

Usage Guidelines4/5

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

The description explicitly says 'Call this first to see what's available,' providing a clear when-to-use directive. It does not explicitly name alternatives or state when not to use it, but the guidance to call first is sufficient to convey its role as an entry point. This is clear context, though it could have mentioned using list_components for actual 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 curated SwiftUI components (id, title, category, description, minIOS, tags). Optionally filter by category. Use get_component to fetch the full source for one.

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryNoOptional category filter (exact match, see list_categories).

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description must carry the burden of disclosing behavior. It mentions the output fields and the optional filter, but does not disclose potential side effects (none expected), pagination, or default sorting. For a simple read-only list, this is adequate but lacks depth on edge cases like empty results or performance.

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

Conciseness5/5

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

The description is extremely concise: two sentences. The first states the core purpose and output fields, the second points to the sibling for full source. No filler, and the key information is front-loaded.

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 optional parameter and no output schema, the description covers the essential aspects: what it returns, the filter, and the alternative for full source. It lacks details on sorting or pagination, but those are not critical for a basic list operation. An agent can invoke it correctly.

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 repeats the category filter but adds no new information beyond the schema, which already notes exact match and references list_categories. The description does not enhance parameter understanding beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists curated SwiftUI components and specifies the fields returned. It differentiates itself from get_component by noting that tool fetches the full source, but it does not explicitly distinguish from search_components or list_categories, leaving some ambiguity about when to choose this over search_components.

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

Usage Guidelines4/5

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

The description gives explicit guidance to use get_component for full source, and mentions the optional category filter. However, it does not mention search_components as an alternative for searching, so the when-to-use context is incomplete but not misleading.

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

search_componentsA

Search the curated SwiftUI catalog by free text (matches title, description, tags, category). Returns brief results; follow up with get_component for full source. Prefer this when the user describes a UI need (e.g. 'glass card', 'pull to refresh', 'onboarding').

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesWhat the user is trying to build.

TDQS

A4.8/5.0
Behavior4/5

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

No annotations are provided, so the description bears the transparency burden. It explicitly says 'Search' and 'Returns brief results', making it clear this is a read operation without side effects. However, it does not explicitly state 'does not modify anything' or mention any side-effect-related details, so a slight gap remains.

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

Conciseness5/5

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

The description is two sentences, free of fluff, and front-loaded with the core search function. The follow-up instruction and preference guidance are packed efficiently without redundancy.

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 sibling tools list_categories, list_components, and get_component, the description fully explains how this search tool fits into the workflow: it returns brief results and advises following up with get_component for source. This is complete for an agent deciding whether and how to use the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'query' is described in the schema as 'What the user is trying to build.' and the description gives concrete examples of queries ('glass card', 'pull to refresh', 'onboarding'). This fully covers the parameter's purpose and expected input.

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?

Clearly states it searches the curated SwiftUI catalog by free text across multiple fields (title, description, tags, category). The verb 'search' and the scope are specific, and the distinction from siblings like list_categories and get_component is evident.

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

Usage Guidelines5/5

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

Explicitly instructs to prefer this tool when the user describes a UI need, provides concrete examples, and directs follow-up with get_component for full source. This gives clear when-to-use and when-not-to-use guidance.

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.

  1. 4 tool updatesv0.2.2
    • First observedget_component
    • First observedlist_categories
    • First observedlist_components
    • First observedsearch_components
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.3/5.0

Scored across 4 tools

Disambiguation4/5

list_categories and get_component are clearly distinct. list_components and search_components overlap somewhat as both return component lists, but their filter/search purposes are described well enough to avoid major confusion.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: list_categories, list_components, search_components, get_component.

Tool Count5/5

Four tools is well-scoped for a curated SwiftUI component catalog, covering browsing, listing, searching, and fetching details without unnecessary clutter.

Completeness5/5

The tool surface covers the full read-only lifecycle of the catalog: discover categories, list/filter components, search by free text, and retrieve full component source. No critical gap for the stated purpose.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • ds-pilot

    lyse-labs
    A
    license
    Not graded
    quality
    C
    maintenance
    MCP server that exposes your design system components and tokens to AI agents, preventing duplicate component creation and hardcoded token values.
    9 npm
    9
    MIT

  • coss-ui-mcp

    Zoot01
    A
    license
    A
    quality
    C
    maintenance
    MCP server for the coss ui design system, enabling AI agents to fetch components, props, and design tokens on demand for accurate, low-cost code generation.
    6
    1
    MIT