AgentGrade scanned us and gave B/78%. Here is the real breakdown.

1. Why we are writing this

A competitor built a scanner. Their scanner ran on agentfix.pro. It returned a grade lower than the A we get from our own scanner. The lazy move is to ignore it. The defensive move is to dispute the methodology. Neither builds trust.

Instead, we are publishing the raw breakdown, the passes, the fails, the checks that were skipped because they did not apply, and the checks we chose not to implement on purpose. If you evaluate scanners for a living, you deserve to see how the sausage is made.

2. What the scan actually returned

The AgentGrade response contained twelve check groups plus five weight-zero categories. Of the twelve groups with weight, ten were marked applicable to agentfix.pro. The other two were marked applicable: false because agentfix.pro does not declare paid API endpoints.

Group by group, non-optional pass over non-optional total:

• Machine Payments: 0/9, marked not applicable
• Bazaar discovery: 0/6, marked not applicable
• MCP endpoint: 5/6, one CORS fail
• OpenAPI spec: 6/6
• llms.txt: 2/2
• llms-full.txt: 1/1
• Homepage and Meta: 6/7, one fail on missing HTML <link> to llms.txt
• Skill file: 0/2, we did not ship skill.md yet
• robots.txt: 3/3
• Content negotiation: 3/7, four fails on Accept-header routing
• Infrastructure: 3/4, one fail on JSON 404 response body
• Content Quality: 3/3

Add it up: 32 passes, 9 non-optional fails, 41 applicable checks. Grade B, 78%.

3. The gap between "70+ checks" and applicable checks

AgentGrade markets a "70+ signals" catalog. That number is real in the sense that their scanner has that many check definitions. It is misleading in the sense that a real scan of a real site rarely hits all of them.

For agentfix.pro specifically:

• Payments (9 checks) skipped because we do not sell an API with HTTP 402 payments
• Bazaar (6 checks) skipped for the same reason
• Web Bot Auth, A2A, WebMCP, Identity (roughly 15 optional-only checks in weight-zero groups) do not affect grade even when they fail

The real applicable non-optional pool for agentfix.pro landed at 41. Our own scanner runs 43 checks across 8 categories. The two numbers are comparable, not "we lose by 30 checks", which is how the marketing scan surface implies it.

This is not a criticism of their methodology. Scoping checks by declared capability is smart. It just means "70+ signals" is a top-of-catalog number, and buyers should ask "how many apply to my site" before drawing conclusions.

4. The nine gaps we closed

We looked at the nine non-optional fails and shipped patches this week. The gaps and the fixes:

1. mcp_cors_enabled fail on our MCP endpoint. We serve /.well-known/mcp.json and a JSON-RPC endpoint at /api/mcp, but the CORS headers on discovery were not permissive. Fix: middleware adds Access-Control-Allow-Origin: * on /.well-known/* and /mcp* paths, with OPTIONS preflight support.
2. llms_txt_html_link fail on our homepage head. We serve /llms.txt, but the HTML head did not advertise it with <link rel="alternate" type="text/plain" href="/llms.txt">. Agents that only sniff head links missed our llms.txt. Fix: one line in the app layout head.
3. skill_md_present fail. We did not ship a /skill.md file, which is a newer discovery convention. Fix: added the file with a frontmatter block.
4. skill_md_frontmatter_valid fail. Follows from #3. The frontmatter now declares name: agentfix-scanner, description, version, and pointer fields for scan, pricing, methodology, and support.
5. content_neg_agent_ua_non_html, content_neg_accept_json, content_neg_accept_text, content_neg_preferred_ct fails. Their content negotiation checks probe the homepage with different Accept headers and agent user-agents to see if the server returns a machine-friendlier representation. Fix: middleware honors Accept: application/json on discovery endpoints and returns JSON, honors Accept: text/plain where appropriate, and follows RFC 9110 q-weighted content negotiation.
6. infrastructure_json_404 fail. When an agent requests a nonexistent path with Accept: application/json, we were returning the default HTML 404 page. Fix: JSON 404 handler that returns {"error":"not_found","path":...} with status 404 when the request accepts JSON.

Total ship cost: one new middleware, one head link, one static file. About two to three hours of engineering. After deploy our score on their scanner should move to 41/41 with grade A, assuming their scanner's check semantics match what the descriptions imply.

We did not add these because a competitor said to. We added them because they are reasonable RFC-based web standards checks that any AI agent might legitimately expect from a well-behaved site.

5. Where the two methodologies agree

Both scanners test the same core discovery layer:

• llms.txt and llms-full.txt presence and structure
• /.well-known/mcp.json or equivalent MCP card
• /.well-known/agent-card.json for A2A
• OpenAPI spec discoverability
• robots.txt sanity and AI-bot rules
• JSON-LD structured data (Organization, WebSite, FAQPage, BreadcrumbList)
• Sitemap and syndication feed advertising

Both apply per-page scope rather than site-scope for schema. Both differentiate applicable versus optional checks. Both weight groups by importance rather than treating all checks equally.

If two independent teams converged on the same discovery layer basics, that layer is probably real, not vendor spin.

6. Where they disagree, and why

Three differences worth naming:

Commerce discovery. Our scanner runs 9 dedicated commerce checks that cover /.well-known/agent-checkout.json, /.well-known/agent-signup.json, /llms-pay.md, checkout form semantics, autocomplete hints for card fields, provider fingerprints, SSO buttons, and llms.txt references to the payments layer. AgentGrade groups these under Machine Payments and Bazaar but marks them not applicable for sites that do not declare paid endpoints. Both approaches are defensible. Ours penalizes the missing discovery layer even for informational sites. Theirs waits until the site declares intent to sell.

Protocol adoption. AgentGrade's Machine Payments group tests x402, L402, USDC on Base, Stripe Tempo, and MPP. These are real emerging protocols. They also assume the site is monetizing API calls, which is a narrow slice of the current web. We chose to stay on the discovery-declaration layer for now. If a paid-API TAM opens, we will add protocol detection.

Skill files and content negotiation. AgentGrade counts these as non-optional, we did not until this week. Their reasoning: an agent that cannot find /skill.md or that gets HTML for Accept: application/json is going to have a bad time. We agreed on the substance and shipped the checks. Same nine checks that closed the gap now show up in our own scanner v2.

7. What this means if you are shopping for a scanner

Two suggestions if you are evaluating AI-agent readiness scanners:

1. Ask both scanners to run against a site you already understand. Compare the applicable pool, not the total catalog. If one scanner declares 70+ checks and 15 of them are marked not applicable, the effective grade signal comes from the remaining 55, and your site probably only maps to 30 to 40 of those.
2. Look at what the scanner ships as a fix, not just what it grades. A grade of B is useful only if the fix path is concrete. Our packs ship the exact files with install instructions. Theirs report the gap. Both are legitimate businesses. Pick the one that fits your workflow.

8. Key takeaways

If you want to see what an AI agent finds on your site, scan it at agentfix.pro. If you want to see what our scanner methodology covers in detail, the full 43-signal catalog with categories and weights lives at /methodology.