Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pesticide-mcp Is Daconil registered for apple scab?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
FAMIC が公開する農薬登録情報 CSV を取り込み、ローカル DB に正規化し、Claude Code から MCP 経由で検索・照会できるようにする MVP プロジェクトです。
注意: 本ツールが返すのは農薬登録情報の検索結果であり、使用可否を保証するものではありません。実際に使用する前に、製品ラベルと最新の農薬登録情報を必ず確認してください。
CLAUDE.md: プロジェクト方針と運用ルールの要点
docs/MVP_DESIGN.md: 設計（アーキテクチャ、データモデル、検索仕様、MCP tool 仕様）
docs/BACKLOG.md: マイルストーンとバックログ
docs/DEVELOPMENT.md: 開発ガイド（技術スタック、環境変数、実行コマンド）
Related MCP server: japan-ir-search
Python 3.12+
# 依存関係のインストール
uv sync
# Lint / format
uv run ruff check .
uv run ruff format .
# テスト
uv run pytestFAMIC の農薬登録情報 CSV/ZIP を data/raw/ に配置してから取り込みます。
uv run python -m pesticide_mcp.import_famic --source-dir ./data/raw --db ./data/pesticides.duckdbFAMIC の登録基本部（例: R0807010.zip）と登録適用部一・二（例: R0807011/012.zip）を
data/raw/ に置いて実行します。ZIP のまま取り込めます。主なオプション:
--source-month YYYY-MM: 更新年月を明示（省略時はファイル名から推定）
--dry-run: DB へ書き込まず解析・検証のみ
再実行しても pesticides / applications の内容は同じになります（取り込み履歴は source_imports に追記）。
ローカル stdio MCP として接続します。
claude mcp add --transport stdio pesticide-registry \
-- uv run python -m pesticide_mcp.serverプロジェクト共有用に .mcp.json.example を用意しています。コピーして利用してください。
cp .mcp.json.example .mcp.json環境変数は以下を利用できます（詳細は docs/DEVELOPMENT.md）。
変数名 | 用途 | 既定値 |
| DuckDB ファイルパス |
|
| FAMIC ZIP/CSV 保存先 |
|
接続後、Claude Code から dataset_status を呼ぶと取り込み状態を確認できます。
いずれも「登録情報の検索結果」を返すもので、使用可否の判定は行いません。
tool | 用途 | 主な入力 |
| 取り込み状態（件数・出典・取り込み日時）を返す | （なし） |
| 農薬基本情報を検索 |
|
| 登録番号で基本情報＋適用サマリを取得 |
|
| 適用情報を検索 |
|
| 条件に該当する登録行候補を返す（可否判定ではない） |
|
各レスポンスには出典（source）と注意文（safety_notice）が含まれ、check_registered_use は
allowed のような可否を断定するフィールドを返しません。
- 「登録番号 12345 の農薬を見て」 → get_pesticide_by_register_no
- 「除虫菊で農薬を検索して」 → search_pesticides
- 「りんごの黒星病に登録のある適用を出して」 → get_applications
- 「ダコニールはりんごの黒星病に登録がある？登録行を出して」 → check_registered_usecheck_registered_use は「使えます」と断定せず、該当する登録行の候補と根拠フィールド
（作物名・適用病害虫雑草名・使用時期・使用方法・使用回数・総使用回数など）を返します。
Claude が結果を説明するときの返答テンプレートは
docs/DEVELOPMENT.md を参照してください。
一次データ: FAMIC 農薬登録情報ダウンロード CSV
補助（任意）: WAGRI 農薬情報取得 API
外部公開・二次配信を行う場合は、FAMIC/WAGRI の利用条件・表示条件を必ず再確認してください。
指定条件に該当する登録行の候補を返す（使用可否の判定ではない）。
返す各候補には match_confidence と matched_fields が付く。
``allowed`` のような可否を断定するフィールドは決して返さない。
実使用前に必ず製品ラベルと最新の農薬登録情報を確認すること。
| Name | Required | Description | Default |
|---|---|---|---|
| crop | Yes | ||
| pest | No | ||
| limit | No | ||
| usage_method | No | ||
| pesticide_name_or_register_no | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral transparency burden. It discloses that output candidates include 'match_confidence' and 'matched_fields', and that it never returns fields like 'allowed'. This informs the agent about the non-deterministic, confidence-based nature of results. It also warns to check product labels, adding safety context. No contradictions with absent 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 concise (4 sentences) and front-loaded with the primary purpose. Every sentence adds unique value: core function, output fields, what it does not return, and a safety warning. No wasted words.
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 5 parameters, no output schema, and 0% schema description coverage, the description is incomplete. It fails to explain parameter meanings, expected values, or constraints. It mentions output fields but not the full return structure. A more complete description would clarify parameter usage and return format.
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 has 0% description coverage for 5 parameters. The description provides no explanation of any parameter (crop, pest, limit, usage_method, pesticide_name_or_register_no). The agent must infer semantics solely from parameter names, which is insufficient. The description does not compensate for the lack of schema 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 returns 'candidates of registration rows' matching conditions, using a specific verb ('返す' - returns) and resource ('登録行の候補'). It explicitly distinguishes from sibling tools by clarifying it is not a usability judgment, and the sibling tools (e.g., get_applications, search_pesticides) have different purposes.
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 usage context by stating it is not a usability judgment, suggesting the tool is for exploratory candidate retrieval rather than definitive answers. However, it does not explicitly state when to use this tool vs. siblings, nor provide when-not-to-use or alternatives. The warning to verify before actual use is a post-hoc guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
データセットの取り込み状態（件数・出典・取り込み日時）を返す。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It indicates a read-only operation returning status info, but lacks details on potential side effects, cost, or what happens if the dataset is not available.
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?
A single sentence is concise and front-loaded. However, it could be slightly expanded to clarify the dataset scope without losing 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?
With no output schema, the description covers return values (count, source, date/time). It lacks specification of which dataset, but in context of sibling tools, it is mostly complete.
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?
No parameters exist, so baseline 4 applies. The description adds no parameter information, which is acceptable given zero parameters.
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 returns dataset import status including count, source, and date/time. However, it does not explicitly specify which dataset, relying on context from sibling tools.
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?
No guidance on when to use this tool versus alternatives. While siblings are distinct, there is no explicit when/when-not advice or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
作物名・病害虫雑草名・農薬名・登録番号などで適用情報を検索する。
各結果は使用時期・使用方法・使用回数などの根拠フィールドを含む。 使用可否の判定ではない。
| Name | Required | Description | Default |
|---|---|---|---|
| crop | No | ||
| pest | No | ||
| limit | No | ||
| register_no | No | ||
| usage_method | No | ||
| pesticide_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that the tool returns certain fields and is not a usability check. It does not mention read-only nature, rate limits, authentication, or any side effects. This is minimal disclosure for a tool with no annotation support.
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 concise (two sentences), with the first sentence stating the core purpose and the second adding result details and a clarification. No unnecessary words. Could be slightly more structured with bullet points or explicit parameter list, but effective as is.
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 has 6 parameters, no output schema, and no annotations, the description is incomplete. It fails to explain all parameters (especially limit and usage_method), provides no return structure details beyond a few fields, and offers no usage guidance. More information is needed for an agent to use it correctly.
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?
With schema description coverage at 0%, the description partially compensates by mentioning search criteria such as crop, pest, pesticide_name, and register_no. However, it does not explain the 'limit' or 'usage_method' parameters. The description adds some meaning beyond the schema but leaves gaps.
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 that the tool searches application information by crop, pest, pesticide name, registration number, etc. It also specifies that results include usage timing, method, and number of uses, and explicitly says it is not a judgment of usability. This differentiates it from sibling tools like check_registered_use, but could be more explicit about exact distinctions.
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 mentions that the tool is 'not a judgment of usability', implying that for usability decisions, another tool (e.g., check_registered_use) should be used. However, it does not explicitly state when to use this tool versus alternatives, nor provide any conditional advice or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
登録番号から農薬基本情報と適用情報の要約を取得する。
登録番号は ``12345`` と ``0012345`` の両方を受け付ける。
適用明細は含めず総件数と作物・病害虫の例のみを返す。
明細は ``get_applications`` に登録番号を渡して取得する。
| Name | Required | Description | Default |
|---|---|---|---|
| register_no | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses that the output is a summary (total count and example crops/pests), not full application details. This adds behavioral context beyond the schema. It could mention whether the operation is read-only, but the context strongly implies it is read-only, and no side effects are mentioned.
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 concise with three focused sentences. The first states the core purpose, the second explains input format, and the third clarifies output scope and directs to the sibling tool. Every sentence adds value without 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?
For a tool with one required parameter and no output schema, the description covers all essential aspects: purpose, input format, output scope, and relationship to sibling tools. It is complete and sufficient for an agent to select and invoke the tool correctly.
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 provides the parameter 'register_no' with only type 'string'. The description compensates by explaining that it accepts both formats like '12345' and '0012345', adding semantic meaning beyond the schema's minimal definition. Since schema coverage is 0%, this is valuable.
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 that it retrieves basic pesticide information and a summary of application data based on a registration number. It differentiates itself from sibling tools like 'search_pesticides' (which searches by other criteria) and 'get_applications' (which provides detailed application records).
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 explicitly advises that for detailed application lines, users should use 'get_applications' with the registration number. It also specifies the accepted input formats for the registration number, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
農薬名・登録番号・有効成分・農薬の種類から農薬基本情報を検索する。
結果は登録情報の検索結果であり、使用可否の判定ではない。
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| limit | No | ||
| register_no | No | ||
| pesticide_type | No | ||
| active_ingredient | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that the tool searches and returns registration information. It does not disclose whether it is read-only, any authentication or rate limits, or the behavior when multiple parameters are given. For a search tool, more behavioral details are needed.
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 only two sentences. The first sentence clearly states the purpose and the searchable fields. The second adds a critical caveat. It is front-loaded with the action and resource. No unnecessary words.
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 that the tool has 5 optional parameters with no output schema and no annotations, the description is insufficient. It does not explain pagination (limit), how the search works (e.g., fuzzy matching, exact match), or what fields are in the output. The caveat is helpful but does not compensate for the missing behavioral and parameter details.
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 coverage is 0%, and the description only lists the parameter names (農薬名・登録番号・有効成分・農薬の種類) without explaining their format, constraints, or how they combine (e.g., AND or OR). The 'limit' parameter is mentioned in the schema but not in the description. The description adds minimal semantic value beyond the field names.
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 that the tool searches basic pesticide information by name, registration number, active ingredient, or pesticide type. It explicitly mentions the resource (pesticide basic information). However, it does not explicitly differentiate from siblings like 'get_pesticide_by_register_no' or 'check_registered_use', but the broader search scope is implied.
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 provides a usage caveat: '結果は登録情報の検索結果であり、使用可否の判定ではない。' This tells the agent that the result is not a judgment of usability. However, it does not provide explicit guidance on when to use this tool vs. alternatives or when not to use it beyond the caveat.
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. Dates show when Glama detected each change.
v0.1.0check_registered_usedataset_statusget_applicationsget_pesticide_by_register_nosearch_pesticidesEach tool has a clearly distinct purpose: checking registered use candidates, dataset status, application search, pesticide details by registration number, and general pesticide search. No overlap in functionality.
All tools use consistent snake_case with a verb_noun pattern (e.g., check_registered_use, get_applications, search_pesticides). No mixed conventions or unclear abbreviations.
Five tools is appropriate for a pesticide information server, covering essential query operations without being too few or excessive.
The tool set provides comprehensive coverage for searching and retrieving pesticide information, including status, registration details, applications, and usage candidates. References between tools (e.g., get_pesticide_by_register_no suggesting get_applications) show good integration.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Japan geodata: cadastral lot numbers (chiban) and reverse geocoding, for AI agents.
Read-only MCP server for searching Japan government procurement bid information from the KKJ portal.
An MCP server that audits the fairness of construction and renovation estimates in Japan. Provides fair-price ranges, overcharge detection, and verifiable unit-cost data based on JCCDB (65,520 items across 402 categories, CC BY 4.0, DOI-backed).
The official Model Context Protocol server for Ambee. It gives any MCP-compatible AI assistant — Claude, ChatGPT, Cursor, VS Code, Ollama, and more direct access to live air quality, pollen, and weather data. To get started, including information on signing up and obtaining your Ambee key, check out the Ambee documentation on https://docs.ambeedata.com
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/shinichinomura/pesticide-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
