lgl-mcp-server

Little Green Light（LGL）MCP 服务

面向 Little Green Light CRM 数据库的直接、安全且高保真的模型上下文协议（MCP）服务。此服务支持 AI 编码助手和聊天应用（如 Claude Desktop、LibreChat 或 Open WebUI）安全地与您的捐赠者数据库交互，以便在本地搜索联系人、记录捐赠、对分类群组进行分类并生成报告，无需任何第三方中间件（如 Zapier）。

---

功能

• 选民与核心管理： 搜索、检索、创建、更新和删除选民记录。create_constituent 会拒绝身份信息完全空白的请求（需要提供 organization_name，或至少提供 first_name/last_name 之一），而不会悄悄创建空记录。批量名称解析辅助工具（用于为 top_donors 等汇总报告添加标签）会区分“选民不存在”和其他查找失败（速率限制、网络、身份验证），而不会将两者都掩盖成相同的兜底结果。
• 高级服务端搜索： search_constituents_advanced 直接通过 LGL 自带的查询引擎筛选选民 — 自定义属性（包含/等于/开头为/为空/不为空）、关键词、位置、会员状态/等级、群组、列表和更新时间 — 所有条件均以 AND 连接，并通过易懂的显示名称而非 LGL 内部 ID 引用。只有在明确请求时（include_custom_attrs），结果才会包含属性值，从而让普通筛选查询保持轻量。constituents_never_touched_attribute 可查找从未设置过特定自定义属性的记录 — LGL 自带的为空/不为空运算符无法区分这种状态与“已设置但值为空”。constituents_missing_info 会遍历完整的选民列表（而非仅遍历第一页），以查找缺少电子邮件、电话号码或地址的记录，并将 count 与经过 limit 截取的结果分开返回；如果账户规模大到触及底层扫描的页数上限，则会标记 truncated。
• 筹款与捐赠： 记录新捐赠、列出交易（支持日期范围筛选）、搜索付款，以及查看筹款活动、基金、募捐倡议和活动事件。捐赠/捐赠者查找工具会显示每条记录的捐赠类型以及与认捐/分期付款的关联；捐赠总额报告会从现金总额中排除认捐，以避免重复计算 — 详见下文的捐赠类型与认捐关联。
• 联系信息子资源： 全面管理选民的街道地址、电话号码、电子邮件地址和网址。
• 活动与备注： 记录备注、撰写联系报告并跟踪志愿服务时长。
• 群组与会员资格： 将选民归入可自定义的群组和会员等级。
• 一站式捐赠者查询： get_donor_context 可在一次调用中返回个人资料、近期捐赠、群组成员资格和近期备注（可通过姓名或 ID 查找）。
• 完整个人资料导出： export_constituent_profile 模拟 LGL 自带的“导出个人资料”按钮 — 完整记录、完整捐赠历史、关系、班级/学校关联、会员资格、志愿服务时长、联系报告、募捐倡议请求、活动邀请、群组成员资格和备注，均通过一次调用并行获取。
• 文档链接： log_document_link 会记录一条指向托管在其他位置（OneDrive/SharePoint 等）的文件的备注 — LGL 的 API 没有文件上传端点，因此这只是一个引用，并非真正的附件。详见下文的 API 缺口与变通方案。
• 将群组用作已保存列表： create_group_with_members 可在一次调用中创建群组并将选民添加到其中 — 这是最接近 API 原生支持的替代方案，可用于代替 LGL 仅限 UI 操作的动态列表；动态列表没有创建/编辑端点。成员资格写入会分批处理（每批 20 条），而非一次性全部发出，因此大型选民列表不会向 API 发送数量不受限制的并发请求。详见下文的 API 缺口与变通方案。
• 三级权限： 严格只读、辅助模式（只读，加上备注和经人工审核的 webhook 写入）以及完整权限。详见下文的权限级别。
• 访问审计跟踪： 使用 get_constituent、get_donor_context 和 export_constituent_profile 时会自动记录访问情况 — 根据 LGL_ACCESS_LOG_DESTINATION 的设置，记录为选民 LGL 记录中的 [AI Access Log] 备注，或记录为本地 Excel 文件中的一行。详见下文的访问审计日志。
• 经人工审核的写入： 五个 submit_*_for_review 工具会向 LGL 自带的 Integration Queue webhook 提交内容，而非调用 API，因此每次写入生效前都需由人员在 LGL 中批准。完整模式和辅助模式均可使用。详见下文的经人工审核的写入（Integration Queue）。
• 零中间件架构： 数据直接在本地 AI 客户端与 LGL API 之间传输，从而降低安全风险和第三方费用。

