AgentFix is a digital tool that scans your website for AI-agent readiness (ChatGPT, Claude, Perplexity, Google Gemini) and delivers a personalized $29 ZIP with llms.txt, GEO fixes, and other AI-optimized files to make your site AI-ready in 5 minutes.

AgentFix is designed for non-developer website owners — marketing managers, SMB founders, agency PMs running WordPress, Webflow, Tilda, Shopify, or raw HTML sites.

What does the pack include?

The ZIP contains llms.txt and llms-full.txt files, robots.txt with AI Content Signals, schema.org JSON-LD snippets (Organization, WebSite, BreadcrumbList, FAQPage), .well-known/mcp/server-card.json, .well-known/agent-card.json (A2A protocol), agent-skills markdown files, a sitemap.xml, per-page meta tag snippets, and step-by-step install guides for WordPress, Webflow, Tilda, Shopify, and raw HTML.

How much does AgentFix cost?

AgentFix scans are free. The Agent-Ready Pack ships in two tiers: Basic at $29 one-time, or Pro at $99 (3 months active service, then $9/month or downgrade to Basic). Pro includes monthly auto-rebuild as the scanner adds new checks, plus priority support.

Refunds are available within 14 days only if the pack failed to build or is technically broken. Once any file from the pack has been downloaded or installed on your site, the purchase is non-refundable.

Will this hurt my Google SEO?

No. All files added (llms.txt, schema.org, .well-known) are AI/agent-readiness signals that complement classic SEO. Search rankings are not affected.

How is this different from agentready.tools?

agentready.tools delivers fixes as a GitHub Pull Request, which assumes you have a Git repo and know how to merge a PR. AgentFix delivers a ZIP with a 5-minute install guide for the platforms non-developers actually use (WordPress, Webflow, Tilda, Shopify, cPanel).

What if my site is on Wix or Squarespace?

Wix and Squarespace have limited control over root files. The pack still includes schema snippets you can paste into the head section. For the .well-known files, a Cloudflare Worker is required (instructions included).

Do you offer a certificate?

Yes. After installing the pack, re-scan your site at agentfix.pro. If your score reaches 80% or higher, an Agent-Ready certificate is issued automatically with a public verification page and embeddable badge.

MCP server card for your website: what to publish at /.well-known/mcp.json in 2026

Model Context Protocol (MCP) is the piece most content sites are still missing from their AI-agent readiness stack in 2026. llms.txt tells agents what to read. Schema.org JSON-LD tells them how to cite. An MCP server tells them how to act: search your knowledge base live, call your public API, fetch a fresh price. If your product has data an agent would want on demand, an MCP server card is how you get discovered by the agents that can hold a tool session.

This guide walks the practical shape of what to publish on your marketing site so MCP-capable clients (Claude Desktop, Anthropic API tool sessions, and a growing pile of MCP-aware IDEs and copilots) can find and mount your server. It does not cover writing the server itself in depth — for that, the reference is modelcontextprotocol.io.

What "MCP server card" actually means

MCP borrowed a naming convention from the A2A world: a small, machine-readable document that advertises what a server exposes, so a client can decide whether to connect. Unlike A2A, MCP has not (as of 2026) mandated a fixed URL for that card. What is emerging in the wild is a small pointer file, usually at /.well-known/mcp.json, that lists one or more MCP endpoints for the domain plus a short description of each. Clients that respect the hint save a full-site scan; clients that do not still discover the server through user configuration or catalog entries.

Treat the card as a discovery courtesy, not a contract. The real contract is the MCP handshake at the endpoint itself, which returns the full set of tools, resources, and prompts on connect.

The minimum viable MCP pointer

Ship this at /.well-known/mcp.json if you run an MCP server that public clients should be able to auto-discover:

{
  "servers": [
    {
      "name": "yourbrand-mcp",
      "description": "Read-only access to the yourbrand public knowledge base and product catalog.",
      "transport": "http",
      "url": "https://mcp.yourbrand.com",
      "auth": "none",
      "docs": "https://yourbrand.com/mcp"
    }
  ]
}

