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

#opensource #mcp #bitcoin #agents

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.