---

安装与设置

1. 前提条件

• Node.js（建议使用 v18 或更高版本）
• Little Green Light API 密钥（在 LGL 账户的 Settings > Integration > API Keys 下生成）

2. 安装依赖项

将此代码库克隆到本地计算机，在该文件夹中打开终端并运行：

npm install

3. 配置环境变量

复制 .env.example 模板，创建本地 .env 配置文件：

cp .env.example .env

在文本编辑器中打开 .env，将占位符替换为实际的 LGL API 密钥和配置：

LGL_API_KEY=your_lgl_api_key_here
PORT=3000

# Optional: Secure your Streamable HTTP endpoint with Bearer Token Authentication
LGL_MCP_TOKEN=your_secure_bearer_token_here

# Optional: enables the submit_*_for_review tools — see "Human-Reviewed Writes" below
LGL_INTEGRATION_LISTENER_URL=https://your-account.littlegreenlight.com/integrations/your-integration-id/listener

# Optional: field-name casing for submit_*_for_review payloads — "snake"
# (default) or "title" — see "Human-Reviewed Writes" below
LGL_INTEGRATION_FIELD_CASE=snake

# Optional: choose where the automatic access-audit trail is logged —
# "lgl_note" (default) writes a note directly to LGL, "excel" appends a row
# to a local spreadsheet instead. See "Access Audit Logging" below.
LGL_ACCESS_LOG_DESTINATION=lgl_note

# Required only when LGL_ACCESS_LOG_DESTINATION=excel — absolute path to the
# .xlsx file to append access-log rows to.
LGL_ACCESS_LOG_PATH=C:\path\to\AI_Access_Log.xlsx

权限级别

两个环境变量组合后可提供三个权限级别：

级别	LGL_READ_ONLY	LGL_ASSISTED_MODE	允许的操作
严格只读	true	未设置/false	仅可读取。完全禁止任何形式的写入操作——不允许直接修改、不允许添加备注（包括当 LGL_ACCESS_LOG_DESTINATION=lgl_note 时自动添加的访问审计备注），也不允许提交 Integration Queue。Excel 访问审计目标（LGL_ACCESS_LOG_DESTINATION=excel）在此模式下仍会记录，因为它不会接触 LGL。
辅助模式	true	true	除只读模式允许的操作外，还允许低风险且易于审核的写入操作：自动添加访问审计备注、显式调用 create_note/update_note/log_document_link，以及 Integration Queue 的 submit_*_for_review 工具。对选民/捐赠/群组等对象的直接修改（包括 create_group_with_members）仍会被禁止。
完整权限	未设置/false	（忽略）	不受限制——允许使用所有工具，包括直接调用 create_*/update_*/delete_* 进行修改。

# Strictly read-only
LGL_READ_ONLY=true

# Assisted: read-only plus notes and human-reviewed webhook writes
LGL_READ_ONLY=true
LGL_ASSISTED_MODE=true

在只读模式和辅助模式下，禁止使用的工具会从 tools/list 中隐藏（而非仅在调用时拒绝），因此 AI 助手不会尝试使用它们。除非同时设置 LGL_READ_ONLY=true，否则 LGL_ASSISTED_MODE 不会生效——在完整权限模式下，它解锁的所有功能本就可用。将服务连接到实时捐赠者数据库时，建议使用此设置：纯探索会话采用严格只读模式；如果还需要访问审计记录和人工审核写入功能，则采用辅助模式。

所有工具还会发布 MCP annotations（readOnlyHint、destructiveHint、idempotentHint），以便客户端在调用具有破坏性的工具前发出警告，而无需依赖服务端保护。

---

访问审计日志

每当调用 get_constituent、get_donor_context 或 export_constituent_profile 时，服务都会记录访问情况，以便审计。日志写入位置由 LGL_ACCESS_LOG_DESTINATION 控制：

• **lgl_note（默认）：**直接在该捐赠者的 LGL 记录中写入备注，例如：[AI Access Log] Record accessed via LGL MCP Server (get_constituent) on 2026-07-13 17:24 UTC. 它遵循当前启用的权限级别，在严格只读模式下会静默跳过，因为严格只读的核心目的就是不在 LGL 中留下任何痕迹。
• **excel：**改为在 LGL_ACCESS_LOG_PATH 指定的 .xlsx 文件中追加一行（时间戳、工具、捐赠者 ID、捐赠者姓名）。此选项在所有模式下都会生效，包括严格只读模式，因为它完全不会写入 LGL。

在 LGL 的界面中停用某种备注类型（Settings → Menu Items → Note Types），不会让该类型已有的备注从捐赠者的活动视图中消失；API 仍可使用已停用类型的 ID 写入新备注。因此，停用用于 lgl_note 日志记录的备注类型并不能减少杂乱，只会让该类型从员工手动选择的“新建备注”下拉菜单中移除。如果你担心捐赠者记录中的备注过多，请改用 excel。

需要了解以下几点：

• **范围仅限单条记录的详情视图。**批量 list_*/search_* 调用不会记录日志——记录 50 条结果列表中的每一行会让日志泛滥，却几乎没有审计价值。只有打开某位特定捐赠者档案的工具才会记录日志。
• **无论目标位置为何，均尽力而为：**如果因任何原因无法写入日志条目，触发日志的读取操作仍会成功；失败信息会记入 stderr，不会作为工具错误返回。对于 excel，如果文件被锁定（例如在 Excel 中打开），系统会重试几次后再放弃。
• lgl_note 通过 API 直接写入，而不是通过 Integration Queue——如果审计记录需要人工批准才能出现，就失去了审计的意义。它还需要一个现有的 note_type_id（数字），而不是类型名称——传入名称时，LGL 会静默忽略，而不会应用该类型。服务会在运行时解析该 ID（优先选择名称恰为 "General" 的类型，否则使用第一个现有类型），而不是将 ID 硬编码，因为类型 ID 因账号而异。此修复也适用于 create_note/update_note：这些工具此前接受的 note_type 字符串实际上从未生效；现在，无效的类型名称会引发明确错误，而不是静默创建无类型备注。
• 如果 excel 文件不存在，系统会创建该文件，并添加加粗且冻结的标题行（Timestamp、Tool、Constituent ID、Constituent Name）；文件会无限增长，不会自动轮换或归档。
• **excel 不适合高并发场景：**每次写入都会读取并重写整个文件，且没有加锁，因此两个真正同时发生的访问可能产生竞态，其中一行可能被另一行静默覆盖。这是尽力而为的审计日志所接受的权衡——对于典型的单客户端用法，预计不会造成影响；但如果你从多个并发 MCP 会话写入同一个文件，就需要留意这一点。

---

人工审核写入（集成队列）

除了直接调用 LGL API，LGL 还提供自定义集成 Webhook功能（LGL Settings → Integrations → Custom Integrations），可接收扁平的键值提交，并将其放入集成队列，由人工批准后才会实际写入捐赠人的记录。此 MCP 服务通过五个工具提供这条路径，与 create_*/update_* API 工具相互独立：

