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
Fetches ONE page exactly the way answer engines do (plain GET as LektaBot + a Chromium render pass) and grades it A+ to F across four layers: Access (robots.txt permissions for ~17 AI crawler tokens), Indexability (how much content exists without JavaScript), Answerability (is there a quotable answer) and Recency (is the page dated). Returns a readable verdict: grade, the issues ranked by point impact, and the complete fix for each. USE THIS when you need the current state of a page or after deploying fixes. DO NOT use it for machine parsing (use lekta_report for JSON), for planning without a new measurement (lekta_fix_plan), or to compare two runs (lekta_diff). COST AND BEHAVIOUR: takes 5-30 s (75 s hard limit), honors robots.txt, consumes one fresh-audit slot from the daily MCP quota; a repeat call within 15 minutes returns the cached measurement for free. The audited site is never modified.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial non-obvious behavior beyond that: it performs a plain GET as LektaBot plus a Chromium render pass, honors robots.txt, takes 5-30 s with a 75 s hard limit, consumes one fresh-audit slot from the daily MCP quota, returns cached results for free within 15 minutes, and 'never modifies' the audited site. The no-modification statement aligns with the readOnly/destructive annotations with no contradiction.
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?
Though longer than average, the description is explicitly structured with labeled sections: core behavior, returned verdict, USE THIS, DO NOT use, and COST AND BEHAVIOUR. Every sentence carries operational information an agent needs for invocation decisions, and the most important scoping facts are front-loaded in the first sentence and the USE/DO NOT section.
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 covers everything an agent needs: fetch mechanics, grading criteria, return value shape (grade, ranked issues, full fixes), latency, quota cost, caching, robots.txt behavior, and a no-side-effects guarantee. Sibling exclusions are complete and explicit, so the agent can decide correctly without opening other definitions.
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%, so the baseline is 3; the schema already documents the url format, the one-page constraint, and the guidance to audit a representative content page. The description adds meaning by framing the parameter as the subject of a four-layer grading and reinforcing 'ONE page,' which helps the agent understand why the url choice matters for the audit output. This is meaningful but modest value on top of a thorough 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?
The description opens with a specific verb and resource: 'Fetches ONE page exactly the way answer engines do' and grades it A+ to F across four named layers (Access, Indexability, Answerability, Recency). It also differentiates from siblings by explicitly naming what lekta_report, lekta_fix_plan, and lekta_diff are for, so an agent can distinguish this tool without inspecting other definitions.
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 when-to-use ('when you need the current state of a page or after deploying fixes') and when-not-to-use guidance, each with named alternatives: lekta_report for machine parsing, lekta_fix_plan for planning without a new measurement, and lekta_diff for comparing two runs. This is the strongest possible usage guidance with zero inference required.
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 stored audits of one URL: grade and score movement, which checks improved, which regressed. This is the progress meter of the fix loop — call it after re-auditing to prove a fix worked. USE THIS after a deploy plus a fresh lekta_audit. DO NOT use it to compare two different URLs, and do not expect a result when only one audit exists. COST: free, reads stored data only.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute http(s) URL with at least two stored audits |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, and the description adds that it 'reads stored data only' and is free, reinforcing the read-only safety profile. It also discloses a key behavioral limitation: no result is produced until at least two audits are stored. This goes beyond the annotations by explaining the preconditions and the operational context of the diff.
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 dense and well-structured: core behavior first, then usage timing, then exclusions and cost. It loses a point for minor redundancy — 'call it after re-auditing' and 'USE THIS after a deploy plus a fresh lekta_audit' convey overlapping guidance. Still, every sentence carries operational value, so it remains above average.
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 one-parameter tool with no output schema, the description gives the agent everything needed: what the result contains (grade and score movement, improved/regressed checks), when to call it, when not to call it, and the required precondition (at least two stored audits). Cost and read-only behavior are also stated. Nothing important is missing for correct invocation and interpretation.
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% — the single required param 'url' is documented as 'Absolute http(s) URL with at least two stored audits.' The description adds nuance by emphasizing it must be one URL, not two, and clarifies that the URL is the anchor of the diff operation. This adds semantic framing beyond the bare schema description.
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 stored audits of one URL' and then specifies exactly what is compared — grade and score movement, which checks improved, which regressed. It also positions the tool relative to its sibling lekta_audit by framing it as the follow-up that proves a fix worked, so an agent can distinguish it from the other lekta tools.
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 is explicit about when to use it: 'call it after re-auditing to prove a fix worked' and 'USE THIS after a deploy plus a fresh lekta_audit.' It also provides concrete exclusions: 'DO NOT use it to compare two different URLs' and warns not to expect a result when only one audit exists. That is clear when-to-use and when-not-to-use guidance.
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 work plan: each fix with the points it is expected to recover, hardest-hitting first. USE THIS to decide what to change before touching the code. DO NOT use it to measure — it never fetches the page; if the URL was never audited it returns nothing and you must call lekta_audit first. COST: free, reads stored data only, and never spends quota.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute http(s) URL that was audited before |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses that it never fetches the page, reads stored data only, returns nothing for unaudited URLs, and never spends quota. These are material behaviors not inferable from the schema or annotations, and they align with 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?
The description is dense and front-loaded: core function, then usage directive, then cost and edge case. It loses a point for mild redundancy among 'reads stored data only', 'never fetches the page', and 'never spends quota', but each sentence otherwise 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?
With one parameter, no output schema, and safety annotations already present, the description fully equips the agent: it names the prerequisite (prior audit), the output shape ('ordered work plan... hardest-hitting first'), the failure mode, and the cost behavior. Nothing essential 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 covers the single URL parameter at 100% with 'Absolute http(s) URL that was audited before'. The description adds the concept of 'MOST RECENT stored audit' and the empty-return edge case, but does not substantially enrich parameter meaning beyond the schema, so baseline 3 applies.
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?
Description states a specific verb ('Turns the MOST RECENT stored audit into an ordered work plan') and resource ('MOST RECENT stored audit of a URL'), and clarifies it is for planning fixes, not for measuring. This distinguiishes it from sisblings like lekta_audit or lekta_report.
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 directs when to use ('USE THIS to decide what to change before touching the code') and when not to ('DO NOT use it to measure'), and routes the agent to call lekta_audit if the URL was never audited. This is perfect usage guidance.
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 with the latest grade, score and scheduled-recheck setting. USE THIS to see what this account already tracks before auditing something new. DO NOT expect sites from other accounts or a fresh measurement — it reads stored state only. COST: free, takes no parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, and non-destructive. The description adds valuable context beyond those annotations: it reads stored state only, is scoped to the authenticated account, and returns no fresh measurement. This fully clarifies the behavior without contradicting 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 compact and front-loaded with the core return value. Every sentence earns its place: what it lists, when to use it, what not to expect, and cost/parameter confirmation. The CAPS usage emphasses key operational guidance without bloating length.
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 zero-parameter, read-only list tool with strong annotations, the description is complete. It communicates scope, the stored-state limitation, the returned fields, and the intended use case. No output schema exists, but the description sufficiently describes what to 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 tool takes zero parameters, and the description explicitly confirms this ('takes no parameters'). With no parameters to document, the description adequately covers the parameter semantics, though it mostly restates the 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?
The description states a specific verb ('Lists'), a clear resource ('sites saved on the authenticated Lekta account'), and the exact information returned (latest grade, score, scheduled-recheck setting). It also distinguishes this tool from a fresh audit by explicitly saying it reads stored state only.
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 clearly says when to use it ('before auditing something new') and gives useful exclusions ('DO NOT expect sites from other accounts or a fresh measurement'). It does not explicitly name sibling alternatives like lekta_audit, but the context strongly implies the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Same measurement as lekta_audit but returned as the complete structured JSON report: every layer, every check with its status, evidence and fix text. USE THIS when a program (not a human) consumes the result, or when you need a field lekta_audit does not print. DO NOT use it for a quick human-readable verdict (lekta_audit is shorter and ranked by impact). COST: identical to lekta_audit — the cached report is free, otherwise it spends one fresh-audit slot.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute http(s) URL of ONE page, e.g. https://example.com/pricing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this read-only and non-destructive. The description adds useful behavioral context beyond annotations: cost is identical to lekta_audit, cached reports are free, otherwise it spends one fresh-audit slot. This is meaningful operational behavior not encoded in 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?
The description is compact and front-loaded with the core distinction, followed by clear usage guidance and cost context. Every sentence contributes information, with no redundant filler.
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?
Despite having no output schema, the description covers what the return value contains, when to use it, when not to use it, and cost/behavioral implications. With only one parameter and no output schema, this is complete guidance for an agent to select and invoke 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?
Schema coverage for the single parameter is 100%, so the schema fully documents the URL field. The description reinforces that it is 'ONE page' but does not meaningfully extend parameter semantics beyond the schema. 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 states a specific verb-like action ('returned as the complete structured JSON report') and clearly identifies the resource as a full audit report with every layer, check status, evidence, and fix text. It explicitly distinguishes itself from lekta_audit by contrasting JSON completeness with shorter human-readable output.
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?
Provides explicit when-to-use guidance: use when a program consumes the result or when a field lekta_audit does not print. It also gives a clear do-not-use condition ('quick human-readable verdict') and names the alternative (lekta_audit) directly.
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. Dates show when Glama detected each change.
lekta_auditlekta_difflekta_fix_planlekta_my_siteslekta_reportClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
AEO audit: score any website 0-100 for AI visibility. Checks schema, meta, content, AI crawlers.
Free SEO, GEO, and AEO audits: analyze any page or domain, AI-crawler access, agent readiness.
Scan any website's AI readiness: AI search visibility and AI agent usability. Free, no auth.
Run SEO + AI-visibility (GEO) audits from Claude, Cursor & other AI clients.
Add one secure layer between your agents and this server.
The tools divide into clear workflow stages, but there is real overlap: lekta_audit and lekta_report are the same measurement with different output formats, and lekta_audit already returns prioritized fixes, so it can easily be confused with lekta_fix_plan. The explicit usage notes help, but an agent could still misselect if it only needs fresh data or fix guidance.
All tool names share the lekta_ prefix and snake_case, giving a predictable family convention. The set is not a strict verb_noun pattern: lekta_my_sites is a noun phrase and lekta_audit/lekta_report are noun/verb ambiguities, but the deviations are minor.
Five tools is well-scoped for an audit-and-remediation workflow: fresh measurement, structured JSON, diff comparison, fix planning, and site listing. Every tool contributes to the workflow and the count is in the ideal range.
The core measure-plan-fix-verify loop is covered end to end, especially with lekta_diff to prove fixes worked. Minor gaps remain around account administration (no add/remove sites or recheck-schedule changes) and no explicit quota/history view, but these are workarounds.
