使用自然语言将您的 BirdNET-Pi 数据与 eBird 观测数据进行交叉引用
此 MCP 插件允许您通过将 BirdNET-Pi/BirdWeather 检测与 eBird 的广泛数据库连接起来来分析它们。
Related MCP server: Birding Planner
用于查询 birdnet-pi / birdweather 和 eBird 数据的自然语言界面
将 BirdWeather 探测结果与 eBird 观测结果进行交叉引用
使用 React 工件实现数据驱动的可视化
克隆存储库：
git clone https://github.com/yourusername/mcp-server-birdstats.git安装依赖项：
npm install"mcp-birdstats": {
"command": "npx",
"args": ["-y", "mcp-birdstats"]
},该插件可处理关于鸟类检测数据的自然语言查询。示例查询：
“我的 BirdNET 听到了斯温森画眉的叫声——这不寻常吗？”
“本周我站最罕见的发现是什么？”
“按一天中的时间绘制我的检测图表”
“其他人在 eBird 上看到这些莺了吗？”
该插件严格遵守数据完整性原则：
仅使用实际的 API 响应数据
从不创建示例或估计数据
始终以百分比显示观察计数
数据不可用时清晰指示
核心功能包含在src/index.txt下的单个文本文件中，其中包括：
BirdWeather API 交互
eBird API 交互
数据分析功能
类型定义
辅助实用程序
站点统计
物种名录
检测记录
最近的观察
值得注意的目击事件
热点数据
物种信息
麻省理工学院
对于问题和功能请求，请在 GitHub 存储库上打开问题。
Use this tool to inspect the BirdWeather OpenAPI contract used by this server. Required inputs: none. Defaults: mode='summary', maxPaths=25, optional pathPrefix filter. Set mode='full' with confirmLargePayload=true for full schema. Side effects: none (read-only local file access). Cost note: full schema is large; summary is preferred for planning.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | summary | |
| confirmLargePayload | No | ||
| maxPaths | No | ||
| pathPrefix | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds valuable context beyond this: 'Side effects: none (read-only local file access)' clarifies the scope, and 'Cost note: full schema is large' warns about payload size. It doesn't contradict annotations but provides practical behavioral details.
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 front-loaded with the core purpose, followed by parameter guidance and behavioral notes in a logical flow. Every sentence adds value: the first states the action, the second covers inputs and defaults, the third explains mode usage, and the fourth adds side effects and cost. 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 4 parameters with no schema descriptions and no output schema, the description does well to explain parameter usage, defaults, and behavioral traits. It covers when to use different modes and warnings about payload size. However, it doesn't detail the response format or error handling, leaving some gaps for a tool with multiple parameters.
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 0% schema description coverage, the description compensates well by explaining parameter purposes: 'mode='summary'' vs. 'full', 'maxPaths=25' for limiting output, 'optional pathPrefix filter' for filtering, and the requirement of 'confirmLargePayload=true' for full mode. It adds meaning beyond the bare schema, though it doesn't detail all constraints like min/max values.
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 specific action ('inspect the BirdWeather OpenAPI contract') and resource ('used by this server'), distinguishing it from sibling tools like get_ebird_api and get_system_prompt. It goes beyond the title by specifying it's for reading the API schema, not just a generic 'read' operation.
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 explicit guidance on when to use different modes: 'summary is preferred for planning' and 'Set mode='full' with confirmLargePayload=true for full schema.' It also mentions 'optional pathPrefix filter' for specific use cases, offering clear alternatives within the tool itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this tool to inspect the eBird OpenAPI contract used by this server. Required inputs: none. Defaults: mode='summary', maxPaths=25, optional pathPrefix filter. Set mode='full' with confirmLargePayload=true for full schema. Side effects: none (read-only local file access). Cost note: full schema is large; use summary first.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | summary | |
| confirmLargePayload | No | ||
| maxPaths | No | ||
| pathPrefix | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it notes 'side effects: none (read-only local file access)' and 'Cost note: full schema is large; use summary first.' While annotations already indicate readOnlyHint=true and idempotentHint=true, the description provides practical implementation details about payload size and local access.
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 efficiently structured: it starts with the core purpose, lists required inputs, explains defaults and options, and ends with behavioral notes. Every sentence adds value without redundancy, making it easy to parse.
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 (4 parameters, no output schema), the description is mostly complete: it covers purpose, usage, parameters, and behavioral traits. However, it lacks details on return values (since no output schema exists) and doesn't fully explain all parameter interactions.
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 0% schema description coverage, the description compensates by explaining parameter semantics: it clarifies that mode has 'summary' and 'full' options, maxPaths defaults to 25, pathPrefix is optional, and confirmLargePayload is required for full mode. However, it doesn't fully explain all parameters (e.g., exact meaning of pathPrefix).
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's purpose with specific verbs ('inspect', 'read') and identifies the resource ('eBird OpenAPI contract used by this server'). It distinguishes from sibling tools like get_birdweather_api by specifying the eBird API schema, not other APIs or system prompts.
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 explicit usage guidance: 'use summary first' due to cost concerns, and specifies when to use mode='full' (with confirmLargePayload=true). It implicitly contrasts with siblings by focusing on eBird API inspection, though it doesn't explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this tool when you need operational instructions for BirdStats analysis behavior. Required inputs: none. Defaults: mode='summary', previewLineCount=12. Set mode='full' with confirmLargePayload=true to return full prompt text. Side effects: none (read-only local file access). Cost note: full mode can consume significant tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | summary | |
| confirmLargePayload | No | ||
| previewLineCount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it notes 'Side effects: none (read-only local file access)' and 'Cost note: full mode can consume significant tokens.' While annotations cover read-only and idempotent aspects, the description provides practical warnings about token consumption and clarifies the access type, enhancing transparency without contradiction.
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 highly concise and well-structured: it opens with the usage scenario, lists required inputs and defaults, explains parameter interactions, and adds behavioral notes. Each sentence serves a distinct purpose—no wasted words, and information is front-loaded for clarity.
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 (3 parameters, no output schema), the description is nearly complete: it covers purpose, usage, parameters, and behavioral notes. However, it lacks details on the output format (e.g., what a 'summary' vs. 'full' prompt looks like), leaving a minor gap in contextual understanding.
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 0% schema description coverage, the description fully compensates by explaining all parameters: it states 'Required inputs: none,' lists defaults for mode and previewLineCount, and details the interaction between mode='full' and confirmLargePayload. This adds essential meaning beyond the bare schema, covering semantics and usage conditions effectively.
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 explicitly states the tool's purpose: 'when you need operational instructions for BirdStats analysis behavior.' It specifies the verb 'read' (implied from title) and resource 'system prompt,' clearly distinguishing it from sibling tools like get_birdweather_api and get_ebird_api, which likely access different data sources.
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 explicit usage guidance: 'Use this tool when you need operational instructions for BirdStats analysis behavior.' It also details when to use specific modes (e.g., 'Set mode='full' with confirmLargePayload=true to return full prompt text'), offering clear alternatives within the tool itself.
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.0get_birdweather_apiget_ebird_apiget_system_promptScored across 3 tools
Each tool has a clearly distinct purpose: inspecting the BirdWeather API contract, inspecting the eBird API contract, and retrieving the system prompt for operational instructions. There is no overlap in functionality or ambiguity between these three tools.
All tool names follow a consistent 'get_' prefix pattern (get_birdweather_api, get_ebird_api, get_system_prompt), with clear and descriptive nouns. This uniformity makes the tool set predictable and easy to understand.
With only three tools, the server feels thin for a domain that appears to involve bird statistics analysis. While the tools cover API inspection and prompt retrieval, the lack of actual data retrieval or analysis tools suggests an incomplete surface for the implied purpose.
The tool set is severely incomplete for a bird statistics server. It only provides meta-tools for inspecting APIs and prompts, with no tools to fetch or analyze bird data from BirdWeather or eBird. This creates significant gaps that will hinder agents from performing meaningful tasks in the domain.
Query BigQuery, Snowflake, Redshift & Azure Synapse with natural language
Natural-language queries over a verified emissions knowledge graph, plus standards validation
Local ML: speech to text (SRT/VTT), text embeddings, reranking, similarity, entities, zero-shot.
Open registry of 1.14M+ rooftop-solar detections across France, queryable by natural language.
