Skip to content
Cite Files

MCP server and CI check

An audit you have to remember to run is an audit that gets run once. These two connect it to the places the work actually happens.

MCP: let your coding agent run the check

Cite Files speaks MCP at https://citefiles.com/mcp. Point Claude Code, Claude Desktop, or anything else that speaks the protocol at it, and the agent can scan a site, read the findings, change your repository, and scan again to check its own work — which is the only honest way for it to tell you the job is done.

No account, no key, nothing to sign up for — for four of the five tools. The fifth, citefiles_agent_commerce, needs an API token; see below.

The server speaks MCP revisions 2026-07-28, 2025-11-25, 2025-06-18, 2025-03-26 over Streamable HTTP, newest first. The older HTTP+SSE transport is not implemented. The protocol is defined in the Model Context Protocol specification (2026-07-28).

Claude Code

claude mcp add --transport http citefiles https://citefiles.com/mcp

Anything reading an mcp.json

{
  "mcpServers": {
    "citefiles": {
      "type": "http",
      "url": "https://citefiles.com/mcp"
    }
  }
}

A plain GET to /mcp answers 405 — the streamable-HTTP spec’s requirement for a server that has no SSE stream to offer on GET — and redirects a browser here instead. Our own Agent Commerce Readiness audit checks other sites’ MCP endpoints the same way.

The tools

  • citefiles_scan — score out of 100, category breakdown, and every finding with the evidence behind it.
  • citefiles_fix_prompt — the same findings as a task list, with the rules that stop an agent inventing facts about your business while it works.
  • citefiles_check_files — which discovery files are genuinely served, distinguishing a real file from a single-page app answering 200 for every path.
  • citefiles_crawler_access — how the site answers GPTBot, OAI-SearchBot, ClaudeBot and PerplexityBot, compared against a browser request.
  • citefiles_agent_commerce — reads back the stored Agent Commerce Readiness audit for a scan on your account, as a tier from T0 to T5. Requires an API token from /account.

What the tools will not return. The written report and the generated files need a free account on the website. The four scan tools — citefiles_scan, citefiles_fix_prompt, citefiles_check_files and citefiles_crawler_access — stay unauthenticated and return measurements and findings only, never the report or the generated files, because an unauthenticated route around the sign-in would be a hole, not a feature. The one exception is citefiles_agent_commerce: it returns a stored Agent Commerce Readiness audit, and only to the account that owns the scan, only with that account’s API token. It never starts an audit — run it from the report page first, then call the tool to read the result.

There is also no argument anywhere for a staging username or password. A tool call is the wrong place to put a secret: the value ends up in an agent transcript, and transcripts get logged and pasted.

Fresh scans are limited to twelve an hour per address, and a scan of the same site within six hours is reused rather than repeated. Every scan costs somebody else’s server real requests, and being polite to the sites we measure is the basis on which this tool gets to exist.

CI: fail the build when it gets worse

Sites drift. A framework upgrade drops the sitemap, a CDN rule starts refusing GPTBot, someone rewrites a page as a client-rendered component and the text disappears from the HTML. None of that announces itself.

The action is a public repository, bryanflowers/citefiles-action. It needs no secret and no checkout step: add a workflow that uses it.

name: AI citation readiness

on:
  # After deploy, not on pull request: this checks the live site, so a PR
  # branch would be measuring whatever is currently in production.
  workflow_dispatch:
  schedule:
    - cron: "17 6 * * 1"

jobs:
  citefiles:
    runs-on: ubuntu-latest
    steps:
      - uses: bryanflowers/citefiles-action@v1
        with:
          url: https://example.com
          min-score: 70
          fail-on: critical

Schedule it, do not run it on pull requests. The check measures the live site, so on a PR branch it would be reporting on whatever is currently in production and blaming the branch for it.

An unreadable site is not a score of zero. If we cannot read the site as a browser, the action says so and does not fail on a score, because failing a build on “0/100” when the real answer is “we could not reach it” sends people to fix the wrong thing.

Our outage is not your build failure. If Cite Files is unreachable or returns something unreadable, the step warns and passes.

Badges: publish the number on your own site

Turn on publishing from your report and embed either badge — one opt-in covers both. Each reads the current measurement, not a frozen high-water mark, and links back to the report so a reader can check it. Replace example.com and the report link with your own from the toggle on your report page.

AI citation readiness

<a href="https://citefiles.com/report/<your-scan-id>" rel="noopener">
  <img src="https://citefiles.com/badge/example.com.svg" alt="AI citation readiness for example.com, measured by Cite Files" height="20">
</a>

Agent commerce readiness

<a href="https://citefiles.com/report/<your-scan-id>" rel="noopener">
  <img src="https://citefiles.com/badge/example.com.svg?kind=agent" alt="Agent commerce readiness for example.com, measured by Cite Files" height="20">
</a>

Reads “not published” until the badge is switched on, and “ungraded” until an Agent Commerce Readiness audit has actually run — never a tier nobody measured.

Something not working? Tell us.