コーディングエージェントにガーデニング計画用の構造化された植物データを提供するMCPサーバーです。種のケアプロファイル、根拠を説明するコンパニオンチェック、10年間の観測気象から導き出した霜日ベースの植え付け期間を提供します。
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.ガーデニング計画について尋ねられたモデルは、もっともらしい間隔の数値やコンパニオンプランティングのアドバイスを気軽に生成します。そのほとんどは民間伝承であり、追跡可能なものは何もありません。プロンプトではなくサーバーにする価値がある理由は3つあります。
データは実在し、出典が明記されています。 すべてのレコードに、出典とライセンスが記載されています。
欠落が可視化されています。 上位のティアがフィールドを提供しない場合、レスポンスはその旨を明示します。どのソースも数値を公開していない場合、勝手に埋めるのではなく、説明付きでnullのままにします。
判定にはメカニズムが伴います。 companion_check は、ガーデニングブログに書いてあるからといって「相性が良い」とは決して言いません。ケアデータの根拠からなぜかを説明し、根拠がまったくない場合にはその旨を明かします。
Related MCP server: mcp-hazards
Tool | 機能 |
| 種カタログを名前で検索。ID付きの候補を返します。 |
| ケアプロファイル: 日照、水、耐寒性ゾーン、成木の高さ、食用可否、人とペットへの毒性、既知の害虫。 |
| 2つの植物が互いの近くに植えるべきかどうか。判定の背後にあるすべてのメカニズム付き。 |
| 観測された日別最低気温から、霜の期間、季節の長さ、サイトのUSDAゾーン適合性。 |
| 実験的、デフォルトではオフ。 画像URLから植物を識別します。Perenualのベータアクセスが必要です。 |
すべてのツールはコンパクトなJSONを返します。HTMLもページダンプもありません。
companion_check は民間伝承ではなくメカニズムを返しますこのサーバーのソース一覧にあるAPIは、植物の敵対関係を公開していません（Permapeopleは「コンパニオン」リンクのみを掲載）。そのため、良い/悪い/中立の回答を単純に検索することはできません。庭の言い伝えを繰り返すのではなく、否定的なケースはケアデータにすでにある根拠から導き出されます。
メカニズム | 判定 | 根拠 |
| 悪い | 同じ植物科: 土壌伝染病を共有し、輪作の枠も同じ。 |
| 悪い | 害虫感受性が重複: 混植すると害虫が集中する。 |
| 良い | Permapeopleに記載されている（そのソースの設定が必要）。 |
リスクメカニズムは肯定的な記載よりも優先されますが、上書きされたものを含め、一致したすべての理由が返されるため、混合ペアも判読可能なままです。neutral の判定は、それが相性の証拠ではなく、証拠がないことを明確に示します。
planting_window は作物のタイミングを推測しません座標を与えると、Open-Meteoの10年分の日別最低気温から、春の最終霜の中央値、秋の初霜、季節の長さ、サイトのUSDAゾーンを導き出し、それを植物の公開された耐寒性範囲と照合します。公開されている平年値と照合済みです。
サイト | 最終霜 | 初霜 | 季節 | 導出ゾーン |
ミネアポリス、MN | 04-28 | 10-28 | 183日 | 4b |
ポートランド、OR | 03-17 | 11-25 | 252日 | 8b |
ホノルル、HI | — | — | — | 13a (霜なし) |
シドニー、AU | — | — | — | 10b (霜なし) |
このサーバーがしないことは、作物側の情報をでっち上げることです。この一覧のソースはどれも成熟日数や耐霜性クラスを公開していないため、移植日と播種期限は、days_to_maturity と frost_tolerance を自分で指定した場合にのみ表示されます。この分割は意図的です。このサーバーは気候側を担当し、呼び出し側は作物側を担当します。
南半球のサイトは、それぞれの栽培シーズンで読み取られます。暦年でグループ化すると南半球の夏が2つに分割され、霜のない期間がおよそ1日と報告されます。
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-mcpclaude_desktop_config.json 内:
{
"mcpServers": {
"plant-intel": {
"command": "npx",
"args": ["-y", "plant-intel-mcp"],
"env": {
"PERENUAL_API_KEY": "your-key"
}
}
}
}変数 | 必須 | 目的 |
| はい | 種データ。無料キー。 |
| いいえ | 文書化されたコンパニオンリストを追加します。無料、セルフサービス。 |
| いいえ |
|
| いいえ | キャッシュの場所。デフォルトは |
| いいえ |
|
Perenualキーがなくてもサーバーは停止しません。ツールはリストに残り、各呼び出しは設定すべき変数とキーの入手先を回答します。
これらの制約がサーバーが正直に回答できる内容を形作るため、明確に述べます。
ソース | ライセンス | 重要な制限 |
API利用規約; 無料ティアは非商用 | 1日100リクエスト。 無料キーは種ID 1〜3000のみをカバーし、宣伝されている10,000+は対象外です。ケアガイドと耐寒性マップは有料です。提供されないフィールドはアップグレードプロンプトを返しますが、このサーバーはそれを除去します。 | |
CC BY-SA 4.0 | オプション。設定しない限りオフ。肯定的なコンパニオンリンクのみ — 敵対関係はありません。その上流にはPFAFとKewが含まれており、その条件はCC BY-SAが示唆するよりも制限的です。商用で利用する前に確認してください。 | |
CC BY 4.0 | 無料、キー不要。~9 kmグリッド上のERA5再解析 — 観測所データではありません。霜日は地域の平年値と異なる可能性があります。特に丘陵、谷、水域の近くでは顕著です。すべての |
1日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.
