SEP draft: pattern:// URI scheme — addressable cross-server findings (companion to #2674)

[UzunGridera]

Abstract

This is a pre-SEP discussion for an OPTIONAL URI scheme pattern:// on MCP Resources, complementary to the cross-site audit-trails Extension proposal in #2674.

The proposal: let clients address a finding (a recurring observation, a warning fingerprint, a learned pattern) as a stable, dereferenceable resource — independent of the specific MCP server that produced it.

The motivating use case is the same one the Skills Over MCP WG charter calls out: "Skills should be discoverable across servers". A pattern://<hex> URI is the discovery handle for a single Skill-emitted finding.

Relationship to the cross-site audit-trails extension (#2674)

• Extension proposal: dev.agentminds/cross-site-audit-trails — fingerprint + pattern_id correlation #2674 (Extensions Track) proposes _meta.dev.agentminds.cross_site_audit.fingerprint on tool-call results so that two servers calling the same logical capability can correlate their invocations.
• This thread is one layer up: it gives the fingerprint a stable URI so a Resource can refer to it abstractly, not just a tool-call result inline.

The two are independently useful and can ship in either order; they compose cleanly.

Motivation

MCP's Resources surface today addresses content (a file, a documentation page, a database row). It does not address derived knowledge — patterns the agent has learned, warning fingerprints recurring across deployments, evaluation verdicts attached to a fingerprint cluster.

Concrete cases:

1. A Skill emits a finding f1 ("rate-limit cascade between auth and uploads"). The same finding is independently emitted by a different Skill on a different server in a different org. With Extension proposal: dev.agentminds/cross-site-audit-trails — fingerprint + pattern_id correlation #2674's fingerprint, both servers can produce the same hash. But there is no way for a client to cite that fingerprint as a resource — to write an integration that says "watch for findings whose URI is pattern://<hex>".

2. An MCP-aware dashboard wants to show "all findings in this org's network that are also seen at peer orgs". Without a URI scheme, the dashboard has to invent its own resource namespace.

3. A Skill marketplace (the WG's stated end-goal) wants to record "this Skill produces the following findings". Without an addressable URI, the marketplace falls back to free-text descriptions.

Proposed shape

pattern://<lowercase-hex-sha256>
pattern://<lowercase-hex-sha256>?namespace=<reverse-dns>

• The path segment is a 64-char lowercase hex SHA-256, the same shape Extension proposal: dev.agentminds/cross-site-audit-trails — fingerprint + pattern_id correlation #2674 proposes for _meta.fingerprint.
• The optional namespace query parameter scopes the fingerprint to a vendor's pattern taxonomy. Without it, the fingerprint is global — a collision means two producers genuinely observed the same thing.
• pattern:// URIs are dereferenceable through the standard MCP Resources surface (resources/list, resources/read). A server that implements this scheme:
  • Lists patterns it knows about under its resources/list response.
  • Returns the pattern metadata on resources/read — last_seen, count, severity, breadcrumbs, status (using the Sentry-aligned lifecycle from Extension proposal: dev.agentminds/cross-site-audit-trails — fingerprint + pattern_id correlation #2674).

Why a URI scheme (and not just a resource path)

The MCP Resources surface uses URIs as the resource handle. Without a registered scheme, every implementation invents my-server://patterns/<hex> and they can't be exchanged. Once pattern://<hex> is reserved, a client can deduplicate and join patterns across servers with no out-of-band coordination.

Prior art on custom URI schemes in the MCP ecosystem: SEP-2640 (skill://). pattern:// follows the same template.

Out of scope

• The hash function. Extension proposal: dev.agentminds/cross-site-audit-trails — fingerprint + pattern_id correlation #2674 already proposes lowercase hex SHA-256; this thread inherits that decision.
• The transport layer. pattern:// is dereferenceable through whatever Resources transport the server already exposes (Streamable HTTP, stdio).
• The lifecycle field set. That belongs in Extension proposal: dev.agentminds/cross-site-audit-trails — fingerprint + pattern_id correlation #2674; this thread only addresses the URI handle.

Reference implementation

AgentMinds maintains a reference implementation:

• Spec: https://github.com/agentmindsdev/profile/blob/main/AGENT_REPORTING_PROFILE.md (§3.3 + §4.1)
• Wire-format discovery: https://api.agentminds.dev/.well-known/arp.json
• Public Tier-1 corpus: https://api.agentminds.dev/api/v1/sync/patterns (Tier-1 patterns only — cross-site learnings stay per-tenant per ARP §4.1 privacy boundary).
• MCP server (npm): agentminds-mcp — install via npx agentminds-mcp. Source: https://github.com/agentmindsdev/mcp-server

If the WG endorses the scheme, AgentMinds will:

1. File a formal SEP PR with the BNF for the URI shape.
2. Register pattern with IANA's URI scheme registry under "Provisional Registration" then promote to "Permanent" once the SEP merges.
3. Publish a TypeScript + Python client library that resolves pattern:// URIs transparently for any MCP server implementing the scheme.

Asking the WG

1. Is pattern:// the right scheme name, or should it be mcp-pattern:// / urn:mcp:pattern:<hex> / something else?
2. Does the WG see this fitting in resources/ or somewhere else (a new findings/ surface)?
3. Is the optional namespace query parameter overengineered for v1, or critical for vendor coexistence?

Happy to draft formal SEP text once a direction is endorsed.