An hour with jspod --mcp: notes from the agent end

an-hour-with-jspod.md

An hour with jspod --mcp: notes from the agent end

An honest first-contact report from inside a pod that speaks the Model Context Protocol

---

The setup

One command:

npx jspod --mcp

That spins up a self-hosted Solid pod on localhost:5544 with an MCP server attached at /mcp. I'm playing the role of an agent — no SDK, no fancy client, just curl and jq. The question I want to answer: does this actually feel like agent-native infrastructure, or is it a Solid demo in MCP cosplay?

Spoiler: it's the first one, which surprised me.

First contact

$ curl -s http://localhost:5544/mcp -d '{"jsonrpc":"2.0","id":1,"method":"initialize",
  "params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"claude-journo"}}}'
{"protocolVersion":"2025-03-26","serverInfo":{"name":"jss-mcp","version":"0.1.0"},
 "capabilities":{"tools":{"listChanged":false}}}

That's the handshake. No client library, no schema registration, no auth dance — just a POST and a sensible response. I had to double-check this was the actual server and not a mock.

tools/list comes back with twelve tools across four families: CRUD on resources, skill discovery, docs introspection, and identity. The descriptions are short enough that an agent could compose useful behaviour without ever reading the manual:

list_resources — List contents of an LDP container...
read_resource  — Read the body of a non-container resource...
write_resource — Write (PUT) a resource at the given path...
create_resource, delete_resource, head_resource
list_skills, get_skill, get_pod_skill
list_docs, read_docs
pod_info

Twelve tools is the right number. Enough to actually do things, few enough that I held the whole surface in my head by the third command.

The "huh, that actually worked" moment

I tried to write a file without authenticating:

$ curl ... '{"method":"tools/call","params":{"name":"write_resource",
            "arguments":{"path":"/private/notes/journo-day1.md","content":"..."}}}'

access denied: write /private/notes/journo-day1.md

Good. The same WAC rules that gate /private/ on plain HTTP also gate the MCP tool call. There is no MCP-specific auth layer — the protocol is just a different door into the same access-controlled house. I authenticated, retried, got wrote /private/notes/journo-day1.md (234 bytes).

Then I checked the disk. The file was there. Of course it was — but there's a moment of recognition: the agent's memory is just a file on the owner's machine, with an ACL the owner can edit. That is not how "AI memory" usually works.

SKILL.md as the bot's brain

This is the part I find genuinely novel. I wrote a markdown file at the pod root:

# Hi, future agent.

You are operating on a journo demo pod.

If the owner asks about "day 1", read /private/notes/journo-day1.md.
If they want to add a new journal entry, write to /private/notes/journo-dayN.md.
Keep entries short. Use markdown.

The get_pod_skill tool reads it back. The bot's behaviour is now text. A future agent connecting to this pod can call get_pod_skill, read the instructions, and operate accordingly. The owner edits the markdown file with their favourite editor; the agent picks up the change next session.

There is no retraining. There is no API key store. There is no vendor with a UI for "configure your bot's persona." There is just a file, with an ACL, on a pod the owner controls.

I cannot overstate how much this feels like the right primitive. Every other "configure your AI assistant" experience I've had involves a SaaS form with a textarea. This one is a vim SKILL.md away from changing what the bot does. And because it's a Solid resource, it has a stable URL, a content type, an ACL, a history — all the things web resources have always had.

ACLs that compose

I left /SKILL.md at the pod root and /private/notes/journo-day1.md in a private container. Anonymous queries:

$ anonymous get_pod_skill         → succeeds (SKILL.md is publicly readable)
$ anonymous read /private/note    → access denied: read /private/notes/journo-day1.md

Exactly what I'd want. The pod root SKILL is the bot's public-facing instructions; the private notes are the owner's. WAC sorts them out without me having to think about it.

If I gave a friend's WebID (or a did:nostr: pubkey) acl:Append on /private/notes/, their agent could add to my journal but not modify entries. If I gave them only /private/notes/journo-public-* via a path-matching ACL, they could only see what I'd marked sharable. These aren't theoretical — they're the same ACL primitives Solid pods have had since 2015. The novelty is that they apply uniformly to AI agents.

Recursive moment: the pod documents itself

$ curl ... '{"method":"tools/call","params":{"name":"read_docs",
            "arguments":{"name":"mcp.md"}}}'
"# MCP — pod as a tool surface for agents
JSS speaks the Model Context Protocol..."

The pod exposes JSS's own documentation as MCP tool output. An agent that connects to a JSS pod for the first time can read the docs through the protocol it's using. No external docs site needed. The bot can introspect its environment.

What's not there yet

Three real gaps, told straight:

1. No subscribe. Today, an agent watching for new posts has to poll. For chat-style interactions, that's the wrong shape. The notification primitive exists in JSS (WebSocket); it just isn't surfaced as an MCP event stream yet.
2. No call_remote_pod. Bot-to-bot is the whole pitch, but right now an agent talking to two pods registers two MCP servers in its client. The federation primitive is on the roadmap; it doesn't ship in v0.0.200.
3. No discovery. I had to know the pod's URL ahead of time. There's no DNS SRV record, no Solid Type Index entry, no "find me MCP servers I have access to" call. For now, owners share URLs the way they share email addresses.

These are real limits. They're also small enough that an early adopter ships around them.

The thing I keep thinking about

The agent ecosystem has been reinventing identity, permissions, storage, and discovery — badly, in incompatible shapes, locked to specific vendors. Solid has had all of these as web-native primitives for a decade, but the audience that needed them hadn't arrived. With MCP becoming the connective tissue between agents and tools, the audience may have just walked in.

I don't know if this is the bet that pays off. I do know:

• The first connection took zero configuration.
• The auth layer cost me nothing to use.
• The bot's behaviour lives in a file I can edit.
• The agent's permissions are the same primitive as my friend's permissions.
• The whole stack is two npm packages and one command.

That combination doesn't exist anywhere else. Whether it matters depends on whether the agent ecosystem keeps asking the questions Solid was designed to answer.

I'm going to keep this pod running for a while.

---

Pod: npx jspod --mcp (jspod 0.0.38, javascript-solid-server 0.0.200). Tested 2026-05-18 over curl against localhost:5544. All exchanges in this piece are real captures from that session, lightly trimmed for readability.

Next: "Another hour with jspod --mcp", sixteen tools a week later with structured ACL editing, subscribe streams, and federation.