一个为编码代理提供结构化植物数据以用于花园规划的 MCP 服务器：物种养护档案、能自我解释的伴生检查，以及根据十年观测天气得出的霜冻日期种植窗口。
companion_check("tomato", "potato")
-> bad: both are Solanaceae. Same-family crops share soilborne diseases and
compete for the same rotation slot, so plant them apart and rotate the bed.模型在被问及花园规划时，会乐于给出看似合理的间距数字和伴生种植建议。其中大部分是民间传说，而且没有一条是可追溯的。有三点使得这值得做成一个服务器而不是一段提示词：
数据真实且有引用。 每条记录都说明其来源和许可协议。
缺口是可见的。 当上游层级隐藏某个字段时，响应会明确说明。当没有来源发布某个数字时，它会保持为 null 并附上解释，而不是被填充。
结论带有机制。 companion_check 从不会因为某个园艺博客这么说就断定“它们很相配”。它会根据养护数据中的证据说明原因，并在完全没有证据时承认这一点。
Related MCP server: mcp-hazards
工具 | 功能 |
| 按名称搜索物种目录；返回带 id 的候选结果。 |
| 养护档案：日照、水分、耐寒区、成熟高度、可食性、对人及宠物的毒性、已知病虫害。 |
| 两种植物是否适合种在一起，以及结论背后的所有机制。 |
| 根据观测到的每日最低气温，得出某地的霜冻包络、季节长度和 USDA 耐寒区适配。 |
| 实验性功能，默认关闭。 通过图片 URL 识别植物。需要 Perenual 测试版访问权限。 |
每个工具都返回紧凑的 JSON。没有 HTML，没有页面转储。
companion_check 返回机制，而非民间传说此服务器来源清单中的 API 均不发布植物相克关系——Permapeople 只列出“伴生”链接——因此无法简单查得“好/坏/中性”的答案。与其复述园艺传说，不如从养护数据中已有的证据推导出负面情况：
机制 | 结论 | 理由 |
| 差 | 同一植物科属：共患病害，轮作位置相同。 |
| 差 | 病虫害易感性重叠：混种会集中病虫害。 |
| 好 | 在 Permapeople 中有记录（需要配置该来源）。 |
风险机制的优先级高于正面记录，但所有匹配的理由都会被返回，包括被覆盖的那条，因此混合配对仍然清晰可读。neutral 结论会明确表示这是缺乏证据，而非兼容性的证据。
planting_window 不会猜测作物时令给它坐标，它就会根据 Open-Meteo 整整十年的每日最低气温，推导出春季最后一次霜冻的中位数日期、秋季第一次霜冻日期、季节长度以及该地的 USDA 耐寒区——然后将其与该植物公布的耐寒范围进行核对。已根据公布的正常值进行验证：
地点 | 最后霜冻 | 首次霜冻 | 季节 | 推导耐寒区 |
Minneapolis, MN | 04-28 | 10-28 | 183 days | 4b |
Portland, OR | 03-17 | 11-25 | 252 days | 8b |
Honolulu, HI | — | — | — | 13a (frost free) |
Sydney, AU | — | — | — | 10b (frost free) |
它不会做的是凭空捏造作物那一半。此清单中的来源均不发布成熟天数或耐霜等级，因此只有在您自己提供 days_to_maturity 和 frost_tolerance 时，才会出现移栽和播种日期。这种划分是经过深思熟虑的：此服务器负责气候那一半，调用方负责作物那一半。
南半球的站点按各自的生长季读取。按日历年分组会将南半球的夏季一分为二，并报告大约一天的无霜窗口。
需要 Node 20 或更高版本以及免费的 Perenual API 密钥。
npm install -g plant-intel-mcp或者直接从仓库运行：
git clone https://github.com/wyattlindsey/plant-intel-mcp.git && cd plant-intel-mcp && npm install && npm run buildclaude mcp add plant-intel --env PERENUAL_API_KEY=your-key -- npx -y plant-intel-mcp在 claude_desktop_config.json 中：
{
"mcpServers": {
"plant-intel": {
"command": "npx",
"args": ["-y", "plant-intel-mcp"],
"env": {
"PERENUAL_API_KEY": "your-key"
}
}
}
}变量 | 必需 | 用途 |
| 是 | 物种数据。免费密钥。 |
| 否 | 添加有记录的伴生列表。免费，自助服务。 |
| 否 | 设置为 |
| 否 | 缓存位置。默认为 |
| 否 | 设置为 |
缺少 Perenual 密钥不会阻止服务器运行。工具仍会列出，每次调用都会返回需要设置的变量以及获取密钥的位置。
直截了当地说，因为这些限制决定了服务器能诚实地回答什么。
来源 | 许可 | 重要的限制 |
API 条款；免费层仅限非商业用途 | 每天 100 次请求。 免费密钥仅覆盖物种 ID 1–3000，而非宣传的 10,000+。养护指南和耐寒区地图是付费的。被隐藏的字段会返回升级提示，此服务器会剥离这些提示。 | |
CC BY-SA 4.0 | 可选，默认关闭，除非配置。仅提供正面的伴生链接——没有相克关系。其上游包括 PFAF 和 Kew，其条款比 CC BY-SA 所暗示的更为严格；在商业依赖前请检查。 | |
CC BY 4.0 | 免费，无需密钥。基于 ~9 公里网格的 ERA5 再分析数据——非站点数据。预计霜冻日期会与当地正常值不同，尤其是在山区、山谷或水域附近。每个 |
由于每天 100 次的上限，服务器会积极缓存（物种数据 30 天，天气档案 90 天），并守护每日预算，拒绝花费没有的请求，并在拒绝时说明重置时间。缓存命中永远不会计入其中。
plant_details 从不返回间距。这里没有来源发布该数据，带有注释的 null 比一个无人负责的数字更有用。
npm test # unit and protocol tests, no network
npm run typecheck
npm run build
npm run test:live # opt-in; hits real APIs and spends quota实时测试套件用于检测漂移。测试夹具是根据已发布的文档构建的，因此它断言映射器读取的每个字段在上游仍然存在。其 Open-Meteo 测试无需凭据，可在任何地方运行。
有关架构和约定，请参阅 CLAUDE.md。
MIT。请参阅 LICENSE。
通过此服务器检索的数据仍受其来源条款的约束——请参阅上表。特别是，Perenual 的免费层是非商业性的，而 Permapeople 的数据是相同方式共享的。
Whether two plants should share a bed, with the mechanism behind the answer. A "bad" verdict is derived from shared botanical family (rotation and soilborne disease) or overlapping pest susceptibility, never from folklore. A "good" verdict comes from a documented Permapeople listing when that source is configured. Every matched reason is returned, including any the verdict overrode.
| Name | Required | Description | Default |
|---|---|---|---|
| plant_a | Yes | A species id from search_plants, or a name. | |
| plant_b | Yes | The plant to check against plant_a. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, but the description adds substantial behavioral detail: the mechanism behind 'bad' (botanical family, pest susceptibility, not folklore) and 'good' (Permapeople listing when configured), plus the return behavior (every matched reason returned, including overridden ones). This goes beyond annotations and provides clear expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and then providing mechanism and return behavior. No redundant words; every clause adds value. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the purpose, the logic behind verdicts, and what is returned. With no output schema, it sufficiently covers the expected result behavior. It doesn't state the exact return format, but that's not essential for a read-only check with clear semantics. It's nearly complete, missing only minor format specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover both parameters clearly: plant_a as a species id or name, plant_b as the plant to check. The description itself adds no extra parameter semantics, but the mention of 'species id from search_plants' in the schema and the overall context is adequate. Baseline 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks whether two plants should share a bed, explaining the criteria for 'bad' and 'good' verdicts. It distinguishes itself from siblings (search_plants, plant_details, planting_window) by focusing on companion compatibility, not search, details, or timing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context implies when to use: to check plant compatibility. The plant_a parameter mentions 'A species id from search_plants', linking to a sibling for finding ids, and the description mentions 'when that source is configured', a prerequisite. However, it doesn't explicitly state when NOT to use it or contrast with alternatives like plant_details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full care profile for one species: sun, water, hardiness zones, mature height, edibility, toxicity to people and pets, and known pests. Fields the configured Perenual plan withholds are reported as null and named in notes rather than left silently absent.
| Name | Required | Description | Default |
|---|---|---|---|
| plant | Yes | A species id from search_plants (e.g. "perenual:1852") or a name. An id is cheaper: a name costs an extra upstream request to resolve. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds meaningful behavior: fields withheld by the configured plan are returned as null and named in `notes` rather than silently omitted. This is useful transparency about response shape, though it does not cover error cases or other edge behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and immediately followed by the most important behavioral caveat. No filler or repetition of structured metadata.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the profile contents and explaining the null/notes handling for plan-withheld fields. For a single-parameter read-only tool, this is complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single `plant` parameter is already fully described in the schema, including accepted formats and the cost difference between an id and a name. The description adds no additional parameter-level meaning, so the schema carries the burden and baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states exactly what it does: 'Full care profile for one species' and enumerates concrete content areas (sun, water, hardiness zones, mature height, edibility, toxicity, pests). This clearly distinguishes it from siblings like search_plants, planting_window, and companion_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need a full one-species care profile) and the schema parameter explains how to supply a plant via search_plants id or name. However, it does not explicitly state when to prefer plant_details over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Frost envelope and hardiness fit for a plant at a location. Given coordinates it derives last spring frost, first autumn frost, season length, and the USDA zone from ten years of observed daily minima. Supply days_to_maturity and frost_tolerance from your own crop data to also get transplant and sow-by dates -- no source this server reads publishes those, so they are never guessed.
| Name | Required | Description | Default |
|---|---|---|---|
| plant | Yes | A species id from search_plants, or a name. | |
| latitude | No | Site latitude in decimal degrees. | |
| longitude | No | Site longitude in decimal degrees. | |
| percentile | No | Higher is more cautious: later spring frost, earlier autumn frost. Defaults to 50. | |
| hardiness_zone | No | A USDA zone such as "7a", used only when coordinates are unavailable. A zone encodes winter minimum temperature, not frost timing, so no frost dates can be derived from it. | |
| frost_tolerance | No | Crop frost hardiness. Defaults to "tender", the cautious assumption. | |
| days_to_maturity | No | Days from sowing or transplant to first harvest. No source this server reads publishes this, so supply it from your own crop data to get a sow-by date. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly discloses the data source ('ten years of observed daily minima') and honestly states that 'no source this server reads publishes those, so they are never guessed' regarding days_to_maturity and frost_tolerance. It also explains that hardiness_zone alone cannot provide frost dates fires. The annotations (readOnlyHint, openWorldHint) are consistent. The description adds substantial behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that efficiently conveys the purpose, data source, and optional parameters. Nofluff, no repetition, and structured logically from core function to optional enhancements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main inputs and outputs, data source, and limitations (no guessing of maturity/tolerance). It doesn't specify output format, but that's not strictly necessary. It also doesn't mention error cases, but the schema covers bounds. Overall, it's informative and sufficient for an agent to decide and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have schema descriptions, with 100% coverage. The tool description adds context by explaining the role of days_to_maturity and frost_tolerance (user-supplied) and the advisory note that they are never guessed. It also clarifies that hardiness_zone is only used when coordinates are unavailable. This goes beyond the schema, enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Frost envelope and hardiness for a location.' It clearly states what the tool derives: last spring frost, first autumn frost, season length, and USDA zone from coordinates. It also differentiates from sibling tools (search_plants, plant_details, companion_check) by focusing on climatic data for planting, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to supply `days_to_maturity` and `frost_tolerance` to obtain transplant and sow-by dates, and notes that these are not sourced from the server. It implies that coordinates are preferred, and that hardiness_zone is only a fallback. It does not explicitly contrast with sibling tools, but the tool's specific inputs (coordinates, plant) and outputs (frost dates, zone) make usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Perenual species catalogue by name and return candidate species with ids. Use the returned id with plant_details, companion_check, or planting_window rather than passing a name again -- resolving a name costs an extra upstream request.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page of results. Defaults to 1. | |
| cycle | No | Restrict to a life cycle. | |
| query | Yes | Common or scientific name, e.g. "tomato" or "Solanum". | |
| edible | No | Restrict to species with edible parts. | |
| indoor | No | Restrict to species suited to indoor growing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description correctly aligns with those. It adds useful behavioral context beyond annotations by noting that resolving a name costs an extra upstream request, which is important for an agent deciding whether to cache or reuse ids. Without output schema, it doesn't describe pagination or result limits, but with strong annotations, the bar is lower and it provides relevant cost information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the verb and resource, and each sentence earns its place. The first sentence states purpose and output; the second provides essential usage guidance and a cost note. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 params, all documented in schema), the description covers the core value: search and return ids, plus a key behavioral note about cost. It doesn't discuss pagination or result structure, but without an output schema, that's not required. The description is complete enough for a search-list tool with strong annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters with descriptions. The description adds little beyond the schema: it mentions 'search by name' but doesn't elaborate on the filter parameters. Per the rubric, since schema coverage is high, baseline is 3, and the description doesn't add extra value beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the Perenual species catalogue by name and returns candidate species with ids. It distinguishes itself by mentioning that the returned id should be used with sibling tools (plant_details, companion_check, planting_window) rather than passing a name again, which highlights its role as a lookup step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly guides when to use this tool: to resolve a name into an id, and when not to: avoid passing a name to downstream tools. It names the specific alternatives (plant_details, companion_check, planting_window) and explains the cost of not using the id, providing clear exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0companion_checkplant_detailsplanting_windowsearch_plantsScored across 4 tools
Each tool targets a distinct operation: searching plants, retrieving details, computing planting windows, and checking companions. There is no overlap in purpose; the tools chain together via the search_then_detail flow, making selection unambiguous.
All tool names follow a consistent pattern: a noun ('plant') modified by a descriptor ('details', 'intel', 'window', 'check'). The names are clear, descriptive, and follow a predictable schema, with no mixed conventions or vague verbs.
Four tools is a lean but coherent set for a plant-intel domain. Each tool covers a distinct need (search, details, planting time, companionship), so none feel redundant. A fifth tool for bulk or batch queries might be additive, but the current count is appropriate for the niche scope.
The server covers the primary lifecycle: identify a plant, retrieve its profile, plan its planting window, and assess its compatibility with neighbors. Notable gaps include a missing tool for updating or managing the data (e.g., adding a custom plant or saving a garden plan), but the core research-oriented use case is fully covered.
Hosted MCP server for live public-data APIs and Skills for AI agents.
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
MCP server for generating rough-draft project plans from natural-language prompts.
