nope-mcp — Open Educational Resources search

Search Educational Content (resources, articles, wikis, projects, measures, publications)

search_content

Read-onlyIdempotent

Topic search across ALL content types on the relay in one ranked call: educational resources (kind 30142), long-form articles/blogs (30023), wikis (30818), projects (30143), measures (30144), and NKBIP-01 publications (30040 indices + 30041 sections — scientific articles, books). Results are interleaved and ranked by semantic passage match, and each carries the matched passage ("snippet") when available — use it to answer the user, not just list links. Educational resources are returned only when openly licensed (CC0, Public Domain, CC BY, CC BY-SA); the other content types carry no license and are all included. This is the tool for DISCOVERY intent — the user wants materials to browse ("finde/suche/empfiehl Materialien zu X"): present the items. For QUESTION intent — the user wants an answer built from the content ("wie/warum/was hilft bei X?") — prefer search_passages, which returns quotable fulltext passages with citations; this tool then supplements the answer with browsable links. Each result carries eventAuthor (the Nostr signer who uploaded the event — often an aggregator) plus, for resources, creator/publisher (who actually made and published the resource); these can differ, so do not treat eventAuthor as the publisher. For full metadata (license, dates, complete entity lists) pass a result's naddr to get_resource. Publication facets ride inside the query string as NIP-50 field filters: append type:academic, doi:10.1234/abcd.5678, keywords:, or partOf:30143:: ("publications of a project") to the query — the relay resolves them server-side. When presenting results to the user, render each as a markdown link so they can open it directly — prefer sourcePage (the original external source page, present on most resources and on projects/measures/publications), then url, then naddr. For upcoming events on the same topic, follow up with search_calendar_events.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Max results (1-250, default 20).
`query`	No	Free-text topic (e.g., "Unaufmerksamkeit im Seminar"). Keep it to the TOPIC only — do not append actor/organization names ("… Lehreladen"): they dilute the semantic ranking and the actor's content drops out of the top results. To constrain by actor, resolve the name first (resolve_author → authors param here; or resolve_publisher → search_resources publisherName).
`since`	No	Created at or after this Unix timestamp.
`types`	No	Restrict to a subset of content types. Default: all of them.
`until`	No	Created at or before this Unix timestamp.
`relays`	No	Restrict the search to specific relays. Only relays returned by list_relays (default or extra) are accepted, by full URL or short name (e.g. "oersi", "sodix"). Default: the default relay set.
`authors`	No	Filter by author pubkeys (hex).
`language`	No	Label language (default "de").	de
`community`	No	Return content shared into this community (Communikey). Accepts a hex pubkey or npub. Resolve a community name to its pubkey with resolve_author. Combine with query to scope a topic to a community (e.g. "math resources shared with X").

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 3, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial context beyond them: license-gating behavior for resources, server-side NIP-50 filter resolution, semantic passage ranking with snippet attachment, and the eventAuthor-vs-publisher distinction with an explicit warning not to conflate them.

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?

Front-loaded with the core verb/resource and organized by concern (types, licensing, intent routing, fields, rendering). It is long and dense, but nearly every sentence carries operational information; a little tightening of the license and rendering guidance would help.

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

Completeness5/5

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

No output schema exists, so the description must cover return values, and it does: interleaved ranked results, snippet passages, eventAuthor/creator/publisher fields, and the sourcePage > url > naddr rendering preference. An agent has everything needed to call and present results.

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

Parameters5/5

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

Schema coverage is 100%, so 3 is the baseline, but the description adds meaning the schema does not carry: the query string can embed NIP-50 field filters (type:, doi:, keywords:, partOf:) resolved server-side, and it explains what the authors/community params reference (resolve_author output) and the actor-dilution pitfall for query.

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

Purpose5/5

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

States a specific verb and resource (topic search across all content types) and enumerates each type with its kind number (30142, 30023, 30818, 30143, 30144, 30040/30041). It is immediately distinguishable from search_resources, search_passages, and search_calendar_events.

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

Usage Guidelines5/5

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

Explicitly splits DISCOVERY intent (browse materials) from QUESTION intent (build an answer) and routes the latter to search_passages, with follow-up to search_calendar_events for events and resolve_author for actor-constrained searches. When-to-use and when-not-to-use are both stated.

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.