DEV Community: Ozan Dikici

Website audits as MCP tools: OAuth sign-in and what one finding has to contain

Ozan Dikici — Wed, 30 Sep 2026 15:24:02 +0000

The problem

After a coding agent ships a site, the checks that should follow are scattered across separate tools: headers and TLS in one, technical SEO in another, then accessibility, performance and analytics tags. Each has its own report, usually written for a person. The agent that will make the change sees none of it unless I paste a summary in.

I'm Ozan. I built Sitelemetry to put those checks where the agent works. It audits sites you own or are authorized to test, in six areas: security, technical SEO, AI visibility, accessibility, performance and integrations (analytics and tag setup).

The intended loop

Audit. The agent calls an audit tool against the site.
Fix list. The tool result carries the evidence and the remediation for every finding, so the agent works from that list.
Change. The agent edits the code or configuration.
Re-audit. The same audit runs again on the same target. A finding that is missing from the new list is fixed; one that is still there is not.

The audit tools are read-only: they report, and the agent that has the repository open makes the change. Step 4 is a new run, not a summary of what was edited.

Why OAuth for the MCP connection, not an API key in a config file

The audits are seven tools on a remote MCP server over Streamable HTTP: audit_security, audit_seo, audit_ai_visibility, audit_accessibility, audit_performance, audit_integrations and audit_full.

They are MCP tools because the agent is the one that needs the output. Findings arrive as a tool result, so the evidence and the remediation text are already in context when it starts the change.

The usual alternative is an API key in a JSON config file. I did not want that. Those files get committed, synced between machines and pasted into bug reports, and the key is a long-lived secret in plain text.

So authorization is OAuth 2.1 with PKCE (S256) and dynamic client registration. You configure one URL. In Cursor's mcp.json, for example:

{
  "mcpServers": {
    "sitelemetry": {
      "url": "https://sitelemetry.com/mcp"
    }
  }
}

That is the whole entry. The client reads /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server, registers itself, and requests one scope, audit. The config file holds a URL and nothing secret. The cost is that the client has to support this flow.

Long audits

A long audit returns status: running with a jobId. The client calls the same tool again with that jobId until the result is final. Polling does not start a second scan.

What one finding looks like

This is a real finding from audit_security, passive profile, run against my own production site on 2026-09-30:

severity:    medium
title:       CSP permits inline styles
evidence:    Affected location: https://sitelemetry.com/ Content-Security-Policy: style-src: 'unsafe-inline'; hardening points: 13/22 (deficit: 9).
impact:      Inline style permissions weaken restrictions on injected CSS and page appearance.
remediation: Remove 'unsafe-inline' from the reported style directives by moving inline styles into approved stylesheets; test in Report-Only mode first.

It is not fixed yet, so I have no before and after to show.

Give an agent only "medium: CSP" and it has to guess what is wrong and where. Each field has a job:

Evidence is what was observed: the URL, the header and the directive. The agent does not have to rediscover the problem.
Impact is one sentence on why it matters, so I can decide whether to do it now.
Remediation is the change to make, including the caution to test in Report-Only mode first. A CSP edit can break a page's styling, so that clause belongs in the finding.
Severity orders the work.

Passing checks carry evidence too. In the same run, "HSTS active" came back with max-age=31536000; includeSubDomains and "Response compression enabled" with content-encoding: gzip; body bytes 109605 → 26480. A pass without the observed value is only an assertion.

A check that did not run is not a pass

That run returned a security score of 96, grade A, with 17 passing checks and 0 critical, 0 high, 1 medium, 3 low and 2 info findings. It also returned coverage status "partial", because the passive profile does not run active checks such as ports or exposure paths. Each of those modules says so:

module: ports
status: unavailable
reason: The selected Passive profile does not run this active check.

An agent that sees no port findings is likely to conclude the ports are fine. So the status is reported per module, with the reason written as a sentence. The 96 describes the checks that ran, and "partial" says that was not everything.

Limits

