Skip to main content
Glama
Sign In

SEO Skill

by dev.seoskill
OverviewDiscussionsAdmin

Check copy for AI writing patterns

seo_lint
Read-only

Checks landing page copy, blog posts, titles and meta descriptions for patterns common in AI-written text (such as "isn't X, it's Y" reframes, ", not X" contrasts, two-beat fragments, stock idioms and kicker lines), weak copy (dash punctuation, buzzwords, vague link text) and SEO rules (title 30 to 60 characters, description 70 to 160, one H1). Each error and warning has a line, the words, and a concrete fix. Each finding has a category (ai, copy or seo); only limits the check, such as only ["ai"] to leave out house style like dashes. Review items are judgement calls for you: read each quote and change it only when it fails the question. A url checks the main content of a live page (CLI and local MCP only). It reads no accounts.

Input Schema

NameRequiredDescriptionDefault
urlNoOptional instead of text: a live page. Its main content is extracted as Markdown (as seo_page with detail full shows it) and checked with the blog preset. Only the CLI and the local MCP server read pages.
onlyNoOptional categories to check: ai (patterns common in AI-written text), copy (weak copy and house style, such as dashes) or seo (titles, descriptions, headings). Default: all.
textNoThe copy to check: a page, post, title or description, up to 200,000 characters. Markdown, MDX or HTML as written, so line numbers match.
rulesNoOptional. true lists every rule with its id, category, level and description instead of checking text; only limits the list, such as only ["ai"].
formatNoOptional. md (default for text), mdx, html, astro or text. Code, tags and URLs are skipped; captions and titles are checked.
presetNoOptional. blog (default for Markdown), landing (default for HTML: stricter on buzzwords, weak links and claims with no number), docs, or meta (one title or description per line; start a line with "title:" or "description:" to say which).
meta_kindNoOptional, with the meta preset: title or description, what a line with no "title:" or "description:" label is. Default: a line up to 70 characters is a title, a longer one a description.
ignore_rulesNoOptional rule ids or review lenses to skip.
ignore_phrasesNoOptional phrases to allow, such as a product name a rule keeps matching.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / rules
      Added value: +{
+  "description": "Optional. true lists every rule with its id, category, level and description instead of checking text; only limits the list, such as only [\"ai\"].",
+  "type": "boolean"
+}
  2. Changed4 schema fields changed
    • addedInput schema / properties / meta_kind
      Added value: +{
+  "description": "Optional, with the meta preset: title or description, what a line with no \"title:\" or \"description:\" label is. Default: a line up to 70 characters is a title, a longer one a description.",
+  "enum": [
+    "title",
+    "description"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / only
      Added value: +{
+  "description": "Optional categories to check: ai (patterns common in AI-written text), copy (weak copy and house style, such as dashes) or seo (titles, descriptions, headings). Default: all.",
+  "items": {
+    "enum": [
+      "ai",
+      "copy",
+      "seo"
+    ],
+    "type": "string"
+  },
+  "maxItems": 3,
+  "type": "array"
+}
    • changedInput schema / properties / preset / description
      Previous value: -"Optional. blog (default for Markdown), landing (default for HTML: stricter on buzzwords, weak links and claims with no number), docs, or meta (one title or description per line)."New value: +"Optional. blog (default for Markdown), landing (default for HTML: stricter on buzzwords, weak links and claims with no number), docs, or meta (one title or description per line; start a line with \"title:\" or \"description:\" to say which)."
    • addedInput schema / properties / url
      Added value: +{
+  "description": "Optional instead of text: a live page. Its main content is extracted as Markdown (as seo_page with detail full shows it) and checked with the blog preset. Only the CLI and the local MCP server read pages.",
+  "format": "uri",
+  "type": "string"
+}
  3. Added

TDQS

A4.4/5.0
Behavior5/5

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

Beyond readOnlyHint/openWorldHint, it discloses what findings look like (line, the words, a concrete fix, a category), how review items differ from errors and warnings, and that no accounts are read. It also flags an environment constraint the annotations do not carry: url fetching works only in CLI and local MCP.

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 purpose is front-loaded and every clause carries content, but the opening sentence is a long, heavily parenthesized enumeration that takes effort to parse. The trailing 'It reads no accounts' is terse but useful; overall dense rather than wasteful.

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 nine parameters and no output schema, the description compensates by explaining the shape of results (per-finding line, quoted words, fix, category) and the review-item distinction. It also covers the environment restriction on url and the default-preset behavior, which is everything an agent needs to call it 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%, so every parameter is already documented, and the description mostly restates those semantics (the 'only ["ai"]' example, the url/CLI caveat). It adds little syntax or format detail the schema does not already supply, 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 names a specific verb and resource ('Checks landing page copy, blog posts, titles and meta descriptions') and enumerates the three finding families (AI patterns, weak copy, SEO rules). An agent can tell instantly this is a copy-linting tool, distinct from siblings like seo_page (extraction) or seo_compare.

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?

It gives clear operational context: use 'only' to skip a category such as house-style dashes, use 'url' instead of 'text' for a live page, and treat review items as judgement calls to read and apply only when they fail the stated question. It stops short of explicitly naming an alternative sibling (e.g. seo_page for extraction), so the when-not guidance is implied rather than complete.

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

All SEO Skill toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources