Level 5 Agent-Native: 100/100 in the Cloudflare Agent Readiness Check

The building blocks in detail

1. Content Signals in der robots.txt

The classic robots.txt only knows yes or no. That's too coarse for a world in which “I want to show up in Perplexity” and “my content may be used for GPT training” are two completely different decisions. Cloudflare specified the Content Signals protocol for exactly this.

Our file:

User-Agent: *
Allow: /
Sitemap: moselwal.de/sitemap.xml
Sitemap: moselwal.de/en/sitemap.xml

Content-Signal: ai-train=no, search=yes, ai-input=yes 

In plain English: no training on our content. AI search permitted. Agent input on concrete user questions permitted.

This is the only building block in this article that is in no way Moselwal's own work — two lines of text, done. But it counts towards one of the three Bot Access Control points.

2. Markdown content negotiation — our own TYPO3 extension

HTML is optimised for browsers. For an agent, everything except the text is ballast. The emerging standard for this: the agent sends an Accept: text/markdown header, the website responds with the Markdown version of the same URL. Try it if you like:

$ curl -H "Accept: text/markdown" moselwal.de
# Moselwal Digitalagentur

> IT services partner for the German mid-market. Since 2012.
...
 

We built this feature as our own TYPO3 middleware. It hooks into the response pipeline, checks the `Accept` header, extracts the content from the rendered ContentBlocks and serves it as Markdown. For TYPO3 13 and 14. No third-party package, no Cloudflare Worker magic.

You can see the effect in the file size: the HTML variant of the homepage weighs in at around 70 kilobytes. The Markdown variant is a fraction of that. For agents that bill per token, that translates directly into money.

3. Our own MCP server as a TYPO3 extension on top of hauptsacheNet
 

The Model Context Protocol (MCP) is the standard Anthropic opened up in late 2024 for communication between AI agents and external systems. Claude, OpenAI, Google and others now use it. It answers the question: how does a system make tools available to an agent that the agent can call?

For TYPO3 there is already an excellent MCP server: hauptsacheNet/typo3-mcp-server by Marco Pfeiffer and his team. That's the foundation — and it's genuinely good. The server covers backend content management via AI: creating pages, editing records, translations, all via TYPO3 workspaces, so nothing accidentally goes live.

What we were missing: TYPO3 14 support and a front-end MCP server that gives agents public access to the website's content — navigation, page content, search. We built both ourselves:

• TYPO3 14 compatibility for hauptsacheNet/typo3-mcp-server. The patches are running in production with us, and we plan to feed them back as a pull request to hauptsacheNet once they have proven production maturity beyond our own site.
• Our own front-end MCP server as a separate extension, running at moselwal.de/mcp. The server card:

$ curl moselwal.de/.well-known/mcp/server-card.json
{
 "serverInfo": {
   "name": "Moselwal Digitalagentur MCP Server",
   "version": "0.9.7"
 },
 "description": "TYPO3 CMS content access via MCP — search, navigation, page content",
 "url": "https://moselwal.de/mcp",
 "transport": { "type": "streamable-http" },
 "capabilities": { "tools": true }
} 

Three tools — navigation, page-content, search. Self-describing via input schemas. An MCP-capable client discovers all of this without our help.

The division of labour is therefore: hauptsacheNet for backend editorial work via AI, Moselwal for public front-end discovery via AI. Both are MCP servers, both are TYPO3 extensions, both complement each other rather than competing.

4. OAuth 2.1 with PKCE — our own implementation

An openly accessible agent API is an attack vector. Our MCP access therefore runs over an OAuth 2.1 flow with PKCE — exactly as required by the MCP spec:

$ curl moselwal.de/.well-known/oauth-authorization-server
{
 "issuer": "https://moselwal.de",
 "authorization_endpoint": "https://moselwal.de/mcp_oauth/authorize",
 "token_endpoint": "https://moselwal.de/mcp_oauth/token",
 "registration_endpoint": "https://moselwal.de/mcp_oauth/register",
 "response_types_supported": ["code"],
 "grant_types_supported": ["authorization_code"],
 "code_challenge_methods_supported": ["S256"],
 "token_endpoint_auth_methods_supported": ["none", "client_secret_post"]
} 

Dynamic client registration per RFC 7591, PKCE with SHA-256, authorization code flow. No secret API key that can leak. No basic auth.

This component is also our own work. There are generic OAuth packages for TYPO3, but none of them cleanly cover the exact MCP OAuth 2.1 profile with dynamic client registration. So we built it — small, focused, with HashiCorp Vault as the key backend.

5. WebMCP: tools straight in the browser — our own ContentBlock integration

MCP is classically spoken server-to-server. Since the start of 2026, Chrome, Edge and Claude in Chrome have been experimenting with WebMCP — tools that are registered in the browser itself. When an agent visits moselwal.de in the browser, it automatically gets a set of tools to hand:

// Simplified from our webmcp.js
navigator.modelContext.registerTool({
 name: "navigation",
 description: "Get the site navigation tree as structured JSON",
 inputSchema: {
   type: "object",
   properties: {
     maxDepth: { type: "integer", default: 4 }
   }
 }
});

navigator.modelContext.registerTool({
 name: "page-content",
 description: "Get structured content of a specific page",
 inputSchema: {
   type: "object",
   properties: {
     pageId: { type: "integer" },
     slug:   { type: "string" }
   }
 }
});

navigator.modelContext.registerTool({
 name: "search",
 description: "Search content on this website",
 inputSchema: {
   type: "object",
   properties: {
     query: { type: "string" },
     limit: { type: "integer", default: 10 }
   },
   required: ["query"]
 }
});
 

Bonus: via navigator.modelContext.provideContext() we hand over two context resources — page-meta and site-info. The agent immediately knows it's looking at a German site with an English variant.

The script is generated by our own TYPO3 extension, which registers the matching tools depending on the page type and ContentBlock setup. So not statically — dynamically, out of the CMS. For a contact page we could add tools like submit_contact_form in future, for a product catalogue product_search. That's the part we're still building.

6. Agent Skills Index

So that agents don't have to guess which skills our site offers, there is a machine-readable index at /.well-known/agent-skills/index.json — three entries, all classified as webmcp-tool. A Link header in the HTML response (rel="mcp-server-card") additionally points at the server card. Both are delivered by our MCP extension.

7. Web Bot Auth — Ed25519 signatures

Conversely, when our own agent reaches out to other sites in the near future, the operators should be able to identify it unambiguously. For that we have placed an Ed25519 key under /.well-known/http-message-signatures-directory — the IETF draft for Web Bot Auth.

$ curl moselwal.de/.well-known/http-message-signatures-directory
{
 "keys": [
   {
     "kty": "OKP",
     "crv": "Ed25519",
     "x": "x0Iu0T4Xn1dOLBXrGSbK8C0eaVmzEgGrBn-RfETa0nA"
   }
 ]
}

Every signed HTTP request can be traced back to us, without us having to handle username/password pairs. The same idea as Cosign keyless signing, just for HTTP traffic.

8. llms.txt — with a wink

For completeness: we have an llms.txt. Personally I'm not convinced by the format — it has no official support from the major providers, OpenAI calls it “noise”, and practice points more towards MCP and structured Schema.org data. But it costs nothing, it does no harm, and it counts for the Cloudflare Content score. So in it goes.

What this all adds up to

The stack behind the score consists of a classic `robots.txt`, an `llms.txt`, a Schema.org markup block — and seven Moselwal-built TYPO3 extensions or middlewares:

• Content Signals in robots.txt  — standard text file 
• Markdown content negotiation — our own work, our own middleware 
• Front-end MCP server `/mcp` — our own work, our own extension 
• TYPO3 14 patches for the backend MCP — fork of `hn/typo3-mcp-server` 
• MCP OAuth 2.1 with PKCE — our own work, our own extension + HashiCorp Vault 
• WebMCP tool registration — our own work, our own ContentBlock integration 
• Agent Skills index + Link header — our own work, part of the MCP extension 
• Web Bot Auth signatures — our own work, our own key infrastructure 

I'm naming this in detail deliberately, because at first glance the Cloudflare score looks like a collection of finished open-source packages you could just download from somewhere and snap together. You can't. Almost everything is built by hand — and almost everything is TYPO3-specific. Comparable building blocks exist for other CMS, but in sum the maturity TYPO3 reaches with the hauptsacheNet server plus our extensions is very much at the front of the CMS market.

What we'll give back as open source

Part of this stack will become open source over the coming months:

• Our TYPO3 14 compatibility work for `hauptsacheNet/typo3-mcp-server` will go back as a pull request to the original project. That is the fairest thing we can do — the project is the foundation of our solution, and Marco and his team deserve the credit.
• Our Markdown content negotiation middleware will be released as a standalone extension once the edge cases are cleanly handled. As of today there's still work on the handling of manual line breaks in headlines and on the completeness of ContentBlock extraction.
• The front-end MCP server, the MCP OAuth flow, the WebMCP integration and the Web Bot Auth component will remain part of our commercial Moselwal distribution for now. We are considering releasing individual modules later as well — but not now. These components are part of the value we deliver to clients; they have to reach field-level maturity before we release them into the wild.

Rollout for existing upgrade clients

Moselwal clients with an active upgrade contract don't need to do anything. Over the coming days we'll start rolling the agent-readiness stack out to your environments — Content Signals, Markdown endpoint, MCP server, OAuth, WebMCP tools, Web Bot Auth and Agent Skills index. That happens in stages, without downtime, without effort from the editorial team. After the rollout, your website will reach the same Cloudflare score moselwal.de has today — without a single editorial meeting having to take place about it.

Anyone without an upgrade contract who wants to be agent-ready earlier than 2027: an email to support@moselwal.de is enough. Beyond that, we're looking for pilot clients in the mid-market who would road-test individual stack components with us in production conditions.
 

What this means for you

For most hidden champions, “agent readiness” isn't a pressing topic right now. By 2027 it will be, at the latest. Until then, it will be decided which suppliers, service providers and product vendors show up in the answers buyers and decision-makers retrieve through their AI assistants. Anyone who isn't machine-readable then doesn't exist for the machine.

Three steps to start:

• Set Content Signals. Two lines in robots.txt — a clear statement of how your content may be used. Costs nothing, counts immediately.
• A Markdown variant of your most important pages. For TYPO3 that's a middleware task of manageable scope. We're working on a public version.
• Tidy up your structured data.Organization, Service, Person, FAQPage are the schemas agents weight most heavily today.

For anyone who wants to go deeper, the MCP server is the actual differentiator. A well-built MCP server turns a static website into a callable API — without editors having to learn anything new and without you having to build a separate agent portal.

A small self-test to finish

Open isitagentready.com and scan your own website. If the result doesn't look anything like ours, that isn't a bug — it's an open flank. And the time to close it is running out.