Forem: Andrew Barnes

Contributing to the Agent Infrastructure Stack: 4 PRs Across 3 Repos in One Weekend

Andrew Barnes — Fri, 27 Mar 2026 00:32:25 +0000

Contributing to the Agent Infrastructure Stack: 4 PRs Across 3 Repos in One Weekend

Most open source contributions exist in isolation. You fix a bug here, add a feature there. But occasionally you get the chance to contribute across an entire ecosystem in a way where each PR reinforces the others. That's what happened when I spent a weekend contributing to three projects in the MCP agent infrastructure stack -- and in the process, made Bitcoin a first-class citizen across all of them.

The Stack

Three projects, three layers:

agentregistry -- the discovery layer where developers find and install MCP servers
agentgateway -- the proxy layer that adds rate limiting, auth, and observability to MCP servers
kagent -- the Kubernetes orchestration layer that deploys AI agents with tool access

Each project solves a different problem, but together they form the infrastructure that makes MCP servers useful in production. My goal was simple: contribute meaningful work to each layer, using bitcoin-mcp (my own MCP server with 40+ Bitcoin network tools) as the connecting thread.

PR 1: Fixing a CLI Crash in agentregistry

The problem: Running arctl skill list --page-size -1 crashed the entire CLI with a Go slice bounds panic. Issue #368 had been open, waiting for someone to pick it up.

The investigation: The --page-size flag value was being passed directly to slice operations without any validation. In Go, creating a slice with negative bounds causes a runtime panic -- no graceful error, no recovery, just a stack trace dumped to the terminal.

The fix: I added input validation at the command level, before the value ever reaches slice operations. If you pass a negative page-size now, you get a clear error message telling you the value must be positive. Simple, defensive, and exactly what you'd expect from a well-behaved CLI tool.

What I learned: agentregistry's CLI is built with Cobra, and the validation pattern I used follows the same approach used elsewhere in the codebase. Reading the existing code before writing new code always pays off.

PR 2: Fixing the Broken Lint Target in agentregistry

The problem: make lint had been broken since PR #253 removed golangci-lint from the Go tools list. The Makefile still tried to invoke it via go install, which no longer worked. Issue #377 documented the failure.

The investigation: The root cause was a dependency change that wasn't fully propagated. When golangci-lint was removed from the project's Go tool management, the Makefile target that depended on it wasn't updated. This is a classic problem in projects with multiple build system entry points.

The fix: Updated the lint target to use the system-installed golangci-lint binary directly, with a clear error message if it's missing. The error message includes the official installation command so contributors can get unblocked immediately. This aligns with golangci-lint's own documentation, which recommends against go install for linter binaries due to version management issues.

What I learned: Broken CI/linting targets are a silent contributor barrier. People clone the repo, try to run make lint before submitting a PR, it fails, and they either skip linting or give up on contributing. Fixing developer experience issues has outsized impact relative to the size of the diff.

PR 3: Bitcoin ToolServer + SRE Agent for kagent

The problem: kagent had great examples for web and cloud tools, but nothing for blockchain infrastructure. Bitcoin node operators running Kubernetes had no way to deploy an AI agent that could monitor their infrastructure using real blockchain data.

The solution: I added two files to kagent's contrib directory:

First, a bitcoin-mcp ToolServer definition (contrib/tools/bitcoin-mcp.yaml) following the established pattern used by other community tools like context7. This tells kagent how to connect to bitcoin-mcp as a tool provider.

Second, a Bitcoin SRE Agent (contrib/agents/bitcoin-sre.yaml) with a detailed system prompt that encodes actual operational knowledge. The agent knows how to:

Monitor block production intervals and alert on delays
Analyze mempool congestion and recommend fee strategies
Triage fee spikes by examining mempool composition
Detect and assess chain reorganizations
Correlate network issues with hashrate changes

This isn't a generic "Bitcoin helper" -- it's a runbook encoded as an agent prompt, written by someone who actually operates Bitcoin infrastructure.

What I learned: kagent's YAML-based agent definition is remarkably clean. The separation between tool definitions and agent prompts means you can iterate on the operational knowledge independently from the infrastructure config. I structured the bitcoin-mcp tool definition to match context7.mcp.yaml exactly, which made the PR easy to review because it followed an established pattern.

PR 4: Bitcoin Example with Rate Limiting for agentgateway

The problem: agentgateway had examples for generic MCP servers but nothing demonstrating a real-world use case with production concerns like rate limiting and CORS.

The solution: I added examples/bitcoin/ with a complete configuration that proxies bitcoin-mcp through agentgateway. The example demonstrates:

Rate limiting (10 requests per minute by default) to protect the upstream API
CORS configuration for browser-based MCP clients
Zero additional configuration -- bitcoin-mcp's free hosted Satoshi API works out of the box, so anyone can run the example immediately

The README walks through setup, configuration, and common queries so developers can see agentgateway's value proposition in action: add security, observability, and traffic management to any MCP server without modifying the server itself.

