Can AI actually read your page? ChatGPT, Perplexity and other answer engines fetch pages very differently from your browser. Paste a URL — Lekta fetches it exactly the way they do and grades it A+ to F, with the spec or measurement behind every finding.
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 provide readOnlyHint=true and destructiveHint=false, but the description adds substantial behavior: plain GET as LektaBot plus a Chromium render pass, honors robots.txt, consumes a daily fresh-audit slot, caches for 15 minutes, takes 5-30 seconds, and 'The audited site is never modified.' This goes well beyond the structured hints and does not contradict them.
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 front-loaded with the core verb, scope, and grading layers, then organized into usage, exclusions, and cost/behavior sections. Despite its length, every sentence contributes distinct, actionable information such as quota, caching, timing, and alternative routing.
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 still explains the return shape: 'grade, the issues ranked by point impact, and the complete fix for each.' It also covers performance limits, quota behavior, caching, robots.txt handling, and non-modification, so an agent has everything needed to invoke it 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 already has 100% schema description coverage, including 'Absolute http(s) URL of ONE page' and 'Not a domain list, not a sitemap.' The tool description reinforces the one-page scope and adds fetch-mode context, but it does not add new parameter format or constraint details beyond what the schema already provides.
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 action and resource: 'Fetches ONE page exactly the way answer engines do' and grades it A+ to F across four named layers. It also clearly distinguishes itself from siblings by naming when to use it versus the alternatives.
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 contains explicit guidance: 'USE THIS when you need the current state of a page or after deploying fixes' and 'DO NOT use it for machine parsing... planning without a new measurement... or to compare two runs.' It names the correct alternative tool for each excluded case, leaving no ambiguity.
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=true and destructiveHint=false; the description adds that the tool is 'free' and 'reads stored data only,' and discloses a hard precondition: no result when only one audit exists. This is useful context beyond the annotations, though the core safety profile is already covered by them.
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 front-loaded with what the tool does, then gives usage and exclusion guidance. It is slightly redundant—'call it after re-auditing' and 'USE THIS after a deploy plus a fresh lekta_audit' overlap—but still economical and well structured.
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 documented parameter, no output schema, and clear annotations, the description covers what the tool returns, when to use it, when not to use it, preconditions, and cost. Nothing essential for an agent to select and invoke 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 coverage is 100% for the single 'url' parameter, so the baseline is 3. The description adds meaningful semantic clarification that only one URL may be passed and that the tool compares audits within that URL's own history, not two separate URLs. This prevents a natural misunderstanding for a diff-like tool.
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 uses a specific verb and resource: 'Compares the two most recent stored audits of one URL' and names the concrete outputs: 'grade and score movement, which checks improved, which regressed.' This clearly distinguishes lekta_diff from siblings 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?
The description gives explicit when-to-use guidance: 'call it after re-auditing to prove a fix worked' and 'USE THIS after a deploy plus a fresh lekta_audit.' It also gives exclusions: 'DO NOT use it to compare two different URLs' and warns that a result should not be expected when only one audit exists.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, but the description adds substantial behavior: the tool never fetches the page, never spends quota, returns nothing for unaudited URLs, uses the most recent stored audit, and orders fixes by expected point recovery. No contradiction with annotations exists.
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?
Every sentence earns its place: the main function is stated first, followed by clear usage directives, an exclusion, a failure mode, and cost behavior. The description is information-dense without redundancy or 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?
Even without an output schema, the description tells the agent what the result will look like (an ordered work plan with fixes and expected points), the prerequisite for successful invocation (URL previously audited), the failure behavior (returns nothing), and the remediation path (call lekta_audit first). Nothing essential is missing for correct selection and invocation.
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 documents the url parameter (absolute http(s) URL that was audited before), so the baseline is 3. The description adds meaningful parameter behavior: the URL must have a stored audit, otherwise it returns nothing and lekta_audit must be called first. It also clarifies the URL maps to the most recent stored 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 uses a specific verb and resource: it turns the most recent stored audit of a URL into an ordered work plan, listing fixes with recoverable points and hardest-hitting first. It explicitly contrasts itself with measurement tools, distinguishing it from siblings like 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 gives explicit when-to-use guidance ('USE THIS to decide what to change before touching the code'), explicit when-not-to-use guidance ('DO NOT use it to measure'), and names the alternative action ('call lekta_audit first'). This leaves no ambiguity about tool selection.
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 the tool readOnly, idempotent, non-destructive, and closed-world. The description adds useful behavioral context beyond those annotations by clarifying that it 'reads stored state only' and does not produce a 'fresh measurement,' which is important for an agent deciding whether results are current.
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: the core listing behavior and returned fields appear in the first sentence, followed by use-case guidance and an explicit cost/parameter note. No sentence is wasted, and the formatting calls out the key caveat with 'DO NOT expect...'.
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 listing tool with no output schema, this description is complete: it explains what is returned (sites with grade, score, and scheduled-recheck setting), the stored-state limitation, and the account-scoped context. There are no missing behavioral or input considerations an agent would need to call it 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?
With zero parameters and an empty input schema, there is nothing for the description to explain; the baseline for a no-parameter tool is 4. The description reinforces this by noting 'takes no parameters,' so an agent will not invent arguments.
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 precise verb and object: it 'Lists the sites saved on the authenticated Lekta account' and names the specific fields returned (grade, score, scheduled-recheck setting). This distinguishes it clearly from siblings like lekta_audit or lekta_report, which target auditing and reporting rather than simply reading saved state.
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 instructs when to use the tool: 'USE THIS to see what this account already tracks before auditing something new.' It also gives exclusions, warning not to expect sites from other accounts or a fresh measurement, which routes the agent away from inappropriate expectations and toward sibling tools for those needs.
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?
Beyond the readOnlyHint=true annotation, the description discloses the cost behavior: the cached report is free, otherwise it spends one fresh-audit slot. This resource-consumption detail is valuable and not present in 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 structured into three purposeful parts: what it returns, when to use it versus lekta_audit, and cost behavior. Every sentence adds distinct value and nothing is redundant.
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 compensates by specifying the JSON report contents: every layer, every check, status, evidence, and fix text. It also covers usage context, alternatives, and cost, which is sufficient for correct invocation.
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 only parameter, url, is fully described in the input schema with a clear example. The description does not add parameter-specific detail, but schema coverage is 100%, so the schema already carries the burden.
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 explicitly states this tool returns the same measurement as lekta_audit but as a complete structured JSON report with every layer, check status, evidence, and fix text. This clearly distinguishes it from the sibling lekta_audit tool.
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 usage guidance: use it when a program consumes the result or when lekta_audit omits a needed field, and do not use it for a quick human-readable verdict. It also names lekta_audit as the alternative, making the decision unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming 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 or an account that owns the GitHub organization, then choose Claim with GitHub.
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!
Add one secure layer between your agents and this server.
Each tool has a clear role: audit and report are the same measurement with different output formats, but the descriptions explicitly separate human-readable verdicts from machine-readable JSON. Diff and fix plan operate on stored audits, and my_sites lists account sites, so there is only minor potential confusion between audit and report.
All tools share the lekta_ prefix and use snake_case, but the second part mixes verbs (audit), nouns (diff, report), and multi-word phrases (fix_plan, my_sites). The naming is readable and predictable enough, but it does not follow a single consistent verb_noun convention.
Five tools is well-scoped for a focused audit-and-fix workflow: measure, get details, plan fixes, compare progress, and list sites. No tool feels redundant, and the count is comfortably within the ideal range.
The tool surface covers the core lifecycle of auditing a page, retrieving structured results, planning fixes, and verifying improvement via diffs. Minor gaps exist, such as no tool to manage scheduled rechecks or delete sites, but these do not block the primary workflow.