工具	涵盖内容
submit_constituent_for_review	身份/姓名字段、最多 3 个电话号码、最多 3 个电子邮箱、最多 2 个邮寄地址、一个网站、捐赠人类别字段和一段关系
submit_gift_for_review	礼物、认捐和目标字段，以及致敬（荣誉/纪念）详情。gift_type 限定为 LGL 实际支持的礼物类型（参见礼物类型与认捐关联）
submit_note_for_review	备注
submit_event_registration_for_review	活动注册/邀请
submit_appeal_request_for_review	募捐请求

这五个工具都不会直接写入 LGL——每次提交都会进入 LGL 的Settings → Integration Queue → Unsaved，由人员审核并选择保存或拒绝。因此，它们只需要辅助模式，无需完整写入权限：设置 LGL_READ_ONLY=true 和 LGL_ASSISTED_MODE=true 即可使用，因为没有人员先在 LGL 中点击 Save，它们就无法更改数据。严格只读模式（未设置 LGL_ASSISTED_MODE）仍会阻止这些工具，因为它们确实会向共享队列写入内容。

设置：

1. 在 LGL 中，前往 Settings → Integrations，创建（或复用）一个 Custom Integration。复制其侦听器 URL。
2. 在环境中将 LGL_INTEGRATION_LISTENER_URL 设置为该 URL。
3. 在该集成的字段映射界面中，将提交所用的字段名称映射到对应的 LGL 字段。映射完全在 LGL 界面中设置，而不在此 MCP 服务中——LGL 会静默忽略未映射的字段，而不会报错，因此未映射的提交看起来可能成功（HTTP 200），实际却没有任何可用数据。重复字段（电话/电子邮箱/地址）使用 LGL 的“Record Type / #”分组：第 1 个槽位使用不带后缀的字段名，第 2–3 个槽位使用数字后缀（phone_2、email_3）。
4. 此 MCP 服务发送的字段名有两种大小写形式，由 LGL_INTEGRATION_FIELD_CASE 控制："snake"（默认值，例如 first_name、phone、gift_amount）或 "title"（例如 First name、Phone number、Gift amount，通过 index.js 中的查找表转换）。请根据你自己的映射界面实际使用的形式进行设置——有些账户直接按原始参数名映射，另一些账户则会（重新）配置映射，以适配 LGL 自带的标题式大小写字段标签。由于没有哪个 LGL 账户的映射开箱即用且完全相同，使用任何工具前都应先对照自己的映射界面确认。

**匹配现有捐赠人：**这五个工具都接受可选的 record_id 字段，用于传入 LGL 捐赠人 ID。这是首选的匹配键，但只有当集成的记录匹配偏好设置（位于该集成的设置中，与字段映射并列）设为基于 ID 匹配时才有效——如果使用默认的基于电子邮箱/姓名的偏好设置，即使映射了“LGL constituent ID”字段，也不会保留匹配结果。如果省略 record_id，或集成仍采用基于电子邮箱/姓名的匹配方式，LGL 就会回退到按 first_name + last_name + email 进行匹配。

---

枚举值约束

多个 submit_*_for_review 字段表示由 LGL 自身定义的固定封闭值集，因此其工具架构使用真正的 JSON Schema enum，而不是带有文字描述的自由文本字段——AI 客户端只能使用有效值，而不能猜测：constituent_type、deceased、gives_anonymously（submit_constituent_for_review）；payment_interval、gift_is_anonymous、auto_generate_installments 和 gift_type（submit_gift_for_review，请参阅下文的礼物类型与认捐关联）；attended、rsvp_status、is_guest（submit_event_registration_for_review）；appeal_status（submit_appeal_request_for_review）。

相比之下，address_type、phone_type、email_type、web_address_type、contact_type 和 relationship_type 在 LGL 中是真正可由账户自定义的值列表，并非固定的平台枚举——已通过当前账户验证；该账户的实际值（例如，联系类型包括 Call/Meeting/Mailing/Proposal/Tour）与通用示例不符。这些字段仍使用自由文本，但其描述会指向 list_type_values（以及匹配的 type 键：street_address_types、phone_number_types、email_address_types、web_address_types、contact_report_types）或 list_relationship_types，以便在提交前查询账户中的真实值。