What I learned: agentgateway's configuration model is well-designed for exactly this kind of layered concern. You define listeners, targets, and policies independently, which means you can swap out the upstream MCP server without changing your security configuration. The Bitcoin example makes this concrete in a way that a generic "hello world" example can't.

The Connecting Theme

These four PRs aren't just four independent contributions -- they tell a story about what it means to make a protocol implementation production-ready.

Having an MCP server (bitcoin-mcp) is step one. But to be useful in production, that server needs to be discoverable (agentregistry), securable (agentgateway), and deployable (kagent). By contributing to all three layers, Bitcoin becomes a reference implementation that demonstrates the full stack working together.

The two bug fixes in agentregistry matter too. They lower the barrier for other contributors who might want to add their own MCP servers to the registry. A CLI that doesn't crash and a lint target that actually works are prerequisites for a healthy contributor experience.

What's Next

All four PRs are submitted and under review. Regardless of whether they merge on the hackathon timeline, the work demonstrates something I believe strongly: the best way to contribute to an ecosystem is to use it for something real. Bitcoin infrastructure monitoring is not a toy example. It involves real operational concerns, real data, and real users. That's what makes these contributions worth reviewing.

If you're building MCP servers and want to see how the infrastructure stack fits together, check out the PRs linked in the README. And if you're running Bitcoin infrastructure on Kubernetes, the kagent Bitcoin SRE agent might be exactly what you need.

Andy Barnes is the creator of bitcoin-mcp, an MCP server providing 40+ tools for querying and analyzing the Bitcoin network. Find him on GitHub at @Bortlesboat.

Building a Bitcoin SRE Agent: Incident Response Meets AI

Andrew Barnes — Fri, 27 Mar 2026 00:28:51 +0000

Building a Bitcoin SRE Agent: Incident Response Meets AI

What if your Bitcoin node had an AI SRE on call 24/7?

Not a chatbot that answers "what is Bitcoin?" -- an actual site reliability engineer that detects fee spikes at 3am, investigates mempool floods, diagnoses root causes, and tells you exactly what to do. One that follows the same incident response protocol your best on-call engineer follows, except it never sleeps and never forgets a runbook.

That's what I built for the MCP & AI Agents Hackathon. Here's how.

The Problem with Bitcoin Monitoring Today

Running Bitcoin infrastructure is operationally demanding. A node operator deals with:

Fee volatility: Fees can jump 10x in minutes during inscription mints or exchange consolidations. Send a transaction at the wrong time and you overpay by $50. Wait too long and your payment doesn't confirm for hours.
Mempool floods: 200,000+ unconfirmed transactions pile up, memory usage spikes, and your node starts evicting low-fee transactions. You need to know if this is transient or sustained.
Mining anomalies: A major pool goes offline, hashrate drops 15%, block times stretch to 25 minutes. Is this a temporary outage or something to worry about?
Node health: Your node falls behind, loses peers, or runs low on disk. By the time Grafana pages you, you've already missed blocks.

The standard response is a wall of dashboards, static alert thresholds, and a runbook wiki page that was last updated six months ago. The operator wakes up, SSHs in, runs commands, cross-references block explorers, and makes a judgment call. This process is slow, error-prone, and doesn't scale.

The Solution: An AI Agent That Follows SRE Protocol

The Bitcoin SRE Agent replaces the runbook with an AI agent that follows a structured four-phase incident response protocol:

DETECT -- Compare current state against baseline thresholds. Is this fee rate 3x the 7-day average? Are there more than 100K unconfirmed transactions? Has it been 20+ minutes since the last block?

INVESTIGATE -- Gather context. If fees spiked, check the mempool composition. Are inscription transactions dominating? Is block production normal? What does the next block template look like?

DIAGNOSE -- Correlate signals. Fee spike + mempool flood + inscription surge = Ordinals mint event. Fee spike + normal mempool = estimation overshoot. Slow blocks + hashrate drop = mining pool outage.

RECOMMEND -- Produce actionable guidance. "Wait 2 hours, fees should normalize. Use 15 sat/vB if time-sensitive. No escalation needed." Or: "CRITICAL -- fees above 500 sat/vB sustained for 3 blocks. Alert the team."

Architecture: Three Sponsor Projects Working Together

The agent uses all three hackathon sponsor projects, each in its natural role:

agentregistry (discover bitcoin-mcp)
    |
    v
agentgateway (rate limit + OTEL traces)
    |
    v
kagent ToolServer (bitcoin-mcp, 49 tools)
    |
    v
kagent Agent CRD (Bitcoin SRE Agent)
    |
    v
Incident Response Loop

kagent provides the orchestration layer. The ToolServer CRD wraps bitcoin-mcp -- my MCP server with 49 tools for querying the Bitcoin network. The Agent CRD defines the SRE agent itself, including a 500+ word system prompt that encodes the full incident response protocol, detection thresholds, diagnostic patterns, and safety rules.

