MCP Xardin

mcp xardin

用于花园管理的MCP服务器。连接到任何兼容MCP的AI客户端 并让它对你的花园有持久的记忆（种了什么、在哪里、有什么 它发生了）。然后，你可以利用法学硕士的一般知识来提供园艺建议， 使用您自己的花园数据作为背景。我经常问各种法学硕士 园艺建议，我觉得最好不要反复征求意见 键入大量关于我目前情况的背景信息。

服务器管理着一个包含植物、位置和活动历史的SQLite数据库。 AI客户端处理所有自然语言理解；服务器处理 结构化存储和检索。

它确实可以从标准的LLM提示输入中工作，但目前是 文件导入采用Emacs的组织模式格式。Markdown支持应该很快就会到来。

我构建了这个来适应我自己的个人工作流程：在园艺时，我创建了一个快速笔记 使用 Orgzly 我手机上的小部件。然后同步笔记 通过以下方式连接到台式机/笔记本电脑 同步工具稍后，我可以 使用LLM sync_notes 工具，解析Org文件并传递条目 返回以供AI进行解释和记录。

只需稍加更改，此代码就可以很容易地适应许多其他 在您只想为LLM保留结构化持久内存的情况下使用。

工具

AI可用于与SQLite数据库交互的工具：

资源

资源无需显式查询即可提供AI环境上下文：

• garden://context --生长区和地区
• garden://plants --所有注册的植物类型；那些种植活跃的植物会显示位置细节，而其他植物则显示为目录条目（例如手头的种子）
• garden://locations --具有属性的位置以及每个位置中种植了什么
• garden://recent-activity --最近30项活动和观察
• garden://schema --数据库模式（用于SQL生成）

设置

pip install -e ".[dev]"

在客户端中配置MCP服务器。克劳德代码：

claude mcp add xardin -- python -m xardin

默认情况下，数据库在以下时间自动创建 data/garden.db 第一次跑步。

配置

这些值在启动时从环境变量中读取。将它们设置在您的 shell配置文件或在注册MCP服务器时内联传递它们。所有位置 变量是可选的，但建议使用——它们通过 garden://context 资源，这样人工智能就可以提供适合位置的建议，而无需重复 你自己。这些是提供给LLM的，因此实际上没有任何强制性格式。

对于Claude Code，可以在 .mcp.json 在项目中 根：

{
  "mcpServers": {
    "xardin": {
      "command": "python",
      "args": ["-m", "xardin"],
      "env": {
        "GARDEN_GROWING_ZONE": "6b",
        "GARDEN_REGION": "Midwest",
        "GARDEN_LAST_FROST": "April 15",
        "GARDEN_FIRST_FROST": "October 15"
      }
    }
  }
}

植物和种植

植物和种植是两个独立的概念。植物类型注册一次 add_plant --它包含物种、品种和一般注释。每组 在某个地方生长的植物是一种单独的种植，用 add_planting，其中 有自己的位置、可选数量、日期和活动状态。

这意味着你可以把辣椒放在种子托盘里，然后把一些移植到饲养的 床和一些锅，并独立跟踪每组。如果一组人死于 霜冻，而其他人都很好，你叫 update_planting 随着 active=false 为了 只是这个群体。

当种植完成（收获、死亡、拔出）时，用标记将其标记为不活动 update_planting。当物理位置被移除或不再使用时，请对其进行标记 不活跃与 update_location在这两种情况下，历史数据都得到了保留。

位置

地点支持属性，提供更丰富的园艺建议：

update_location("Bed A", sun_exposure="full sun", size="4x8 ft",
                notes="South-facing, against fence",
                adjacent_to=["Bed B"])

邻接链接是对称的——标记A与B相邻，标记B与A相邻。 它们是添加剂；呼叫 update_location 再次添加更多邻居。

当床或锅被移除时，它会被标记为非活动状态，而不是被删除。这是为了 保存历史数据。如果以后创建同名的新位置 （例如移动后），它会得到一个没有继承属性或邻接链接的新记录。