---

分页与截断信号

现在，几个用于列出或搜索无界记录集的工具会在结果可能不完整时发出信号，而不会再静默地返回部分页面，让人误以为那就是全部结果：

• 账户范围内的列表——list_campaigns、list_funds、list_events、list_appeals、list_groups、list_categories——会遍历完整数据集（最多 5,000 条记录），而不是只调用一次写死的 limit=200。除非达到上限，否则响应仍是之前的普通数组；达到上限时，响应会变为 { count, <items>, truncated: true }，以免将不完整的结果误认为完整结果。同一底层修复也适用于内部按名称查找（按名称解析组、自定义属性、列表、成员级别或关键词）：这些查找以前会因目标值位于旧的 200 条记录上限之外，而错误地报告“并不存在”。
• search_contact_reports、search_volunteer_times，以及未限定范围（不带 constituent_id）的 list_notes/list_contact_reports/list_volunteer_times 模式——现在接受 limit 参数，并在返回的页面恰好填满时发出提示（这是一种启发式判断，并非保证，因为实际数量可能恰好等于限制值）：响应会变为 { count, results, note }，提示你提高 limit 或缩小查询范围。

另外：search_contact_reports 和 search_volunteer_times 之前无论查询内容是什么，每次调用都会返回 400——这是测试时发现的一个既有错误，与上述问题无关。其根本原因与下文已介绍的 /constituents/search 特例相同：LGL 会拒绝裸 q=value，而要求使用 q[]=field=value。现已改用这种格式（字段为 text/description，与 create_contact_report/create_volunteer_time 已写入的字段一致）——已通过实时测试确认联系报告可用；志愿者服务时间搜索现在也不再报错，不过该账户没有志愿者服务时间记录，因此无法完全确认字段名称。

---

捐赠类型与承诺关联

在 LGL 中，承诺、配捐和分期付款并非独立的对象类型，而都是 Gift 记录，由一对 gift_type_name/gift_category_name 区分；付款则通过 parent_gift_id 关联到对应的款项。如果直接查看原始 API 输出，很容易误读（除非知道某笔分期付款的 parent_gift_id 指向一笔承诺，否则它看起来就像一笔无关的小额捐赠）。此服务会明确呈现这些区别：

• list_gifts、get_gift、get_donor_context 和 export_constituent_profile 都包含 type 字段（取自 gift_type_name），并在 LGL 提供时包含 gift_category_name 和 parent_gift_id。get_gift 还会将 type 提到响应顶层，而不是埋在数十个字段中。
• LGL 的嵌套 /constituents/{id}/gifts 列表端点对某些记录会省略这些字段；遇到这种情况时，这些工具会通过逐条记录的后续调用补充字段（每个请求最多处理 50 条记录）。
• submit_gift_for_review 的 gift_type 字段仅允许使用 LGL 的实际捐赠类型：Gift、In Kind、Pledge、Other Income、In Honor of、In Memory of、Soft Credit、Matching、Installment（来自 list_gift_types）。分期付款应引用承诺的捐赠 ID，以便 LGL 正确关联两者。
• record_gift/update_gift（直接写入 API 工具，与上述 Integration Queue 路径不同）也接受 gift_type（相同的枚举值）和 parent_gift_id。此前这些工具完全没有 gift_type 字段，因此通过它们写入的所有捐赠都会悄然变成普通的 Gift——无法记录 Pledge 或将 Installment 付款关联回对应承诺，这会从写入端重新引发上述重复计数问题。
• 承诺重复计数：Pledge 记录包含完整的认捐金额，而其分期付款还会另行记录各自的金额；两者相加会导致同一笔款项被计算两次。因此，recent_donors、top_donors 和 lapsed_donors 会从捐赠总额中排除 Pledge 和 Soft Credit 记录（已通过线上数据验证：一笔 $500,000 的承诺加上五笔 $100,000 的分期付款，否则会使捐赠者报告的总额虚增至接近 $1,000,000 或更高）。list_gifts/get_gift/get_donor_context/export_constituent_profile 仍会返回 Pledge 记录本身；此排除规则仅适用于这三个汇总报告工具。

