构建 MCP Connect:用于服务器的 MCP iOS 应用
tech
tech
ios
swift
mcp

构建 MCP Connect:用于服务器的 MCP iOS 应用

我打造了 MCP Connect,这是一款原生的 MCP iOS 应用,用于连接服务器、浏览工具,并在路上与 AI 聊天。

Uygar DuzgunUUygar Duzgun
Mar 22, 2026
Updated Mar 23, 2026
10 min read

What if your iPhone could talk to your own MCP servers anywhere? That is exactly what I built with MCP iOS app MCP Connect, a native mobile client for the Model Context Protocol. In this article, I explain how I designed, shipped, and deployed it, and why this approach matters if you want real AI tools on mobile.

MCP Connect 是什么?

MCP Connect 是我的 MCP iOS 应用,用于通过 HTTP 连接 MCP 服务器、浏览工具,并在路上与 AI 聊天。我用 Swift 和 SwiftUI 构建它,让它在 iPhone 上有原生的感觉,运行也快速且稳定。

该应用让你可以:

通过 HTTP 连接任意 MCP 服务器
浏览每个服务器上可用的工具
通过你的工具与 AI 进行对话
监控服务器健康状态与延迟
管理多个服务器连接
在英语和瑞典语之间切换

我希望这个应用看起来更“高级”,而不是一个简单的封装器。因此我采用了深色影院风格、玻璃拟态(glassmorphism)、弹簧动画(spring animations)以及触觉反馈(haptic feedback)。这个设计选择很重要,因为移动端的 AI 工具需要让人感觉快速且清晰,尤其是在用户在聊天与服务器之间切换时。

为什么我要构建一个 MCP iOS 应用

我构建这个 MCP iOS 应用,是因为我想要能直接从手机访问自己的工具。当你离开桌面时,桌面端的工作流会让你慢下来。在 iPhone 上,我想要获得与我在浏览器和 Mac 上已经拥有的同样控制能力。

在我于哥德堡(Gothenburg)构建产品的经验里,最好的移动应用会把一个痛点、狭窄的问题解决得非常到位。MCP Connect 就是这样。它为我提供对 MCP 服务器的安全访问,而且不会再增加一层复杂的东西。

这也符合 Model Context Protocol 本身的方向。Anthropic 的 MCP 规范围绕清晰的客户端-服务器模型构建,这使得它非常适合需要结构化工具访问的移动应用。我让实现与这个理念保持一致,这样随着协议演进,应用仍然易于维护。

我解决的用户问题

大多数 AI 工具仍然假设你坐在桌面前。当你在旅行中需要检查服务器、触发工具或查看结果时,这就会被打破。有了 MCP Connect,我降低了这种摩擦。

结果很简单:我可以打开应用,选择一个服务器,然后在几秒内与我的工具进行交互。MCP iOS 应用 的速度就是它存在的意义。

支撑 MCP iOS 应用的技术栈

我让技术栈保持聚焦且现代。我不想要臃肿的架构,也不想引入不必要的依赖。

技术
------
平台iOS 17+、Swift 6、SwiftUI
架构MVVM + Coordinators
后端Supabase(Auth、PostgreSQL、Realtime)
MCP 传输HTTP 上的 JSON-RPC
持久化SwiftData
IAPStoreKit 2
i18nString Catalogs(EN + SV)
部署Xcode + XcodeGen

这个技术栈为 MCP iOS 应用 提供了坚实的基础。SwiftUI 很擅长处理界面,SwiftData 支持离线优先(offline-first)的存储,而 Supabase 则在不增加额外后端负担的情况下提供认证与同步。

我还使用了熟悉的生产级工具,比如用 Keychain 存储密钥,以及用 StoreKit 2 处理订阅。这样应用就能把注意力放在产品质量上,而不是基础设施噪音上。

第 1 步:我先设计系统

我总是先从设计系统开始,因为这能节省后面很多时间。在这个项目里,我在编写功能代码之前就先做了 tokens 和共享组件。

