seo-geo-mcp-server

Content Quality Analysis

content_analysis

Read-onlyIdempotent

Analyze a page's main content for word count, readability, and thin-content signals. Get reading time, text-to-HTML ratio, and top keyword densities from the main/article landmark.

Instructions

Measure the page's main content: word count, sentence and paragraph counts, Flesch reading ease with a plain-language reading level, estimated reading time, text-to-HTML ratio, thin-content detection, and the top non-stopword terms with their density (English and Spanish stopwords are both filtered).

Content is read from the / landmark when present, so navigation and footer chrome do not inflate the counts.

Args:

url (string): the page to check.
response_format ('markdown' | 'json'): output format (default 'markdown').

Returns: { word_count, sentence_count, paragraph_count, avg_words_per_sentence, reading_ease, reading_level, reading_time_minutes, thin_content, text_to_html_ratio, used_content_landmark, top_terms[{term, count, density}], score, grade, findings[] }.

Example: "Is the content on https://example.com/post too thin?" -> content_analysis(url="https://example.com/post").

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes	Page URL to analyse, e.g. 'https://example.com/blog/post'. The scheme defaults to https://.
`response_format`	No	Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload.	markdown

Output Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes
`grade`	Yes
`score`	Yes
`findings`	Yes
`final_url`	Yes
`top_terms`	Yes
`html_bytes`	Yes
`word_count`	Yes
`reading_ease`	Yes
`thin_content`	Yes
`reading_level`	Yes
`sentence_count`	Yes
`paragraph_count`	Yes
`text_to_html_ratio`	Yes
`reading_time_minutes`	Yes
`used_content_landmark`	Yes
`avg_words_per_sentence`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.2.0Sep 16, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedv1.0.0Aug 3, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With readOnlyHint=true and idempotentHint=true already covering safety, the description adds valuable non-obvious behavior: content is scoped to the <main>/<article> landmark so navigation/footer chrome don't inflate counts, and both English and Spanish stopwords are filtered. The return contract's used_content_landmark field reinforces this. It does not disclose fallback behavior when no landmark exists, which is a minor residual gap.

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 well-organized and front-loaded: purpose, behavioral note, args, returns, and a concrete example. Each block earns its place, though the Args section duplicates schema content and the Returns block partially repeats what the output schema already documents, keeping it from a 5.

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

Completeness4/5

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

Given two well-documented parameters, an output schema covering the rich return shape, and annotations covering safety, the description covers the remaining essentials: extraction behavior, supported languages, output contract, and a usage example. It omits only edge-case behavior (unreachable URLs, or the content fallback when no landmark is present), which is a minor gap for an otherwise complete definition.

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 schema fully documents both url and response_format, including the enum and default. The Args section largely repeats that structured data, adding no meaning beyond inline convenience and an example value. A baseline 3 is appropriate since the description does not need to compensate.

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 ('Measure') and resource ('the page's main content') and enumerates a concrete metric list: word/sentence/paragraph counts, Flesch reading ease, reading time, text-to-HTML ratio, thin-content detection, and top non-stopword terms. This clearly distinguishes it from siblings like robots_txt_check, meta_tags_check, and link_audit, which target wholly different concerns.

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?

The metric list and the worked example ('Is the content on https://example.com/post too thin?') provide clear context for when to invoke this tool: content-depth, readability, and thinness questions. It does not explicitly name alternatives or exclusion criteria versus the closest sibling (seo_audit), so it stops short of a 5, but the context is unambiguous enough to route an agent correctly.

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

Deploy Server