mofox-docs-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MOFOX_DOCS_TIMEOUT | No | 请求超时(秒) | 30 |
| MOFOX_DOCS_BASE_URL | No | 文档站地址 | https://docs.mofox-sama.com |
| MOFOX_DOCS_CACHE_TTL | No | 索引缓存时长(秒) | 300 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_docsA | 按关键词检索 Neo-MoFox 官方文档。查询按空白拆分为多个关键词,按「命中关键词数量」降序返回(命中全部关键词的文档排最前,至少命中一个即返回)。匹配标题 / 简介 / 正文预览 / 分类 / id / 路径。结果不含完整正文,需要全文时再用 get_doc 获取。 |
| list_docsA | 列出 Neo-MoFox 官方文档。按 section 排序,部署指南(guides/deployment)排最前,每篇含 title / description / preview / section。支持 offset 分页。 |
| get_docA | 获取指定文档的完整正文(纯文本)。doc_id 形如 guides/deployment/deployment_guide,可从 search_docs / list_docs 结果的 id 字段获取。 |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| docs-index | |
| 社区部署方式 | 欢迎来到 Neo-MoFox 社区部署方式专区!这里汇集了由社区成员贡献的各种便捷部署方案。 |
| [ 没更新的旧时代文档 ] Neo-MoFox安装脚本使用说明文档 | sudo curl -fsSL "https://raw.githubusercontent.com/MoFox-Elysia/MoFox-Installer/main/mofox.sh" -o "mofox.sh" && echo bash mofox.sh |
| Neo-MoFox Windows 部署指南 | 本指南将引导你在 Windows 环境下完成 Neo-MoFox 的部署流程。 |
| Neo-MoFox Launcher 使用指南 | Neo-MoFox Launcher 是一个图形化的机器人管理工具,让您通过可视化界面轻松部署和管理 Neo-MoFox QQ 机器人。无需敲命令,全程鼠标点击即可完成。 |
| Neo-MoFox Android 官方部署指南 | MoFox Android App 会在应用内部安装一套独立的 Debian 13 运行环境,并通过 proot 运行 Neo-MoFox、NapCat 和 WebUI。整个过程不依赖 Termux,也不要求设备获取 Root 权限。 |
| Neo-MoFox Docker 部署指南 | 本指南介绍如何使用主项目提供的 Docker Compose 编排部署 Neo-MoFox。当前编排使用 SnowLuma 作为 QQ 协议桥接服务,不再使用 NapCat 容器。 |
| Neo-MoFox Linux 部署指南 | 欢迎使用 Neo-MoFox,一个高度可定制化的 AI Bot 框架。 |
| 部署指南 | 欢迎来到 Neo-MoFox 部署指南。请根据你的操作系统选择对应的指南开始部署。 |
| Neo-MoFox 核心配置指南 (core.toml) | config/core.toml 是 Neo-MoFox 的核心配置文件。首次启动时程序会自动生成带注释的默认配置文件,本文档帮助你理解各项含义。 |
| 如何更换 Neo-MoFox 的端口? | 在大多数情况下,你不需要修改 Neo-MoFox 的默认端口。但如果你遇到了端口冲突(例如,电脑上其他程序占用了 8095 端口),那么本指南将帮助你安全地更换端口。 |
| MCP 使用教程 | MCP(Model Context Protocol)允许 Neo-MoFox 通过外部工具服务器扩展 AI 能力,如网页抓取、搜索引擎查询、文件管理等。 |
| 模型配置问题排查指南 | LLM 请求失败:model=deepseek-v3, request=actor, errortype=LLMAuthenticationError, reason=Error code: 401 - 'Invalid API key' |
| 模型配置高级指南:从资源调度到智能策略 | 本文档介绍如何通过 model.toml 配置 Neo-MoFox 的 AI 模型。配置分为三个层次:资源层(API Providers)、能力层(Models)和应用层(Model Tasks)。 |
| 模型配置快速上手 | 本篇指南将用最直接的方式,告诉你如何让 Neo-MoFox 开口说话。 |
| Neo-MoFox 维护指南 | 欢迎来到机器人保养手册!🔧 这里会教你如何给机器人做「体检」、「升级大脑」以及「搬家」。别担心,比组装宜家家具简单多了。 |
| 指令权限系统使用指南 | 在开始使用权限系统之前,最重要、最优先的一步是在你的机器人配置文件中设置 Owner 用户。 |
| 插件安装指南 | 欢迎来到 Neo-MoFox 插件的世界!在这里,你可以找到各种有趣的插件来扩展 Neo-MoFox 的功能。 |
| Skill 使用教程 | Skill 是 Neo-MoFox 的扩展能力模块,通过 SKILL.md 文件声明工具的使用方法,由内置的 Skill 管理器(skillmanager) 插件自动发现并按需加载。 |
| Neo-MoFox WebUI 部署指南 | 欢迎!这份指南会手把手教你安装并启动 Neo-MoFox WebUI——让你从命令行地狱中解脱出来,用浏览器优雅地管理你的机器人。 |
| 适配器列表 | 适配器负责连接 Neo-MoFox 与外部平台,让机器人能够收发消息。 |
| OneBot 适配器配置指南 | OneBot 适配器(onebotadapter)是 Neo-MoFox 连接 QQ 平台的推荐方式,通过 OneBot 协议与 Napcat QQ 客户端通信。 |
| QQ Bot 适配器配置指南 | QQ Bot 适配器(qqbotadapter)用于对接腾讯 QQ 官方机器人(小龙虾 Bot)。它使用 QQ 官方 WebSocket OpCode 网关协议接收消息,通过 REST API 发送消息,认证方式为 AppID + AppSecret。 |
| **欢迎使用 Neo-MoFox!** | 更新日期:2026年3月21日 |
| 如何高效提问 | 遇到问题寻求帮助时,清晰的提问能让你更快地获得有效的答案。本指南将教你如何向他人高效地提问。 |
| 提问的智慧 (精简版) | 本文档不直接解决你的具体问题,但它会告诉你如何高效地获得答案。一言以蔽之:授人以鱼不如授人以渔。 |
| Neo-MoFox 开发指南 | 欢迎来到 Neo-MoFox 的开发文档。无论你是想贡献代码、开发插件,还是了解框架内部机制,这里都有你需要的资料。 |
| 文档 JSON API | MoFox-Bot-Docs 内置了一个文档 JSON API,允许外部程序(或本站组件)以 JSON 格式获取、搜索文档。无论你是在本地开发服务器(npm run docs:dev)还是静态托管(npm run docs:build 之后的产物,如 GitHub Pages),同一批 URL 完全可用,无需任何后端服务。 |
| 文档编辑指南 | MoFox-Bot-Docs 是 Neo-MoFox 的官方文档站点,基于 VitePresshttps://vitepress.dev/ 构建。本章节面向所有希望为文档贡献内容的写作者——无论你是修正一个错别字,还是新增一整章指南,都可以在这里找到完整的本地编辑流程。 |
| 编辑文档内容 | 本章介绍 MoFox-Bot-Docs 的仓库结构、Markdown 写作约定,以及 VitePress 提供的扩展语法。掌握这些之后,你就可以开始添加或修改任意一个文档页面了。 |
| 安装 Node.js 环境 | VitePress 是基于 Vite + Vue 的纯前端工具链,必须依赖 Node.js 运行。本章将带你完成 Node.js 与包管理器的安装和验证。 |
| 启动与预览 | 本章介绍如何在本地把 MoFox-Bot-Docs 跑起来,包括开发服务器、生产构建、产物预览,以及常见的排错思路。前两步假设你已经完成 Node.js 安装./nodejs-install。 |
| 侧边栏与顶栏配置 | VitePress 的导航完全由 .vitepress/config.ts 中的 themeConfig 配置驱动。本章讲解如何为新页面添加 顶栏(nav) 与 侧边栏(sidebar) 入口。 |
| 参与 Neo-MoFox 项目贡献 | 非常感谢您有兴趣为 Neo-MoFox 做出贡献!我们欢迎任何形式的贡献,无论是报告错误、提交功能请求,还是直接贡献代码和文档。 |
| Development Guidelines | 为了确保项目的代码质量、可维护性和协作效率,所有贡献者都应遵守以下开发准则。 |
| MPDT: 你的插件开发启动器 | 本文档对齐 mofox-plugin-dev-toolkit v0.6.5 版本 |
| mpdt config | 配置管理命令组,用于管理 MPDT 的全局配置。 |
| mpdt config edit | mpdt config edit key value options |
| mpdt config init | 交互式初始化 MPDT 配置文件。 |
| mpdt config open | 在编辑器中打开 MPDT 配置文件。 |
| mpdt config show | 显示当前的 MPDT 配置。 |
| mpdt depend | 依赖管理命令组,处理插件依赖和 Python 包依赖。 |
| mpdt depend add | 添加依赖到插件,支持 Python 包和插件依赖。 |
| mpdt depend info | 查看依赖的详细信息和可用版本。 |
| mpdt depend list | 列出插件的所有依赖。 |
| mpdt depend remove | mpdt depend remove dependency path options |
| mpdt depend search | 搜索可用的依赖(插件或 Python 包)。 |
| mpdt market | 插件市场命令组,提供插件发布、管理和搜索功能。 |
| mpdt market delete | 从市场删除插件(慎用)。 |
| mpdt market info | 查看插件的详细信息,包括所有版本、依赖、作者等。 |
| mpdt market package-update | 更新已发布的插件包,创建新版本的 Release。 |
| mpdt market publish | 一键发布插件到 Neo-MoFox 插件市场,自动处理构建、Git 提交、GitHub Release 创建等全流程。 |
| mpdt market search | 搜索插件市场中的插件。 |
| mpdt market yank | 废弃指定版本的插件,标记为不推荐使用。 |
| mpdt plugin | 插件开发命令组,提供插件项目的完整生命周期管理。 |
| mpdt plugin build | 将插件目录打包为 .mfp 文件(MoFox Plugin),用于分发和安装。 |
| mpdt plugin bump | 升级插件版本号,遵循语义化版本(Semantic Versioning)规范。 |
| mpdt plugin check | 对插件进行全面的静态检查,包括结构、元数据、组件、类型和代码风格等 8 层检查。 |
| mpdt plugin dev | 启动开发模式,提供热重载(Hot Reload)功能,文件修改后自动重新加载插件。 |
| mpdt plugin generate | 快速生成插件组件代码,避免手写样板代码。 |
| mpdt plugin init | 初始化新插件项目,创建标准的插件目录结构和配置文件。 |
| 安装 MPDT | mpdt 是一个标准的 Python 包,安装方式多种多样,总有一款适合你。 |
| AI Skill 安装指南 | 本指南适用于 GitHub Copilot Claude Code、Cursor、VS Code 等支持 Skill 文件的 AI 编辑器。 |
| 插件开发概览 | Neo-MoFox 插件系统为开发者提供了一套灵活、类型安全的组件模型,支持从目录、ZIP 压缩包或 .mfp 格式加载插件。 |
| API 文档 | Neo-MoFox 为插件开发者提供了一套完整的 API 接口,涵盖消息收发、LLM 调用、数据库操作、事件系统、日志记录等核心功能。 |
| Action API | src.app.pluginsystem.api.actionapi 提供 Action 组件的查询、Schema 获取、执行、缓存管理与上下文激活。 |
| Adapter API | src.app.pluginsystem.api.adapterapi 提供适配器的启动、停止、重启、查询、Bot 信息获取与命令调用能力。 |
| Agent API | src.app.pluginsystem.api.agentapi 提供 Agent 组件的查询、Schema 获取、执行与可用工具管理。 |
| Chat API | src.app.pluginsystem.api.chatapi 提供 Chatter 组件的查询、活跃实例管理和聊天流绑定。 |
| Command API | src.app.pluginsystem.api.commandapi 提供命令注册、匹配、执行和帮助信息。 |
| Config API | src.app.pluginsystem.api.configapi 提供插件配置的加载、重载和查询。 |
| Database API | src.app.pluginsystem.api.databaseapi 提供扁平化的数据库操作接口,封装了 CRUD、查询构建器、聚合查询、分页和批量迭代。 |
| Event API | src.app.pluginsystem.api.eventapi 提供事件的发布、处理器注册和临时监听器管理。 |
| LLM API | src.app.pluginsystem.api.llmapi 提供 LLM 请求创建、模型集获取、工具注册表管理、工具调用执行与 LLM 统计查询。 |
| Log API | src.app.pluginsystem.api.logapi 提供日志记录器的创建,并导出 COLOR 枚举与 Logger 类型(后者为 src.kernel.logger.Logger 的再导出,不在模块 all 中但可直接导入使用)。 |
| Media API | src.app.pluginsystem.api.mediaapi 提供媒体识别(图片、表情包、语音)和信息管理。 |
| Message API | src.app.pluginsystem.api.messageapi 提供消息查询、计数与可读格式化接口。 |
| Permission API | src.app.pluginsystem.api.permissionapi 提供用户身份标识生成与权限管理能力。 |
| Person API | src.app.pluginsystem.api.personapi 提供用户身份标识生成、用户记录管理、名称变更历史、关联聊天流/消息查询,以及印象与态度维护能力。 |
| Plugin API | src.app.pluginsystem.api.pluginapi 提供插件的加载、卸载、重载、查询和生命周期管理。 |
| Prompt API | src.app.pluginsystem.api.promptapi 提示词模板的注册、查询、系统提醒管理与流隔离 reminder 管理。 |
| Router API | src.app.pluginsystem.api.routerapi 提供 HTTP Router 组件的查询、挂载、卸载和信息获取。 |
| Send API | src.app.pluginsystem.api.sendapi 提供各类消息的发送、批量发送与广播接口。 |
| Service API | src.app.pluginsystem.api.serviceapi 提供 Service 组件的查询与实例获取。 |
| Storage API | src.app.pluginsystem.api.storageapi 提供两种独立存储能力:JSON 文件存储(基于 JSONStore)和 PluginDatabase(SQLite)。 |
| Stream API | src.app.pluginsystem.api.streamapi 提供聊天流的创建、查询、消息管理、上下文操作与批量清空能力。 |
| 组件总览 | Neo-MoFox 插件系统提供了 11 种组件类型,每种组件有明确的职责边界。本文帮助你快速了解各组件的适用场景,选择合适的组件类型。 |
| Action — 动作组件 | BaseAction 定义了"主动响应"组件的行为。Action 通过 LLM Tool Calling 被触发,执行后会产生副作用(如发送消息、调用外部 API)。 |
| Adapter — 适配器组件 | BaseAdapter 是平台接入层组件,继承 mofoxwire.AdapterBase,增加了: |
| Agent — 代理组件 | BaseAgent 定义了"任务代理"组件的行为。Agent 是 Chatter 的任务协助者,拥有专属的私有 usables 套件,可以编排多个工具完成复杂任务。 |
| Chatter — 聊天器组件 | BaseChatter 是对话流程组件,使用异步生成器通过 yield 返回状态。 |
| Command — 命令组件 | BaseCommand 提供命令式交互能力,支持: |
| Config 配置组件 | BaseConfig 是 MoFox 插件的配置管理基类,用于定义和管理插件的 TOML 配置文件。它基于 Pydantic 实现,提供类型验证、默认值管理和自动配置文件生成功能。 |
| EventHandler — 事件处理器组件 | BaseEventHandler 订阅系统事件并在事件触发时执行响应逻辑。支持优先级排序和事件拦截控制。 |
| Plugin — 插件根组件 | BasePlugin 是所有插件的根组件,作为其他组件的容器,同时提供插件元数据和生命周期钩子。 |
| Router — 路由组件 | BaseRouter 为插件提供基于 FastAPI 的 HTTP 路由能力。 |
| Service — 服务组件 | BaseService 暴露特定功能供其他插件调用,是插件间通信的标准机制。 |
| Tool — 工具组件 | BaseTool 定义了"查询"工具的行为。与 Action 不同,Tool 侧重于返回信息供 LLM 参考,而非执行有副作用的操作。 |
| 贡献插件到插件市场 | 把辛苦开发的插件发布到 Neo-MoFox 插件市场https://39.96.71.162/,让更多用户一键安装、依赖和搜索,是参与社区共建最直接的方式。本文以 mpdt 为核心,串起从「插件就绪」到「市场可装」的完整贡献流程。 |
| 插件机制原理 | 在开始开发 Neo-MoFox 插件之前,了解插件系统的运作机制有助于做出更合理的设计决策。 |
| 插件编写指南 | 这份指南是一份循序渐进的 Neo-MoFox 插件开发教程。它围绕同一个示例插件(echodemo)从最小可运行版本逐步演化到包含多组件、能调用 LLM、能查发消息、能持久化存储的完整实现。 |
| 1. 写在前面 | 如果你会一点 Python,也愿意花一点时间理解 Neo-MoFox 的运行方式,那么这份指南就是写给你的。 |
| 10. 系统能力导览:把 Prompt 真正送进 LLM API | 上一章我们已经把一件很关键的事理顺了: |
| 11. 系统能力导览:让 Tool 真正接进 LLM 调用链 | 上一章我们已经把一条很重要的链路打通了: |
| 12. 番外篇:拆开 default_chatter 的 enhanced 状态机,理解“标准上下文”怎么流动 | 前面几章我们一直在教你怎么写插件、怎么接 Prompt、怎么接 LLM、怎么把 Tool 放进调用链。 |
| 13. 用 Agent 编排工具组:把复杂任务关进一个更小、更省 token 的工作流里 | 前一章我们拆了 defaultchatter 的 enhanced 状态机,目的是让你理解“标准上下文”为什么要严格闭合。 |
| 14. 让插件真正动起来:什么时候该写 Action | 前面我们已经分别讲过: |
| 15. 让插件学会旁听与介入:事件系统怎么用 | 前面几章我们一直在围绕“模型如何调用组件”展开: |
| 15.5. 内置事件参考:所有系统事件、参数与可改字段 | 第 15 章已经强调过:事件系统是链式传递共享参数,你可以改 params 里的字段。但“能改”和“改了有用”不是一回事。 |
| 16. Chatter:插件里的总控组件,到底该负责什么 | 前面几章已经把插件系统里几种重要的“能力型组件”都走过一遍了: |
| 16.5. Stream:聊天流是什么 | 前面几章里,streamid 这个东西其实已经到处出现过了: |
| 17. Router:给插件开一个 HTTP 入口,但别把它当聊天入口 | 前面几章,我们一直在讲插件怎样参与“对话系统”本身: |
| 18. Adapter:插件怎样真正接上外部平台 | 前面几章,我们一直在插件系统的“核心里面”走: |
| 19. 消息模型:先把 MessageEnvelope、message_info、message_segment 看明白 | 上一章我们讲 Adapter 时,一直在反复提一个词: |
| 2. 先建立一个最小认知 | 在真正开始写插件之前,先做一件重要的事:把"插件"这个词从模糊的印象,变成一个可以落到代码里的具体对象。 |
| 20. 先回头看一眼:你其实已经走到插件系统门口了 | 这一段路其实已经走了很长。 |
| 21. 适配器命令:让插件真正调到平台的 API | 前面我们已经分别讲过两件事: |
| 22. 存储框架:让插件既能存简单 KV,又能开自己的 SQLite | 前面几章我们一直在讲“插件怎样和能力打交道”: |
| 23. 消息 API:怎样查历史消息,怎样把消息真正发出去 | 前面几章里,消息其实一直隐含在场: |
| 24. Stream API:插件作者怎样管聊天流 | 本章刻意不重复"聊天流是什么"的概念性介绍。关于 ChatStream / StreamContext 的结构、可读字段、以及 streamapi 和 messageapi / sendapi 的边界,概念部分统一在 16.5 Stream./16.5-stream 里讲。本章专注于"每个函数怎么用、踩哪些坑"。 |
| 25. Service API:跨插件复用服务能力的统一入口 | 本章不重复"为什么要写 Service"的概念讨论,也不展开 BaseService 基类的字段与生命周期。Service 的定位、与 Command / Tool 的边界,统一在 第 7 章./7-command-and-service 里讲。本章专注于 serviceapi 的几个函数怎么用、签名怎么拼、实例从哪里来、踩哪些坑。 |
| 3. 10 分钟做出第一个插件 | 前两章一直在铺垫。到了这里,终于可以做一件真正有成就感的事:亲手做出一个能被 Neo-MoFox 发现、加载,并且能响应命令的插件。 |
| 4. 看懂最小插件到底发生了什么 | 到了这里,我们先暂时停一下,不继续往插件里加新东西。 |
| 5. 番外:从单一文件到清晰结构 | 这一篇不算主线章节,更像一个轻量番外。 |
| 6. 给插件加配置 | 到了这里,插件终于要开始摆脱“写死行为”了。 |
| 7. 从单组件走向多组件 | 到了这里,echodemo 已经不再只是一个最小样例了。 |
| 8. 再进一步:引入 Tool | 到了这里,我们的 echodemo 已经不只是一个“能跑起来”的插件了。 |
| 9. 系统能力导览:先认识 Prompt API | 写到这里,echodemo 已经有了 Command、Service、Config 和 Tool。 |
| manifest.json 格式说明 | manifest.json 是插件元数据入口,用于插件发现、依赖校验和加载顺序计算。 |
| 插件结构与最佳实践 | 一个规范的 Neo-MoFox 插件项目结构有助于提高可维护性和可扩展性。 |
| Agent 插件开发工作流 | 这套工作流面向 Claude Code 等支持 Skill / 自定义命令的 Agent,编排从需求澄清、方案确认、开发与测试,到真实加载/卸载验证的插件交付流程。 |
| 内置插件 | Neo-MoFox 内置了一系列官方插件,提供核心功能和扩展能力。 |
| Booku 记忆(booku_memory) | Booku 记忆系统是 Neo-MoFox 内置的长期记忆插件,让机器人能记住用户的偏好、过往事件与知识,并在后续对话中按需调用。 |
| Booku 开发指南 · 总览 | 本文面向希望在 Booku 记忆系统基础上做二次开发的插件作者,详列对外暴露的服务、方法签名、返回结构与使用示例。 |
| 默认聊天器(default_chatter / DFC) | Neo-MoFox 的默认聊天组件,机器人收到消息后由它驱动整个对话回复流程。 |
| DFC 开发指南 · 总览 | 本文面向希望复用默认聊天器完整聊天链路的插件开发者,详述通用聊天服务 defaultchatter:service:chatcore 的工厂方法、会话异步生成器驱动方式、配置项、全部适配器协议方法与会话状态机。 |
| 表情插件(emoji_like / emoji_sender) | Neo-MoFox 内置两个表情相关插件,分别负责贴表情回应和表情包收藏发送。 |
| Neo-Default-Chatter(neo_default_chatter / NDFC) | NDFC 是 Neo-MoFox 的新一代聊天执行核心,定位为「可复用的会话逻辑中台」。它采用 EventBus 事件驱动架构,把会话流水线上的全部可替换 seam 都以事件形式暴露给第三方插件——订阅事件即可「换函数」,不再需要像 DFC 那样构造聚合 Protocol 适配器。 |
| NDFC 开发指南 · 总览 | 本文面向希望在 Neo-Default-Chatter(NDFC)基础上做二次开发的插件作者,详述对外暴露的 Service 接口、事件 Hook 体系、payload schema 与扩展模式。 |
| OneBot 适配器(onebot_adapter) | OneBot 11 适配器,让你的机器人接入 QQ 等 OneBot 11 协议平台,通过 WebSocket 与 Napcat 等实现端通信。 |
| OneBot 适配器开发指南 · 总览 | 本文面向希望监听 OneBot 通知事件或扩展适配器行为的插件开发者,详列适配器对外发布的事件、通知转换为 MessageEnvelope 后的字段结构、消息段格式与处理流程。 |
| 权限管理(perm_plugin) | 让机器人主人(OWNER)直接在聊天框里管理用户权限,无需修改配置文件或重启。 |
| Neo-MoFox WebUI / Plugin UI | Neo-MoFox WebUI 是机器人的浏览器管理界面,让你告别命令行,用网页管理机器人。Plugin UI 是其中的插件界面扩展子系统,允许任何插件在 WebUI 中注册自己的管理页面。 |
| HTML 开发 | XML 轨用声明式 XML 描述界面,HTML 轨则把整个页面交给插件自己控制:你写原生 HTML / CSS / JS,WebUI 用 Shadow DOM 沙箱加载,并提供一个 sys 桥接对象作为与系统交互的唯一通道。 |
| HTML 组件参考 | HTML 轨与 XML 轨共享同一套 sys- 组件源(components/plugin-ui/sys-components/)。差异仅在标签名与调用方式: |
| HTML sys API | sys 是 HTML 轨插件与系统交互的唯一桥接对象。每个 HTML 沙箱实例都对应一个独立的 sys,挂在 window.pluginsyspageId 上。沙箱在执行你的 scripts 之前会自动注入前缀: |
| 总览 | Plugin UI 开发指南带你从零开始,为你的插件编写自定义 WebUI 管理页面。 |
| XML 入门 | 本文是 XML 轨的入门指南:从注册页面、最小示例到完整语法、语法糖、API 模板与示范。XML 轨用一段声明式 XML 描述界面,由 WebUI 内置渲染引擎解析为 Vue 组件树,配合管道指令编排交互,无需写 JS 即可完成表单、列表、配置页等标准管理界面。 |
| XML 组件参考 | Plugin UI XML 轨提供一套内置的 Material Design 3 风格组件。本文列出所有可用组件的标签名、属性、事件和用法示例。 |
| Skill 管理器(skill_manager) | SkillManager 是 Neo-MoFox 的技能索引与按需加载插件。它会在插件加载完成后扫描本地 skill 目录,建立技能清单,并提供 3 个工具给 LLM 按需调用。 |
| 实用命令(utility_commands) | 实用命令集合插件,收纳一组常用的运维 / 管理类命令。 |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/minecraft1024a/mofox-docs-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server