agentgateway sits in front of bitcoin-mcp, enforcing rate limits (60 req/min to prevent runaway investigation loops) and exporting OpenTelemetry traces to Jaeger. After an incident, you can replay every tool call the agent made -- complete forensics.

agentregistry publishes bitcoin-mcp so other agents and operators can discover it. The registry entry describes all 49 tools across 9 categories, making it composable into other agent workflows.

The Demo: A Fee Spike at 3am

Here's what happens when you run the agent:

=== Bitcoin SRE Agent -- Incident Response Demo ===

[1/4] NODE HEALTH CHECK
  Block Height:    889,241
  Sync Status:     GREEN -- SYNCED (height 889,241)
  Network:         main

[2/4] FEE ENVIRONMENT
  Assessment:      YELLOW -- Elevated (28.0 sat/vB)
  Recommendation:  Non-urgent txs should wait. Use 17 sat/vB if time-sensitive.

[3/4] MEMPOOL ANALYSIS
  Assessment:      YELLOW -- Congested (67,234 txs, 245 MB)
  Recommendation:  Estimated clearing time: ~3 hours at current hashrate.

[4/4] SITUATION REPORT
  Overall Status:  YELLOW
  Diagnosis:       Fee spike correlated with mempool congestion.
                   Likely organic demand surge or inscription event.
  Recommendation:  Non-urgent transactions should wait.
                   Monitor for resolution over next 1-3 hours.

The agent called three bitcoin-mcp tools (get_blockchain_info, get_fee_estimates, get_mempool_info), analyzed the results against its built-in thresholds, correlated the signals, and produced a structured situation report. No dashboards, no manual investigation, no runbook lookups.

The System Prompt: Encoding Operator Knowledge

The most interesting part of this project isn't the code -- it's the system prompt in the kagent Agent CRD. It encodes years of operator knowledge into structured rules:

Fee interpretation: Normal is 1-10 sat/vB. Elevated is 10-50. High is 50-200. Crisis is 200+.
Diagnostic patterns: Fee spike + mempool flood + inscriptions = mint event. Fee spike + normal mempool = estimation overshoot.
Safety rules: Never broadcast a transaction without explicit approval. Never make financial recommendations. Always caveat uncertainty.
Escalation criteria: Alert humans when peers drop below 2, node falls 100+ blocks behind, or fees exceed 500 sat/vB for 3+ blocks.

This is the key insight: the agent's intelligence comes from the prompt, not the code. The code just calls tools and formats output. The prompt makes it an SRE.

Why This Pattern Matters Beyond Bitcoin

The architecture -- domain MCP server + kagent orchestration + agentgateway security -- isn't Bitcoin-specific. It's a template for any infrastructure SRE agent:

Database SRE: Wrap pg_stat_statements as MCP tools. Detect slow queries, recommend index changes.
Kubernetes SRE: Wrap kubectl as MCP tools. Detect crash loops, recommend resource adjustments.
Network SRE: Wrap SNMP/NetFlow as MCP tools. Detect anomalous traffic, recommend firewall rules.

The pattern is always the same: domain tools (MCP server) + structured reasoning (agent prompt) + guardrails (gateway) + discoverability (registry). kagent makes the agent Kubernetes-native. agentgateway makes it production-safe. agentregistry makes it composable.

Try It Yourself

# Clone and run the demo
pip install bitcoin-mcp
python demo.py

No Bitcoin node required -- bitcoin-mcp falls back to the free Satoshi API automatically. The demo connects, runs a health check, analyzes fees and mempool, and produces a situation report in about 10 seconds.

For the full stack with agentgateway and Jaeger tracing:

docker compose up -d
python demo.py --gateway
# Open http://localhost:16686 to see traces in Jaeger

All code, CRDs, and configs are in the submissions/agents/ directory.

What's Next

This is a proof of concept, but the path to production is clear:

Scheduled execution: Run the health check on a cron (every 15 minutes via kagent). Alert on severity changes.
Historical baselines: Store past readings and compare against rolling averages instead of static thresholds.
Multi-node: Monitor a fleet of Bitcoin nodes, not just one. The ToolServer CRD supports multiple instances.
Automated remediation: For safe operations (restart a stuck node, add peers), let the agent act without human approval.
A2A composition: Other agents can delegate to the Bitcoin SRE agent via kagent's A2A protocol. A general infrastructure agent could ask "is Bitcoin healthy?" and get a structured response.

The future of infrastructure operations isn't more dashboards. It's agents that understand your systems, follow your runbooks, and wake you up only when they need to.

Built for the MCP & AI Agents Hackathon -- Building Cool Agents category.

Tools: bitcoin-mcp | kagent | agentgateway | agentregistry

I Built My First AI Agent That Understands Bitcoin -- Here's How

Andrew Barnes — Thu, 26 Mar 2026 23:59:38 +0000

I Built My First AI Agent That Understands Bitcoin -- Here's How

A beginner's guide to MCP, agentgateway, and bitcoin-mcp