组织模式工作流

组织文件中的所有条目都必须是顶级标题(* ).子标题被视为其父级的正文，其自身的时间戳将被忽略。这实际上很有用：你可以将一个带有副标题的笔记结构化为一个列表，LLM将把整个内容作为一个条目接收。例如，标题为“买来的种子” ** Tomatoes 和 ** Peppers 副标题将作为一个条目到达，法学硕士可以致电 add_plant 对于每一个。如果你想清楚地分开条目，请使用带有不同时间戳的单独顶级标题。

在导入过程中跳过没有时间戳的顶级条目。如果你需要记录一些没有有意义的日期的东西（例如位置信息），只需插入一个随机日期。

重新导入同一文件不会造成任何问题，因为内置了重复数据删除功能 按时间戳+内容检查。具有相同时间戳的两个条目被视为 相同的条目。编辑的条目（相同的时间戳、更改的文本）被标记为已更新 重新进口。

注意：由于标准组织时间戳不包括秒，因此在以下时间内创建了两个条目 同一分钟就会发生碰撞。

条目应为顶级标题，并带有 :CREATED: 财产：

* Planted 4 Super Sweet 100 tomatoes in the raised bed 
:PROPERTIES:
:CREATED:  [2026-04-25 Sat 13:05]
:END:

时间戳中的时间是可选的。 内联时间戳也可以使用，可以使用尖括号或方括号。

最初提到的工厂或地点应该更详细，以便可以添加细节 各自的表格。后面的条目可以说“给西红柿施肥”，如果只有一个选择的话 对于西红柿，该事件将被记录为正确的植物。

关于现有植物（主动种植）的条目可能是关于一个事件（例如，施肥、修剪、收获、， 移动、治疗等）或简单的观察，并将其记录在数据库中， 基本上就像园艺日记/日志条目。

* Basil underwatered, wilted in the sun
:PROPERTIES:
:CREATED:  [2026-06-28 Sun 17:45]
:END:

组织备注可以是多个标题；您可以在注释文本中提供其他数据。假设我们 在室内开始播种时，我们已经将金盏花放入数据库中，我们可以导入注释：

* Transplanted calendula outdoors
:PROPERTIES:
:CREATED:  [2026-04-21 Tue 15:32]
:END:
Put them in pots 3, 4, 5, and 6. 6 and 5 are by the front door and the other two are near the tomatoes.

法学硕士应该足够聪明，能够注意到这一点，并且：

1. 阅读 garden://plants 确认金盏花的存在并找出其位置

西红柿在里面

1. 阅读 garden://locations 看看四个罐子中哪一个已经存在
2. 呼叫 add_planting 四个花盆中的每一个都有金盏花，可以制作任何花盆

它还没有自动存在

1. 呼叫 log_activities 记录每个花盆的移植事件
2. 呼叫 update_location 适用于5号和6号锅 notes="by the front door" 而是

而不是创建一个虚假的“前门”位置

1. 呼叫 update_location 适用于3号和4号锅 adjacent_to 指向任何一个

西红柿的位置（在步骤1中查找）

但是，您确实希望LLM清晰明确。您可以使用此MCP服务器，而无需 了解此README中除安装之外的任何内容。但是知道SQL模式和可用的 MCP工具/资源允许您作为用户在笔记中非常精确。我可能永远不会进入 请注意，就像上一个例子一样。相反，我可能有两个注意事项：

* Create locations for Pots 3 through 6
:PROPERTIES:
:CREATED:  [2026-04-21 Tue 15:32]
:END:
3 and 4 are adjacent to Bed A
5 and 6 are near the front door

* Transplant calendula outdoors
:PROPERTIES:
:CREATED:  [2026-04-21 Tue 15:35]
:END:
To pots 3, 4, 5, and 6

无论哪种情况，结果都很有可能是一样的，但你不想给惊喜留下空间。

名字

如果你很好奇：

花园 /a?ˈdin/-加利西亚语/阿斯图里亚斯语，意为“花园”