Skip to main content
Glama

Get SEO Audit

get_audit
Read-only

Reads one SEO Audit of a site, by default the latest, as a report per category: status, stage, crawl progress, each category’s state and a seoAuditUrl that opens the site’s SEO Audit page in Keytomic. A finished category adds its finding and limitation counts and, for audits from crawlers with live category summaries, its issue, advisory and check counts and top findings; older audits leave these null. A category fails only for a high-severity issue, warns for any other issue, a limitation or a check that warns or fails, and passes otherwise; advisories alone leave it passing. Check counts count checks, not findings. While the audit is queued or running, follow it with watch_audit. Once it is completed or partial, it includes the summary: per category its status, finding and check counts and its 0–100 Category Health score with band; the 0–100 Website Health score with band; reportAreas; the Start Page’s metrics; PageSpeed scores per strategy (null when the strategy did not run); average and median time to first byte; the top 20 findings (key, title, severity, affected count), coverage and limitations. reportAreas has one entry per Report Area of the run’s mapping version, in display order, with the crawler’s label. Each entry has its 0–100 Area Health score with band and its passed, warning, failed and notApplicable check counts. notApplicable counts the area’s not applicable checks, which are not assessed; it is null on audits stored before the crawler counted them. For Performance, strategy names the PageSpeed strategy behind the score. An area has no weight and feeds no other score. The deductions behind the score are left out. An area without a score gives a reason: not_scored (stored before Report Areas), not_executed, unavailable, undeclared_finding_code, no_pagespeed_score (Performance only) or no_checks_assessed. Scores are null with a reason when there is none, and audits from older crawlers leave the newer fields null. It leaves out evidence: read it with list_audit_findings and list_audit_rows. Pass category to read only that category’s report from a finished audit: its status, every check with its status and row count, its findings and limitations; read a check’s rows with list_audit_rows. A failed or cancelled audit includes the crawler’s error. To compare audits, read each one by runId.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectId": "<projectId>"
    },
    "name": "get_audit"
  }
}

Input Schema

NameRequiredDescriptionDefault
runIdNoSEO Audit to read. Defaults to the latest one.
categoryNoCategory whose report to read instead of the whole audit. The audit must be finished.
projectIdYesSite to read, from list_sites. Its SEO Audits are read.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=true, and the description adds substantial behavior beyond them: status-dependent output, null fields for older audits, failure/warn/pass category semantics, score-reason values, and crawler errors on failed or cancelled audits. Nothing contradicts 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the description is a dense single paragraph with extensive scoring, null-handling, and report-shape detail. Much of that detail is justified because there is no output schema, but the structure could be clearer and some points are repetitive.

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?

With no output schema, the description carries the full burden of explaining return values, and it does so thoroughly: category reports, summary fields, health scores, reportAreas, null behavior, score reasons, and error handling. It is complete for an agent to invoke and interpret the tool correctly.

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%, and the schema already documents runId defaulting to latest, category requiring a finished audit, and projectId coming from list_sites. The description elaborates what the category report contains, but adds limited parameter-level meaning beyond the already complete schema, so the baseline of 3 applies.

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 states a specific verb and resource: 'Reads one SEO Audit of a site', with the latest audit as the default. It clearly distinguishes the tool from watch_audit for in-progress audits and from list_audit_findings/list_audit_rows for evidence.

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 explicit routing guidance: use watch_audit while queued or running, use this tool once completed or partial, use list_audit_findings/list_audit_rows for evidence, pass category only for finished audits, and read each runId to compare audits. These are concrete when-to-use and alternative-tool instructions.

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