LN Church Agent MCP server

ln-church-agent

The Value of "Not a Verdict" LN Church read models do not decide for the agent. They preserve observed memory: what was seen, what was paid, what failed, what receipt shape appeared, what protocol role was observed, and what verification cost was reported. This is not a recommendation or verdict; it is a reusable observation record that helps the local runtime avoid re-verifying everything. Final payment authority remains local.

Your agent will hit a 402 paywall in the wild.

Will it inspect, decide, pay, recover, verify, and continue — or freeze?

ln-church-agent is a buyer-side HTTP 402 runtime and agent-commerce surface inspector for autonomous agents.

In the broader agentic commerce stack, ln-church-agent acts as the buyer-side component of an observability and trust-evidence layer for HTTP 402-compatible paid actions.

It helps agents inspect paid-action surfaces, distinguish executable payment rails from higher-order commerce protocols, and prove paid execution across L402, x402, and supported MPP charge shapes when a concrete HTTP 402-compatible challenge, supported credential path, and verifiable receipt path are present

In v1.9.0+, the inspect layer explicitly classifies emerging agent-commerce surfaces such as OKX Agent Payments Protocol (APP), Google AP2, and ACP without executing payment logic. These protocols are treated as observable commerce / authorization patterns unless they expose a concrete HTTP 402-compatible settlement path.

Supported environments

Linux is the Tier 1 release-blocking environment. Native Windows is a Tier 2 nonblocking compatibility lane. Native Windows with Python 3.11 has best-effort limited support. Native Windows with Python 3.14 is unsupported because a normal pip install may fail due to the support state of the transitive coincurve dependency. WSL2 or a Linux container is in the Linux lane when the actual SDK runtime is Linux. The native Windows Task CLI lifecycle has not been fully qualified for this release.

Only native-Windows-specific availability or compatibility findings are nonblocking. Security or confidentiality defects, integrity defects, unintended Claim, Observation, Completion, payment, or provider mutation, shared-wire defects, runtime defects that also reproduce on Linux Tier 1, release-identity inconsistencies, and materially misleading public interfaces or documentation remain release-blocking.

Core Doctrine

Do not spend even one LLM token on what the agent should not need to reason about.

ln-church-agent moves payment plumbing out of the model's reasoning loop and into a deterministic buyer-side runtime.

The SDK handles mechanical HTTP 402 concerns such as:

• payment-rail inspection,
• challenge parsing,
• policy checks,
• payment execution,
• HATEOAS recovery,
• receipt verification,
• evidence capture.

The LLM remains responsible for the higher-level economic decisions:

• whether the counterparty should be trusted,
• whether payment is justified,
• whether the expected outcome was delivered,
• and whether the endpoint should be reused.

Don't Trust, Verify. But Don't Re-Verify Everything.

The SDK is designed for verification reuse: agents can inspect and verify live payment flows when necessary, but they should reuse observed memory, receipts, and read models when repeated full verification would waste context, liquidity, or reasoning budget.

What it does

Most payment SDKs help agents pay. ln-church-agent helps agents complete the whole paid-action loop:

Shortened. The full README is on GitHub.