Skip to main content
Glama

nope-mcp — Open Educational Resources search

Get Educational Resource

get_resource
Read-onlyIdempotent

Retrieve a single piece of content by naddr (preferred — pass a search_content result's naddr), d-tag identifier, or event ID. naddrs of ANY content type from search_content work (resources, articles, wikis, projects, measures, publications); non-resource kinds return the same shape as their search results. Bare identifier/eventId lookups (no naddr) always resolve the full educational-resource metadata (kind 30142), including creator/publisher and educational properties. get_resource is never license-filtered: a learning resource 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). Only accessLevel:"full" resources have indexed fulltext, snippets and passages — 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. openLicense is kept for compatibility (deprecated; use accessLevel). When presenting the resource, render a markdown link the user can open: prefer its sourcePage (the original source page); fall back to url (the edufeed viewer) only when sourcePage is absent.

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": "get_resource"
  }
}

Input Schema

NameRequiredDescriptionDefault
naddrNoNIP-19 naddr from a search result — the preferred handoff to fetch full metadata.
authorNoAuthor pubkey (hex) to disambiguate if multiple resources share the same identifier
relaysNoRestrict the lookup to specific relays — pass the relays a search found the result on. Only relays returned by list_relays (default or extra) are accepted, by full URL or short name (e.g. "oersi"). Default: the naddr's relay hints that list_relays knows, else the default relay set.
eventIdNoNostr event ID (hex) for direct lookup. Alternative to identifier.
languageNoPreferred language for labels (default: "de")de
identifierNoResource identifier (d-tag). Use this for stable lookups.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / relays / description
      Previous value: -"Restrict the lookup to specific relays — pass the relays a search found the result on. Only relays returned by list_relays (default or extra) are accepted, by full URL or short name (e.g. \"oersi\"). Default: the default relay set."New value: +"Restrict the lookup to specific relays — pass the relays a search found the result on. Only relays returned by list_relays (default or extra) are accepted, by full URL or short name (e.g. \"oersi\"). Default: the naddr's relay hints that list_relays knows, else the default relay set."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations cover the read-only/idempotent profile, but the description adds substantial behavior the agent could not infer: the tool is never license-filtered, how license and accessLevel are populated, that only accessLevel:'full' resources have fulltext/snippets, and that openLicense is deprecated. This is exactly the context annotations cannot carry.

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 addressing modes and the preferred path, then layers licensing and presentation rules. Dense but every clause carries operational meaning; the presentation/markdown-link guidance is useful yet slightly tangential to invocation and lengthens the block.

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, the description does much of the return-value work by naming license, accessLevel, creator/publisher and the fulltext limitation, plus how to present the result. It stops short of enumerating the full educational-properties shape, which is a minor gap for a metadata-heavy tool.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning on top: naddr accepts ANY content type from search_content, relays is constrained to known relays with a stated default resolution order, and eventId is framed as an alternative to identifier. Only `author` and `language` get no extra prose, keeping it from a 5.

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 ('Retrieve a single piece of content') and immediately enumerates the three addressing modes (naddr, d-tag identifier, event ID), which distinguishes it cleanly from search_content/search_resources siblings that return lists.

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 routes the agent: prefer the naddr handed off from a search_content result, fall back to identifier or eventId for bare lookups, and use `relays` only with relays a search or list_relays returned. It also tells the agent what to do when a non-resource content type comes back.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.