SEO site audit MCP: up to 5 supplied URLs for on-page issues, plus Lighthouse page-speed scores.
On-page and technical SEO checks for up to 5 pages (status code, on-page score, title, meta description, H1, canonical, word count, links, load time and every failed check), plus Lighthouse scores and Core Web Vitals for a page.
Use before publishing or after a migration to check up to 5 supplied URLs per audit, or inspect a page's speed. This is a focused SEO Data subset, not an automatic whole-site crawler. Distinguish Lighthouse lab checks from field measurements.
Billing: paid data calls use API credits; get_api_credit_balance is free. The focused connections and SEO Data use the same balance and prices.
Example prompts:
Audit the owned page I provide for title, headings and canonical issues after I approve the API-credit spend.
Within my approved API-credit budget, compare failed technical checks for up to five supplied pages.
After confirming the API-credit cost, report Lighthouse scores and available Core Web Vitals for my page, distinguishing lab checks from field data.
Scored across 3 tools
The three tools have largely distinct purposes: credit balance is billing metadata, page speed is a single-page Lighthouse/CWV report, and site audit is a multi-page on-page check. Some overlap exists because the site audit also reports load time, so an agent could hesitate between page speed and audit for a single URL, but descriptions clarify the distinction.
All names use consistent snake_case verb_noun form: get_api_credit_balance, get_page_speed_scores, run_seo_site_audit. The get/run verb split maps cleanly to retrieval vs. execution rather than introducing inconsistency.
Three tools is thin but defensible for a narrowly scoped audit server covering billing, speed, and on-page checks. It is on the low end for a domain as broad as SEO, leaving little room for keyword or crawl-level operations.
The surface covers the advertised on-page and speed checks plus a cost guardrail via credit balance, which is coherent. However, there is no single-page on-page-only check, no crawl beyond 5 pages, no historical comparison, and no mobile/desktop distinction, so an agent hitting those needs has no path.
API credit balance: prepaid credits left for SEO data calls, amount spent, whether spending is suspended, and the per-call pricing rule. Free; no supplier call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| packs | No | API credit packs the account owner can buy, smallest first. |
| frozen | Yes | True when spending is suspended after a refund or dispute. |
| pricing | Yes | |
| creditsUrl | No | Dashboard page where the account owner buys API credits. |
| historyUrl | No | Dashboard page listing this account's data calls and costs. |
| spentMicros | Yes | |
| availableUsd | Yes | |
| creditsNotice | No | Low API credit balance: tell the user once, with this link to add credits. Never open it automatically. |
| availableMicros | Yes | |
| dataCallsEnabled | Yes | False until SEO data calls are switched on for this deployment. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: the call is free of charge and triggers no upstream supplier call, which tells the agent it is cheap in both cost and latency. It does not discuss caching or freshness of the balance value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence packs the returned fields and the cost/latency caveat with no filler. The leading 'API credit balance:' label is mildly redundant with the title but functions as a scannable anchor rather than waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema documenting the return shape, zero parameters, and rich annotations, the description's burden is small and it meets it: what the tool reports and that it costs nothing. Only the when-to-use signal is absent, which keeps it short of a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly offers no parameter guidance, which is appropriate rather than a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource (prepaid API credit balance) and enumerates the four facts it exposes: credits remaining, amount spent, suspension status, and per-call pricing rule. An agent can tell this is an account/billing read, distinct in substance from the SEO-data siblings, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'Free; no supplier call' hints it is safe to call speculatively (e.g., to verify credits before paid SEO queries), but the description never states when to use it or what alternative exists. Nothing misleads, but the agent must infer the check-before-spending workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Page speed and Core Web Vitals: Lighthouse performance, SEO, accessibility and best-practices scores for a page, with LCP, CLS, TBT and FCP. Costs API credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute public http(s) URL of the page. | |
| mobile | No | Test the mobile experience (true) or desktop (false). Default true. |
| Name | Required | Description |
|---|---|---|
| result | Yes | |
| billing | Yes | |
| dashboardUrl | No | Dashboard page where this tool also runs in the app; its call history and costs are linked from there. Share it when the user asks what they ran or spent. |
| creditsNotice | No | Low API credit balance: tell the user once, with this link to add credits. Never open it automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds a genuinely new behavioral fact not in structured data: each call consumes API credits, which affects how an agent should batch or ration calls. It omits operational details like expected latency (these tests are slow) or rate limits, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence: capability and returned metric set first, cost caveat last. Zero filler and nothing that could be cut without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only measurement tool with a full schema, an output schema, and rich annotations, the description covers purpose, metrics and cost. What remains missing is timing/expectations around a slow external Lighthouse run and whether both mobile and desktop are returned, but those are minor given the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
schema_coverage is 100% and both parameters are self-describing, including the true/false mobile semantics and http-only absolute URL constraint, so the description needs to add little. It correctly adds no conflicting parameter language. Baseline behavior for a fully documented 2-param schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names the concrete resource (a page's Lighthouse performance, SEO, accessibility and best-practices scores) and enumerates the metrics returned (LCP, CLS, FCP), so the agent knows exactly what it gets. It is clearly distinct from every sibling (all ranking/link/index tools). The verb is only implied via the tool name rather than stated in the description, which keeps it just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance and no named alternative, though the sibling list contains no competing page-speed tool, so the choice is unambiguous by default. The 'Costs API credits per call' note is cost context rather than usage routing. Adequate but requires inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SEO site audit: on-page and technical SEO checks for up to 5 pages, with status code, on-page score, title, meta description, H1, canonical, word count, links, load time and every failed check. Costs API credits per page.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | Up to 5 page URLs to audit. | |
| javascript | No | Render JavaScript before auditing (slower, costs more). Default false. |
| Name | Required | Description |
|---|---|---|
| result | Yes | |
| billing | Yes | |
| dashboardUrl | No | Dashboard page where this tool also runs in the app; its call history and costs are linked from there. Share it when the user asks what they ran or spent. |
| creditsNotice | No | Low API credit balance: tell the user once, with this link to add credits. Never open it automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world and non-destructive behavior, so the description's main added value is the commercial constraint: 'Costs API credits per page', which tells an agent to avoid wasteful bulk calls. It also discloses the 5-page ceiling and that every failed check is returned, but says nothing about rate limits or error behavior on unreachable URLs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that opens with the verb-resource and finishes with the cost caveat. The long field enumeration is informative but could be trimmed since an output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema, full annotation coverage, and fully documented parameters, the description only needs to add scope and cost, which it does. Missing only light guidance on alternatives and failure handling for invalid URLs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, including the 5-item max, URI format, and the 'javascript' flag with its performance/cost tradeoff, so the schema does the heavy lifting. The description only echoes the page cap and adds no format or default detail, which is the baseline 3 given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('SEO site audit: on-page and technical SEO checks') and scopes it to 'up to 5 pages', which separates it from single-purpose siblings like check_if_url_is_indexed or get_page_speed_scores. The enumerated result fields (status code, on-page score, title, meta, H1, canonical, word count, links, load time, failed checks) make the deliverable unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the 5-page cap suggests this is for small batches, and the credit-cost note hints at when to be selective. There is no explicit statement of when to choose this over inspect_url_in_google, get_page_speed_scores, or the per-URL checks, and no exclusions (e.g. internal/private URLs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_api_credit_balance2 fields changedOutput schema / properties / creditsNoticeAdded value: +{
+ "additionalProperties": false,
+ "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}Output schema / properties / packsAdded value: +{
+ "description": "API credit packs the account owner can buy, smallest first.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "url": {
+ "description": "Page where the account owner confirms this pack in checkout.",
+ "type": "string"
+ },
+ "usd": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "usd",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}get_page_speed_scores1 field changedOutput schema / properties / creditsNoticeAdded value: +{
+ "additionalProperties": false,
+ "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}run_seo_site_audit1 field changedOutput schema / properties / creditsNoticeAdded value: +{
+ "additionalProperties": false,
+ "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}get_api_credit_balance2 fields changedOutput schema / properties / creditsNoticeRemoved value: -{
- "additionalProperties": false,
- "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
- "properties": {
- "label": {
- "type": "string"
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "label",
- "url"
- ],
- "type": "object"
-}Output schema / properties / packsRemoved value: -{
- "description": "API credit packs the account owner can buy, smallest first.",
- "items": {
- "additionalProperties": false,
- "properties": {
- "url": {
- "description": "Page where the account owner confirms this pack in checkout.",
- "type": "string"
- },
- "usd": {
- "type": "number"
- }
- },
- "required": [
- "usd",
- "url"
- ],
- "type": "object"
- },
- "type": "array"
-}get_page_speed_scores1 field changedOutput schema / properties / creditsNoticeRemoved value: -{
- "additionalProperties": false,
- "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
- "properties": {
- "label": {
- "type": "string"
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "label",
- "url"
- ],
- "type": "object"
-}run_seo_site_audit1 field changedOutput schema / properties / creditsNoticeRemoved value: -{
- "additionalProperties": false,
- "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
- "properties": {
- "label": {
- "type": "string"
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "label",
- "url"
- ],
- "type": "object"
-}get_api_credit_balance2 fields changedOutput schema / properties / creditsNoticeAdded value: +{
+ "additionalProperties": false,
+ "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}Output schema / properties / packsAdded value: +{
+ "description": "API credit packs the account owner can buy, smallest first.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "url": {
+ "description": "Page where the account owner confirms this pack in checkout.",
+ "type": "string"
+ },
+ "usd": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "usd",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}get_page_speed_scores1 field changedOutput schema / properties / creditsNoticeAdded value: +{
+ "additionalProperties": false,
+ "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}run_seo_site_audit1 field changedOutput schema / properties / creditsNoticeAdded value: +{
+ "additionalProperties": false,
+ "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}get_page_speed_scores1 field changedOutput schema / properties / dashboardUrl / descriptionPrevious value: -"Dashboard page with this server's call history and costs. Share it when the user asks what they ran or spent."New value: +"Dashboard page where this tool also runs in the app; its call history and costs are linked from there. Share it when the user asks what they ran or spent."run_seo_site_audit1 field changedOutput schema / properties / dashboardUrl / descriptionPrevious value: -"Dashboard page with this server's call history and costs. Share it when the user asks what they ran or spent."New value: +"Dashboard page where this tool also runs in the app; its call history and costs are linked from there. Share it when the user asks what they ran or spent."get_api_credit_balanceget_page_speed_scoresrun_seo_site_auditSEO data MCP: SERP, keywords, backlinks, live rank checks, page audits, local and AI checks. Every SEO data tool in one server: Google and Bing SERP results, live rank checks, AI Overview sources, keyword search volume, ideas and difficulty, backlinks, referring domains and anchors, ranked keywords, competitor domains and keyword gaps, site audits with Lighthouse scores, Google Maps rankings, Google Business Profiles, and ChatGPT and Perplexity brand mentions. Start here for paid SEO research with one connection. Includes all seven focused SEO data servers' tools at the same prices and from the same API-credit balance; do not connect both for duplicate results. Search Console reporting and URL Indexing are separate connections. Billing: paid data calls use API credits; get_api_credit_balance is free. The focused connections and SEO Data use the same balance and prices. Example prompts: - After I approve the API-credit cost, compare US search volume and difficulty for 'trail running shoes' and 'running shoes for flat feet'. - For the domain I provide, check its backlink summary, referring domains and anchor texts after confirming the API-credit spend. - Compare live Google positions and competitor keyword opportunities for my domain and keywords, within the API-credit budget I approve. Docs: https://docs.crakseo.com/mcp-servers/seo
Backlink checker MCP: backlink summary, top backlinks, referring domains and anchor texts. A backlink summary (rank, backlinks, referring domains, broken links, spam score) and the strongest backlinks with anchor text and follow status, plus referring domains and anchor text counts for any domain or URL. Use to analyze backlinks, referring domains and anchor text for your site or a competitor. This focused SEO Data subset checks links; it does not submit backlinks for indexing. For a backlink indexer, use the separate URL Indexing server's paid Force indexing offering. Billing: paid data calls use API credits; get_api_credit_balance is free. The focused connections and SEO Data use the same balance and prices. Example prompts: - Check my domain's backlink summary and top backlinks after I approve the API-credit spend. - Within my approved API-credit budget, list the referring domains for the domain I provide. - After confirming the API-credit cost, summarize the anchor texts in my domain's link profile without assuming they prove a penalty. Docs: https://docs.crakseo.com/mcp-servers/backlinks
Your agent needs to crawl a site and say what is wrong with it — broken tags, duplicate content, pages nothing can index, resources that never load. **What you can ask for** • "Crawl this site and list every page with a duplicate title or missing description." • "Which pages are non-indexable, and why?" • "Run Lighthouse on these URLs and give me the failing audits." • "Show the internal link graph and the orphan pages." • "Give me this page's raw HTML and its microdata." **How to use it** Point any MCP client at https://mcp.aisa.one/seo-onpage/mcp and sign in with OAuth — there is no key to create or paste. 20 tools: submit a crawl and read its summary, pages, resources, links and waterfall; duplicate content and duplicate tags; keyword density; non-indexable and uncrawlable resources; parsed content, raw HTML, microdata, screenshots and Lighthouse. **Why this rather than the source** A crawler you drive from the agent, with the audit results as structured data rather than a PDF. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Find the broken pages here, then ask the same agent what those pages used to rank for — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/seo/mcp for all of it at once — rankings, keywords, backlinks, site health and AI-answer visibility across DataForSEO, Semrush and Ahrefs.
Google SERP API MCP: live Google, Bing, AI Overview and Google Maps results as JSON. Pay per call. Live search engine results pages as structured JSON: Google organic results with SERP features and AI Overview sources, Bing results, Google Maps local results, and live Google rank checks for a domain across up to 10 keywords. Use when an agent needs live Google or Bing search results for a keyword, country, language and device. This is a focused subset of SEO Data, not an additional required connection or a scheduled monitoring service. Billing: paid data calls use API credits; get_api_credit_balance is free. The focused connections and SEO Data use the same balance and prices. Example prompts: - Show the top ten Google results and SERP features for 'trail running shoes' in the US, after I approve the API-credit spend. - Compare Google and Bing results for my keyword in the same market, within my approved API-credit budget. - After confirming the API-credit cost, report which source URLs Google's AI Overview cites for my keyword. If none is present, say so. Docs: https://docs.crakseo.com/mcp-servers/serp-api
Add one secure layer between your agents and this server.
