정원 계획을 위해 코딩 에이전트에게 구조화된 식물 데이터를 제공하는 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.정원 계획에 대해 묻는 모델은 그럴듯한 식재 간격 수치와 동반 식재 조언을 기꺼이 만들어냅니다. 대부분은 민간 전승에 불과하며, 그 어느 것도 추적 가능하지 않습니다. 세 가지 이유로 이는 프롬프트가 아닌 서버로 만들 가치가 있습니다:
데이터는 실제이며 출처가 명시됩니다. 모든 레코드는 데이터가 어디서 왔는지, 어떤 라이선스 하에 있는지 명시합니다.
공백이 보입니다. 상위 계층이 필드를 제공하지 않으면 응답이 그렇게 명시합니다. 어떤 출처도 수치를 게시하지 않으면, 임의로 채우는 대신 설명과 함께 null로 남깁니다.
판정에는 메커니즘이 담깁니다. companion_check는 정원 블로그가 그렇게 말했다는 이유로 "이 둘은 잘 어울린다"고 말하지 않습니다. 관리 데이터의 증거를 바탕으로 왜 그런지 말하며, 증거가 전혀 없을 때는 그 사실을 인정합니다.
Related MCP server: mcp-hazards
도구 | 기능 |
| 이름으로 종 카탈로그를 검색합니다. ID가 포함된 후보를 반환합니다. |
| 관리 프로필: 햇빛, 물, 내한성 구역, 성숙 높이, 식용 여부, 사람과 반려동물에 대한 독성, 알려진 해충. |
| 두 식물이 서로 가까이 있어야 하는지 여부와 판정 뒤의 모든 메커니즘을 반환합니다. |
| 관측된 일일 최저 기온에서 서리 범위, 계절 길이, 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를 직접 제공할 때만 나타납니다. 그 구분은 의도적입니다: 이 서버는 기후 절반을 소유하고, 호출자는 작물 절반을 소유합니다.
남반구 지역은 자체 성장 계절로 읽습니다. 달력 연도로 그룹화하면 남반구 여름이 둘로 나뉘고 서리 없는 기간이 대략 하루로 보고됩니다.
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 약관; 무료 티어는 비상업적 | 하루 100회 요청. 무료 키는 종 id 1–3000만 지원하며, 광고된 10,000+는 아닙니다. 관리 가이드와 내한성 지도는 유료입니다. 보류된 필드는 업그레이드 프롬프트를 반환하며, 이 서버는 이를 제거합니다. | |
CC BY-SA 4.0 | 선택 사항, 구성되지 않으면 꺼짐. 긍정적인 동반자 링크만 — 적대자는 없음. 상위 소스에는 PFAF와 Kew가 포함되며, 그 약관은 CC BY-SA가 암시하는 것보다 더 제한적입니다. 상업적으로 의존하기 전에 확인하세요. | |
CC BY 4.0 | 무료, 키 없음. ERA5 재분석 ~9 km 그리드 — 관측소 데이터 아님. 서리 날짜가 특히 언덕, 계곡 또는 물 근처에서 지역 정상값과 다를 수 있습니다. 모든 |
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의 데이터는 share-alike입니다.
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.
