mcp-server-birdstats

DMontgomery40/mcp-server-birdstats

3.2

If you are the rightful owner of mcp-server-birdstats and would like to certify it and/or have it hosted online, please leave a comment on the right or send an email to dayong@mcphub.com.

Cross-reference your BirdNET-Pi data with eBird observations using natural language.

mcp-server-birdstats

MCP server that exposes BirdWeather and eBird analysis context for code-execution and chat clients.

What This Server Provides

This server focuses on three read-only tools and one analysis prompt:

  • get_system_prompt
  • get_birdweather_api
  • get_ebird_api
  • check-bird prompt

The tools are intentionally optimized for low-token defaults:

  • Default mode is summary.
  • Full payload access requires mode="full" and confirmLargePayload=true.
  • Tool failures return structured errors (status, retryable, suggestion, message) to help clients self-correct.

Requirements

  • Node.js 18+
  • npm

Install

npm install
npm run build

Run

stdio (default)

npm run start

or explicitly:

npm run start:stdio

Streamable HTTP

MCP_TRANSPORT=streamable-http \
MCP_HTTP_HOST=127.0.0.1 \
MCP_HTTP_PORT=3000 \
MCP_HTTP_PATH=/mcp \
npm run start

Optional hardening:

  • MCP_ALLOWED_ORIGINS=http://localhost,http://127.0.0.1:3000

If an Origin header is present and not allowed, the server returns 403.

Docker

Build:

docker build -t mcp-server-birdstats .

Run in stdio mode:

docker run --rm -it mcp-server-birdstats

Run in Streamable HTTP mode:

docker run --rm -p 3000:3000 \
  -e MCP_TRANSPORT=streamable-http \
  -e MCP_HTTP_HOST=0.0.0.0 \
  -e MCP_HTTP_PORT=3000 \
  -e MCP_HTTP_PATH=/mcp \
  mcp-server-birdstats

Test

npm test

The behavior suite covers:

  • initialize lifecycle
  • tools/list
  • successful tools/call
  • failing tools/call with structured error assertions
  • both stdio and streamable-http transports

Provider API Notes

The included birdweather_api.json and ebird_api.json files are local OpenAPI snapshots consumed by the tools above.

License

MIT

Appendix: MCP in Practice (Code Execution, Tool Scale, and Safety)

Last updated: 2026-02-24

Why This Appendix Exists

Model Context Protocol (MCP) is still one of the most useful interoperability layers for tools and agents. The tradeoff is that large MCP servers can expose many tools, and naive tool-calling can flood context windows with schemas, tool chatter, and irrelevant call traces.

In practice, "more tools" is not always "better outcomes." Tool surface area must be paired with execution patterns that keep token use bounded and behavior predictable.

The Shift to Code Execution / Code Mode

Recent workflows increasingly move complex orchestration out of chat context and into code execution loops. This reduces repetitive schema tokens and makes tool usage auditable and testable.

Core reading:

Recommended Setup for Power Users

For users who want reproducible and lower-noise MCP usage, start with a codemode-oriented setup:

Practical caveat: even with strong setup, model behavior can still be inconsistent across providers and versions. Keep retries, guardrails, and deterministic fallbacks in place.

Peter Steinberger-Style Wrapper Workflow

A high-leverage pattern is wrapping MCP servers into callable code interfaces and task-focused CLIs instead of exposing every raw tool to the model at all times.

Reference tooling:

What Works Best With Which MCP Clients

  • Claude Code / Codex / Cursor: strong for direct MCP workflows, but still benefit from narrow tool surfaces.
  • Code-execution wrappers (TypeScript/Python CLIs): better when tool count is high or task chains are multi-step.
  • Hosted chat clients with weaker MCP controls: often safer via pre-wrapped CLIs or gateway tools.

This ecosystem changes rapidly. If you are reading this now, parts of this guidance may already be out of date.

Prompt Injection: Risks, Impact, and Mitigations

Prompt injection remains an open security problem for tool-using agents. It is manageable, but not solved.

Primary risks:

  • Malicious instructions hidden in tool output or remote content.
  • Secret exfiltration and unauthorized external calls.
  • Unsafe state changes (destructive file/system/API actions).

Consequences:

  • Data leakage, account compromise, financial loss, and integrity failures.

Mitigation baseline:

  • Least privilege for credentials and tool scopes.
  • Allowlist destinations and enforce egress controls.
  • Strict input validation and schema enforcement.
  • Human confirmation for destructive/high-risk actions.
  • Sandboxed execution with resource/time limits.
  • Structured logging, audit trails, and replayable runs.
  • Output filtering/redaction before model re-ingestion.

Treat every tool output as untrusted input unless explicitly verified.