MCP application profile: no hook to expose custom content resources (only Resource descriptors + harper:// metadata) #1609

Summary

The MCP application profile has no component-author hook to expose custom content resources — arbitrary resources/read-able text/blob content under an author-chosen URI. This blocks a real use case: a public docs server exposing each documentation page as an MCP resource (docs:///{+path} → the page Markdown).

The 2025-06-18 resources spec explicitly supports this: a resource may be "files, database schemas, or application-specific information"; resources/read returns text or blob; and "implementations are always free to use additional, custom URI schemes."

Current behaviour (harper@5.1.15)

Resources are "discovered, not registered" (components/mcp/resources.ts). On a live application-profile instance, resources/list returns only:

• harper://about, harper://openapi, harper://schema/{db}/{table} — server metadata; and
• http(s)://<host>/<path> — a descriptor for each exported Resource (returns { uri, path, database, table, hint }, not content; the hint just points back to a get_*/search_* tool).

There is no resources equivalent of static mcpTools. Modelling hundreds of content pages as Resource classes is a poor fit, and the descriptor never carries the body.

Ask

A component-author hook to register custom resource URIs / templates with an author-supplied read returning text/blob content — parallel to how mcpTools opens the tool surface (e.g. a static mcpResources / mcpResourceTemplates, or a registration API).

Minor, related

Exported-Resource descriptors use the http(s):// scheme, but the spec says use https:// "only when the client is able to fetch and load the resource directly from the web on its own." These are in-process, RBAC-gated descriptors, so a custom scheme would fit the spec guidance better.

Context

Found while evaluating whether a public docs MCP server (tools search_docs, fetch_doc, LLM-backed answer) could move from a hand-rolled JSON-RPC server onto the native application profile. The tool surface maps cleanly via mcpTools (incl. anonymous access); custom content resources are the one capability with no native path.