I wanted to build an AI agent that could answer questions about Bitcoin. Not from a static FAQ -- I mean real-time data. Current block height. Mempool congestion. Fee estimates. Mining stats.

I figured this would take days of API wrangling, authentication headaches, and custom plumbing. It took 10 minutes.

Here's what I learned.

The Problem

AI models are smart, but they're stuck in the past. Ask Claude or GPT about the current Bitcoin block height and you'll get a polite "I don't have access to real-time data." Fair enough -- but what if you could give them that access?

That's what MCP does.

What is MCP?

Model Context Protocol (MCP) is an open standard that lets AI models call external tools. Think of it like USB for AI: a universal plug that connects any AI client to any data source. An MCP server exposes tools (like "get the current Bitcoin block height"). An MCP client (like Claude Desktop or a custom script) calls those tools. The AI model decides which tools to call based on your question.

The beauty is separation of concerns. The Bitcoin logic lives in the MCP server. The AI logic lives in the client. They speak the same protocol.

What is agentgateway?

agentgateway is a lightweight proxy that sits between your AI client and your MCP servers. Why do you need a proxy? A few reasons:

Protocol translation -- it can bridge different MCP transports (stdio, SSE, Streamable HTTP)
Routing -- it can fan out to multiple MCP servers from a single endpoint
Security -- it's where you'd add authentication, rate limiting, and audit logging in production

For our purposes, it gives us a clean HTTP endpoint that any MCP client can connect to.

The Stack

Here's what we're building:

AI Client  --->  agentgateway (port 3000)  --->  bitcoin-mcp (port 8000)

Three components. Two commands to start. One config file.

Let's Build It

Step 1: Install bitcoin-mcp

pip install bitcoin-mcp

That's the entire Bitcoin integration. bitcoin-mcp ships with 49 tools for querying the Bitcoin network, and it works out of the box -- no API keys, no local node required. It connects to the free Satoshi API by default.

Step 2: Start bitcoin-mcp

bitcoin-mcp --transport sse --port 8000

This starts an MCP server on port 8000 using Server-Sent Events transport. Leave this terminal running.

Step 3: Get agentgateway

Download the binary from the agentgateway releases page for your platform.

Step 4: Create the Config

Save this as config-sse.yaml:

binds:
- port: 3000
  listeners:
  - routes:
    - policies:
        cors:
          allowOrigins: ["*"]
          allowHeaders: ["*"]
          exposeHeaders: ["Mcp-Session-Id"]
      backends:
      - mcp:
          targets:
          - name: bitcoin-mcp
            sse:
              url: http://localhost:8000/sse

This tells agentgateway to listen on port 3000 and forward everything to bitcoin-mcp.

Step 5: Start agentgateway

./agentgateway -f config-sse.yaml

Step 6: Connect

Open MCP Inspector:

npx @modelcontextprotocol/inspector

Set the transport to Streamable HTTP, enter http://localhost:3000, and click Connect.

Go to the Tools tab. You'll see 49 tools. Click get_situation_summary and hit Call.

The "Aha" Moment

When I called get_situation_summary for the first time, I got back a wall of structured data: block height, hashrate, difficulty adjustment progress, mempool size, fee tiers, mining pool distribution. Real data. Live from the Bitcoin network.

I didn't write any Bitcoin code. I didn't parse any APIs. I didn't handle any authentication. I installed an MCP server, pointed a proxy at it, and connected.

That's when MCP clicked for me. The AI doesn't need to know how Bitcoin works. It just needs to know which tool to call. The MCP server handles everything else.

I tried more tools. get_fee_estimates told me exactly what fee to use for a transaction right now. analyze_mempool showed me the current congestion. get_mining_info gave me hashrate and difficulty data. Each one returned structured, accurate, real-time data.

Then I connected it to Claude Desktop (just a one-line config change) and asked in natural language: "What's the current state of the Bitcoin mempool?" Claude called the right tools automatically and gave me a clear, conversational summary backed by live data.

What I Learned

MCP is simpler than I expected. I kept looking for the catch -- the complex authentication step, the mandatory configuration file with 200 options, the thing that would take an hour to debug. It wasn't there. The protocol is genuinely simple.

agentgateway solves real problems. Without it, you'd need every AI client to support every MCP transport. With it, you expose one HTTP endpoint and route to any backend. It's the missing piece between "I have an MCP server" and "any client can use it."

The tool ecosystem is the killer feature. bitcoin-mcp alone has 49 tools. Imagine stacking multiple MCP servers -- weather, databases, APIs, Bitcoin -- all accessible through one gateway. That's where this gets powerful.

Separation of concerns matters. The AI model picks which tools to call. The MCP server implements the tools. The gateway handles routing and security. Each piece does one thing well.

What's Next

This starter example runs everything locally with no authentication. For production, you'd want:

Authentication -- agentgateway supports JWT validation and API keys
Rate limiting -- prevent abuse
Audit logging -- track what tools are being called and by whom

