MCP resources

Resources reference

The acf-mcp server exposes the ACF® corpus as MCP resources, canonical URIs, typed MIME, read-only access, signed content. Every resource is addressable by its acf://… URI and served in the locale negotiated with the client.

→Tip

Resources vs tools. An MCP tool either reasons (REASON) or retrieves (READ); an MCP resource is just read. acf-mcp resources are the raw matter: whitepaper, cards, regulator articles, glossary, metadata. READ tools (e.g. acf.fiche.lookup) are enriched access points to the same resources with context and cross-refs.

What is an MCP resource

In the Model Context Protocol specification, a resource is content identified by a URI, accompanied by a MIME type and exposed read-only through the resources/list and resources/read methods. The client negotiates the content, the server serves it. It is the doctrinal equivalent of an HTTP GET, no mutation, no side effect.

Every acf-mcp resource is signed at the source: the doctrine version is frozen in the content_hash exposed by acf://meta, signed Ed25519 and archived on acfstandard.com. A client can therefore cite a resource in a user reply and prove, offline and years later, that it was read exactly as it stands today.

By category

ACF® resources are organised into four logical categories. Click for the exhaustive list and a fetch example.

Doctrine×27

The founding corpus: white paper, 4 principles (P1 to P4), 4 delegated autonomy levels, the DDAO role, the toolkit manual and the deck.

Toolkit cards×45

The 45 ACF® toolkit cards (Decide ACF-01 to ACF-20, Organise ACF-O1 to ACF-O10, Operate ACF-P1 to ACF-P15), bilingual, served as Markdown. The operational backbone of the standard.

Regulator guides×5

Operational reading of AI Act, GDPR, DORA, NIS2 and ISO 42001, each guide cross-mapped to the relevant principles and cards.

Reference×3

Glossary index, doctrine metadata (version, hash, archive URL, locales) and the permanent archive bundle.

By URI pattern

All resources are addressed by a URI of the form acf://category/identifier. The locale is negotiated outside the URI via the Accept-Language header or the ACF_MCP_LOCALE variable, not in the URI itself, so that each piece of content has a single canonical URI.

acf://whitepaper: the founding ACF® whitepaper (Markdown)
acf://deck: the standard’s presentation deck (Markdown)
acf://manual, acf://manual/toc, acf://manual/section/{N}: the full pedagogical manual, its table of contents, and each part individually (9 parts)
acf://framework/principle/{P1..P4}: the 4 founding principles (structured JSON)
acf://framework/autonomy-level/{suggestive|co_decision|supervised_autonomous|autonomous}: the 4 delegated autonomy levels (structured JSON)
acf://framework/ddao: the canonical definition of the DDAO role
acf://fiche/{ACF-01..ACF-20 | ACF-O1..ACF-O10 | ACF-P1..ACF-P15}: one of the 45 toolkit cards (Markdown)
acf://guide/{ai-act|gdpr|dora|nis2|iso-42001}: the operational guide for a regulator (Markdown)
acf://glossary: the canonical index of ACF® terms
acf://meta: doctrine metadata, version, hash, archive URL, locales

Fetching a resource

An MCP client calls the resources/read method with the target URI. The server returns a contents array with the MIME type and the text. The actually-served locale is exposed in the served_locale frontmatter (for Markdown) or in the served_locale / is_fallback envelope (for JSON), so a client can detect a fallback to English.

fetch-resource.tsts

import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";

const transport = new StdioClientTransport({
  command: "npx",
  args: ["-y", "acf-mcp@latest"],
  env: { ACF_MCP_LOCALE: "fr" },
});

const client = new Client({ name: "acf-demo", version: "1.0.0" }, {});
await client.connect(transport);

// List every resource
const { resources } = await client.listResources();

// Read one, here ACF-07 (Kill switch)
const { contents } = await client.readResource({
  uri: "acf://fiche/ACF-07",
});

console.log(contents[0].mimeType);   // "text/markdown"
console.log(contents[0].text);       // served_locale header + card body

Signing

Signing does not target each resource individually, it targets the content_hash of the full doctrine, exposed by acf://meta and embedded in every tool output footer. That hash is what makes the whole corpus defensible: if a single card changes, the hash changes, and the entire doctrine receives a new version. Cryptographic details and verification code: Signatures page.