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.
Summary
The MCP application profile has no component-author hook to expose custom content resources — arbitrary
resources/read-abletext/blobcontent 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/readreturnstextorblob; 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 liveapplication-profile instance,resources/listreturns only:harper://about,harper://openapi,harper://schema/{db}/{table}— server metadata; andhttp(s)://<host>/<path>— a descriptor for each exported Resource (returns{ uri, path, database, table, hint }, not content; the hint just points back to aget_*/search_*tool).There is no
resourcesequivalent ofstatic 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
readreturningtext/blobcontent — parallel to howmcpToolsopens the tool surface (e.g. a staticmcpResources/mcpResourceTemplates, or a registration API).Minor, related
Exported-Resource descriptors use the
http(s)://scheme, but the spec says usehttps://"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-backedanswer) could move from a hand-rolled JSON-RPC server onto the nativeapplicationprofile. The tool surface maps cleanly viamcpTools(incl. anonymous access); custom content resources are the one capability with no native path.