Dark Cinema 配色使用深黑色、细微的抬升表面,以及靛蓝(indigo)的强调色。每个表面都使用带 `.ultraThinMaterial` 的玻璃拟态处理,并配以细边框,让 UI 有层次感但不显沉重。

系统包含:

ColorTokens:用于语义化颜色
TypographyTokens:用于 UI 与代码样式
SpacingTokens:基于 4/8 节奏构建
可复用的 GlassMorphism 修饰器(modifier)
具有一致运动风格的弹簧动画(spring animations)
每次交互都带触觉反馈(haptic feedback)

我构建了可复用的组件,比如 `GlassCard`、`AccentButton`、`StatusBadge`、`ShimmerLoader` 和 `GlassTextField`。这让 MCP iOS 应用 更容易扩展,因为新页面会继承相同的视觉语言。

第 2 步:我把模型与持久化分离

我将领域模型(domain models)与 SwiftData 持久化模型分开。这样能让业务逻辑保持干净、可测试。

主要模型包括:

`MCPServer`:用于连接设置
`Conversation`:用于每个聊天会话
`Message`:用于用户与助手消息
`ToolCall`:用于工具输入、输出以及计时

这种分离比听起来更重要。它让我可以在不重写应用逻辑的情况下更换存储细节。对于一个 MCP iOS 应用 来说,这种边界会让未来功能更容易上线。

安全决策:只用 Keychain 存 API keys

我定了一条不会打破的规则:API keys 永远不触碰 Supabase。我只在数据库里存一个 `apiKeyRef`,而真正的 key 存在 iOS 的 Keychain 中。

这意味着数据库泄露不会暴露凭据。代价是 key 不会在设备之间自动同步。用户需要在新手机上重新输入,但这只需要几秒钟,同时消除了严重的安全风险。

第 3 步:我构建 MCP 客户端

客户端使用 HTTP 上的 JSON-RPC,这与 MCP 规范中的 Streamable HTTP transport 相匹配。每个请求都会以标准的 HTTP POST 形式发出,body 为 JSON-RPC。

应用支持四个核心操作:

`initialize`:协商协议版本并完成会话初始化
`tools/list`:发现可用工具
`tools/call`:使用参数执行工具
`ping`:测量延迟并检查健康状态

我在请求时从 Keychain 加载授权 tokens。这样能让 MCP iOS 应用 更安全,并避免把密钥在内存中保存得比需要更久。

我用自己的服务器进行测试,直到请求流程在真实使用下感觉稳定。最终得到的是可预测的延迟,以及比我一开始预期更好的移动端体验。

第 4 步:我接入 Supabase

我使用 Supabase 进行认证与同步,因为它能让我快速走向生产环境。后端有四张表:

`user_profiles`:用于主题与语言设置
`mcp_servers`:用于每个用户的服务器配置
`conversations`:用于聊天会话
`messages`:用于消息历史与工具数据

每张表都启用了行级安全(Row Level Security)。这意味着用户只能访问自己的记录。我还添加了一个数据库触发器:在用户注册后自动创建 profile。

认证支持使用 Apple 登录以及邮箱/密码登录。这样我就能提供一个干净的注册流程,而不强迫用户只能用某一种登录方式。对于一个 MCP iOS 应用 来说,这种灵活性有助于提升采用率。

第 5 步:我构建主要功能

应用有三个核心界面:聊天、服务器管理和设置。我让每个界面都保持聚焦,这样在手机上体验依然快速。

聊天界面

聊天使用状态机:`idle` → `sending` → `streaming` → `toolCalling` → `idle`。工具调用会以可展开卡片的形式内联展示,包含工具名称、参数、结果以及执行时间。

这个 UI 很关键,因为它帮助用户信任 AI 正在做什么。他们能看到每一步,而不是只能猜。

服务器管理

用户可以添加、编辑和删除服务器。我加入了 URL 校验、向左滑动删除,以及确认弹窗,让服务器变更感觉安全且经过深思熟虑。

