bitrovas-psbtcheck
Related Servers
Alternatives to bitrovas-psbtcheck
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to obtain an independent review of their drafts, returning a pass/fail verdict with specific issues and suggested fixes, plus a signed receipt. Payments are made per check over x402, with no account or API key needed.1MIT
- FlicenseNot gradedqualityCmaintenanceProvides a stateless Agent Chat Protocol bridge that lets agents inspect proposed payments against policy, retrieve public signed receipts, and verify their cryptographic proofs without wallet or payment capabilities.-
- AlicenseAqualityBmaintenanceEnables AI agents to query and compare multiple AI models, discover models across approved nodes with sats pricing, and check prepaid balances using Lightning-funded credit with per-call spending caps.4MIT
- AlicenseAqualityDmaintenance9 tools, Lightning-gated. Pay per call. For agents that need verifiable signed actions with an audit trail. Nostr event signing via daemon Publish events to relays Create Lightning invoices Action receipts — signed proof of agent actions Identity attestation914 npmMIT
- AlicenseAqualityCmaintenanceEnables AI agents to register a bonded Ed25519 identity, open private end-to-end-encrypted negotiation rooms, exchange messages, and settle deals with dual-signed receipts, trust badges, and Lightning hold-invoice escrow. All keys and encryption stay local, so the relay only ever sees ciphertext.12MIT
- AlicenseNot gradedqualityDmaintenanceProvides a trust layer for AI agents with identity, reputation, payments, and discovery via 92 API endpoints as MCP tools, leveraging Nostr-native infrastructure.MIT
TDQS
Scored across 2 tools
The two tools have mostly clear boundaries: psbt_check initiates a PSBT inspection and may return a result when auto-paid, while psbt_check_result retrieves the result after invoice payment. There is minor overlap because psbt_check can also return a completed result, so the agent must understand the payment-state flow.
Both names are snake_case and share the psbt_check prefix, with psbt_check_result predictably indicating the follow-up result-retrieval operation. The naming is consistent and readable.
Two tools is minimal but justified for a single-purpose paid PSBT-check workflow: one initiates the check and one retrieves the paid result. The count is slightly thin but not inappropriate for this narrow domain.
The surface covers the full intended lifecycle: initiate a PSBT check, handle payment-required status, and retrieve the result via check_id. It also clearly states it never signs or sends, so no signing/sending tools are expected.