nope-mcp — Open Educational Resources search

Search Calendar Events

search_calendar_events

Read-onlyIdempotent

Search for NIP-52 calendar events (date-based and time-based). Supports temporal filters (start/end time ranges), geohash location filtering, and hashtag filtering. Returns events from the configured calendar relay. When presenting an event to the user, render it as a markdown link: prefer the event url (the edufeed-app viewer at /, which shows fuller details) over sourcePage (the original external event page). Never construct an naddr or viewer URL yourself — use the naddr/url fields as returned.

Input Schema

TableJSON Schema

Name	Required	Description
`kinds`	No	Event kinds to query (default: [31922, 31923]). 31922 = date-based, 31923 = time-based.
`limit`	No	Maximum number of results (1-250, default: 20)
`query`	No	Free-text topic for the events. Combines with a time range (startAfter/startBefore/endAfter/endBefore) in a single server-side query — e.g. "events about X in the next week" is one call. EXCEPTION: a geohash query forces the relay location index, which ignores this topic; for "events about X near a place" pass the geohash and filter the returned events by topic on the client.
`since`	No	Return events created at or after this Unix timestamp
`until`	No	Return events created at or before this Unix timestamp
`authors`	No	Filter by author pubkeys (hex format)
`geohash`	No	Geohash prefix for location-based search
`endAfter`	No	Only events ending after this Unix timestamp
`hashtags`	No	Filter by hashtags (e.g., ["meetup", "nostr"])
`community`	No	Return calendar events shared into this community (Communikey). Accepts a hex pubkey or npub; resolve a community name with resolve_author. Combines with a time range (startAfter/startBefore/endAfter/endBefore) in a single server-side query, so "events shared with X next week" is one call. EXCEPTION: a geohash query forces the relay location index, which ignores this community filter; for "shared with X near a place" pass the geohash and filter the returned events by community client-side.
`endBefore`	No	Only events ending before this Unix timestamp
`startAfter`	No	Only events starting after this Unix timestamp
`startBefore`	No	Only events starting before this Unix timestamp

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 3, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive and openWorld=false, so the safety profile is covered. The description adds real behavioral context beyond that: results come from 'the configured calendar relay' (a closed, specific data source), and it discloses output-field relationships (url vs sourcePage) plus a hard constraint that the agent must never synthesize an naddr or viewer URL itself.

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?

Capability statement is front-loaded in the first two sentences, and the rendering guidance follows. The rendering instructions are arguably tangential to invoking a search tool, but they encode a real correctness rule, so the length is mostly earned.

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 13 optional parameters, a 100%-covered schema, and no output schema, the description supplies what the schema cannot: the data source, the usable output link fields, and the anti-hallucination rule for constructing links. It would be more complete with explicit sibling routing, but it is sufficient for correct invocation.

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 one of the 13 parameters is already documented, including kinds defaults, timestamps, and the geohash-vs-query/community caveat. The description only restates the filter categories generically, adding no syntax or default information beyond the schema — the baseline 3 is appropriate.

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?

The description states a specific verb and resource ('Search for NIP-52 calendar events') and even splits the resource into its two subtypes (date-based 31922 / time-based 31923), which is enough to distinguish it from generic search_content or search_resources siblings. It stops short of naming or contrasting those siblings explicitly.

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?

It lists the supported filter dimensions (temporal, geohash, hashtag) but never states when to choose this tool over the sibling search/content tools, nor any prerequisite. The genuinely useful routing rule ('a geohash query forces the location index and ignores topic; filter client-side') lives in the schema's query/community params rather than in the description. Usage is implied rather than guided.

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

All nope-mcp — Open Educational Resources search tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.