Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
NOSTRCLAW_RELAYSNoComma-separated relays the tools may use; the first is the defaultwss://relay.hivescope.xyz
NOSTRCLAW_STATE_DIRNo`audit.jsonl`~/.local/state/nostrclaw
NOSTRCLAW_CONFIG_DIRNo`policy.json` and the saved signer session~/.config/nostrclaw
NOSTRCLAW_MAX_EVENTSNoMost events any single call may fetch (1–2000)500
NOSTRCLAW_TIMEOUT_MSNoPer-request timeout (500–60000)8000
NOSTRCLAW_ALLOW_PRIVATENo`1` allows localhost / private-network relays (development)off
NOSTRCLAW_SIGNER_RELAYSNoRelays used to talk to the signerwss://relay.powr.build + the first relay
NOSTRCLAW_ENABLE_SIGNINGNo`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

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 trusted: a trusted key following it counts most), how many different keys interacted with it, and how long it has been seen. Give pubkeys, or leave them out to examine the NEW keys of a recent window (keys not seen on any relay before it). A web-of-trust aid, not a verdict or an identity check: keys can follow each other in rings, and "unknown" means nothing vouches for it here, not that it is bad.

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 trusted for a much better signal.

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

NameDescription
audit_relayA 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

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 12 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues