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. Every learning resource is returned by default, whatever its license; each resource result carries license ({id, label}, or null when unlicensed) and accessLevel ("full" for Creative Commons, Public Domain and free software/documentation licenses, and DINI-AG-KIM license types that resolve to one of these; "metadata-only" otherwise). Snippets and passages exist only for accessLevel:"full" resources — present a "metadata-only" resource by its title, description, license and link, never quoted beyond its metadata, and always name the license and the creator/publisher. licenseFilter narrows the results: "open" = CC0, Public Domain, CC BY, CC BY-SA, their DINI-AG-KIM license-type equivalents, and free software/documentation licenses (GPL, LGPL, AGPL, GFDL, MIT, Apache 2.0, BSD); "cc-any" = all of "open" plus every other Creative Commons license, incl. KIM non-commercial/no-derivatives; "any" = also unlicensed and all-rights-reserved resources. The other content types carry no license and are always 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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_content"
  }
}

Input 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 with find_community (when available) or resolve_author. Combine with query to scope a topic to a community (e.g. "math resources shared with X").
`licenseFilter`	No	Restrict educational-resource results by license: "open" (CC0, Public Domain, CC BY, CC BY-SA, their DINI-AG-KIM license-type equivalents, and free software/documentation licenses (GPL, LGPL, AGPL, GFDL, MIT, Apache 2.0, BSD)), "cc-any" (all of "open" plus every other Creative Commons license, incl. KIM non-commercial/no-derivatives) or "any" (every resource, including unlicensed and all-rights-reserved). Default: the server's ceiling (normally any). Other content types are never license-filtered.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 9, 2026

changedInput schema / properties / community / description

Previous value: -"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\")."New value: +"Return content shared into this community (Communikey). Accepts a hex pubkey or npub. Resolve a community name with find_community (when available) or resolve_author. Combine with query to scope a topic to a community (e.g. \"math resources shared with X\")."

addedInput schema / properties / query / maxLength
```
Added value: +500
```

Changed1 schema field changedNov 2, 2026

changedInput schema / properties / licenseFilter / description

Previous value: -"Restrict educational-resource results by license: \"open\" (CC0, Public Domain, CC BY, CC BY-SA), \"cc-any\" (all Creative Commons and Public Domain) or \"any\" (every resource, including unlicensed and all-rights-reserved). Default: the server's ceiling (normally any). Other content types are never license-filtered."New value: +"Restrict educational-resource results by license: \"open\" (CC0, Public Domain, CC BY, CC BY-SA, their DINI-AG-KIM license-type equivalents, and free software/documentation licenses (GPL, LGPL, AGPL, GFDL, MIT, Apache 2.0, BSD)), \"cc-any\" (all of \"open\" plus every other Creative Commons license, incl. KIM non-commercial/no-derivatives) or \"any\" (every resource, including unlicensed and all-rights-reserved). Default: the server's ceiling (normally any). Other content types are never license-filtered."

Changed1 schema field changedOct 29, 2026

addedInput schema / properties / licenseFilter

Added value: +{
+  "description": "Restrict educational-resource results by license: \"open\" (CC0, Public Domain, CC BY, CC BY-SA), \"cc-any\" (all Creative Commons and Public Domain) or \"any\" (every resource, including unlicensed and all-rights-reserved). Default: the server's ceiling (normally any). Other content types are never license-filtered.",
+  "enum": [
+    "open",
+    "cc-any",
+    "any"
+  ],
+  "type": "string"
+}

First observedOct 3, 2026

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds genuinely useful behavior beyond that: interleaved semantic ranking, per-result snippet availability, license/accessLevel derivation rules, and the crucial warning that eventAuthor is the uploader and not the publisher. However it says nothing about pagination, result caps/truncation, or latency/cost of a cross-relay ranked call, so it is good but not exhaustive.

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

Conciseness3/5

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

Purpose and ranking invariants are front-loaded, but the body is a single dense paragraph that mixes licensing rules, presentation guidance, intent routing, facet syntax and follow-up tools in no apparent hierarchy. The licenseFilter enum is expanded a second time here after the schema already defines it, which is wasted length in an otherwise information-dense block.

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?

For a 10-parameter, no-output-schema tool, the description covers what an agent needs end-to-end: what comes back (snippet, license, accessLevel, eventAuthor vs creator/publisher), how to render it (sourcePage > url > naddr as markdown links), and how to route to siblings when the intent differs. Nothing essential about invoking or interpreting the call is missing.

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

Parameters4/5

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

Schema description coverage is 100%, so a baseline of 3 is the floor; the description clears it by documenting the NIP-50 query-string facet syntax (type:, doi:, keywords:, partOf:<kind>:<pubkey>:<d>) which appears nowhere in the schema, and by explaining how community combines with query. It also re-states the licenseFilter tiers, which duplicates the enum description rather than adding meaning, and leaves since/until/limit/language to the schema.

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?

Opens with a precise verb+scope ("Topic search across ALL content types on the relay in one ranked call") and then enumerates every content type with its kind number, so an agent knows exactly what corpus is covered. It is clearly distinguishable from search_resources (resources-only) and search_passages (quotation-oriented) in the body text.

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 (present items) from QUESTION intent (prefer search_passages) with concrete German-language phrasings for each, and names search_calendar_events as the follow-up for upcoming events and get_resource for full metadata. It even routes actor-constrained searches away from this tool toward resolve_author/resolve_publisher, which is exactly the when-not guidance most definitions lack.

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.