I'm also looking into publishing bitcoin-mcp to an MCP registry so anyone can discover and use it without knowing the GitHub URL.

Try It Yourself

The full code is in the hackathon repo. Clone it, follow the README, and you'll have a working Bitcoin AI agent in 10 minutes.

If you've been curious about MCP but haven't tried it yet -- this is your on-ramp. The barrier is genuinely low, and the payoff is seeing an AI agent answer questions with real-time data for the first time.

Built with bitcoin-mcp, agentgateway, and an unreasonable enthusiasm for Bitcoin tooling.

Securing AI Access to Financial Data: How We Govern Bitcoin MCP with agentgateway

Andrew Barnes — Thu, 26 Mar 2026 23:59:33 +0000

Securing AI Access to Financial Data: How We Govern Bitcoin MCP with agentgateway

What happens when an AI agent has a tool called send_raw_transaction?

That's not a hypothetical. bitcoin-mcp is a Model Context Protocol server that gives AI agents access to 49 tools for querying the Bitcoin network -- block analysis, fee estimation, mempool inspection, address lookups, transaction decoding, and yes, broadcasting signed transactions to the network.

For a data analyst building a dashboard, these tools are a goldmine. For a production deployment without guardrails, they're an open door.

We built Bitcoin Gateway Guard to close that door and hand out keys only to the people who should have them.

The Threat Model

AI agents are not users. They don't have judgment. They do exactly what their prompt says, and prompts can be injected, manipulated, or just poorly written. Consider what goes wrong when an AI agent has unrestricted access to Bitcoin tools:

Accidental broadcast. A developer testing transaction construction accidentally calls send_raw_transaction instead of decode_raw_transaction. The transaction is irreversible.

Prompt injection. A malicious input tricks the agent into calling generate_keypair, and the private key appears in a response that gets logged, cached, or displayed in a UI.

Runaway loops. A bug in the agent's reasoning causes it to hammer the Bitcoin node with thousands of requests per minute, degrading service for everyone.

Shadow access. Six months later, nobody can tell you which agents accessed what data, when, or why. Your compliance team is not happy.

These are not exotic attacks. They are the predictable consequences of deploying AI agents on financial infrastructure without the same controls you'd apply to human users.

Four Layers of Defense

Bitcoin Gateway Guard places agentgateway -- an open-source MCP security gateway built in Rust -- between AI agents and bitcoin-mcp. Every request passes through four independent security layers.

Layer 1: JWT Authentication

No anonymous access. Every request must carry a valid JWT signed with RS256. The gateway validates the signature, issuer (bitcoin-gateway-guard), audience (bitcoin-mcp), and expiration before the request touches any downstream logic.

No token? HTTP 401. Expired token? HTTP 401. Wrong issuer? HTTP 401.

Layer 2: Role-Based Access Control

We define two roles using CEL (Common Expression Language) expressions:

jwt.role == "admin"
jwt.role == "reader" && mcp.tool.name != "send_raw_transaction" && mcp.tool.name != "generate_keypair"

The reader role gets access to 47 read-only tools -- everything you need for dashboards, analytics, research, and monitoring. The two tools that can modify state or create sensitive material -- send_raw_transaction and generate_keypair -- are reserved for admin.

This is a single line of policy. No code. No middleware. No if-else chains buried in application logic. The policy is auditable, declarative, and lives in a YAML config file that can be version-controlled and reviewed.

Layer 3: Rate Limiting

A token bucket algorithm caps every consumer at 10 requests per minute with burst capacity of 10. This is deliberately conservative. A legitimate dashboard refresh needs one request every few seconds. An agent stuck in a loop will hit the limit in under a second.

localRateLimit:
  - maxTokens: 10
    tokensPerFill: 1
    fillInterval: 60s

Rate limiting is the safety net that catches everything else. Even if authentication and authorization both pass, a runaway agent cannot overload your Bitcoin node.

Layer 4: Audit Trail

Every tool invocation generates an OpenTelemetry span exported to Jaeger. Each span records the tool name, the JWT subject (who), the JWT role, the authorization decision (allowed or denied), the HTTP status, and the latency.

Open Jaeger at localhost:16686, select the agentgateway service, and you have a complete, searchable, time-ordered record of every AI agent interaction with your Bitcoin data. Feed it into your SIEM, set up PagerDuty alerts on denied requests, run weekly access reviews.

The Demo

Setup takes two commands:

python scripts/generate_keys.py   # Generate RSA keys + JWT tokens
docker compose up -d               # Start bitcoin-mcp + agentgateway + Jaeger

Then test the security model:

# Reader queries block height -- works fine
python scripts/test_rbac.py --user reader --tool get_block_count
# Result: ALLOWED

# Reader tries to broadcast a transaction -- blocked
python scripts/test_rbac.py --user reader --tool send_raw_transaction
# Result: DENIED (authorization)