API 缺口与变通方案

LGL 自带的 Web 界面支持的一些功能，在 LGL 的 API 中完全没有对应实现——无论是 REST API，还是 Integration Queue Webhook（它只接受联系人／捐赠／备注／活动注册／申请字段）。截至本文撰写时，已确认以下功能缺失：

界面功能	API 端点？	Webhook 字段映射？	此服务的处理方式
分配给团队成员的任务／待办事项／提醒	否	否	无。无法通过编程方式使用 LGL 的 Tasks 功能（包括其提醒邮件）——唯一的解决途径是向 LGL Support 正式提交功能请求。
联系人记录中的文件／文档附件	否	否	log_document_link 会记录一条备注，其中包含托管在其他位置（OneDrive、SharePoint、Google Drive 等）的文件链接及说明。这只是一个引用，并非真正的附件——LGL 完全无法通过 API 接收上传的文件；即使是它自带的 Web 表单，也只接受托管文件的 URL，从不接受原始文件字节。
已保存的名单（可动态重新运行的查询）	否（至多只读）	否	create_group_with_members 会创建一个 LGL 群组（一组静态联系人），并通过一次调用将成员添加到其中。群组可通过 API 完全写入，且用途相似——“一组以后还要再次联系的人”——但成员关系是静态的，并非实时查询。之后可使用 add_constituent_to_group / remove_constituent_from_group 添加／移除成员。
承诺捐赠的分期到期／预定日期	否	否	已对照实时记录确认：未支付的分期捐赠在 API 响应中没有 gift_date、due_date 或任何排期字段——只有 received_date，而且在实际收到付款前一直为 null。GET 返回的承诺捐赠记录本身也不包含 payment_interval / pledge_start_date，因此客户端也无法计算预期到期日期。list_gifts / get_gift 对这些记录显示 date: null，这是因为 LGL 的 API 实际上只返回这些信息——排期似乎仅在界面中可用，并未通过 API 暴露。

---

传输方式选择

此服务支持两种通信传输标准：

• **Stdio 传输（默认）：**标准输入／输出进程通道。适用于 Claude Desktop 等本地程序或本地命令配置。
• **Streamable HTTP 传输（SSE）：**运行原生 HTTP 服务，通过 HTTP 提供现代的有状态服务器发送事件（SSE）。GitHub Copilot、Cursor 的 SSE 模式、云容器，以及无法原生执行本地 Node.js 进程的系统都需要此传输方式。

以 Streamable HTTP 模式运行

要以 Streamable HTTP 模式启动服务，请使用 --http（或 --sse）标志：

node index.js --http --port 3000

• **端口选择：**可使用 --port <number> 或 PORT 环境变量指定自定义端口（默认为 3000）。
• **安全令牌保护：**如果在 .env 文件中设置了 LGL_MCP_TOKEN，则会严格强制执行 Bearer 令牌身份验证。所有客户端请求都必须包含 Authorization: Bearer <your_token> 标头，否则将被拒绝并返回 401 Unauthorized。如果未设置该令牌，服务仍会启动，但完全不会进行身份验证——启动时会记录一条非常醒目的警告，但任何能够访问该端口的人都可以发送请求。只有在服务绑定到 localhost 或以其他方式无法从本机外部访问时，才可在不设置令牌的情况下运行。

---

与 AI 客户端集成

此服务可以集成到任何支持 Model Context Protocol（MCP）的 AI 客户端、编辑器或聊天界面中。

1. Claude Desktop