Six fields, all self-explanatory. transport is http, sse, or stdio. auth is none, bearer, or oauth. Anything past the minimum is discretionary and will churn as the spec matures.

Serve it with Content-Type: application/json. If your framework wraps every unmatched path in an HTML shell (Next.js, Nuxt, Astro middleware — all common offenders), the file will 200 but return HTML and no MCP client will parse it. Verify with curl -I, not a browser tab. Same rule that catches half of the failures in the wider /.well-known/ audit.

What your MCP endpoint has to actually do

The card is bait. The endpoint is the product. A conformant MCP server exposes three surfaces:

Tools — callable actions the model can invoke. For a content site: search_articles(query), get_pricing(plan), list_changelog(since). Keep tool descriptions short and imperative. Long descriptions confuse the model at selection time.
Resources — read-only references the model can pull into context. Individual docs, product pages, changelog entries. Use stable URIs so the model can quote a specific version.
Prompts — reusable templates a user can invoke by name. Optional; ship if you have a genuinely reusable workflow, skip if you do not have a strong opinion.

A read-only server with three good tools and ten well-named resources beats a sprawling one with fifty tools no model can pick between.

Transport: which one to pick for a public server

MCP defines multiple transports. For a server you want public clients to reach over the internet, the practical options in 2026 are:

HTTP with Server-Sent Events (SSE) — the mainstream transport for hosted servers. Works through CDNs and firewalls, plays with existing load balancers, streams tool results back to the client without holding a socket open.
Streamable HTTP — the newer transport that consolidates request and response over a single HTTP connection. If your client base updates fast (Anthropic-first users), prefer this; if you serve a mix of older clients, keep SSE as a fallback endpoint.
stdio — for local developer tools only. Do not advertise a stdio server from a public MCP card; it cannot be reached over the network.

Whichever transport you pick, keep the URL stable. MCP clients cache endpoint URLs on user machines. A moved server is a broken tool call in the middle of a chat, and the user will remove it rather than debug.

Auth: what to use, what to skip

For a read-only, public-data MCP server (docs, changelog, pricing), publish auth: none. Anonymous discovery is the fastest path to real usage. Rate-limit at the edge; do not gate the front door.

For anything that touches user data or costs you money per call, ship auth: bearer and let the user paste a token in their client config. OAuth in MCP is still shaking out in 2026, so keep it in mind but do not require it. The friction of an OAuth dance in a Claude Desktop config file kills adoption faster than a missing feature.

Cross-referencing MCP with your other agent files

The card at /.well-known/mcp.json is a pointer. Two other files should confirm the same story:

/llms.txt — mention the MCP server in the "Optional" section with a short description, so agents that never read the well-known directory still hear about it. Two lines is enough. See our llms.txt guide for the format.
Schema.org JSON-LD on the marketing page — if you publish a /mcp docs page for humans, add a WebPage block with about pointing at the MCP endpoint. Agents that ground on schema will surface the docs when asked about your tools. Templates in the JSON-LD guide.

Three signals pointing at the same server, all machine-readable, all stable URLs. That is the whole trick.

How to verify the card is landing

curl -I https://yourbrand.com/.well-known/mcp.json — expect 200 and Content-Type: application/json. Anything else and no client will parse it.
curl https://yourbrand.com/.well-known/mcp.json | jq .servers[0].url — expect your MCP endpoint URL back cleanly.
Point a real MCP client (Claude Desktop, the Anthropic SDK, one of the MCP-inspector CLIs) at the URL. If it lists your tools, the loop is closed.
Run a full scan on agentfix.pro. It checks /.well-known/mcp.json, the pointer format, and the endpoint handshake alongside 28 other agent-readiness signals, and ships the missing files back filled in.

The one anti-pattern to avoid

Do not publish an MCP card for a server that does not exist yet. Empty tools, broken URLs, or a 502 endpoint teaches every client that hits you to skip your brand next time. If the server is not ready, do not ship the card. MCP discovery is one of the few places where "coming soon" is worse than silence.