Skip to main content
Glama
rzazo24

nostrclaw

by rzazo24
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Activity report

activity_report
Read-onlyIdempotent

Analyze recent Nostr events to report counts by kind, hourly activity, active authors, posting bursts, repeated text, and possible spam signals.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoFilter by single-letter tags, e.g. {"e": ["<event id>"]} for events that reference an event, {"p": ["<pubkey>"]} for mentions, {"t": ["bitcoin"]} for hashtags. e and p take 64-hex values.
hoursNoTime window in hours (default 24).
kindsNoOnly these event kinds (e.g. [1] for notes, [7] reactions).
relayNoRelay URL (wss://…). It must be one of the configured relays; default: the first one. See nostrclaw_status.
relaysNoSeveral relays (each must be configured): the same question goes to all of them and the answers are merged without duplicates; the result says what each relay returned. Overrides `relay`.
sampleLimitNoMost events to analyse per relay (a relay may return fewer).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.14.0

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open world). The description adds genuinely non-obvious behavior: results are computed over a sample of the newest events, capped at sampleLimit, so counts are approximate rather than exhaustive, and it flags heuristic outputs like possible spam or throw-away keys. It does not note sampling error magnitude or the merge semantics across multiple relays.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded sentence with the verb first and the sampling caveat last; nothing is wasted. It is dense and would read better as a short list, but every clause carries real information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and six all-optional parameters, the description largely compensates by enumerating exactly what the report contains. Remaining gaps are minor: it does not explain how the multi-relay merge or default-relay selection affects the report, though the schema covers those mechanics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter (tags, hours, kinds, relay, relays, sampleLimit) is already documented in the schema. The description only echoes sampleLimit and the time window, adding no syntax or format detail beyond the schema, which matches the baseline for full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Analyses a sample of recent events') and enumerates seven concrete output metrics, which lets an agent place it as the aggregate-analytics tool rather than a raw lister. It does not name or contrast with the nearest sibling (author_report, count_events), so overlap on 'most active authors' has to be inferred.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the metric list tells the agent this is for a broad activity overview rather than a targeted query, but there is no explicit when-to-use, no when-not-to-use, and no pointer to alternatives like author_report or count_events.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools