Can AI actually read your page? ChatGPT, Perplexity, Claude and Google's AI Overviews fetch pages very differently from your browser — no JavaScript, tight timeouts, and a robots.txt rulebook of their own. Lekta fetches a URL exactly the way they do and grades what survives, A+ to F.
This is the technical half of AEO (answer engine optimization) and GEO (generative engine optimization): before a model can cite you, it has to be able to fetch you, parse you, and find one sentence worth quoting.
The loop this server was built for:
Audit https://mysite.com/pricing with Lekta, apply the fixes it lists, audit it again, and show me the difference.
Your agent gets a graded verdict, a ranked fix plan with the exact markup to paste, and a diff that proves the change landed. Repeat until A+.
Four layers, 100 points: Access 25 — do the ~17 AI crawler tokens get past robots.txt? Indexability 25 — how much content survives without JavaScript? Answerability 30 — is there a single quotable sentence an engine can lift? Recency 20 — can a model tell when this page was last true?
What this is not: a rank tracker. Lekta will not tell you how often ChatGPT mentions your brand. It tells you whether your page can be read and quoted when it does — the part you can actually fix.
No black box. Every finding cites its basis — an RFC, a vendor doc, or a dated measurement we ran. The engine is versioned with a public changelog: a score never moves without a published shift table.
Tools: lekta_audit (fresh fetch) · lekta_report (cached read) · lekta_fix_plan (ranked, paste-ready) · lekta_diff (before/after) · lekta_my_sites
Listing tools is open. Tool calls need a free key from lekta.dev/en/panel/api — send Authorization: Bearer lekta_… or x-api-key. Cached reads, fix plans and diffs cost nothing; only fresh fetches count against the daily limit.
Topics: AEO · GEO · AI SEO · LLM SEO · answer engine optimization · generative engine optimization · AI crawler access (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) · JavaScript-free indexability · structured data · content freshness
Scored across 5 tools
Each tool has a clearly distinct role: audit (human-readable Markdown), report (same audit as JSON), diff (comparison over time), fix_plan (prioritized remediation), and my_sites (account inventory). The descriptions explicitly call out when not to use each tool, eliminating ambiguity.
All tools follow a consistent lekta_ prefix with snake_case noun-style names: lekta_audit, lekta_report, lekta_diff, lekta_fix_plan, lekta_my_sites. The pattern is predictable and each name conveys its function clearly.
Five tools is well-scoped for an audit workflow: inspect, audit (two formats), diff, and fix planning. Each tool earns its place and there is no redundancy or bloat.
The set covers the full audit lifecycle: discover tracked URLs, run the audit (human or machine-readable), generate prioritized fixes, and compare runs over time. Site management is intentionally delegated to the web panel, and the tools explicitly cross-reference each other, leaving no obvious workflow gaps.
Audits ONE live page for AEO (Answer Engine Optimization), also called GEO (Generative Engine Optimization): whether ChatGPT, Claude, Perplexity, Google AI Overviews and Bing can reach, read, quote and cite it. Fetches the page the way those engines do — a plain HTTP GET as LektaBot, then a headless-Chromium render pass — and grades it A+ to F across four weighted layers: Access 25% (robots.txt permission for 36 published AI crawler tokens: GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot, PerplexityBot, Googlebot, bingbot, CCBot and more), Indexability 25% (noindex / nosnippet / canonical controls, and how much main content survives with JavaScript off), Answerability 30% (concrete data density, external evidence, semantic section structure, hedging), Recency 20% (a machine-readable and visible last-updated date). Returns Markdown under fixed headings: "## Verdict" (grade, score, per-layer scores, and the URL actually measured after redirects), "## Top issues" (failing and warned checks ranked by points lost, tagged critical/serious/moderate/minor, with evidence), "## Fixes" (the full remediation text for each). Unmeasured layers cap the grade at B and say so. USE THIS for "run an AEO audit", "run a GEO audit", "why is my page not cited in AI answers", "will ChatGPT / Claude / Perplexity quote this page", "check my robots.txt for AI crawlers" — and again after every deploy to re-measure. DO NOT use it when code will parse the result (lekta_report is the same run as JSON), when an audit already exists and you only want the ranked work list (lekta_fix_plan, which never fetches), or to compare two runs (lekta_diff). It scores one page, not a site: no crawling, no sitemap expansion. COST AND BEHAVIOUR: read-only — the audited site is never modified. It READS AND GRADES robots.txt rather than obeying it as a fetch gate: the audit runs even where LektaBot is disallowed, and the report flags that. A blocking call — a live fetch plus a render pass, cut off at a 75 s hard limit. NOT idempotent: a URL not audited in the last 15 minutes starts a fresh run and spends one slot of the daily MCP quota (free plan default 10 fresh audits per UTC day across 1 hostname; every result prints the count used and the host slot in use), while a repeat inside that window replays the cached measurement for free. An unreachable, blocked or HTTP-error target still returns a report, graded U for "unknown" — never F. Only these return an error instead of a grade: a timeout or a server-side engine failure, an exhausted daily quota or host slot, 2 audits already in flight for this account, or the per-target ceiling of 1 audit per minute and 5 per hour.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Required. The one absolute http(s) page URL to audit, e.g. "https://example.com/pricing". A bare host+path ("example.com/pricing") is accepted and upgraded to https; the #fragment is dropped and the hostname lower-cased, but the query string is kept and is part of the page identity (?variant=b is a distinct target). ONE page per call — not a domain, a sitemap or a list. Prefer a representative content page over the homepage: scoring is per-URL, not per-site. Redirects are followed and the verdict names the final measured URL, but the audit is STORED under the URL you pass here — give lekta_fix_plan and lekta_diff this same string, not the redirect destination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, openWorld, non-idempotent, and non-destructive hints, and the description goes well beyond them by explaining the practical consequences: it reads and grades robots.txt rather than obeying it, is a blocking call with a 75s hard limit, can replay cached results within 15 minutes, consumes daily quota on fresh runs, returns U instead of F for unreachable targets, and lists the exact error conditions. None of this contradicts the annotations; it enriches them substantially.
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?
The description is long, but the tool is genuinely complex and the length is justified by dense, non-redundant content. It is well structured with scannable sections for usage, exclusions, cost, and behavior, and the most important facts (what it audits, how it grades, and what it returns) are front-loaded. Every chunk earns its place.
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 single-parameter tool with no output schema, the description is unusually complete. It specifies the exact Markdown return structure, the grading layers and weights, the cap on unmeasured layers, the quota and caching rules, and the full set of error outcomes. An agent has everything needed to decide when to call it and to interpret the result.
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?
Even though schema description coverage is 100%, the description adds important behavioral meaning to the single url parameter: normalization rules (http upgrade, fragment drop, hostname lower-casing, query string identity), redirect handling, and the critical distinction between the final measured URL and the stored key. This extra context helps an agent pass the same URL to lekta_fix_plan and lekta_diff correctly.
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 opens with a specific verb and resource: 'Audits ONE live page for AEO (Answer Engine Optimization), also called GEO.' It names the grading scale (A+ to F) and the four weighted layers, and explicitly differentiates itself from siblings like lekta_report, lekta_fix_plan, and lekta_diff. An agent can immediately tell what this tool does and what it is not.
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?
The description gives explicit triggers ('USE THIS for "run an AEO audit", ...') and explicit exclusions ('DO NOT use it when code will parse the result', 'to compare two runs', etc.). It also states the scope boundary — one page, not a site — and clarifies when the same URL string must be passed to sibling tools. This is model usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compares the two most recent scorable audits stored for ONE URL and reports the movement: score and grade before → after, which checks improved, which regressed, with both run timestamps. This is the progress meter of the fix loop. USE THIS to prove a deploy actually moved the number: lekta_audit → apply the fixes → deploy → lekta_audit again → lekta_diff. DO NOT use it to compare two different URLs or two pages of one site — it takes ONE url and compares that page against its own history — and do not call it when fewer than two scorable audits exist for that URL, which returns an error rather than a partial answer. For the ranked work list use lekta_fix_plan; for the current state of a page use lekta_audit. COST AND BEHAVIOUR: free and idempotent — reads storage only, no fetch, no quota; it never triggers an audit, so no diff exists until you have run lekta_audit twice yourself. Runs that could not be scored (grade U) and runs where a rule crashed server-side are excluded from the comparison entirely, so a failed re-audit is never reported as a regression — it simply is not there. When the engine version changed between the two runs the output says so, because part of the delta is then ours rather than yours.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Required. An absolute http(s) URL with at least two stored scorable audits, e.g. "https://example.com/pricing". Same normalisation and the same keying rule as lekta_fix_plan: history is stored under the URL passed to lekta_audit, not the post-redirect final URL. One URL only — this compares a page with its own past, never with another page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent, and the description adds concrete behavioral details: it reads storage only, performs no fetch, uses no quota, and never triggers an audit. It also explains that failed or unscored runs are excluded and that engine-version changes are flagged, with no contradiction against the annotations.
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?
Although the description is long, it is front-loaded with the core purpose and every sentence adds distinct operational guidance. The workflow, negative cases, cost/behaviour notes, exclusion rules, and engine-version caveat are all non-redundant and earn their place.
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?
Given there is no output schema, the description still explains the key output semantics: before/after score and grade, which checks improved or regressed, and both run timestamps. It also covers important edge cases like failed audits being excluded and engine-version changes being reported, so the agent has enough context to use the tool correctly.
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 single url parameter is fully described: it must be an absolute http(s) URL with at least two stored scorable audits, an example is provided, and the normalisation and keying rule are explicitly tied to lekta_fix_plan. It also clarifies that only one URL is accepted and that history is keyed under the pre-redirect URL passed to lekta_audit.
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 opens with a specific verb and resource: 'Compares the two most recent scorable audits stored for ONE URL'. It also clearly distinguishes the tool from siblings by stating it must not be used to compare two different URLs and points to lekta_fix_plan and lekta_audit for other tasks.
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?
It gives an explicit when-to-use workflow: 'lekta_audit → apply the fixes → deploy → lekta_audit again → lekta_diff'. It also gives explicit negative conditions: do not call with fewer than two scorable audits and do not use to compare different URLs, while naming alternative tools for those cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turns the most recent STORED audit of a URL into an ordered remediation plan: every failing or warned check as a numbered step, biggest point recovery first, each with its severity, the points that fixing it is expected to regain, and the full fix text. Reads storage only and never fetches, so the plan is exactly as fresh as the last audit of that URL — and any audit of it counts, whether it was started over MCP or from the lekta.dev panel. USE THIS between lekta_audit and the code change, to decide what to fix and in what order, or to hand a developer or another agent a prioritised AEO/GEO work list. It keeps working when the daily fresh-audit quota is exhausted. DO NOT use it to measure or re-measure a page (lekta_audit does that), and do not call it for a URL that was never audited — it returns an error telling you to run lekta_audit first, not an empty plan. For what changed between two runs use lekta_diff; for the raw structured data use lekta_report. COST AND BEHAVIOUR: free and idempotent — no fetch, no quota, no rate limit; it never starts an audit under any circumstance, and repeat calls return the same plan until a newer audit lands. When the stored audit came from an older engine version the output says so and marks the point estimates unreliable. When it has no failing or warned checks, the tool reports that instead of inventing work.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Required. An absolute http(s) URL that already has a stored audit, e.g. "https://example.com/pricing". Normalised like the lekta_audit url (https assumed when the scheme is missing, #fragment dropped, hostname lower-cased, query string significant). History is keyed on the URL that was PASSED to lekta_audit, never the final URL after a redirect — so if the audit reported a redirect, still pass the address you originally sent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower, but the description still adds substantial context: reads storage only and never fetches, freshness is tied to the last audit from any source (MCP or panel), works when the daily audit quota is exhausted, errors loudly for never-audited URLs instead of failing silently, flags older-engine audits as having unreliable estimates, and reports an empty plan rather than inventing work. No contradiction with annotations.
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?
The description is long, but every clause earns its place: core function first, then behavioral constraints, then usage directions, then edge-case behaviors. The USE THIS/DO NOT use contrast is efficient, and the redundancy between 'reads storage only' and the readOnlyHint annotation is minor because it carries the freshness implication. Slightly dense, but not padded.
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?
There is no output schema, so the description correctly carries the burden of describing the return value (numbered steps, severity, points, fix text) and covers the edge cases an agent would hit in practice: never-audited URL, older engine version, no failing checks, and quota exhaustion. Given a single well-documented parameter, nothing an agent needs to call it correctly is missing.
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%, so the baseline is 3. The schema already documents URL normalization (https assumption, fragment dropping, case-folding, query significance) and the redirect-keying caveat. The tool description itself adds no parameter-level information beyond the schema, but with full coverage it does not need to — baseline 3 is appropriate.
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 opens with a specific verb and resource: "Turns the most recent STORED audit of a URL into an ordered remediation plan," and enumerates exactly what the plan contains (numbered steps, severity, expected point recovery, fix text). It clearly distinguishes itself from lekta_audit by being a planning tool, not a measurement tool, and from lekta_report by its remediation-plan shape.
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?
Explicit positioning: "USE THIS between lekta_audit and the code change" names the exact workflow slot, and "DO NOT use it to measure or re-measure a page (lekta_audit does that)" names the sibling alternative with the exclusion condition. It also states the never-audited precondition and the error behavior that follows, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the sites saved on the authenticated Lekta account: URL, latest authoritative grade and score, when it was last audited, and the recheck interval where a schedule is on. This is account inventory, not a measurement. PARAMETERS: none — this tool takes no arguments; call it with an empty arguments object. USE THIS first in a session to see which URLs this account already tracks before picking one to pass to lekta_audit, lekta_fix_plan or lekta_diff, or to answer "which of my pages has the worst grade" and "which pages are on a schedule". DO NOT expect a fresh measurement (lekta_audit does that), sites belonging to other accounts, or arbitrary URLs — and do not expect to change anything here: sites are added and removed on the web panel at lekta.dev/en/panel, not over MCP. An account with no saved sites gets an explicit empty-list message, not an error. COST AND BEHAVIOUR: free and idempotent — no fetch to any site, no quota. Each grade shown is the last AUTHORITATIVE (scorable) run for that URL, the same definition the web panel and the badge use; when a newer attempt existed but could not be scored, that is stated on its own line, so the grade is neither hidden nor silently presented as current.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses additional behavioral details: 'no fetch to any site, no quota', the authoritative-grade semantics with explicit handling of unscored newer attempts, and the empty-list response instead of an error. These details meaningfully enhance transparency.
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?
The description is verbose and contains redundancy, such as repeating 'the same definition the web panel and the badge use' and restating idempotency and read-only behavior which are already in the annotations. While the structure uses clear sections, several sentences could be trimmed without losing meaning.
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?
The description fully covers the tool's context: its purpose, output fields, edge cases (empty list, unscored newer attempts), and limitations (no fresh measurement, account scope, no mutation). Given the absence of an output schema, this prose provides a complete picture of what the caller can expect.
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 schema has no properties and coverage is 100%, so there is little to add. The description goes slightly beyond by explicitly stating 'PARAMETERS: none — this tool takes no arguments; call it with an empty arguments object', which reinforces the calling convention in prose.
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 clearly states the tool's primary function: 'Lists the sites saved on the authenticated Lekta account' and enumerates the returned fields (URL, grade, score, last audit, recheck interval). It also differentiates itself from siblings by calling it 'account inventory, not a measurement' and by contrast with lekta_audit.
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?
The description explicitly instructs when to use this tool: 'USE THIS first in a session to see which URLs this account already tracks before picking one to pass to lekta_audit, lekta_fix_plan or lekta_diff'. It also states when not to use it, e.g., 'DO NOT expect a fresh measurement (lekta_audit does that)' and clarifies account scope and panel-based management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs the same page audit as lekta_audit and returns the whole report as one JSON document instead of Markdown — for programs, not people. Top-level fields: engineVersion, url (as requested), finalUrl, fetchedAt, durationMs, targetState, robotsDisallowsLektaBot, score (0-100, null when the target could not be measured), grade, coverage, coverageNote, appliedCaps, movers, warningCount, failCount, and fetchMeta (HTTP status, redirect chain, content type, bytes). layers[] carries each layer definition (name, weight) with its score, and layers[].checks[] every check with id, title, status (pass / fail / warn / info / not_applicable / unmeasured), severity, evidence values and full fix text. Scoring internals are stripped by design — rule source names, reference URLs and threshold rationale are absent; each check keeps only its dated evidence-class tag (SPEC, VENDOR, MEASUREMENT, PEER-REVIEWED or PROVISIONAL). USE THIS when code consumes the result, or when you need a field the Markdown verdict never prints: check ids, per-layer scores, raw evidence values, the redirect chain. DO NOT use it to show a person a verdict (lekta_audit is shorter and ranked by point impact), do not call it after lekta_audit for the same URL expecting new data (it is the same measurement in another shape), and do not reach for it to learn WHY a rule exists — that material is deliberately not in the payload. COST AND BEHAVIOUR: the same fetch, 15-minute cache, quota and limits as lekta_audit, with two differences — the JSON carries no quota line, so call lekta_audit when you need the count used, and nothing here is ranked: checks arrive in layer order, not by point impact.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Required. One absolute http(s) page URL, e.g. "https://example.com/pricing". Handled exactly like the lekta_audit url: a missing scheme becomes https, the #fragment is dropped, the hostname is lower-cased, the query string is significant, and it is one page per call — no domain lists or sitemaps. A URL already audited within the last 15 minutes returns the cached run and spends no quota. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, open-world, and non-destructive behavior; the description adds valuable behavioral context above that: the same fetch, 15-minute cache, quota limits, absence of a quota line, and deliberate stripping of scoring internals while retaining evidence-class tags. These details materially affect how an agent interprets results and manages calls.
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?
The description is long but every sentence is informative and the core purpose is front-loaded in the opening sentence. The first paragraph is a dense single-sentence enumeration of fields that could be more scannable, but it is structured into two logical sections and achieves a good signal-to-noise ratio.
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 no output schema, the description fully carries the burden of explaining the JSON response shape, and it does so thoroughly: top-level fields, layers/checks structure, status enum, evidence-class tags, and the explicit absence of ranking and scoring internals. Caching, quota behavior, and differences from lekta_audit are also covered. Nothing important for correct invocation and interpretation is missing.
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 input schema already provides a thorough description of the url parameter (absolute http(s), scheme defaulting, fragment dropping, hostname lower-casing, query significance, one page per call, and cache behavior). Schema description coverage is 100%, and the tool description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.
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 ('runs the same page audit') and output resource ('whole report as one JSON document'), and explicitly contrasts it with the Markdown output of lekta_audit. The phrase 'for programs, not people' clarifies the intended consumer. This fully distinguishes it from its most similar sibling.
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?
Explicitly says when to call lekta_audit instead (when the quota count is needed) and notes that the JSON carries no quota line. It also warns that nothing is ranked and that checks arrive in layer order, helping an agent decide whether this format fits the use case. While it doesn't discuss lekta_diff or lekta_fix_plan, those differ in tool purpose and are not confusable.
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.
lekta_audit1 field changedInput schema / properties / url / descriptionPrevious value: -"Absolute http(s) URL of ONE page, e.g. https://example.com/pricing. Not a domain list, not a sitemap — audit a representative content page, not only the homepage."New value: +"Required. The one absolute http(s) page URL to audit, e.g. \"https://example.com/pricing\". A bare host+path (\"example.com/pricing\") is accepted and upgraded to https; the #fragment is dropped and the hostname lower-cased, but the query string is kept and is part of the page identity (?variant=b is a distinct target). ONE page per call — not a domain, a sitemap or a list. Prefer a representative content page over the homepage: scoring is per-URL, not per-site. Redirects are followed and the verdict names the final measured URL, but the audit is STORED under the URL you pass here — give lekta_fix_plan and lekta_diff this same string, not the redirect destination."lekta_diff1 field changedInput schema / properties / url / descriptionPrevious value: -"Absolute http(s) URL with at least two stored audits"New value: +"Required. An absolute http(s) URL with at least two stored scorable audits, e.g. \"https://example.com/pricing\". Same normalisation and the same keying rule as lekta_fix_plan: history is stored under the URL passed to lekta_audit, not the post-redirect final URL. One URL only — this compares a page with its own past, never with another page."lekta_fix_plan1 field changedInput schema / properties / url / descriptionPrevious value: -"Absolute http(s) URL that was audited before"New value: +"Required. An absolute http(s) URL that already has a stored audit, e.g. \"https://example.com/pricing\". Normalised like the lekta_audit url (https assumed when the scheme is missing, #fragment dropped, hostname lower-cased, query string significant). History is keyed on the URL that was PASSED to lekta_audit, never the final URL after a redirect — so if the audit reported a redirect, still pass the address you originally sent."lekta_report1 field changedInput schema / properties / url / descriptionPrevious value: -"Absolute http(s) URL of ONE page, e.g. https://example.com/pricing"New value: +"Required. One absolute http(s) page URL, e.g. \"https://example.com/pricing\". Handled exactly like the lekta_audit url: a missing scheme becomes https, the #fragment is dropped, the hostname is lower-cased, the query string is significant, and it is one page per call — no domain lists or sitemaps. A URL already audited within the last 15 minutes returns the cached run and spends no quota."lekta_auditlekta_difflekta_fix_planlekta_my_siteslekta_reportAEO audit: score any website 0-100 for AI visibility. Checks schema, meta, content, AI crawlers.
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.
Free AI-readiness audit of any URL: AI crawler rules, JS-free text, JSON-LD, llms.txt. Tool catalog.
Free SEO, GEO, and AEO audits: analyze any page or domain, AI-crawler access, agent readiness.
Add one secure layer between your agents and this server.
