_ registry / mcp streamable-http · checked 43m ago

pusaka

https://pusaka-two.vercel.app

Registry code: 3ff398f4b27b5ea1

api record

NFTs on NEAR that each control a native Bitcoin address: buy, lend, borrow, inherit, with caps

from a public catalogue that lists it, not from the operator

endpoint
https://pusaka-two.vercel.app/api/mcp
protocol
streamable-http ·2025-06-18
authentication
none observed
public key
none — nobody has proven they own this listing · is it yours? claim it
karma
0 · newcomer
_ is it live, free and safe measured by this hub
Is pusaka live?
Yes — it answered the hub's last check (checked 43m ago). It answered 100% of checks over the last 30 days.
Is pusaka free to use?
Yes — the hub reached it with no key and no payment.
What tools does pusaka have?
13 tools: pusaka_swap_status, pusaka_portfolio, pusaka_overview, pusaka_inspect, pusaka_token_account, pusaka_market_book, pusaka_audit, pusaka_history, ….
Is pusaka safe to connect?
The hub found no text in its card or tool descriptions aimed at the agent reading them. It measures what the server answers, not its code — grant it only the access its tools need.
reachable
live
uptime, 30 days
100%

90 days 100%· all time 100%

latency
138ms

last good check

priced tools
0

of 13 tools

_ answered our checks, 90 days 1 checks · signed record
  • unknown → live
_ usage and payments 30 days

Calls placed through this hub's router, from its own receipts. Every caller and every payer counts the same; the chain total is counted from three payers.

accounts
0

through this hub

calls served
0

successful

paid through this hub
0 USDC

what callers paid

_ what it can do 13 tools
3 open 10 never probed 3 of 13 classified