It is not a pentest.
A score describes what the checks returned on that run, not whether the site is secure.
AI visibility means readiness for AI crawlers and answers, not tracking of chatbot mentions.
It is a closed-source hosted service. The public repository holds client manifests only.
This post covers only the MCP server. Also live: a GitHub Action, a GitLab CI/CD component, an n8n node, a WordPress plugin, a Chrome extension, and a loopback-only Local Agent for localhost targets.
The snapshot needs no signup. The Free plan is $0 and covers security checks only, 10 scans per month. The other five areas and scheduled audits are on paid plans, from $49/month.
I build and support it myself.
My own site still has the medium finding and three low ones open: no CAA record, no MTA-STS policy, and server: nginx disclosed.

Questions for you

When coverage is partial, is a per-module unavailable with a reason enough, or would you withhold or cap the score?
If you have connected remote MCP servers that use OAuth with dynamic client registration, which clients failed, and at which step?
Would you rather have the agent work through the whole finding list in one pass, or one finding at a time so each change can be committed and re-audited on its own?

2 a.m.: your AI says “fixed.” Your client asks how you know.

Ozan Dikici — Wed, 09 Sep 2026 10:32:23 +0000

Imagine you're finishing a client website at 2 a.m. The AI agent has made its changes. The build passes. You've checked the homepage, and tomorrow's handover is on the calendar.

Then you picture the client's question: "How do we know the problems are fixed?"

You have an SEO export, a browser screenshot, notes in Excel, a WhatsApp message about a broken form, and an AI conversation that started before the last deployment. Each piece contains something useful. Reconstructing the story takes work.

The discomfort is understandable. You've put effort into the project, but your evidence is scattered. Saying "the agent fixed it" leaves you accountable for an answer you cannot easily demonstrate.

Make the handover question smaller

Start by identifying the claim you need to support.

"Everything is fine" is too broad. "The contact form has a visible label associated with each input" gives you an observable result. So does "these pages now generate their intended canonical URLs."

This makes the conversation with a client clearer. You can explain what was checked, what changed, and which questions still need attention. It also gives the next person a starting point if the issue returns.

Walk one finding through the whole loop

Take an illustrative example: a product page points its canonical URL at the category page.

First, confirm the intended behavior. That canonical might be deliberate. Read the page requirements before treating an observation as a defect.

If it is wrong, record the target, the observed canonical, the expected canonical, and where the evidence came from. Identify the rule or template responsible for generating it.

Then give the coding agent a focused task:

Inspect canonical generation for this page. Propose the smallest change that produces the intended URL. Check another page using the same template, and explain any shared behavior the change affects.

Review the proposed change. Keep unrelated refactoring outside this repair. After applying it, inspect the same page again and record the resulting canonical. Re-test another affected page as well.

You now have a traceable sequence: observation, decision, change, verification. The result supports a specific handover claim. It leaves room for other checks instead of pretending one repair proves the whole website is ready.

Stop paying to rebuild the same context

Fragmentation has a cost even when individual tools are inexpensive.

Someone must reconcile the spreadsheet with the chat thread, find the latest evidence, and explain the deployment state. If you open another AI conversation, you may repeat that explanation and ask the agent to investigate facts you already collected.

Structured findings can help reduce token waste by carrying the observation, evidence, scope, and next action together. A focused task gives the agent less reason to repeat broad browsing or guess what "fix the site" means. Keep the context relevant to the finding and preserve the re-test result for the next handover.

Make the work easier to stand behind

For a small web team, a useful commercial question is: can this workflow make delivery and maintenance easier to explain, repeat, and review?

A buying decision can start there: what repeated work does the tool remove, and is its evidence useful to the person approving the handover?

That is the workflow we're building with Sitelemetry. It brings security, technical SEO, AI visibility, accessibility, performance, and integration evidence together. Coverage and usage depend on your plan.

Use ChatGPT, Claude, or a compatible MCP client to review findings. A coding agent can propose changes in your codebase; Sitelemetry's hosted audit tools do not edit the website. Run protected audits on authorized targets with the required domain verification.

Start with the free Launch Readiness Snapshot for limited passive public checks, or read the MCP setup guide.

At handover, bring the finding, the fix, and the re-test result into the same conversation.