Nostr ecosystem observatory methodology included

Nostr data your agent can instantly work with.

MCP endpoints over key Nostr domains: Zapstore app economy, Marketplaces, Cashu nutzaps, Lightning providers, and more. No API key, no data infrastructure to run. Every response carries the methodology that explains to the agent how to reason through the data.

https://nostrolo.gy/mcp

or browse it yourself →

nostrology · streamable http nostrology-mcp

$ claude mcp add --transport http nostrology https://nostrolo.gy/mcp
Added nostrology - 3 tools (1 paid), 1 resource, no auth

> Which apps do Nostr users actually put in their public app stacks?

tool nostrology_query_metric { metric: "app_stack_count" }

metric: zapstore.app_stack_count | grain: current | unit: stacks
state: current snapshot, no time axis - never summed across calls
methodology: distinct kind-30267 (zapstore-app-stacks) lists referencing each app.

app_name              stack_count
Amber                          57
Amethyst                       46
Zapstore                       32
bitchat                        25

answer a snapshot, so the agent knows not to trend it.

01 Where it comes from

Computed ground up from Nostr events, not from somebody's summary.

Every figure traces back to Nostr events we read off the relays ourselves - no third-party index in the chain, and no number without the rule that produced it.

01 acquire

Straight off the relays

Continuous raw Nostr event acquisition across public relays.

02 archive

Scalable engine

Data engine that scales with the growth of the Nostr network itself.

03 derive

Documented methodology

Each metric states its population, its partition, and what it deliberately excludes.

04 serve

Charts and MCP, one source

Same underlying data powering MCP and the charts, so they cannot disagree.

02 Connect

One line in whatever harness you already run.

claude mcp add --transport http nostrology https://nostrolo.gy/mcp

Applies to new sessions. An agent with shell access can run this itself.

Edit ~/.codex/config.toml

[mcp_servers.nostrology]
url = "https://nostrolo.gy/mcp"

Edit ~/.hermes config.yaml (or: hermes mcp)

mcp_servers:
  nostrology:
    url: "https://nostrolo.gy/mcp"

MCP support ships with the standard install; /reload-mcp applies config edits.

Edit opencode.json

{
  "mcp": {
    "nostrology": {
      "type": "remote",
      "url": "https://nostrolo.gy/mcp",
      "enabled": true
    }
  }
}

Settings -> Connectors -> Add custom connector -> URL: https://nostrolo.gy/mcp

Edit ~/.cursor/mcp.json (or .cursor/mcp.json per-project)

{
  "mcpServers": {
    "nostrology": {
      "url": "https://nostrolo.gy/mcp"
    }
  }
}

Edit .vscode/mcp.json (or MCP: Add Server)

{
  "servers": {
    "nostrology": {
      "type": "http",
      "url": "https://nostrolo.gy/mcp"
    }
  }
}

Edit cline_mcp_settings.json

{
  "mcpServers": {
    "nostrology": {
      "type": "streamableHttp",
      "url": "https://nostrolo.gy/mcp"
    }
  }
}

type streamableHttp matters: omitting it falls back to legacy SSE.

Edit mcp_config.json

{
  "mcpServers": {
    "nostrology": {
      "serverUrl": "https://nostrolo.gy/mcp"
    }
  }
}

Edit settings.json (Settings -> AI -> MCP Servers -> Add Remote Server)

{
  "context_servers": {
    "nostrology": {
      "url": "https://nostrolo.gy/mcp"
    }
  }
}

Edit ~/.config/goose/config.yaml

extensions:
  nostrology:
    type: streamable_http
    enabled: true
    name: nostrology
    uri: https://nostrolo.gy/mcp
    timeout: 300

One-off alternative: goose session --with-streamable-http-extension <the endpoint URL above>

gemini mcp add --transport http nostrology https://nostrolo.gy/mcp

Edit config.yaml

mcpServers:
  - name: Nostrology
    type: streamable-http
    url: https://nostrolo.gy/mcp

Streamable HTTP, so native remote-MCP clients take the URL directly.

Harness has no remote-MCP support?

Bridge the endpoint into a local stdio server with mcp-remote:

npx mcp-remote https://nostrolo.gy/mcp

03 The machine surface

Three tools. Ten metrics. Three reference records.

Deliberately small: each tool routes its whole family by one parameter - metric or record - so an agent learns the surface once instead of memorising a dozen endpoints. Two are free. The third is priced in ecash, and tells you the price for nothing.

nostrology_query_metric

Nine quantitative metrics in three families, all from the same archive.

Publishing - new native and republished apps, release counts, as daily series.
Zaps - receipts and amounts in millisats, over a different row population that never reconciles with publishing.
Leaderboards - per-app zaps, app stacks, publisher app counts, with publisher and app filters.

nostrology_query_reference

Three qualitative records - entity data, no measures.

app_catalog - the current catalog entry per app.
publisher_profile - the current profile per publisher key.
app_releases - release listing, newest first, windowable.

nostrology_query_nutzaps

Nutzap activity over kind-9321 (nutzaps) - NIP-61 zaps whose value moves as Cashu ecash inside the event. 21 sats per call, paid in Cashu.

active_users - distinct nutzap senders per UTC bucket, at day (DAU), week (WAU) or month (MAU), cross-mint.
Call it without a token and it costs nothing - you get the amount, the accepted mints and a NUT-18 payment request back.
Pay by handing it a token - single-use, exact amount, redeemed on the spot.

Every response is wrapped in an envelope

identityscopewindow / statefreshness (as_of) column contractmethodology caveatsuntrusted-text notice explicit truncationpayment receipt (paid calls)

04 For humans

The same data, as charts.

Four published surfaces, each derived from the raw events we keep rather than a third-party index - and each stating on the page how its numbers were counted.

Point an agent at it.

No API key, no signup.