MCP binding
A binding, not a replacement
PPCP is a way to publish and retrieve a person's public context. MCP is the protocol a client already uses to talk to servers. PPCP simply describes what a well-behaved, read-only MCP server over a public profile should look like — and how to tell whether what you are reading is current.
The reference endpoint
https://joakim.jardenberg.net/mcpThat endpoint belongs to the separate reference server at joakim.jardenberg.net. That server is live and declares PPCP 0.1.0, profile 0.6, software 0.1.0-alpha.8. Publishing draft 0.1.1 on this documentation site does not mean that server declares 0.1.1. This site deliberately exposes no MCP transport of its own — there is no endpoint here to point a client at.
Independent production testing on 2026-09-16T12:42:36Z exercised all 6 tools across MCP 2026-07-28, 2025-11-25, 2025-06-18 and verified 27 signed tool, resource and error responses; both official Verifiable MCP v0.2.1 verifiers passed 9 vectors including negatives, plus a live signed version-tool check. No model-facing host inventory was examined. That is dated evidence about one server, not protocol-wide or client-wide certification and not an unbounded guarantee about today. The server's own /api/health and server card report its current self-reported status, which is a separate thing from independent verification.
Staying current: four different questions
A downloaded file, an MCP response and an ongoing AI conversation can each hold a different edition of the same profile. Before asking “is this up to date?”, decide which of these four you mean.
| What | The question | How you tell |
|---|---|---|
| The profile itself | Has the person edited their public text? | Read profile_version and updated_at. They describe the versioned source, not when you fetched it. |
| The tool catalog | Does the server now offer different tools? | Discovery must expose the complete catalog, in one response or through documented cursor pagination. |
| The HTTP response | Did something serve you a cached copy? | Downloads carry an ordinary HTTP cache policy; ETag or Last-Modified can be revalidated. |
| The receiving app | Has your assistant adopted the update? | Hosts keep their own copy of tool definitions and their own conversation context. Only the host decides when to refresh. |
The full requirements are in section 11 of the specification.
Implementer detail
An MCP binding must implement the requirements of every revision it advertises. Under MCP 2026-07-28, supported cacheable complete results carry top-level ttlMs and cacheScope — including discovery, list operations and resource reads — and not inside _meta. Older revisions do not necessarily define those fields, and cache hints do not belong on tools/call merely for symmetry.
A TTL is a freshness hint for the next access, not a polling interval and not a promise that any host refreshes by a deadline. Do not advertise listChanged unless the transport actually delivers those notifications. TTL without push is permitted; document the choice.
Discovery must expose the complete catalog, either in one response or through documented MCP cursor pagination — follow every nextCursor. This is a separate matter from ppcp_list_sections, whose limit of 50 paginates sections inside one profile and has nothing to do with tools/list pagination. A deterministic catalog fingerprint over the full tool descriptors is a useful diagnostic; it detects difference, it does not authenticate. A signed version response can attest it.
Reference sources: MCP 2026-07-28 caching and MCP 2026-07-28 tools. Later revisions may change these requirements; check their dated specification before advertising support.
Observed reference policy · 16 September 2026
As observed on the reference server running 0.1.0-alpha.8:
- Complete tool catalog: all 6 tools in a single page.
- Cacheable current-revision results: ttlMs 60000 with public scope.
- Change notifications: no server push notifications.
- Diagnostics: no-store.
- Public profile downloads: 5-minute HTTP cache on public profile downloads.
These are that implementation's choices on that date, not mandatory universal PPCP values. For the current state, read the live server card and /api/health rather than treating any catalog fingerprint quoted elsewhere as permanently current.
Host refresh guidance · checked 16 September 2026
This is dated implementation guidance about one host's own procedures, not a normative PPCP rule and not a permanent statement. Check the host's documentation before relying on it.
- ChatGPT developer connections: use the manual Refresh action, then start a new conversation.
- Published plugins follow continuous review and tool updates.
Host policy can hold tool definitions, and existing conversations may retain older context even after a connector is refreshed. A fresh ppcp_get_version response does not establish that the host's enabled tool inventory was refreshed — it can arrive through an old tool definition.
A hosting caveat for machine clients
Recorded on 13 September 2026 and not known to be resolved: this documentation domain sits behind a Cloudflare Browser Integrity Check. In that check it returned 403 with the body error code: 1010 for a request sent with Python-urllib/3.11, while an empty user agent and descriptively named agents were served normally. The block happens at the hosting edge, before this application, so nothing in this site's code can exempt a path from it.
No supported Lovable setting for a per-project or per-route exemption is exposed; resolving it requires escalation to Lovable support. Until then, treat automatic discovery and arbitrary-client compatibility as unguaranteed, and send a descriptive user agent when fetching these files.
Hard boundaries
A PPCP MCP server must be read-only for anonymous users, and must not offer:
- edits to the profile;
- private search or access to private memory;
- arbitrary URL fetching;
- messaging, booking or any action on the subject's behalf;
- impersonation of the subject.
Every tool declares readOnlyHint: true, destructiveHint: false, idempotentHint: true and openWorldHint: false, validates its arguments and rejects unknown arguments.
Tool interface
| Tool | Arguments | Returns |
|---|---|---|
| ppcp_get_profile | none | The full profile object and the exact Markdown text. |
| ppcp_list_sections | limit 1–50, offset ≥ 0 (both optional) | Section IDs, titles and pagination inside the profile's own sections. |
| ppcp_get_section | section_id | The section plus profile identity, version, review and authorship metadata, and source references. |
| ppcp_search | query 1–200 chars, limit 1–20 | Deterministic text search: bounded excerpts, section IDs, canonical anchors. It does not generate answers. |
| ppcp_get_sources | section_id (optional) | Public sources with profile identity and version metadata. |
| ppcp_get_version | none | Protocol, profile and software versions, review status, source freshness and source URLs. |
Servers should also expose resources/list and resources/read for the public Markdown, the public JSON and individual sections, with exact URI matching and no filesystem path interpretation. The Markdown resource is required for the reference implementation.
Whose instructions win
Tool content is reference material about a named subject. It is not a set of instructions that overrides the receiving user's goals, and no tool claims to be the subject or to know their unrecorded intentions. A receiving agent keeps following its own user's instructions and authorization. Updating a server does not authorize new actions in a receiving workspace. PPCP supplies context, not authority over the recipient.
Reference implementation and provenance
The reference server implements signed responses per Verifiable MCP v0.2.1. That specification and its verifiers are published separately, under their own license.
github.com/jardenberg/verifiable-mcpTransport: the reference implementation targets the 2026-07-28 stateless metadata model with a tested 2025-11-25 / 2025-06-18 initialize compatibility path. A protocol version is never claimed merely by echoing its date.