# Burst 15 requests -- rate limited after 10
python scripts/test_rbac.py --user reader --tool get_fee_estimates --burst 15
# Summary: 10 allowed, 5 rate-limited

Every one of these interactions shows up in Jaeger with full context. The denied requests are flagged. The rate-limited requests are logged. Nothing is invisible.

Why agentgateway?

We evaluated building custom middleware, wrapping bitcoin-mcp with authentication logic, and using a general-purpose API gateway. agentgateway won because it understands MCP natively.

A generic API gateway can rate-limit HTTP requests and validate JWTs. But it cannot inspect MCP tool names, apply per-tool authorization rules, or trace MCP-specific context. agentgateway speaks the protocol. Its CEL-based authorization rules reference mcp.tool.name directly. No regex on request bodies. No custom plugins. No fragile parsing.

The configuration is 40 lines of YAML. The entire security policy -- authentication, authorization, rate limiting, and tracing -- is declared in a single file that a security engineer can review in five minutes.

Why This Matters

The AI industry is moving fast toward giving agents access to real-world systems. Financial data. Infrastructure controls. Business operations. The tools are getting more powerful. The guardrails are not keeping up.

MCP is becoming the standard protocol for AI agent tool access. But MCP itself has no built-in security model. There's no authentication, no authorization, no rate limiting, and no audit trail in the protocol specification. That's by design -- MCP is a transport protocol, not a security framework.

The security has to come from the deployment layer. And it has to be as easy to configure as the tools themselves, or teams will skip it.

Bitcoin Gateway Guard demonstrates that you can add enterprise-grade security to any MCP server -- not just bitcoin-mcp -- with a single configuration file and zero code changes to the underlying server. The same pattern applies to database MCP servers, cloud infrastructure tools, payment APIs, or anything else you'd hesitate to give an AI agent unrestricted access to.

The question is not whether AI agents should have access to financial tools. They should -- the productivity gains are real. The question is whether that access is governed with the same rigor we apply to human users.

With agentgateway, the answer is yes. And you can prove it to your auditors.

Bitcoin Gateway Guard is open source. The full configuration, Docker setup, and test scripts are available at github.com/Bortlesboat/bitcoin-gateway-guard. Built with bitcoin-mcp and agentgateway for the MCP & AI Agents Hackathon -- Secure & Govern MCP category.

From PyPI to Production: Publishing bitcoin-mcp to agentregistry

Andrew Barnes — Thu, 26 Mar 2026 23:59:26 +0000

From PyPI to Production: Publishing bitcoin-mcp to agentregistry

How we turned a 49-tool Bitcoin MCP server into a one-command deployment for any AI agent.

The MCP Server Discovery Problem

The Model Context Protocol ecosystem is exploding. There are over 100 MCP servers on PyPI and npm right now, covering everything from GitHub to Slack to databases. But here is the uncomfortable truth: finding and deploying them is still painful.

The typical workflow looks like this:

Google "bitcoin mcp server"
Find a GitHub repo (maybe)
Read the README to figure out installation
Determine the transport type (stdio? SSE? streamable HTTP?)
Manually edit your IDE's MCP configuration file
Restart your IDE and pray it connects

This is 2026. We send agents to browse the web and write code. We should not need 10 minutes of manual config to add a tool.

Enter agentregistry

agentregistry solves this by creating a centralized, searchable registry for MCP servers, skills, and agent blueprints. Think of it as npm for AI agents — you search, you install, you go.

We decided to register bitcoin-mcp as the first Bitcoin-focused entry. Here is how that went.

The Registration Process

What We Had

bitcoin-mcp is a production MCP server for Bitcoin network analysis:

49 tools for mempool analysis, fee estimation, block inspection, transaction decoding, mining insights, and market data
116 tests with full CI coverage
Zero configuration — it auto-detects a local Bitcoin Core node or falls back to the free Satoshi API
Already published on PyPI as bitcoin-mcp

The server was ready. What it lacked was discoverability.

What We Built

Three pieces make up the agentregistry submission:

1. Server Registration

The straightforward part. We registered bitcoin-mcp as a PyPI-sourced server with stdio transport:

arctl register server \
    --name bitcoin-mcp \
    --source pypi \
    --package bitcoin-mcp \
    --transport stdio \
    --command bitcoin-mcp

Now arctl search bitcoin finds it. arctl install bitcoin-mcp installs it. Done.

2. The Bitcoin Skill

This is where it gets interesting. MCP servers give agents tools. But tools without context are like giving someone a stethoscope without medical school. They can press buttons, but they do not know what the results mean.

We created a Bitcoin Intelligence Skill — a structured knowledge document (SKILL.md) that teaches the agent:

When to use get_fee_estimates vs estimate_smart_fee vs get_fee_recommendation
How to interpret mempool congestion (50 MB = congested, 100 MB = severely congested)
Confirmation thresholds based on transaction value ($1K = 1 conf, $100K = 6+ conf)
How to read mining pool rankings and difficulty adjustments
Correlation patterns between on-chain data and market movements

