Skip to main content
Glama
HalidSaglam

saglitzdesign-mcp

by HalidSaglam

Audit Seo Geo

audit_seo_geo
Read-onlyIdempotent

Audit source code for missing titles, meta descriptions, heading issues, canonical errors, hreflang gaps, invalid JSON-LD, missing alt text, robots.txt and llms.txt problems. Get structured findings with rule, severity, and fix.

Instructions

Audit a page, a component or a whole web project for the SEO and GEO signals that are actually in the source: a missing , and one longer or shorter than the width a result gives it; a missing meta description, and one outside the width a snippet gives it; more than one on a page; a heading level skipped in the outline; no canonical link at all; a canonical written as a relative URL in a self-contained document; a canonical left pointing at localhost or a staging host; an hreflang set that never lists the page itself; JSON-LD that does not parse, or that declares no @context or @type; JSON-LD declaring a type whose rich result Google has retired; an image with no alt attribute at all; robots.txt crawl rules, including the AI crawlers behind ChatGPT, Claude, Perplexity and Google's AI surfaces; a robots.txt that names no sitemap; no llms.txt beside it; and content that exists only once a script has run. It reads source and does not measure anything: no request is made to your site, nothing is rendered, and no finding is or can be a Core Web Vitals result, an indexing status or a ranking outcome — so do not call it expecting a vitals or ranking report. Absence is only ever claimed where it can be proven — a self-contained HTML document, or a whole directory — and a scan that hits its cap downgrades every absence claim to an unconfirmed note. Returns markdown plus structured output: findings (rule, severity, message, fix, doc, file, line), a severity summary, and a machine-readable notVisible list of what it could not check. A missing or non-directory path is returned as an error result, not as an empty audit. Pair with audit_performance for the delivery signals, audit_ux_copy for whether the writing earns the click, and seo_geo_guide for the guidance behind the rules.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNoA single snippet to audit instead of a directory. Page rules only.
pathNoDirectory to audit. Absolute paths are strongly preferred. This is the useful mode — robots.txt, llms.txt, sitemap and project-wide metadata rules all need a directory.
filenameNoFilename for the snippet, e.g. 'index.html' or 'page.tsx'. Load-bearing: a plain HTML file carries its whole <head> and can prove metadata absent, a framework component cannot.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
summaryYesCounts by severity. Always agrees with `findings` — it is derived from the same list.
findingsYesEvery finding, in the order the markdown report lists them.
notVisibleYesWhat this audit structurally could not check, one limitation per entry. Read it as a peer of `findings`: silence on a subject named here is this tool's reach, not a clean result. Nothing any of these tools reports is measured.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Addedv0.28.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces them with concrete behavior: 'no request is made to your site, nothing is rendered'. It goes well beyond annotations by disclosing the proof policy for absence claims, the cap's downgrading of claims to 'unconfirmed notes', and the error result for missing/non-directory paths — all genuinely useful behavioral context.

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?

Every sentence carries information, and the definition is appropriately sized for a complex tool with exclusions, modes, and sibling routing. However, it is delivered as one dense unbroken paragraph — the long enumeration of checks is a sprawling run-on — which makes it harder for an agent to parse quickly than the content justifies.

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?

For a three-parameter, two-mode tool with an output schema, the description is complete: it enumerates all rule categories, states the safety profile, explains the absence-proof policy and cap behavior, describes the return shape, documents the error condition, and routes to complementary tools. Nothing an agent needs to invoke this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds real meaning above the schema: that code mode runs 'page rules only', that path mode is needed for robots.txt/llms.txt/sitemap rules, and that filename is 'load-bearing' because a plain HTML file can prove metadata absent while a framework component cannot. This explanation of the code/path/filename interplay is valuable beyond the field descriptions.

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 opening sentence states a specific verb ('Audit') and resource ('SEO and GEO signals that are actually in the source') and enumerates an exhaustive, concrete list of checks. It further sharpens the definition by stating what it is not ('no request is made to your site... not a vitals or ranking report'), which cleanly distinguishes it from audit_performance and other siblings.

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?

The description gives an explicit when-not ('do not call it expecting a vitals or ranking report'), names complementary siblings with their distinct roles ('audit_performance for the delivery signals, audit_ux_copy for whether the writing earns the click, seo_geo_guide for the guidance behind the rules'), and even tells the agent which mode is the 'useful mode' (path over code). This is exemplary routing guidance.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/HalidSaglam/saglitzdesign-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server