nostrclaw
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NOSTRCLAW_RELAYS | No | Comma-separated relays the tools may use; the first is the default | wss://relay.hivescope.xyz |
| NOSTRCLAW_STATE_DIR | No | `audit.jsonl` | ~/.local/state/nostrclaw |
| NOSTRCLAW_CONFIG_DIR | No | `policy.json` and the saved signer session | ~/.config/nostrclaw |
| NOSTRCLAW_MAX_EVENTS | No | Most events any single call may fetch (1–2000) | 500 |
| NOSTRCLAW_TIMEOUT_MS | No | Per-request timeout (500–60000) | 8000 |
| NOSTRCLAW_ALLOW_PRIVATE | No | `1` allows localhost / private-network relays (development) | off |
| NOSTRCLAW_SIGNER_RELAYS | No | Relays used to talk to the signer | wss://relay.powr.build + the first relay |
| NOSTRCLAW_ENABLE_SIGNING | No | `1` enables the signing tools (see Publishing) | off |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| nostrclaw_statusA | Shows how this server is configured: which relays it may talk to, its limits, and that it is read-only (signing is not enabled). |
| relay_overviewA | First look at a relay: reachability and latency (HTTP and WebSocket), its NIP-11 information document (name, supported NIPs, limits, policies) and, when the relay publishes them, its public statistics (events stored, authors, connections, last-24h activity). |
| recent_eventsA | Fetches recent events from a relay, newest first, optionally filtered by kind, author and age. Content is cleaned (hidden characters removed) and truncated. Signatures are verified; events with a bad signature are dropped and counted. |
| count_eventsA | Counts the events matching a filter using NIP-45 COUNT, without downloading them. Reports clearly when the relay does not support COUNT. |
| activity_reportA | Analyses a sample of recent events: counts by kind, events per hour, most active authors, repeated text across keys, bursts from one key, share of authors with a single event, and a list of notable signals (possible spam or throw-away keys). The sample is the newest events in the window, up to sampleLimit. |
| author_reportA | Looks at one public key: its profile (kind 0), follow count, relay list, and its recent events on this relay with the same analysis as activity_report. "first/last" are the oldest/newest events this relay returned, not the age of the account. |
| account_triageA | Lists the authors seen in a recent window whose BEHAVIOUR looks like spam or abuse (the same text posted by other keys — near-copies included —, bursts, link-only posting), highest score first, with the reason for every point; missing profile / follow list / relay list on this relay adds to the score but never flags an author on its own. Authors with no behaviour signal are only counted ("quiet"). Established signs lower the score. It looks up the profile, follow list and relay list of the most suspicious candidates. A triage aid, not a verdict: absence of data on this relay does not mean the account is new elsewhere. |
| event_engagementA | For one event: the event itself and how much happened around it on this relay — replies, reactions, reposts and zaps (counted from the events that reference it, up to 500), with a breakdown of what the reactions are and how many different people reacted. |
| compare_relaysA | Compares several configured relays side by side: what each says about itself (NIP-11: software, supported NIPs, limits), how fast it answers, how busy it is (events per hour) and what kinds it holds, and — the useful part — PROPAGATION: it takes the recent events of one reference relay (default: the first configured, normally yours) and asks every other relay for those exact ids, so you see what share of them reached each one. Busy public relays return only their newest events, so samples are never compared directly. A relay that fails is reported and the others still compared; "0 events" comes with the reason the relay gave when it has one. |
| trust_scoreA | Scores how much the network vouches for keys, using what the configured relays hold about who follows whom: how many keys follow it, how many of those followers are themselves followed (established), how close it is to keys YOU trust (pass them as |
| review_interactionsA | For one note: who replied to it, reacted to it or reposted it on the configured relays, and for each distinct person a verdict — promotional-bot, automated, suspicious, unknown or established — that combines what the key DOES (above all what it says to OTHER people: the same text or links in its answers to strangers; also the same text again and again, links in most notes, bursts) with its web-of-trust score. Behaviour outweighs trust: a spam bot can be followed by other bots and still look "somewhat trusted". "automated" is a bot that publishes in bulk or periodically but does not push the same advert at strangers; "promotional-bot" does. Replies are examined first. A triage aid, not a verdict; give your own key in |
| event_locationsA | For up to 20 event ids: which of the configured relays hold each one. Shows the kind and age only, not the content. Useful to check whether a note spread to other relays, or whether a relay dropped something. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| audit_relay | A step-by-step review of a relay: health, configuration, activity and anything that looks like abuse. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Most tools have clearly distinct scopes: relay configuration/metadata, event fetching/counting, aggregate reports, single-entity analysis, and multi-relay comparison. Potential confusion remains between event_engagement and review_interactions, which both inspect interactions around one event/note, and between account_triage and trust_score, which both score keys from different evidence, but their descriptions differentiate them well.
All tool names use lower snake_case, which is consistent and readable. However the pattern mixes noun-first names such as activity_report and trust_score with verb-first names such as count_events and compare_relays, and nostrclaw_status carries a server prefix, so it is not a strict verb_noun convention.
12 tools is well within the ideal 3-15 range for a multi-purpose relay analysis server. Each tool appears to serve a distinct investigative function, including status, relay metadata, event retrieval/counting, aggregate reports, single-author/event/relay analysis, and trust/triage.
The surface covers the apparent read-only Nostr investigation domain comprehensively: configuration, relay metadata, event retrieval/counting, activity/author reports, triage, engagement, relay comparison, trust scoring, interaction review, and event location checks. Minor gaps include no dedicated single-event content retrieval by id and no standalone profile lookup beyond author_report.