The skill turns a generic tool-caller into a Bitcoin analyst.

3. The Agent Blueprint

The agent.yaml ties everything together into a single deployable unit:

name: bitcoin-intelligence
skills:
  - bitcoin-skill
servers:
  - name: bitcoin-mcp
    source: pypi
    package: bitcoin-mcp

One command deploys the complete package: arctl deploy bitcoin-intelligence.

The Demo

Here is what one-command deployment looks like in practice:

$ arctl deploy bitcoin-intelligence
Installing bitcoin-mcp from PyPI... done
Loading bitcoin-skill... done
Configuring IDE... done

Bitcoin Intelligence agent is ready.

Then, in your AI assistant:

You: "Should I send this Bitcoin transaction now or wait?"

Agent: checks mempool (42MB, moderate congestion), gets fee estimates (12 sat/vB for next block), looks at recent block intervals (9.2 min average — slightly fast)

"The mempool is moderately congested at 42MB. Current next-block fee is 12 sat/vB (~$2.40 for a typical transaction). Blocks are coming slightly faster than average, so the mempool should clear over the next hour. If you can wait 30-60 minutes, you will likely see fees drop to 6-8 sat/vB. If it is urgent, 12 sat/vB will get you into the next block."

That response required three different tools, domain knowledge about fee interpretation, and an understanding of how block timing affects mempool dynamics. The skill makes this possible.

What We Learned

Skills are the missing layer. Everyone talks about MCP tools, but domain knowledge is what separates a useful agent from a button-masher. The skill concept in agentregistry is underexplored and powerful.

Zero-config matters for registries. bitcoin-mcp works without any API keys or node setup because it falls back to a hosted API. This is critical for registry deployments — if arctl install requires a 10-step configuration guide, you have lost the whole point.

Agent blueprints enable composition. The agent.yaml format lets you bundle servers and skills into opinionated packages. Imagine a "DeFi analyst" blueprint that combines bitcoin-mcp, an Ethereum MCP server, and a cross-chain skill. Registries make this composable.

Try It Yourself

pip install arctl
arctl search bitcoin
arctl deploy bitcoin-intelligence

Three commands. Zero to Bitcoin intelligence.

The full source is at github.com/Bortlesboat/hackathon-mcp.

Built for the MCP Hackathon — Explore Agent Registry category.
bitcoin-mcp: PyPI | GitHub
agentregistry: agentregistry.dev

I Built a REST API for Bitcoin Core - Here's what I Learned

Andrew Barnes — Sat, 07 Mar 2026 15:46:43 +0000

I run a Bitcoin full node. When I started building apps against it, I hit the same wall everyone hits: Bitcoin Core's JSON-RPC is designed for node operators, not application developers.

The RPC works. It's stable, well-documented, and battle-tested. But if you've ever tried to build a product on top of it, you know the pain points. So I spent a few months wrapping it in a proper REST API, and I learned some things worth sharing.

The Problem Nobody Talks About

Bitcoin Core's RPC returns fees in BTC/kVB. Every application developer on earth thinks in sat/vB. That's a multiplication, a unit conversion, and a mental model mismatch — on every single call.

estimatesmartfee returns one estimate per call. Want fee recommendations for 1, 3, 6, and 144 blocks? That's four RPC round-trips, four response parses, and you still have to write the logic to tell your user "fees are moderate right now, you can wait."

getmempoolinfo gives you transaction count and total size. Useful, but what developers actually need is: "How congested is the mempool? What fee rate gets me into the next block? What does the fee distribution look like?"

Raw RPC is a power tool. Most apps need a product.

What I Built

Satoshi API is a thin REST layer over Bitcoin Core. pip install, point at your node, get 40 clean endpoints with analyzed data.

pip install bitcoin-api
export BITCOIN_RPC_USER=your_user
export BITCOIN_RPC_PASSWORD=your_password
bitcoin-api  # http://localhost:9332/docs

That's the entire setup. Here's what the fee endpoint looks like versus calling estimatesmartfee five times yourself:

curl https://bitcoinsapi.com/api/v1/fees/recommended

{
  "data": {
    "recommendation": "Fees are moderate. For next-block confirmation use 25 sat/vB. If you can wait 1 hour, 12 sat/vB should suffice.",
    "estimates": {
      "1": 25.0,
      "3": 18.0,
      "6": 12.0,
      "25": 8.0,
      "144": 5.0
    }
  },
  "meta": {
    "timestamp": "2026-03-05T12:00:00+00:00",
    "node_height": 939462,
    "chain": "main"
  }
}

One call. Human-readable recommendation. All targets. Units already in sat/vB. The meta envelope tells you exactly which chain and height this came from.

But the interesting part isn't the API itself — it's the design decisions I had to make along the way.

Lesson 1: Analyzed Data > Raw Data

The biggest ROI came from adding an analysis layer between the RPC and the REST response. Bitcoin Core gives you primitives. Apps need derived insights.

