OpenAI-compatible remote MCP
Sitelemetry gives OpenAI clients seven audit tools for security, SEO, AI visibility, integrations, accessibility and performance. Every MCP request needs a Sitelemetry credential; OpenAI clients connect with OAuth.
01 / Capabilities
Each tool takes an explicit target and returns prioritized findings with evidence, impact and a fix, or a not-started notice when the account or target does not allow the audit. Checks are not meant to change the site. Audits are automated checks, not a manual security or accessibility review.
Checks DNS, email, domain, TLS, HTTP header, HTTPS and technology signals. On a target whose hostname the account has verified, it can add the deeper checks the account includes, such as port and injection probes. On an unverified target it runs public checks only or returns a not-started notice that uses no allowance.
audit_security
Reviews crawlability, indexation, metadata, headings, canonical tags, structured data and internal links, and can add Search Console data from the account's existing Google connection.
audit_seo
Checks entity clarity, answerability, llms.txt and AI-crawler policy against the site's own content, without querying any AI provider.
audit_ai_visibility
Inspects analytics, search, tag and platform integration signals exposed by the target.
audit_integrations
Runs static WCAG 2.2 checks on the page markup, such as alt text, form labels, headings, landmarks and contrast signals, and returns fixes.
audit_accessibility
Measures Core Web Vitals and lab metrics through Google PageSpeed Insights, which receives the target URL.
audit_performance
Runs every audit area the account includes in one call and returns a combined score across the measured areas. It needs a verified target, except on security-only accounts, where an unverified target gets public security checks only.
audit_full
02 / Access
Compatible clients discover the authorization service, open a browser consent flow and exchange an authorization code using PKCE S256. Access tokens are bound to the Sitelemetry MCP endpoint and its audit scope. A Sitelemetry account is required; available audits and usage limits reflect the access already assigned to the connected account. New users can create a Free account from the sign-in step of the connection flow; it includes security audits only, within its usage allowance, and access starts only after the consent screen is approved.
The client reads protected-resource and authorization metadata from Sitelemetry.
The user signs in on Sitelemetry and reviews the requested audit access.
The client exchanges its short-lived code with its PKCE verifier.
Authorized tool calls return structured findings, or a not-started notice that uses no allowance.
03 / Safeguards
SEO, AI visibility, integrations, accessibility and performance audits run on public websites without ownership verification. Protected security checks need ownership verification of the target hostname; without it, security and full audits run only public checks or return a not-started notice that uses no allowance.
These checks use information any internet client can see and need no ownership verification. On an unverified target, a default security audit runs them on security-only accounts; other accounts get a not-started notice unless only public checks are selected.
Deeper security checks run only when the account has a current verification of the target's hostname; some checks also accept a matching URL-prefix verification. Full audits need the same verification, except on security-only accounts, where an unverified target gets public security checks only.
Built-in checks send read-style requests and benign probes that are not meant to change the site but can appear in its logs or alerts. Depending on the account, security and full audits of a verified target can include active checks such as port and injection probes. A completed audit uses the account's audit allowance, and repeating a call can run another audit.
Localhost and private-network targets are blocked.
Each account has a monthly audit allowance. When it is used up, the tool returns a not-started notice that uses no allowance and sends no request to the target. Short-term rate and concurrency limits ask the client to retry later.
Tool inputs are limited to the target and the audit options in each tool's schema. Results contain findings with evidence and fixes; the SEO audit can add Search Console data from the account's existing Google connection, and the performance audit sends the target URL to Google PageSpeed Insights.
Verified domains decide where protected security checks and full audits can run. Standalone SEO, AI visibility, integrations, accessibility and performance audits need no verification. Monitoring projects are separate from domain verification, and the account's audit permissions and remaining allowance still apply.