要在官方 Claude Desktop 应用程序中使用此服务，请将配置添加到 claude_desktop_config.json 文件中。

文件位置：

• Windows：%APPDATA%\Claude\claude_desktop_config.json
• macOS：~/Library/Application Support/Claude/claude_desktop_config.json

配置：

{
  "mcpServers": {
    "lgl-crm": {
      "command": "node",
      "args": ["C:\\path\\to\\your\\workspace\\folder\\index.js"],
      "env": {
        "LGL_API_KEY": "your_lgl_api_key_here"
      }
    }
  }
}

2. Cursor IDE（AI 代码编辑器）

Cursor 支持直接在图形用户界面中配置自定义 MCP 服务。你可以使用 Stdio（命令）或 Streamable HTTP（SSE）进行连接：

选项 A：本地 Stdio（命令）

1. 打开 Cursor，然后前往 Settings > Features > MCP。
2. 点击 + Add New MCP Server。
3. 在弹出窗口中配置以下字段：
   • Name： lgl-crm
   • Type： command
   • Command： node C:\path\to\your\workspace\folder\index.js
4. 点击 Save。注意：请确保在操作系统环境变量或 Shell 配置中设置了 LGL_API_KEY，以便 Cursor 能够继承该变量。

选项 B：Streamable HTTP（SSE 模式）

1. 以 HTTP 模式启动 LGL MCP 服务：node index.js --http --port 3000
2. 前往 Settings > Features > MCP。
3. 点击 + Add New MCP Server。
4. 在弹出窗口中配置以下字段：
   • Name： lgl-crm-sse
   • Type： sse
   • URL： http://localhost:3000/mcp
5. 点击 Save。注意：如果启用了 LGL_MCP_TOKEN，请确保编辑器包含 Bearer 授权标头或连接配置。

3. Windsurf IDE（AI 代码编辑器）

Windsurf 支持通过全局配置文件使用原生 MCP 配置。

文件位置：

• Windows： %USERPROFILE%\.codeium\windsurf\mcp_config.json
• macOS/Linux： ~/.codeium/windsurf/mcp_config.json

配置：

{
  "mcpServers": {
    "lgl-crm": {
      "command": "node",
      "args": ["C:\\path\\to\\your\\workspace\\folder\\index.js"],
      "env": {
        "LGL_API_KEY": "your_lgl_api_key_here"
      }
    }
  }
}

4. LibreChat（开源聊天界面）

LibreChat 允许你通过集中式配置文件 librechat.yaml 直接集成 MCP 服务。

在 librechat.yaml 中配置：

mcpServers:
  lgl-crm:
    type: "stdio"
    command: "node"
    args: ["C:\\path\\to\\your\\workspace\\folder\\index.js"]
    env:
      LGL_API_KEY: "your_lgl_api_key_here"

5. Open WebUI（本地/可自托管的 AI 界面）

要将其添加到 Open WebUI（通常与本地 Ollama 实例搭配使用）：

1. 前往 Admin Settings > Connections > MCP。
2. 点击 Add Connection。
3. 将连接命名为 lgl-crm。
4. 输入命令配置：
   • Command： node C:\path\to\your\workspace\folder\index.js
5. 点击 Submit。（请确保在运行 Open WebUI 实例的主机上或 Docker 运行语句中加载了环境变量 LGL_API_KEY。）

---

安全与数据隐私

与其他会通过第三方服务（例如 Zapier 或 Make）传输敏感捐赠者信息的 MCP 集成不同，此服务采用直接本地管道：

• 零第三方存储： 所有成员数据、实际地址、电子邮件、电话号码和财务捐赠信息，都会通过安全加密的 HTTPS 直接从你的计算机发送到官方 LGL API。
• 最小权限原则： 部署前，你可以通过注释掉或移除 index.js 文件中相应的工具，轻松限制对数据库修改操作（例如删除记录）的访问。

---

许可证

本项目采用 MIT 许可证开源，并可供非营利组织免费改编使用。