dev.lekta/lekta
REMOTE · LEKTA.DEV · SCANNED SEP 25
Audits how AI answer engines read a page and grades it A+ to F across four measured layers.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security74
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one. See how to fix → View diagnostics → Partial
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability63
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 2523 tokens (~504/item across 5 items; 5 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management60
- Stability observed for 18 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 5 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 6 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities60
- Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28. See how to fix → Fail
How do I install the dev.lekta/lekta MCP server?
dev.lekta/lekta is a hosted endpoint at https://lekta.dev/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · lekta.dev
claude mcp add --transport http dev-lekta-lekta 'https://lekta.dev/mcp'
{
"mcpServers": {
"dev-lekta-lekta": {
"url": "https://lekta.dev/mcp"
}
}
} {
"servers": {
"dev-lekta-lekta": {
"type": "http",
"url": "https://lekta.dev/mcp"
}
}
} [mcp_servers.dev-lekta-lekta] url = "https://lekta.dev/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"dev-lekta-lekta": {
"type": "remote",
"url": "https://lekta.dev/mcp",
"enabled": true
}
}
} openclaw mcp add dev-lekta-lekta --url 'https://lekta.dev/mcp' --transport streamable-http
mcp_servers:
dev-lekta-lekta:
url: "https://lekta.dev/mcp" {
"McpServers": {
"dev-lekta-lekta": {
"Transport": "http",
"Url": "https://lekta.dev/mcp"
}
}
} assistant mcp add dev-lekta-lekta -t streamable-http -u 'https://lekta.dev/mcp'
{
"mcpServers": {
"dev-lekta-lekta": {
"type": "http",
"url": "https://lekta.dev/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 25 Sept 26 +1
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 23 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 50 to 53. That category is still filling its 30-day observation window: 15 days of observed history at the previous scan, 16 at this one. The score rises as the window fills, whether or not the server changes.
- 21 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes.
- 18 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes.
- 16 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 27 to 30. That category is still filling its 30-day observation window: 8 days of observed history at the previous scan, 9 at this one. The score rises as the window fills, whether or not the server changes.
- 14 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.
- 12 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 13 to 17. That category is still filling its 30-day observation window: 4 days of observed history at the previous scan, 5 at this one. The score rises as the window fills, whether or not the server changes.
- 10 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 25 Sept 2026 · Probed https://lekta.dev/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=lekta.dev | CN=WE1,O=Google Trust Services,C=US | 8 Aug 2026 | 6 Nov 2026 | ECDSA 256 | ECDSA-SHA256 | e03990d3bea8af58130b197eb9d63974 |
| SANs: lekta.dev, *.lekta.dev | ||||||
| CN=WE1,O=Google Trust Services,C=US (CA) | CN=GTS Root R4,O=Google Trust Services LLC,C=US | 13 Dec 2023 | 20 Feb 2029 | ECDSA 256 | ECDSA-SHA384 | 7ff31977972c224a76155d13b6d685e3 |
| CN=GTS Root R4,O=Google Trust Services LLC,C=US (CA) | CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE | 15 Nov 2023 | 28 Jan 2028 | ECDSA 384 | SHA256-RSA | 7fe530bf331343bedd821610493d8a1b |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of lekta.dev. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| dev. | present | 60074 | 8 | Verified |
| lekta.dev. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
| Header | Value |
|---|---|
| x-content-type-options | nosniff |
| referrer-policy | no-referrer |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://lekta.dev/mcp | Verified | 200 | |
| http (plaintext) | http://lekta.dev/mcp | HTTPS enforced | 301 | https://lekta.dev/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
lekta_audit AEO / GEO audit: grade one page A+ to F ~811
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 har…
| Name | Type | Req | Description |
|---|---|---|---|
| url | string | 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… |
No output schema declared.
No examples provided.
lekta_diff Compare the last two audits of a page ~371
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 | Type | Req | Description |
|---|---|---|---|
| url | string | 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… |
No output schema declared.
No examples provided.
lekta_fix_plan Ordered path to A+ for an audited page ~420
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 | Type | Req | Description |
|---|---|---|---|
| url | string | 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… |
No output schema declared.
No examples provided.
lekta_my_sites List saved sites on this account ~282
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
lekta_report Full audit report as JSON ~492
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 | Type | Req | Description |
|---|---|---|---|
| url | string | 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-… |
No output schema declared.
No examples provided.
What is the dev.lekta/lekta MCP server?
dev.lekta/lekta is an MCP server listed in the public MCP registry as dev.lekta/lekta. Audits how AI answer engines read a page and grades it A+ to F across four measured layers. This page covers its hosted endpoint (https://lekta.dev/mcp).
Is the dev.lekta/lekta MCP server safe to use?
dev.lekta/lekta scores 76 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the dev.lekta/lekta MCP server expose?
dev.lekta/lekta exposes 5 tools: lekta_audit, lekta_report, lekta_fix_plan, lekta_diff, lekta_my_sites. Their descriptions and schemas cost roughly 2,376 tokens of context every time the server is loaded.
Does the dev.lekta/lekta MCP server require authentication?
No. We connected to dev.lekta/lekta without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the dev.lekta/lekta MCP server still maintained?
dev.lekta/lekta is still listed as active in the MCP registry. We last reached this channel on 25 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.