MCP: Exposed resources · rousseau-agent docs

Current status

Rousseau's MCP server (internal/mcp/server.go) declares Tools capability only. It returns an empty list on resources/list:

MethodResourcesList → okResponse(env.ID, map[string]any{"resources": []any{}})

The intent is deliberate. Every use case that would look like an MCP resource — a saved session, a cron job description — is exposed today through a tool (rousseau_read_session, rousseau_cron_list) so the host can request exactly the data it needs, when it needs it, rather than pre-listing every session.

Why not resources today

MCP resources shine when a host wants to enumerate a modest, well-defined set of URIs (files, pages) and dereference them lazily. Rousseau's session store can grow into thousands of rows; enumerating every session on every resources/list call would blow up the host's context. The tool surface (search / list / read) is a better shape for high-cardinality state.

Roadmap

Two candidates worth exposing as MCP resources, once the MCP spec supports paginated resource enumeration robustly:

Candidate: `rousseau://sessions/<id>`

Every rousseau session as a resource. URIs would look like:

rousseau://sessions/1a2b3c4d-…

Dereferencing would return the same transcript rousseau_read_session returns today. This would let the host attach a specific session to a conversation as a first-class citizen ("attach session 1a2b3c…", drag-and-drop), rather than requiring the model to remember to call the tool.

Gating: a resource list would need to be paginated. Recent versions of the MCP spec propose cursor-based pagination; once that lands and hosts implement it, this becomes viable.

Candidate: `rousseau://cron/<name>`

Every cron job as a resource. Read-only inspection of the prompt, schedule, delivery target, and last-run timestamp. Small list — probably safe to enumerate today, but not worth exposing separately from rousseau_cron_list until the sessions-as-resources shape is proven.

Prompts capability

Similarly not exposed today. MethodPromptsList returns {"prompts": []any{}} in internal/mcp/server.go dispatch. Rousseau does not have a curated prompt library to expose; the skills mechanism (internal/skills/skills.go) is the equivalent internal concept, and it is not currently surfaced over MCP.

If the skills roadmap converges on shareable prompts, exposing them as MCP prompts is the natural next step. See Skills.

How to work around the gap today

If your MCP host requires resources for a specific UI affordance (e.g. drag-and-drop of a session), the workaround is:

Ask the host to invoke rousseau_list_sessions at the start of the chat.
Copy the session id you want to reference.
Invoke rousseau_read_session with that id.

Not as ergonomic as native resource dereferencing, but functionally equivalent.

Requesting a resource surface

Not every operator needs resources over MCP. If your team does, the constructive path is to file an issue with:

The specific MCP host you're integrating with.
The user-facing action that would be nicer with resources.
Rough traffic expectations (how many sessions, how often).

MCP — the umbrella reference.
MCP: Exposed tools — what is exposed today.
MCP: Compatibility — tested clients.
Skills — the internal concept that may become MCP prompts.