The mempool endpoint is a good example. Raw getmempoolinfo tells you there are 14,832 transactions using 7.5 MB. The analyzed endpoint tells you the mempool is at "medium" congestion, the minimum fee to make the next block is 8.2 sat/vB, and breaks down the fee distribution into buckets so you can visualize where your transaction would land.

The transaction analysis endpoint detects SegWit, Taproot, and inscriptions automatically. Block analysis includes weight utilization percentage and a SegWit adoption ratio. None of this is hard to compute, but doing it once in the API layer saves every downstream consumer from reimplementing it.

If you're wrapping any RPC-style backend in a REST API, consider what your consumers actually want to know, not just what the backend returns.

Lesson 2: Not All Blocks Are Created Equal

This one bit me early. I added caching (obviously — you don't want to re-fetch block 500,000 every time someone asks for it). But blocks near the chain tip can be orphaned by a reorg. Cache a tip block for an hour and you might serve stale data after a reorg.

The solution is depth-aware caching with two separate stores:

Deep blocks (6+ confirmations): 1-hour TTL. These are effectively immutable.
Tip blocks (< 6 confirmations): 30-second TTL. Short enough to catch reorgs.
Mutable data (fees, mempool): 5-10 second TTL. Always near-fresh.

When a block request comes in, the cache checks tip_height - block_height to decide which store to use. Block 100,000 gets cached once and served for an hour. The latest block gets re-validated every 30 seconds. Fees refresh every 10 seconds.

This pattern applies to any blockchain API. If you're caching chain data, you need to think about finality depth, not just time.

Lesson 3: Rate Limit Your Own Node

This sounds counterintuitive — why would you rate limit yourself? Because Bitcoin Core's RPC server is single-threaded. Flood it with concurrent requests from multiple apps and you'll block your own wallet operations.

Satoshi API has four tiers (Anonymous at 30/min, Free at 100/min, Pro at 500/min, Enterprise at 2,000/min) with per-minute sliding windows in memory and daily limits backed by SQLite so they survive restarts. Even if you're the only user, the rate limiter prevents any single runaway script from starving your node.

The per-minute window is in-memory for speed. Daily counters persist in SQLite (WAL mode, so reads don't block writes). Every response includes X-RateLimit-Remaining headers so clients can self-throttle.

Lesson 4: Response Envelopes Save Everyone's Time

Every successful response returns { data, meta }. Every error returns { error: { status, title, detail, request_id } }. No exceptions.

This seems trivial, but it eliminates an entire category of client-side bugs. You never have to guess whether the response is the data directly or wrapped in an object. You never parse a 200 response that's actually an error message. The request_id (UUID on every response via header and body) makes debugging trivial — "this request failed" becomes "request 550e8400-... returned 404 with detail 'Transaction not found'."

If you're building any API from scratch in 2026, standardize your envelope on day one. Retrofitting it later is painful.

The AI Agent Angle

This is the part I'm most excited about. The third layer of the stack is bitcoin-mcp, a Model Context Protocol server that lets AI agents query your node directly.

Add this to your Claude Desktop config:

{
  "mcpServers": {
    "bitcoin": {
      "command": "uvx",
      "args": ["bitcoin-mcp"],
      "env": {
        "BITCOIN_API_URL": "http://localhost:9332"
      }
    }
  }
}

Now you can ask Claude: "What's the current mempool congestion?" or "Analyze the latest block" and it hits your node, gets structured JSON, and reasons over it. No third-party API. No privacy leakage.

As far as I know, no other Bitcoin API has native AI agent support. The pipeline is three clean layers: bitcoinlib-rpc (typed Python library) -> satoshi-api (REST) -> bitcoin-mcp (AI interface). Each layer has one job.

Self-Hosting Matters More Than You Think

When you use a hosted Bitcoin API, every address lookup, transaction query, and fee check is correlated with your IP. The API provider builds a profile of which addresses you care about. For a technology built on financial privacy, that's a significant tradeoff most developers don't think about.

Self-hosting Satoshi API means your queries never leave your network. Your node, your data, your privacy. The three-line setup makes this practical, not just aspirational.

There's also a free hosted tier if you want to prototype before running your own node — but for production, self-hosting is the point.

What's Next

The API currently covers blocks, transactions, mempool, fees, mining, and network info — everything Bitcoin Core exposes via RPC. The roadmap includes:

Address lookups via Electrs/Fulcrum integration
Prometheus metrics endpoint for node monitoring dashboards
Webhook notifications for new blocks and mempool events

Try It

Live API + docs playground: bitcoinsapi.com/docs
GitHub: github.com/Bortlesboat/bitcoin-api
PyPI: pypi.org/project/satoshi-api/
Comparison with other Bitcoin APIs: bitcoinsapi.com/best-bitcoin-api-for-developers

MIT licensed, 95 unit tests + 21 E2E tests, CI pipeline. If you run a node and want a clean API on top of it, I'd love feedback — open an issue or drop a comment below.