让它跑起来确实花了我不少排查时间，不是因为某一步特别难，而是因为手动路径默认你的配置文件干净、Node 版本足够新，而且如果不满足这些条件，你得自己把它们修好。
按类别选择工具的功能是真正的优势，比单一的捆绑权限授权更精确。
一旦连接成功，就要做好“谨慎但不快”的准备。每次工具调用都会等你确认，这正是当你在认真盯着它时所希望的；而如果你只是想尽快完成工作，它也会显得很慢。
如果你正在阅读这篇文章，你很可能是在试图回答一个具体的问题：你到底能不能信任一个 AI 编码代理来管理你的 Hostinger 真实账户，以及在不依赖预置扩展的情况下，连接一个这样的代理究竟需要什么。
这正是我测试的内容。Hostinger MCP 是一项集成，它让 Claude Code、Cursor 和 Codex 等 AI 工具能够通过 Model Context Protocol 连接到 Hostinger 服务。
Hostinger Connector 是进入该集成的一种方式，是一个基于 OAuth 的一键式 VS Code 扩展。本文我没有测试 Connector。我测试的是直接在 hPanel 中生成 API 令牌，并手动将其接入 Claude Code；如果你使用 Claude Code、JetBrains，或者任何没有专用扩展的客户端，你就会走这条路线。
我构建了一个名为 LinkSnap 的小型链接缩短应用，将其连接到一个真实的 Hostinger 账户，并带着它经历了账户读取、部署目标发现、一次正式部署、一次刻意制造的失败，以及恢复过程。
我们的 Hostinger Connector 评测 介绍了这个基于 OAuth 的扩展是如何实现相同底层协议的，以及我们对此得出的不同结论。
下面是我对 Hostinger MCP 的评分方式，基于那些真正影响你是否值得花时间手动设置的方面：它是否收费、你实际能获得什么、设置有多麻烦、执行是否准确，以及当你需要帮助时支持是否到位。
| 参数 | 分数 | 为什么给这个分数 |
|---|---|---|
| 价格 | 9.7/10 | MCP 本身不额外收费，并且可用于你已经拥有的任何 Hostinger 套餐。 |
| 功能 | 9.3/10 | 手动设置让你可以单独启用工具类别：Websites、Domains and DNS、Subscriptions and Payments、Email Marketing、VPS 和 Ecommerce，每个类别都会成为单独的连接，而不是一个捆绑权限包。 |
| 设置与认证 | 7.8/10 | 令牌生成很快，但如果你的配置文件里已经有内容，你就得自己处理，我在真正开始之前还遇到了一个过旧的 Node 版本和一个残留的全局路径问题。 |
| 执行准确性 | 9.2/10 | 账户读取发现了两个已悄然过期的托管订单，而目标发现则用真实、可核查的理由排除了两个现有候选项，没有盲目猜测。 |
| 支持 | 9.0/10 | Kodee 在大约两分钟内、经过四轮交互，准确回答了一个真实的双重术语问题。 |
| 总体 | 9.0/10 | 一种更透明、更手动的方式来将 AI 代理连接到你的 Hostinger 账户，并且在我故意制造的失败中，部署流程保护了一个线上站点。 |
你找不到 Hostinger MCP 的价格页面，因为它根本没有价格页面。它不是单独购买的产品。
如果你启用手动设置路径，你可以在首次打开之前选择 AI 客户端可见的工具类别，而你启用的每一个类别都会在配置文件中生成一个单独的连接，而不是一个大而统一的工具集。
Hostinger 还在底层 API 中记录了默认速率限制：每分钟 60 次请求、每小时 1,000 次请求，并且当前使用量会通过响应头返回。
对于本评测所涵盖的那种交互式、一次只处理一件事的工作，我从未接近任何一个上限。如果你打算做更自动化的事情，比如无人值守运行的脚本，而不是等待你批准的代理，这就是一个需要设计时认真考虑的数字。
如果你想判断自己是否真的能完成手动设置，先理解为什么这一部分看起来和普通的易用性评测完全不同会有帮助。
Hostinger MCP 没有自己的账户可创建，没有注册表单，也没有首次登录时可浏览的仪表盘。它是建立在你已经拥有的 Hostinger 账户和托管套餐之上的。之所以没有注册步骤，是因为除了你本来就持有的账户之外，它没有需要注册的东西。
这里的“易用性”实际上指的是连接过程本身， 也就是把一个你已经能够登录的账户变成 AI 代理可以看到并执行操作的对象。这就是为什么这一部分会直接从生成访问权限开始，而不是从注册页面说起。
而且手动设置并不只绑定某一个客户端。Hostinger 列出了：
我选择了 Claude Code ，因为它在终端中运行，而不是在 IDE 侧边栏中运行；同时它没有自己的 Hostinger 专用扩展，这意味着手动的令牌路径是唯一入口，也让我能够最纯粹地测试这条路径。
在 Hostinger 进入画面之前，还有一个前置条件，而且这取决于你选择的客户端。Claude Code 本身运行就需要 Node.js 22 或更高版本。我的机器上仍然是之前项目留下的旧版本，在我碰到 hPanel 之前就已经遭遇了引擎警告和安装损坏的问题。那不是 Hostinger 的问题，但如果你的开发机还没有更新，这确实会消耗时间。
当 Claude Code 真正开始运行后，我转向了 hPanel 的 API 页面，而它现在已经直接围绕 MCP 构建。
页面顶部列出了六个客户端：VS Code、Cursor、Devin Desktop、Antigravity、Claude Code 和 Codex，其中 VS Code 使用一键式 Connector 扩展，而其他所有客户端，包括 Claude Code，都走手动路径。
生成令牌本身只需要很少的信息：
最后这一点如果你在意访问控制，就很重要。它不在令牌上设置，而是在前一步单独的选择器里设置，你可以在那里决定连接实际会暴露哪些工具类别，这也是我接下来要做的。
| 细节 | 结果 |
|---|---|
| 生成令牌所需字段 | 仅名称和有效期 |
| 令牌本身是否可选择作用域 | 没有 |
| 离开页面后是否还能再次看到令牌 | 不能，仅显示一次 |
| 令牌表记录 | 名称、创建日期、最后使用时间、过期时间 |
接着，在任何配置文件存在之前，hPanel 要我选择这个连接将暴露哪些类别的工具：
我只启用了 Websites，因为这已经涵盖了 LinkSnap 所需的一切。你启用的每个类别都会在生成的 JSON 中变成一个单独的条目，带有自己的命令和自己的包名，但都指向同一个令牌。这正是手动路径真正优于单一捆绑权限界面的地方：你在 AI 客户端打开之前就能决定它的精确形态，而不是之后。
然后到了真正花我时间的部分。hPanel 会给你一段现成的 JSON 代码块和一个文件路径，在 Linux 上是 ~/.claude.json，并告诉你把它粘贴进去。
我的文件里已经有之前一次设置尝试留下的内容。直接把新的代码块粘进去而不进行合并，会让我得到两个顶层对象，这不是有效的 JSON，而 Claude Code 也无法启动，直到我手动把文件重写为一个对象。
当配置文件终于有效后，最后一步是让 Claude Code 本身读取它。这里你还需要单独登录 Claude，和 Hostinger 令牌是分开的，因为 Claude Code 运行在 Claude 订阅或 API 计费之上。与浏览器扩展相比，这确实是一个额外步骤，因为浏览器扩展通常会直接复用你大概已经登录的会话。
完成这一步后，连接在第一次重启时就顺利成功了。直接询问 Claude Code 它可以访问哪些 Hostinger 工具，返回的是完整且分组正确的列表，与我启用的那个类别完全一致。
| 检查项 | 结果 |
|---|---|
| Claude Code 需要单独登录，与 Hostinger 分开 | 是 |
| 修正配置后首次重启即连接成功 | 是 |
| 返回的工具列表与启用类别一致 | 是 |
| 默认每次工具调用都需要确认 | 是，每次都需要 |
最后一行会决定你之后的整体体验。Claude Code 发起的每次工具调用，无论是列出网站、检查构建，还是运行 shell 命令，都会先停下来向你请求是否同意，除非你开启自动批准。
在整个测试过程中，我一直保留单独批准，以便真实了解它的代价，而仅一次部署与恢复循环就需要我逐一批准十多次。
在你把任何真正的工作交给它之前，还有一件事要知道：这里没有沙盒。你批准的每条命令都会立即作用于你的真实账户和真实托管环境 ，只要你说了是。
这里不存在夹在提示和真实变更之间的模拟环境，所以一次错误的批准就是真的错误。
按类别选择工具的功能是真正的优势，比单一的捆绑权限授权更精确。
一旦连接成功，就要做好“谨慎但不快”的准备。每次工具调用都会等你确认，这正是当你在认真盯着它时所希望的；而如果你只是想尽快完成工作，它也会显得很慢。
你已经知道配置文件可以把它连起来。你真正想知道的是，对面那个东西到底能不能正确完成真实的托管工作，所以我构建了 LinkSnap，一个小型 Express 应用，并让它经历了完整的部署生命周期。
| 测试 | 我想了解什么 |
|---|---|
| 读取账户数据 | 它能准确报告你的账户吗？ |
| 查找部署目标 | 它是在猜，还是会先检查？ |
| 部署 LinkSnap | 它能把一个真实应用从本地迁移到线上吗？ |
| 验证线上应用 | 它会相信自己的成功声明吗？ |
| 故意破坏应用 | 平台会如何处理一个坏构建？ |
| 恢复应用 | 它能干净地恢复到一个已知良好版本吗？ |
LinkSnap 的健康检查端点在后面会起作用，原因很简单：一个平台可以声称构建完成，但你的应用实际上从未启动。
一个线上端点是你唯一能独立核实这一点的方式 ，而不是相信状态标签。
我让 Claude Code 列出账户中的所有网站和活跃托管套餐，没有给它任何提示。
这个账户确实很复杂：一个订单下有十七个站点，第二个订单下有两个站点，另外还有两个站点挂在已经不再显示为活跃的订单下。
| 检查项 | 结果 |
|---|---|
| 列出的网站总数 | 21，与 hPanel 完全一致 |
| 识别出的活跃套餐 | 2，与 hPanel 完全一致 |
| 未被询问就标记了过期订单中的站点 | 是，两个都正确识别 |
它不仅仅是列出了我要求的内容。它注意到有两个站点属于不在活跃列表中的订单，标记它们很可能已经暂停，而我随后在 hPanel 中独立确认了这两个站点确实已过期。
这已经不只是检索了，这更像是在审计你的账户，而不是单纯读取它。
这项测试最能告诉你是否真的可以信任它处理一个真实的线上账户。
我让它在不指定任何域名的情况下，判断我是否有一个可用于 LinkSnap 的 Node.js 站点。
| 步骤 | 发生了什么 | 结果 |
|---|---|---|
| 检查第一个现有 Node.js 站点 | 发现一个正在使用中的活跃部署 | 正确排除 |
| 检查第二个现有 Node.js 站点 | 发现它隶属于一个已过期订单 | 正确排除 |
| 提出新站点 | 位于正确的活跃订单下 | 准确 |
| 行动前先询问 | 提供一个免费子域名或自定义域名 | 通过 |
我选择了免费子域名。它生成了 floralwhite-ferret-411142.hostingersite.com ，并在正确的订单下创建了站点，之后我在 hPanel 中自己验证了这一点。
一切都匹配。
有了经过确认的目标后，我把 LinkSnap 打包成 zip 压缩包，并让 Claude Code 进行部署。
主要部署工具在第一次尝试时失败了，失败发生在上传步骤。
它没有盲目重试，而是先检查站点存储是否真的可访问，排除了这一原因，然后切换到另一种方法：请求一个直接上传 URL，把压缩包上传过去，再单独触发构建。
| 步骤 | 结果 |
|---|---|
| 主要部署工具 | 在上传时失败 |
| 存储可达性检查 | 通过，排除为原因 |
| 备用方法 | 手动上传 URL 加单独构建触发 |
| 备用方法结果 | 成功 |
| “构建完成”后的自我验证 | 执行了自己的实时请求，确认 HTTP 200 |
| 我的独立检查 | 主页和健康端点都正常响应 |
部署工具第一次就失败，这确实是一个弱点，我想明确说出来。让它没有变成坏结果的，是后面发生的事情：一次真实的诊断、一个可用的替代方案，以及不是只看状态徽标的实时检查。
如果你想知道事情出问题时会发生什么，这一部分才是你真正关心的。
我让 Claude Code 先备份了正常工作的 package.json，然后把启动命令改成指向一个不存在的文件。
它无法直接编辑线上应用的文件，因为部署的 Node.js 应用没有暴露文件编辑工具。
它没有悄悄绕过这个限制，而是解释了这个限制，改为使用我本地的压缩包，从中展示了精确的单行改动，并在触碰任何内容之前等待我的确认。
| 测试 | 结果 |
|---|---|
| 更改前已创建备份 | 是 |
| 应用更改前展示了精确变更 | 是 |
| 部署了损坏的构建 | 构建报告失败 |
| 失败构建期间的线上应用 | 保持运行，继续提供正常版本 |
| 显式重启后的线上应用 | 仍然提供正常版本 |
| 从备份恢复 | 通过 |
| 重新部署干净版本 | 完成，经过一次重试 |
| 最终验证 | HTTP 200，已确认健康响应 |
这是一项最重要的发现。平台没有悄悄接受一个损坏的部署。它拒绝了坏构建，并且在整个过程中一直让我的最后一个已知良好版本保持运行，无论是重启前还是重启后。
唯一诚实的空白： 构建日志只显示了依赖项安装成功，却没有显示实际缺失文件的错误，所以如果是真实故障，你仍然需要到别处去找具体原因。
还有一件你应该知道的小事：在这项测试进行到一半时，Claude Code 提到了一个与本次会话无关的、之前项目的名称。它没有影响结果，但我觉得有必要把这点标出来，而不是忽略。
最明显的弱点是主要部署工具本身，它在我两次尝试中都失败了，每次都需要手动备用方案。
如果你在自己设置时遇到问题，下面就是你向 Hostinger 寻求帮助时实际会发生的事情。
| 渠道 | 可用性 | 备注 |
|---|---|---|
| 在线聊天（Kodee，AI） | 24/7 | 运行在本评测所涉及的同一 Model Context Protocol 上，且 Hostinger 将其描述为能够执行真实账户操作，而不仅仅是回答问题 |
| 在线聊天（人工） | 可由 Kodee 升级转接 | 可在同一聊天窗口中按需使用 |
| 知识库 | 自助服务 | support.hostinger.com |
我向 Kodee 提了一个有真实双向答案的问题：Hostinger MCP 是否是一个可单独购买的产品，以及它与 Hostinger Connector 到底是什么关系。
你不能通过复制一段文档内容来回答这个问题，因为它需要正确区分一个协议与其某个具体实现。
| 问题 | Kodee 的回答 | 评估 |
|---|---|---|
| MCP 和 Connector 是一回事吗 | 不是，MCP 是更广泛的集成，Connector 是一种推荐的基于 OAuth 的设置方法 | 正确且范围界定精确 |
| MCP 本身能单独购买吗 | 不能，它不是一个单独的产品或订阅 | 正确 |
| API 令牌在哪里找 | 账户，然后是 API 或 Dev Tools，生成、命名、设置有效期、立即复制 | 正确且具体 |
| 要使用什么环境变量 | 直接说明令牌变量的名称，并指出 Connector 是跳过它的替代方案 | 正确 |
整轮交流，四个问题和四个答案，根据时间戳看大约用了两分钟。
我一次都不需要反驳、改写或升级转接。很多 AI 支持工具在两部分问题里只会处理简单的一半，而在更难的一半上变得含糊。Kodee 在这里没有这样做。
Hostinger 的知识库按大类组织：Getting Started、hPanel、AI Builder、Domains、DNS、Files Management、Email、MySQL Databases、Website、VPS、Agency Hosting Plans、Reach、SSL、PHP、Profile Management、Billing、Affiliates and Referrals、Features、cPanel 和 About Hostinger。
其中没有任何一个类别是专门给 MCP 的，所以如果你按类别浏览，是找不到它的。
不过，直接搜索“MCP”就能找到相关内容。该搜索返回了二十条结果，其中最相关的两篇文章，WordPress 专用的 MCP 设置和本地 IDE 设置，排在最前面。
其下混杂着一些关联较弱的结果，主要是其他碰巧提到 MCP 的 AI 代理产品。
我直接打开了与本评测设置相符的文章：“如何在本地 IDE 上设置 web hosting MCP。”这篇文章确实写得很好：
你需要知道的一个缺口是，这篇文章中的手动教程用 Cursor 作为示例，而不是 Claude Code，尽管 Claude Code 也是官方列出的客户端之一。
实际上这并没有拖慢我，因为 hPanel 自己的 API 页面直接生成了针对 Claude Code 的文件路径和 JSON 块，而这比文章中的示例更新。
如果你只依赖这篇文章并使用 Claude Code，你就需要自己把 Cursor 特定步骤改成适用于自己的版本。
唯一真正的不足是，旗舰设置文章偏向于以 Cursor 为示例，所以如果你使用 Claude Code，你得到的是准确但不是专为你准备的指导。
值得。不是因为设置过程一直很顺利，它并不顺利，而是因为当我把一个 AI 代理交给真实账户并故意尝试破坏它时，实际发生了什么。
账户读取在没有被要求的情况下发现了两个悄然过期的托管订单。目标发现以真实、可核查的理由排除了两个不合适的站点，而不是盲目猜测。一个被我故意破坏的部署被拒绝了，而且在整个过程中，你的站点始终保持在线。
在整个评测中最突出的，不是某个单独功能表现正确，而是它们背后的共同模式：先检查，再行动，并且在无法核实的时候如实说明。
同样的模式也出现在支持中，Kodee 在大约两分钟内首次就正确回答了一个确实有两个部分的技术问题。
这并不意味着它是一个成熟、无摩擦的产品。主要部署工具在我尝试的两次中都失败了，每次都需要手动备用方案。
如果配置文件里已经有内容，只要粘贴不当就会坏掉。而且整个过程中根本没有沙盒，你给予的每一次批准都会立即作用于你的真实账户，这让同样需要谨慎的操作变得风险更高。
如果你想要一个会先检查再行动、并且在遇到限制时会坦白说明的 AI 代理，并且你愿意接受这套工具周边的一些粗糙之处，那么 Hostinger MCP 值得你花时间。
如果你需要的是一个开箱即用、打磨完善且没有摩擦的产品，或者如果“部署工具第一次就失败”对你来说不是小毛病而是无法接受的硬伤，那它现在还不值得你花时间。
| Description | Expert Review |
|---|---|
| 价格实惠的托管服务，具有高性能和简便的管理工具。 | Read Shared Hosting Review |
| 快速且安全的 WordPress 托管，提供一键安装和高级功能。 | Read Wordpress Hosting Review |
| 具有专用资源和 root 访问权限的可扩展 VPS 托管. | Read VPS Review |
| 快速、灵活的云托管，拥有出色的正常运行时间和可扩展的资源�... | Read Cloud Hosting Review |
| 具有海外数据中心的安全私密托管解决方案。 | Read Offshore Hosting Review |
| 具有专业级功能的安全可靠电子邮件托管服务。 | Read Email Hosting Review |
| 为开发者提供灵活环境的可靠 Python 托管服务。 | Read Python Hosting Review |
| 高性能 PHP 托管，全面支持动态网站和应用程序。 | Read PHP Hosting Review |
| 可靠的 Windows VPS 托管，提供完全控制和自定义选项。 | Read Windows VPS Review |
| 为 Node.js 应用量身定制的快速灵活托管，带来最佳性能。 | Read Nodejs Hosting Review |
| 针对 WooCommerce 商店的优化托管，提供高速和安全集成。 | Read Woocommerce Hosting Review |
| 专用服务器托管，带来无缝的Minecraft游戏体验。 | Read Minecraft Server Hosting Review |
| 面向数字化代理机构和开发者的具有高级功能的可扩展托管解决�... | Read Agency Hosting Review |
| 为 Magento 电子商务网站优化的快速、安全托管. | Read Magento Hosting Review |
| 基于 Linux 的高性能托管，用于网站的稳定和安全运行。 | Read Linux Hosting Review |
| 为动态Web应用和项目提供稳健的Java托管解决方案。 | Read Java Hosting Review |
| 适用于电子商务网站的优化托管，提供安全、快速且可靠的性能�... | Read Ecommerce Hosting Review |
| 可靠的 Django 托管，具有快速速度和安全的环境。 | Read Django Hosting Review |
| 易于使用的 cPanel 托管，具有强大性能和可靠支持。 | Read Cpanel Hosting Review |
| 为企业提供强大的托管服务，具有高速、安全性和可扩展性。 | Read Business Hosting Review |
| Easy-to-use website builder with drag-and-drop tools and customizable templates. | Read Website Builder Review |
| Optimized hosting for Joomla sites with one-click installation and reliable performan... | Read Joomla Hosting Review |
| Powerful hosting with full PostgreSQL database support for data-driven applications. | Read PostgreSQL Hosting Review |
| Flexible hosting with MongoDB integration for scalable, modern web applications. | Read MongoDB Hosting Review |
| AI-powered website creation platform for building professional sites in minutes. | Read Horizons Review |
| Reliable hosting for n8n workflow automation with easy setup and management. | Read n8n Hosting Review |
| VPS hosting with Docker support for containerized application deployment and scaling. | Read Docker VPS Review |
| 专用 SMTP 服务器托管，实现可靠且安全的电子邮件传递。 | Read SMTP Server Review |
| 为 Ruby on Rails Web 应用量身定制的快速且优化的托管服务。 | Read Ruby on Rails Review |
| 适用于构建和管理抓娃娃机游戏的功能丰富的托管服务，集成 Ope... | Read OpenClaw Review |
| 快速且可靠的托管服务，配备英国本地服务器，提供最佳本地性�... | Read UK Hosting Review |
| 价格实惠且可靠的主机，配备印度本地服务器，低延迟访问。 | Read India Review |
| Read Singapore Review | |
| Read Australia Review | |
| Read AI Agent Review | |
| Read Paperclip VPS Review | |
| Read Hermes Agent Review | |
| Read Hostinger Connector Review | |
| Read Web Apps Hosting Review | |
| Read Hostinger Reach Review | |
| Read hpanel Review | |
| Read Odoo Review | |
| Read Laravel Review | |
| Read MERN VPS Review | |
| Read Ubuntu Review | |
| Read Drupal Hosting Review | |
| Read Express.js Review | |
| Read React Review | |
| Read Nextjs Review |
Hostinger MCP 是一种集成，可让 AI 编程工具通过模型上下文协议连接到你的 Hostinger 服务。它不是单独的托管产品，并且它会与你现有的账户配合使用，而不是取代 hPanel。
不是。Connector 是一种设置方法，通过浏览器扩展使用 OAuth。你也可以手动使用 API 令牌配置连接，这是本次评测测试的路径，目前支持包括 Claude Code、Cursor、Devin Desktop、Antigravity 和 Codex 在内的客户端。
是的，MCP 集成本身不收取单独费用。您仍然需要一个符合条件的 Hostinger 主机、云服务器或 VPS 方案，才能让 AI 代理实际执行您需要的任务。
在我的测试中，我故意破坏的构建被拒绝而不是部署了，这倒是个好迹象。但构建日志没有显示失败背后的具体运行时错误，只显示依赖安装成功。请直接检查你的线上应用或健康检查端点，不要只依赖构建日志。
是的。我仅使用 Claude Code 中手动配置的 API 令牌，且没有使用 Connector 扩展，部署了一个 Node.js 应用，之后又故意把它弄坏了。主要的部署工具在我两次尝试中都失败了，每次都需要手动上传并构建作为备用方案，不过这两次备用方案都成功了。
我没有直接测试这一点，因为我的令牌设置为一个月后过期，而它持续的时间比整个评审期还长。这是一个需要提前规划的现实问题，而不是我能通过测试回答的问题：请设置一个日历提醒，在令牌到期前轮换它，因为任何依赖它的任务一旦在会话中途过期，理论上都会失败。
HostAdvice.com在完全独立于任何实体机构的情况下提供了专业的网络主机评价服务。我们的评论不偏袒、诚实而且对所有的评论都以相同的审查标准进行。
我们的收入是从我们从评论的公司那里收取得来的。但相关的服务及产品的补贴并不影响我们评论的方向及结论，也不会影响我们对特定主机公司的排名。
所收取的补偿金包括：账户采购成本、测试成本和支付的相关版税等。
