Kevin Pirnie

AI agents — tools like ChatGPT, Claude, Copilot, and the growing ecosystem of autonomous AI systems — are increasingly being pointed at websites to gather information, interact with APIs, and perform tasks on behalf of users. For a site to work well with these agents, it needs to speak the right language: publishing structured discovery files, declaring its capabilities, and responding to agent-specific requests in the right format.
KP Agent Ready handles all of that for your WordPress site. It implements the current set of agent-readiness standards and the broader AI agent ecosystem — without requiring you to manually create files, edit server configs, or touch a line of code. Everything is managed from a dedicated settings page in the WordPress admin.
<h4>What It Does</h4>
RFC 8288 Link Response Headers 
Every response your site sends will include <code>Link</code> headers pointing agents to your API catalog, agent skills index, and MCP server card. This is how agents find your discovery documents without having to guess URLs.
API Catalog — <code>/.well-known/api-catalog</code> 
Publishes a machine-readable catalog of your site’s APIs in the <code>application/linkset+json</code> format defined by RFC 9727. Each entry in the catalog can point to an OpenAPI specification, human-readable documentation, and a health/status endpoint. If you have not configured any entries yet, the plugin serves a sensible fallback automatically so the endpoint is always valid.
Agent Skills Index — <code>/.well-known/agent-skills/index.json</code> 
Publishes a skills discovery index per the Agent Skills Discovery RFC v0.2.0. This tells agents what your site can do — search your blog, browse your portfolio, submit a contact form, and so on.
Skills are built from three sources:
<ul>
<li>Blog articles — a search skill and a browse skill, toggled with a single switch</li>
<li>Custom post types — any public CPT registered on your site appears as a checkbox; tick it and it gets a browse skill pointing to its archive</li>
<li>Manual entries — define any additional skill with a name, type, description, URL, and an optional sha256 digest</li>
</ul>
MCP Server Card — <code>/.well-known/mcp/server-card.json</code> 
Publishes an MCP Server Card (SEP-1649) identifying your site to Model Context Protocol clients. Configurable name, version, description, transport endpoint, and a capability list. If you do not have an MCP server running yet, just leave the transport blank — the card is still valid and useful for discovery.
OAuth / OIDC Discovery — <code>/.well-known/openid-configuration</code> or <code>/.well-known/oauth-authorization-server</code> 
If your site exposes protected APIs that require authentication, this feature publishes the discovery metadata agents need to authenticate. Supports both OpenID Connect Discovery 1.0 and RFC 8414. Disabled by default — only enable it if you have the infrastructure in place.
OAuth Protected Resource Metadata — <code>/.well-known/oauth-protected-resource</code> 
Complements the OAuth/OIDC feature by publishing RFC 9728 Protected Resource Metadata. Disabled by default.
robots.txt Content Signals 
Appends Content Signals directives to your <code>robots.txt</code> file, declaring your preferences for how AI systems may use your content:
<ul>
<li>ai-train — whether AI companies may use your content to train models</li>
<li>search — whether search engines may index your content</li>
<li>ai-input — whether AI retrieval systems (RAG) may use your content as input</li>
</ul>
Markdown Negotiation 
When an AI agent sends a request with the <code>Accept: text/markdown</code> header, the plugin intercepts the response for singular posts and pages and returns a clean Markdown version of the content. Regular browser requests are completely unaffected.
WebMCP 
Injects a small JavaScript snippet into your page footer that calls <code>navigator.modelContext.provideContext()</code>, exposing your site’s key actions as tools to AI agents running in the browser. Built-in tools include blog search, portfolio navigation, and contact page navigation — each individually toggleable.
llms.txt and llms-full.txt 
Generates physical <code>/llms.txt</code> and <code>/llms-full.txt</code> files in your WordPress web root per the <a href="https://llmstxt.org" rel="nofollow ugc">llmstxt.org</a> specification. These files give AI systems a structured, readable index of your site’s content — who you are, what pages exist, and what your posts are about.
<pre><code>llms.txt contains your site header and a clean list of links by content type. `llms-full.txt` contains the same structure but expands each entry with an excerpt or truncated content block so AI systems can understand the content without fetching every URL.
</code></pre>
Files are regenerated automatically when posts are published, unpublished, or trashed, and whenever settings are saved. A manual Regenerate button is available in the llms.txt settings tab. If your host prevents direct file writes, the generated content is displayed in the admin as a copyable textarea so you can create the files manually.
Configurable options include a custom intro block, toggling pages and posts independently, selecting additional custom post types, setting the excerpt word limit for <code>llms-full.txt</code>, and defining optional additional links that appear under an <code>## Optional</code> section in both files.
<h4>Developer Filters</h4>
Two filters let themes and other plugins extend the plugin’s output without touching settings:
<pre><code>kp_agent_skills — add entries to the agent skills index:

add_filter( 'kp_agent_skills', function ( array $skills ): array {
 $skills[] = [
 'name' => 'my-skill',
 'type' => 'api',
 'description' => 'Does something useful.',
 'url' => 'https://yoursite.com/api/endpoint',
 ];
 return $skills;
} );

kp_webmcp_tools — add tools to the WebMCP context:

add_filter( 'kp_webmcp_tools', function ( array $tools ): array {
 // $tools is the PHP array that becomes the JS tools array
 return $tools;
} );
</code></pre>

KP Agent Ready

Very good for AI

Make your WordPress site discoverable and usable by AI agents via well-known endpoints, MCP, OAuth, and Markdown negotiation.

Matthias Pfefferle

This plugin enables “Well-Known URIs” support for WordPress (RFC 5785: http://tools.ietf.org/html/rfc5785).
From the RFC:
It is increasingly common for Web-based protocols to require the 
 discovery of policy or other information about a host (“site-wide 
 metadata”) before making a request. For example, the Robots 
 Exclusion Protocol <a href="http://www.robotstxt.org/" rel="nofollow ugc">http://www.robotstxt.org/</a> specifies a way for 
 automated processes to obtain permission to access resources; 
 likewise, the Platform for Privacy Preferences 
 tells user-agents how to discover privacy policy beforehand.
While there are several ways to access per-resource metadata (e.g., 
 HTTP headers, WebDAV’s PROPFIND [RFC4918]), the perceived overhead 
 (either in terms of client-perceived latency and/or deployment 
 difficulties) associated with them often precludes their use in these 
 scenarios.
When this happens, it is common to designate a “well-known location” 
 for such data, so that it can be easily located. However, this 
 approach has the drawback of risking collisions, both with other such 
 designated “well-known locations” and with pre-existing resources.
To address this, this memo defines a path prefix in HTTP(S) URIs for 
 these “well-known locations”, “/.well-known/”. Future specifications 
 that need to define a resource for such site-wide metadata can 
 register their use to avoid collisions and minimise impingement upon 
 sites’ URI space.

/.well-known/

This plugin enables "Well-Known URIs" support for WordPress

KP Agent Ready vs /.well-known/