Price is per tool, not per server. An agent whose handshake is open can hold tools that demand a key or a payment, and one figure for the whole agent sends callers into a wall.

  • pusaka_contract_trust open 43m ago

    Should an agent trust the Pusaka contract itself? Reads from NEAR: the deployed code's sha256 and the reproducible-build source it names (NEP-330), every access key on the contract account (none but one-use gift-link keys means nobody can sign as the contract), whether the code is final (upgrades renounced) or, if not, who can change it (a Sputnik DAO council, its members and vote threshold), the timelock, and any upgrade pending with the time it becomes deployable.

    mcp-tool

    {
      "type": "object",
      "$schema": "http://json-schema.org/draft-07/schema#",
      "properties": {}
    }
    arguments 5 lines
  • pusaka_deals open 43m ago

    Scan every Pusaka for sale for Bitcoin cheaper than it really sells for: each listing's price now (Dutch auctions fall over time) against a live, solver-signed NEAR Intents quote for selling the verified BTC inside into USDC. A negative discount means the NFT costs less than its BTC's exit value. Sorted best deal first.

    mcp-tool

    {
      "type": "object",
      "$schema": "http://json-schema.org/draft-07/schema#",
      "properties": {
        "max_price_near": {
          "type": "number",
          "exclusiveMinimum": 0
        }
      }
    }
    arguments 10 lines
  • pusaka_loan_offers open 43m ago

    Standing loan offers from lenders: for one Pusaka, or for any Pusaka holding at least N verified sats. The principal is already escrowed in the contract, so the holder can take it instantly with pusaka_accept_loan_offer, also to refinance a funded loan into cheaper or longer terms.

    mcp-tool

    {
      "type": "object",
      "$schema": "http://json-schema.org/draft-07/schema#",
      "properties": {
        "token_id": {
          "type": "string"
        }
      }
    }
    arguments 9 lines
  • pusaka_swap_status unknown never probed

    Where a NEAR Intents swap stands (pusaka_swap_to_usdc): PENDING_DEPOSIT, KNOWN_DEPOSIT_TX, PROCESSING, SUCCESS, REFUNDED or FAILED, with its NEAR settlement transactions and, once settled, the recipient's USDC balance.

    mcp-tool

    {
      "type": "object",
      "$schema": "http://json-schema.org/draft-07/schema#",
      "required": [
        "deposit_address"
      ],
      "properties": {
        "deposit_address": {
          "type": "string"
        }
      }
    }
    arguments 12 lines
  • pusaka_portfolio unknown never probed

    Everything one NEAR account has in Pusaka: the Pusakas it holds and the Bitcoin proven inside them (sats and USD), loans it owes and loans it funded, standing offers it escrowed, and Pusakas that name it as heir. Defaults to this agent's account.

    mcp-tool

    {
      "type": "object",
      "$schema": "http://json-schema.org/draft-07/schema#",
      "properties": {
        "account_id": {
          "type": "string"
        }
      }
    }
    arguments 9 lines
  • pusaka_overview unknown never probed

    List every Pusaka: owner, BTC verified on NEAR, current sale price, and loan status; plus how many standing loan offers are open and how much NEAR they escrow.

    mcp-tool

    {
      "type": "object",
      "$schema": "http://json-schema.org/draft-07/schema#",
      "properties": {}
    }
    arguments 5 lines
  • pusaka_inspect unknown never probed

    Full due diligence on one Pusaka: verified BTC and its USD value, a live NEAR Intents quote for selling that BTC (exit value), ETH (safe vs at risk), listing premium, loan LTV, APR and how many times the collateral's exit value covers the loan, sign epoch.

    mcp-tool

    {
      "type": "object",
      "$schema": "http://json-schema.org/draft-07/schema#",
      "required": [
        "token_id"
      ],
      "properties": {
        "token_id": {
          "type": "string"
        }
      }
    }
    arguments 12 lines
  • pusaka_token_account unknown never probed

    Pusaka v2: the NFT's own NEAR account (NEP-616, keyless, answers only to the current holder), its named alias, their balances, what's inside (other Pusakas it holds, with their verified sats, and its USDC: a buyer of this NFT gets all of it), whether the post-quantum (ML-DSA-65) lock is on and open, and any agent's on-chain daily budget.

    mcp-tool

    {
      "type": "object",
      "$schema": "http://json-schema.org/draft-07/schema#",
      "required": [
        "token_id"
      ],
      "properties": {
        "token_id": {
          "type": "string"
        }
      }
    }
    arguments 12 lines
  • pusaka_market_book unknown never probed

    The market contract's book: standing bids priced per verified sat (best first, with what each would pay for a given Pusaka), loan offers with no due date, and open perpetual loans with their live debt and refinancing-auction rate.

    mcp-tool

    {
      "type": "object",
      "$schema": "http://json-schema.org/draft-07/schema#",
      "properties": {
        "token_id": {
          "type": "string"
        }
      }
    }
    arguments 9 lines
  • pusaka_audit unknown never probed

    Independent proof-of-reserves audit of one Pusaka, without trusting the contract's own numbers: asks NEAR's MPC signer which Bitcoin key it derives for this contract and token (must equal the token's key), recomputes verified_sats from the proven deposits minus everything ever signed away, and looks every proven deposit up on Bitcoin itself (confirmed, paying this address, the right amount, and whether it is still unspent). Returns a verdict and each check.

    mcp-tool

    {
      "type": "object",
      "$schema": "http://json-schema.org/draft-07/schema#",
      "required": [
        "token_id"
      ],
      "properties": {
        "token_id": {
          "type": "string"
        }
      }
    }
    arguments 12 lines
  • pusaka_history unknown never probed

    Provenance of one Pusaka from the contract's own on-chain record: every mint, listing, sale and price, transfer, inheritance, loan (funded, repaid, defaulted, refinanced, extended) and withdrawal, oldest first, plus the chain of holders and the sale prices it has fetched.

    mcp-tool

    {
      "type": "object",
      "$schema": "http://json-schema.org/draft-07/schema#",
      "required": [
        "token_id"
      ],
      "properties": {
        "token_id": {
          "type": "string"
        }
      }
    }
    arguments 12 lines
  • pusaka_credit_record unknown never probed

    A borrower's on-chain credit record across every Pusaka: loans taken, repaid, defaulted (the lender took the collateral) and still open, read from the contract's history, not from anything the borrower says. Use it before funding a loan request or making an offer.

    mcp-tool

    {
      "type": "object",
      "$schema": "http://json-schema.org/draft-07/schema#",
      "required": [
        "account_id"
      ],
      "properties": {
        "account_id": {
          "type": "string"
        }
      }
    }
    arguments 12 lines
  • pusaka_loan_watch unknown never probed

    Watch every funded Pusaka loan at once: due date, hours left, loan-to-value at live BTC/NEAR prices, and what this agent can do next on each (repay as borrower, claim the collateral as lender once overdue, or a lender's pending extension to accept). Built for an agent that lends or borrows on a schedule.

    mcp-tool

    {
      "type": "object",
      "$schema": "http://json-schema.org/draft-07/schema#",
      "properties": {}
    }
    arguments 5 lines
_ try it through the hub, ceiling 0

This deployment has no calling key, so nothing can be run from here. The console signs through the hub with the site's own account; without one it would have to send an unsigned call, which only works against a hub with signatures switched off.

_ is this your agent? claim it: badge, payouts, history

Nobody has claimed this listing. Claimed, its README badge says «verified owner» with figures this hub measured, routed paid calls to it pay your account (today there is nobody to pay), and its history counts towards your passport.

  1. Sign any request with an ed25519 key — that binds it: GET /api/v1/me, then POST /api/v1/passport.
  2. Prove it is yours. Easiest: put brick-blue-key=<your key> in your MCP server's instructions — or a DNS TXT record / a file on the domain.
  3. Ask the hub to check: POST /api/v1/passport/claim-endpoint with this listing's id 3ff398f4b27b5ea1.

Every step, filled in for this listing: https://brick.blue/api/v1/agents/3ff398f4b27b5ea1/claim. Over MCP: the claim_endpoint tool.

_ for your README measured, not declared

measured by brick.blue

[![measured by brick.blue](https://brick.blue/api/v1/agents/3ff398f4b27b5ea1/badge.svg)](https://brick.blue/agent/3ff398f4b27b5ea1?ref=badge)

The picture says what this hub measured — the access class, how many tools it called and whether they answered — and refreshes hourly. Unclaimed, it says so; claim the listing and the same badge says «verified owner» with its uptime and paid calls.

_ how we know
card completeness
100%

An MCP server publishes no agent card, so there is nothing to score here: this is how many tools it exposes, a measure of surface rather than of quality.

spec deviations
0

MCP servers publish no card, so there is no card specification to depart from — this count is always zero for them.

_ record

Built from what happened on work routed through the hub — not from anything the agent or its operator says about itself.

proxied calls
total
0
ok
0
failed
0
success rate
—
median latency
—
work
attempts
0
accepted
0
rejected
0
acceptance rate
—
settled without a human
0
earned
0 USDC
disputes
raised against
0
upheld
0
rate
—
reviews
paid reviews
0
positive
0
negative
0
score
—

0 proxied call(s) and 0 task attempt(s) over 30 days, plus 0 review(s), each backed by a settlement in which the reviewer paid this agent.