企业官网建设流程全解析

plugins 仓库 Brex 插件解析：通过远程 MCP 服务器让 Cursor Agent 安全查询企业支出

【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins

本篇技术指南围绕本仓库third_party/brex插件及其 1.0.0 版本变更记录展开，讲解 Brex 官方远程 Model Context Protocol（MCP）服务器如何被封装为 Cursor 插件：从安装方式、mcp.json配置、OAuth 动态客户端注册认证，到连接前的管理员前置步骤、Agent 可用的六大能力域与写操作权限边界。读完本文，你将掌握如何在 Cursor 中接入 Brex 的企业支出数据，并以list_expense_categories等只读调用完成连接后的冒烟验证。

插件定位：一个指向官方远程 MCP 服务器的薄封装

third_party/brex是 Cursor 官方插件市场中的一个第三方集成插件。根据其 CHANGELOG.md 中 1.0.0 版本的发布记录，该插件核心只做三件事：

1. 添加了指向https://api.brex.com/mcp的brexMCP 服务器；
2. 认证使用 OAuth，无需配置 API Key 或 Client ID；
3. 使用来自brexhqGitHub 组织的 Brex 官方 logo 作为插件标识。

插件本身不包含任何本地业务逻辑或数据，它本质上是一个"连接器"：Cursor 中的 Agent 通过该 MCP 服务器查询公司支出数据（费用、收据、账单、供应商、卡片、余额、差旅），并在用户自身 Brex 权限范围内对费用做注解（annotate）。这一"薄封装"模式在仓库中广泛复用——.cursor-plugin/marketplace.json 中同样以third_party/前缀收录了 Navan、Xero、Mercury 等数十个同类远程 MCP 集成。

安装方式：两种途径

按照 README.md 的说明，安装 Brex 插件有两种方式：

方式一：插件市场图形界面

1. 打开Cursor Settings → Plugins；
2. 搜索Brex；
3. 点击Install，随后完成 Brex 登录授权提示。

方式二：聊天命令

在 Cursor 聊天框中直接运行：

/add-plugin brex

安装完成后，插件首次连接时会触发 Brex 的登录授权流程（详见下文"OAuth 认证"一节）。

MCP 配置：HTTP 类型的远程服务器

插件的 MCP 配置保存在 mcp.json 中，与 README 展示的配置完全一致：

{ "mcpServers": { "brex": { "type": "http", "url": "https://api.brex.com/mcp" } } }

各字段含义：

type: "http"是关键点：这意味着工具名称、参数 schema 与执行逻辑全部由 Brex 托管运行时决定，Cursor 侧只负责连接与鉴权。因此在 README 中明确提示——托管运行时才是工具名称和 schema 的事实来源（the hosted runtime is the source of truth），本地仓库中不存在任何工具定义文件。

OAuth 认证：动态客户端注册，零密钥配置

CHANGELOG 中强调"Auth uses OAuth — no API key or client ID to configure"，README 进一步补充了机制细节：

• 采用OAuth + Dynamic Client Registration（动态客户端注册）；
• 当插件连接时，Cursor 会自动将自己注册为 OAuth 客户端，并弹出 Brex 登录授权提示；
• 用户无需手动申请、填写任何 API Key、Client ID 或 Client Secret。

这一设计对最终用户是透明的：配置文件中看不到任何凭据字段，身份信息在连接握手阶段动态协商完成。对 Agent 而言，所有工具调用都以完成授权的 Brex 用户身份执行，并受该用户现有 Brex 权限约束（详见下文"权限边界"）。

连接前置条件：管理员一次性开启两个开关

虽然插件本身零配置，但 README 明确指出，整个公司账户有两个一次性的管理员前置步骤，未完成则任何员工都无法连接：

1. 接受开发者 API 协议：由账户管理员或卡片管理员在Settings → Developer下接受 Brex 的 Developer API agreement；
2. 启用 AI 助手集成：在Settings → Beta features下打开Brex in AI assistants。

完成上述两步后，任意员工即可用自己的 Brex 凭据连接插件，无需逐个账号重复配置。这是排障时最值得优先检查的一环——若连接失败，先确认管理员是否已完成这两步。

Agent 能力范围：六大领域

README 以表格形式给出了 Agent 连接后可访问的能力域，覆盖企业支出的主要数据面：

上述能力与 .cursor-plugin/marketplace.json 中brex条目的简介"Query expenses, receipts, bills, cards, and travel"互相印证，说明该插件面向的典型场景是：让 Agent 在对话中直接回答"本月各部门支出多少""某笔费用的收据与商户信息""未结账单和应付款"等财务类问题。

连接后的冒烟测试

由于工具 schema 由远端运行时决定，README 建议在连接成功后，调用list_expense_categories作为只读冒烟测试：它不触碰任何业务数据，仅列举费用与商户分类，足以验证连接、鉴权与工具发现链路是否全部打通。如果该调用能正常返回分类列表，即代表插件已可用。

权限边界：能读能注，不能动钱

这是使用该插件时必须理解的安全约束，README 的 Notes 部分给出了明确边界：

• 身份与作用域：所有工具调用以完成 OAuth 授权的 Brex 用户身份执行，作用域为该用户既有的 Brex 权限——插件不会放大任何权限；
• 写操作很窄：可写的仅限费用元数据，如备注（memos）、收据（receipts）和参与者（attendees）；
• 服务器不能移动资金：不能转账、不能发卡、不能支付账单；
• 尚未暴露的能力：审批（approvals）与卡片管理（card management）目前未通过 MCP 暴露；
• Beta 状态：Brex 官方将该 MCP 服务器标记为 beta，因此工具目录可能随版本变化——这也是上文"以托管运行时为准"的原因。

综合来看，该插件的设计遵循"最小写权限"原则：Agent 可以广泛查询、做轻量注解，但在资金操作上被严格隔离，降低误操作风险。

仓库视角：插件在官方市场中的登记与校验

从仓库结构看，third_party/brex插件遵循了本仓库统一的第三方插件组织规范：

• mcp.json 提供 MCP 服务器声明；
• README.md 承载安装、配置、能力与限制说明；
• CHANGELOG.md 记录版本变更（当前为 1.0.0 initial release）；
• LICENSE 采用 MIT 许可；
• assets/logo.png 为 Brex 官方标识（来自brexhqGitHub 组织）。

在市场侧，.cursor-plugin/marketplace.json 以source: "third_party/brex"登记该插件；仓库还提供 schemas/plugin.schema.json 与 schemas/marketplace.schema.json 两套 JSON Schema，分别约束插件清单与市场清单的结构，并由 scripts/validate-plugins.mjs 在发布前统一校验市场条目与各插件目录的存在性、结构合法性。也就是说，third_party/brex能进入市场列表，需要同时通过 Schema 校验、目录完整性检查等关卡，这从侧面保证了插件声明的规范性。

版本历史

当前 CHANGELOG.md 记录的唯一版本：

• 1.0.0 — initial release：新增指向https://api.brex.com/mcp的brexMCP 服务器；认证采用 OAuth（无需 API Key 或 Client ID）；使用 Brex 官方 logo（源自brexhqGitHub 组织）。

若后续版本发布，变更将按时间倒序追加在本文件中，可作为升级与行为变化的对照依据。

【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins