The content-optimizer-mcp server is a free, self-contained SEO content optimization tool offering SERP-based analysis, content scoring, and actionable recommendations.
Score content (score_content): Evaluate content against a target keyword across 7 SEO categories (keyword usage, word count, heading structure, readability, entity coverage, content depth, internal structure), returning an overall 0–100 score with per-category breakdowns and recommendations.
Analyze keywords (analyze_keyword): Retrieve simulated SERP data for any keyword, including top 10 results with word counts, heading counts, common topics, and SERP features.
Get content recommendations (get_content_recommendations): Obtain a prioritized list of specific, actionable improvements to optimize content for a target keyword.
Check readability (check_readability): Analyze content via Flesch-Kincaid score, grade level, sentence statistics, and estimated reading time.
Find missing topics (find_missing_topics): Identify topics SERP competitors cover that your content lacks, along with covered topics and an overall coverage percentage.
Optimize headings (optimize_headings): Analyze heading hierarchy, detect structural issues, and receive a recommended keyword-rich heading outline.
Paid content optimization tools charge $89-$170/month for SERP-based scoring. Content Optimizer gives you the same analysis — for free, self-hosted, and extensible.
Feature | Content Optimizer | Surfer SEO | Clearscope | Frase |
Price | Free | $89/mo | $170/mo | $15/mo |
Self-hosted | :white_check_mark: | :x: | :x: | :x: |
Open source | :white_check_mark: | :x: | :x: | :x: |
Content scoring | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: |
Keyword analysis | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: |
Readability analysis | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: |
Heading optimization | :white_check_mark: | :white_check_mark: | :white_check_mark: | :x: |
Entity/topic coverage | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: |
MCP server | :white_check_mark: | :x: | :x: | :x: |
AI editor integration | :white_check_mark: | :x: | :x: | :x: |
API access | :white_check_mark: | Paid add-on | :x: | Paid add-on |
No data limits | :white_check_mark: | Credits-based | Credits-based | Credits-based |
Related MCP server: Fan Out Query MCP
:dart: Content Scoring — Score content 0-100 across 7 SEO categories with per-category breakdowns
:mag: SERP Analysis — Analyze top-ranking pages for word count, headings, and topic benchmarks
:abc: Readability Analysis — Flesch-Kincaid scoring, grade level, sentence length, reading time
:bookmark_tabs: Heading Optimization — Detect hierarchy issues, suggest keyword-rich heading structure
:brain: Entity Coverage — Find topics competitors cover that you're missing
:clipboard: Actionable Recommendations — Prioritized improvements ranked by impact
:robot: MCP Server — Use with Claude Desktop, Cursor, or any MCP-compatible AI tool
Category | Max Points | What It Measures |
Keyword Usage | 20 | Density, placement in first paragraph and headings |
Word Count | 15 | Content length vs SERP average and target |
Heading Structure | 15 | H1/H2/H3 hierarchy, count, keyword inclusion |
Readability | 15 | Flesch-Kincaid score, grade level |
Entity Coverage | 15 | Topic coverage vs SERP competitors |
Content Depth | 10 | Paragraphs, lists, statistics, data points |
Internal Structure | 10 | Introduction, conclusion, logical flow |
100 |
Node.js 18+
npm 9+
git clone https://github.com/sharozdawa/content-optimizer.git
cd content-optimizer
npm installnpm run devOpen http://localhost:3000.
npm run build
npm startThe MCP server lets you use Content Optimizer directly inside AI coding tools like Claude Desktop and Cursor.
No setup required — just add the config:
Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"content-optimizer": {
"command": "npx",
"args": ["-y", "content-optimizer-mcp"]
}
}
}Add to .cursor/mcp.json in your project:
{
"mcpServers": {
"content-optimizer": {
"command": "npx",
"args": ["-y", "content-optimizer-mcp"]
}
}
}cd mcp-server
npm install
npm run buildThen use node ./mcp-server/dist/index.js as the command in your MCP config.
Tool | Description |
| Score content against a keyword across 7 categories (0-100) |
| Analyze SERP data — top 10 results with word counts, headings, topics |
| Get prioritized improvement recommendations |
| Flesch-Kincaid score, grade level, sentence stats, reading time |
| Find topics from SERP competitors missing in your content |
| Analyze heading structure and suggest improvements |
Project | Description |
Generate structured data (JSON-LD) for any page — Product, Article, FAQ, HowTo, and more | |
Track how your brand appears in AI search engines (ChatGPT, Perplexity, Gemini) | |
Instantly notify search engines when you publish or update content | |
AI content humanizer — make AI-generated text sound natural |
Contributions are welcome! See CONTRIBUTING.md for guidelines.
MIT — see LICENSE for details.
Analyze SERP data for a keyword. Returns simulated top 10 results with word counts, heading counts, common topics, and SERP features.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | The keyword to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that results are 'simulated', which is critical for understanding tool limitations. Describes return fields comprehensively. No annotations provided, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose, no redundant words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simplicity of tool (1 param, no output schema, no nested objects), description adequately explains input and output. Could be enhanced with example or note on simulation accuracy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, and the description adds no significant meaning beyond the schema's 'The keyword to analyze'. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Analyze', resource 'SERP data', and specifies output ('simulated top 10 results with word counts, heading counts, common topics, and SERP features'). Distinguishes from sibling tools like check_readability and find_missing_topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for keyword analysis but lacks explicit guidance on when to use versus alternatives or when not to use. No mention of conditions or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze content readability. Returns Flesch-Kincaid score, grade level, sentence stats, and reading time.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The content to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions return values. It lacks behavioral details such as input requirements (e.g., text length, language support) or side effects, leaving an agent uninformed about how the tool operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently communicates the tool's purpose and output without any redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and missing output schema, the description provides a reasonable overview of return values. However, for a tool returning structured data, the format is unspecified, which may hinder an agent's ability to parse results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'content' is already well described in the schema as 'The content to analyze' (100% coverage). The description adds no further semantic value beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes readability and lists specific metrics returned (Flesch-Kincaid score, grade level, sentence stats, reading time). This distinguishes it from sibling tools like analyze_keyword or score_content, which focus on other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for readability analysis but does not provide explicit guidance on when to use this tool over alternatives or mention any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find topics from SERP competitors that are missing in your content. Returns covered topics, missing topics, and coverage percentage.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The content to check | |
| keyword | Yes | The target keyword |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden for behavioral disclosure. It mentions returns (covered, missing topics, coverage) but does not disclose how SERP competitors are fetched, potential rate limits, whether the tool is read-only, or any dependencies on external data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently states the purpose and return types. It is front-loaded with the action and avoids extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description adequately states inputs and outputs but lacks behavioral context like processing time, data source reliance, or usage constraints. It is minimally viable but has significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds value by introducing the concept of 'SERP competitors', explaining how the keyword is used beyond just targeting. This partial addition of context raises the baseline above 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds topics from SERP competitors that are missing in content. It uses a specific verb-resource combination and distinguishes from sibling tools like analyze_keyword or score_content by focusing specifically on competitor topic gap analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for identifying missing topics in content relative to competitors, which is clear context. However, no explicit when-not-to-use or alternatives are provided, though the sibling tool list helps the agent infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a prioritized list of specific improvements to optimize content for a target keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The content to analyze | |
| keyword | Yes | The target keyword |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fails to disclose if the operation is read-only, what the output format or structure is, or any prerequisites beyond parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded. Could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for simple string parameters and no output schema, but lacks detail on what 'improvements' entail or how they are ranked. More context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover both parameters well. Description adds no additional meaning, but baseline 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get' and resource 'prioritized list of specific improvements' with purpose 'to optimize content for a target keyword'. It distinguishes from sibling tools like 'analyze_keyword' and 'score_content' which offer different outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs siblings or alternatives. Description only states what it does, without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze heading structure and suggest improvements. Returns current headings, issues, and recommended heading outline.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The content to analyze | |
| keyword | Yes | The target keyword |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool analyzes and suggests improvements, which implies non-destructive behavior. However, it does not disclose any additional behavioral traits such as authentication needs, rate limits, or whether it modifies content. Returns are mentioned but not deeper behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Efficiently communicates purpose and outputs. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% schema coverage for two simple parameters and no output schema, the description adequately explains return values (headings, issues, recommended outline). No missing context for this straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (content and keyword). The description adds no new meaning beyond the schema; it just mentions analyzing heading structure. Baseline score of 3 is appropriate as schema already documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes heading structures, suggests improvements, and returns specific outputs including current headings, issues, and a recommended outline. It distinguishes from sibling tools like 'analyze_keyword' which focuses on keywords, and 'check_readability' which checks readability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when heading structure improvement is needed, but does not explicitly state when to use versus alternatives. Sibling tools are listed but not compared. Provides clear context but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score content against a keyword across 7 SEO categories. Returns an overall score (0-100), per-category breakdowns, and actionable recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The content to score (Markdown or plain text) | |
| keyword | Yes | The target keyword to optimize for | |
| target_word_count | No | Target word count (default: 1500) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes output (scores and recommendations) but does not disclose if the tool is read-only, requires authentication, or has rate limits. It fails to state that it is a non-destructive analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that are front-loaded with the key action and output. Every word is useful with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers return values (overall score, breakdowns, recommendations). However, it omits details like the 7 categories names, which could help an agent interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema; it restates the purpose but does not provide formatting details or constraints for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('score') and resource ('content against a keyword'), mentions the scope (7 SEO categories), and clearly distinguishes from siblings like 'analyze_keyword' and 'check_readability' by focusing on scoring with breakdowns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for SEO content optimization but does not explicitly state when to use this tool versus alternatives (e.g., when to use 'analyze_keyword' instead). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0analyze_keywordcheck_readabilityfind_missing_topicsget_content_recommendationsoptimize_headingsscore_contentv0.1.0analyze_keywordcheck_readabilityfind_missing_topicsget_content_recommendationsoptimize_headingsscore_contentEach tool has a clear, unique purpose: keyword analysis, readability, topic gaps, recommendations, headings, and scoring. No overlap or ambiguity.
All tools follow a consistent verb_noun pattern (e.g., analyze_keyword, check_readability, score_content), making them predictable and easy for an agent to understand.
With 6 tools, the set is well-scoped for content optimization—covering analysis, readability, gaps, recommendations, headings, and scoring without being too sparse or excessive.
The tool surface covers key content optimization workflows: keyword analysis, readability, competitor gap analysis, recommendations, heading optimization, and scoring. No obvious gaps for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-powered SEO and marketing: keyword research, SERP analysis, and content optimization tools.
Turns SEO insight into page changes: keyword research, SERP and rank data, rewrites you approve.
Six tools for SEO and AI-readability audits. 91 checks, 11 score modules.
Site scores, audits, Search Console, keywords, competitors, authority and AI visibility tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sharozdawa/content-optimizer'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