每个服务器详情页都会展示健康数据、使用 Swift Charts 绘制的延迟图表,以及一个 Tool Explorer,用于列出可用工具与参数 schema。这样让 MCP iOS 应用 比一个简单的聊天前端更有用。

导航与设置

我使用三标签(three-tab)布局,结合 `NavigationStack` 与类型安全的路由。通过 `mcpconnect://` URL scheme 支持深度链接。

设置包括:

深色、浅色与系统主题
8 种强调色选项
应用内语言切换:英语与瑞典语
订阅管理

第 6 步:我部署 MCP 服务器端点

最难的部分是让一个基于 stdio 的 MCP 服务器能够被移动端访问。我的个人站点 MCP 服务器最初以本地 Node.js 进程运行,并使用 `StdioServerTransport`。

为了让它能被 MCP iOS 应用 使用,我在 Vercel 上的 Next.js 站点中添加了一个 API 路由。该路由使用 MCP SDK 的 `InMemoryTransport`,把 JSON-RPC 请求桥接到本地服务器实现。

每个请求都会通过 `createLinkedPair()` 创建一对新的服务器/客户端实例,执行操作并返回响应。这个方案很适合无服务器(serverless)基础设施,因为它避免了长连接。

该端点位于 `https://uygarduzgun.com/api/mcp`,并暴露了 15 个工具,任何 MCP 客户端都可以调用。这个配置把一个本地工具服务器变成了移动端可用的服务,而无需重设计整个后端。

为什么这种架构有效

在实践中,它之所以有效,是因为每个请求都是无状态且彼此隔离的。这降低了运维风险,也让扩展更容易。如果你要构建一个 MCP iOS 应用,那么这种模式值得考虑用于无服务器部署。

第 7 步:IAP 与变现

我使用 StoreKit 2 做了一个简单的免费/Pro 模式。免费档可用,但 Pro 档会移除高活跃用户最先遇到的限制。

功能免费Pro($4.99/月)
------:---:
服务器2无限
会话50无限
历史记录30 天无限
主题深色 + 浅色+ 自定义强调色
搜索当前聊天全文搜索

我喜欢这个模式,因为它不会惩罚普通/随用用户。它会在一开始给足价值,然后当应用成为真实工作流的一部分时,自然扩展。

项目数据与结果

最终构建出来的体量比我预期更大,但结构依然保持清爽。

9 个功能模块中共有 50+ 个 Swift 源文件
英语与瑞典语各 90+ 条本地化字符串
通过 API 端点暴露 15 个 MCP 工具
4 张 Supabase 表,并配置了 RLS 策略
5 个 Swift Package Manager 依赖
0 行 UIKit

这些数字之所以重要,是因为它们表明这个应用是生产级的,而不是原型。我想要一个真正的 MCP iOS 应用,并且我已经上线了。

我会为这篇文章添加的图片

如果我发布这篇文章,我会加入带描述性 alt 文本的截图,帮助读者并提升 SEO。

iPhone 上的 MCP Connect 主界面
MCP iOS 应用内的 Tool Explorer
Swift Charts 中的服务器延迟仪表盘
Dark Cinema 设计系统组件

关键要点

我先围绕清晰的设计系统构建了 MCP iOS 应用
我把领域模型与持久化分离,让代码库更易维护。
我只把 API keys 存在 Keychain 中,而不是 Supabase。
我用 `InMemoryTransport` 把 MCP 服务器桥接到 Vercel。
我交付了一款原生 SwiftUI 应用,在移动端表现良好。

MCP Connect 证明了 MCP iOS 应用 这个想法是可行的、足够安全,并且已经准备好用于真实场景。如果你正在构建移动端 AI 工具,这种架构可以帮你节省时间并降低风险。阅读相关帖子:audio signal levels explained(音频信号电平解释),或者如果你希望我下一步拆解服务器代码,请留言。