Skip to main content
Glama

seo_link_audit

Audit cached scan_site results to find link-equity issues like missing metadata, noindex pages, thin content, broken links, orphan pages, and schema/OG gaps; run scan_site first.

Instructions

Audit the cached scan_site result for problems that waste or block link equity: missing titles/ descriptions/canonicals, noindex, thin pages, missing schema/OG, broken links, orphan pages. Run scan_site first.

Input Schema

NameRequiredDescriptionDefault
domainYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description carries the full burden; it does disclose that the tool operates on cached rather than live data and lists exactly which issue classes are reported. However, it never states that it is read-only/non-mutating, whether it refreshes or invalidates the cache, or what form the findings take, so behavioral coverage is partial.

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?

Two sentences: the action and its audit scope first, the prerequisite last. The colon-delimited list delivers dense information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, no-output-schema tool this is close, but the description leaves open what an agent gets back and how findings are structured or scored, and it doesn't address the failure case of an unscanned domain. No return-format detail is strictly required, but some indication would round it out.

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 coverage is 0% for the single `domain` parameter, so the description must compensate, and it partially does by implying the domain identifies which cached scan_site result to audit. It never states that the domain must match a previously scanned site or how mismatches are handled.

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?

"Audit the cached scan_site result" gives a specific verb (audit) and resource (cached scan output), and the enumerated problem categories (titles, canonicals, noindex, thin pages, schema/OG, broken links, orphans) define the scope precisely. It is clearly distinct from the sibling scan_site, which produces the data this consumes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Run scan_site first" states an explicit prerequisite and, by naming the sibling, routes the agent to the right first step. It lacks any when-not-to-use or alternative path (e.g., what to do if no cached scan exists), which keeps it below a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.