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.

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"
    }
  }
}

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, ClaudeBot, PerplexityBot and Google-Extended, compared against a browser request.

What the tools will not return. The written report and the generated files need a free account on the website, and the MCP endpoint does not hand them out — an unauthenticated route around the sign-in would be a hole, not a feature. The tools return measurements and findings, which is what an agent needs to do the work.

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.

Copy action.yml into .github/actions/citefiles/ and add a workflow:

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: actions/checkout@v4
      - uses: ./.github/actions/citefiles
        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.

Something not working? Tell us.