Skip to main content
Glama

Lekta — AEO/GEO Audit for AI Answer Engines

Compare the last two audits of a page

lekta_diff
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesRequired. 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / url / description
      Previous 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."
  2. First observed

TDQS

A5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources