Skip to main content
Glama

Lekta — AEO/GEO Audit for AI Answer Engines

Ordered path to A+ for an audited page

lekta_fix_plan
Read-onlyIdempotent

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.

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

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

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

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: "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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources