Which integrations are available for this server?

Uses Node.js runtime environment for executing the MCP server implementation Distributed and installed through npm package manager for easy deployment

How do I use Semantic Pen MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Semantic Pen MCP Server create an article about AI content marketing strategies for 2024" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Semantic Pen MCP Server

by pushkarsingh32

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Remote

Semantic Pen MCP Server

The official MCP server for Semantic Pen - an advanced AI article generator and SEO content writer. Create, manage, and optimize SEO-friendly articles directly from Claude Code and Cursor with powerful AI automation.

Quick Setup (Recommended)

Just add this to your MCP configuration - no installation required!

One-Click Install for Cursor

⚠️ Important: After clicking the button above, you'll need to replace your-api-key-here with your actual Semantic Pen API key in the Cursor settings.

The button automatically adds this configuration to your Cursor MCP settings:

{
  "command": "npx",
  "args": ["-y", "semantic-pen-mcp-server@latest"],
  "env": {
    "SEMANTIC_PEN_API_KEY": "your-api-key-here"
  }
}

You just need to replace the API key placeholder with your actual key.

For Claude Code

Add to your ~/.config/claude-code/settings.json:

{
  "mcpServers": {
    "semantic-pen": {
      "command": "npx",
      "args": ["-y", "semantic-pen-mcp-server@latest"],
      "env": {
        "SEMANTIC_PEN_API_KEY": "your-api-key-here"
      }
    }
  }
}

For Cursor

Add to your Cursor MCP settings:

{
  "mcpServers": {
    "semantic-pen": {
      "command": "npx",
      "args": ["-y", "semantic-pen-mcp-server@latest"],
      "env": {
        "SEMANTIC_PEN_API_KEY": "your-api-key-here"
      }
    }
  }
}

Replace your-api-key-here with your actual Semantic Pen API key.

For Windsurf

Add to your ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "semantic-pen": {
      "command": "npx",
      "args": ["-y", "semantic-pen-mcp-server@latest"],
      "env": {
        "SEMANTIC_PEN_API_KEY": "your-api-key-here"
      }
    }
  }
}

Then restart Windsurf to load the new MCP server. Access through Cascade → Configure (hammer icon).

Related MCP server: Publora MCP Server

Features

🤖 AI-Powered Article Creation - Generate SEO-optimized articles with advanced AI automation
📊 SEO Content Optimization - Built-in keyword targeting and SEO best practices
📋 Content Project Management - Organize and manage your AI writing projects efficiently
🔍 Smart Content Search - Find and filter articles across projects instantly
⚡ Automated Workflow - Streamline your content creation process with AI automation
📄 Full Content Access - Retrieve complete article HTML ready for publishing
🔑 Seamless Authentication - Automatic API verification for hassle-free setup

Available Tools

`get_projects`

Get all your projects from the article queue

No parameters required

`get_project_articles`

Get all articles from a specific project

projectId (string): The project ID to get articles from

`search_projects`

Search projects by name

projectName (string): The project name to search for (partial match)

`create_article`

Generate SEO-optimized AI articles with advanced customization

targetArticleTopic (string): The article topic/title for AI content generation
targetKeyword (string, optional): Primary SEO keyword for optimization
wordCount (number, optional): Target word count for content length (default: 1000)
language (string, optional): Content language (default: English)
articleType (string, optional): Article format type (default: Article)
toneOfVoice (string, optional): Writing tone and style (default: Professional)

`get_article`

Get a specific article by ID with full content

articleId (string): The ID of the article to retrieve

Example Usage

Browse Content Projects: Use get_projects to view your AI article generation projects
Explore Project Content: Use get_project_articles to see all AI-generated articles in a specific project
Generate AI Articles: Use create_article with topics like "AI Content Marketing Strategies for 2024"
Access Generated Content: Use get_article to retrieve your SEO-optimized article content ready for publishing

Getting Your API Key

Visit SemanticPen.com - Your AI article writing platform
Create your account or log in to access the AI content generator
Navigate to API settings to generate your content automation key
Copy the API key and configure it for seamless AI article generation

Manual Installation (Alternative)

If you prefer to install manually:

npm install -g semantic-pen-mcp-server

Then use in your MCP config:

{
  "command": "semantic-pen-mcp",
  "env": {
    "SEMANTIC_PEN_API_KEY": "your-api-key-here"
  }
}

Troubleshooting

"API key not configured": Make sure SEMANTIC_PEN_API_KEY is set in the env section
"API key verification failed": Check that your API key is valid and active
Server not starting: Ensure you have Node.js 18+ installed

Support

For issues or questions:

Visit SemanticPen.com for support
Check your API key is valid and has sufficient credits
Ensure stable internet connection for API calls

Available Tools

5 tools

create_articleC

Create a new article

ParametersJSON Schema

Name	Required	Description	Default
`targetArticleTopic`	Yes	The topic/title for the article
`targetKeyword`	No	Target SEO keyword for the article (optional)
`wordCount`	No	Target word count (default: 1000)
`language`	No	Language for the article (default: English)	English
`articleType`	No	Type of article (default: Article)	Article
`toneOfVoice`	No	Tone of voice (default: Professional)	Professional

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure but only states the basic action. It doesn't mention what happens after creation (e.g., where the article is stored, if it's editable, permissions needed, or any side effects), leaving significant gaps for a mutation tool.

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?

The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a tool with a clear purpose and well-documented schema, making it easy to parse and understand immediately.

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

Completeness2/5

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

For a creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, where the article is created, or any behavioral nuances. Given the complexity of a 6-parameter mutation tool, more context is needed to guide the agent effectively.

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 all 6 parameters with their types, defaults, and descriptions. The description adds no additional parameter information beyond what's in the schema, meeting the baseline for high coverage but not exceeding it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Create' and the resource 'article', making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_article' or 'get_project_articles' beyond the obvious create vs. get distinction, which prevents a perfect score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. There are no mentions of prerequisites, when not to use it, or how it relates to sibling tools like 'get_article' or 'search_projects'. The agent must infer usage from context alone.

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

get_articleC

Get a specific article by ID with full content

ParametersJSON Schema

Name	Required	Description	Default
`articleId`	Yes	The ID of the article to retrieve

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves an article with full content, implying a read-only operation, but doesn't mention potential errors (e.g., invalid ID), permissions required, rate limits, or response format. This leaves significant gaps for a tool with no annotation coverage.

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?

The description is a single, efficient sentence that front-loads the core action ('Get a specific article') and adds necessary detail ('by ID with full content') without any wasted words. It's appropriately sized for a simple retrieval tool.

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

Completeness2/5

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

Given the tool's simplicity (1 parameter, 100% schema coverage) but lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like error handling or response structure, which are crucial for an agent to use it correctly, especially with no output schema to clarify return values.

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?

The schema description coverage is 100%, with the parameter 'articleId' fully documented in the schema. The description adds no additional meaning beyond implying retrieval by ID, so it meets the baseline of 3 where the schema handles parameter documentation adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get') and resource ('article') with specificity ('by ID with full content'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'get_project_articles' or 'search_projects', which might also retrieve articles in different contexts.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'get_project_articles' or 'search_projects'. It lacks context about prerequisites, such as needing an article ID, or exclusions, leaving the agent to infer usage based on the name alone.

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

get_project_articlesC

Get all articles from a specific project by project ID

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes	The project ID to get articles from

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states a read operation ('Get') but doesn't cover critical aspects like pagination, rate limits, authentication needs, error handling, or what 'all articles' entails (e.g., filtering, sorting). This leaves significant gaps for a tool that likely returns multiple items.

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?

The description is a single, clear sentence that front-loads the core action and resource without any wasted words. It efficiently communicates the essential purpose, making it easy for an agent to parse quickly and accurately.

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

Completeness2/5

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

Given the complexity of a list-fetching tool with no annotations and no output schema, the description is incomplete. It lacks details on return format (e.g., array structure, fields), behavioral traits (e.g., pagination, limits), and error cases, which are crucial for an agent to use this tool effectively in real scenarios.

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%, with the single parameter 'projectId' well-documented in the schema. The description adds no additional meaning beyond implying it's used to fetch articles, matching the schema's purpose. This meets the baseline of 3 since the schema handles parameter documentation adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get all articles') and resource ('from a specific project by project ID'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_article' (singular vs. plural) or 'search_projects' (articles vs. projects), missing explicit distinction that would warrant a 5.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'get_article' (for a single article) or 'search_projects' (for project-level queries). The description implies usage by mentioning 'project ID' but lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage scenarios.

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

get_projectsB

Get all projects from your article queue

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states it 'gets all projects' but doesn't disclose behavioral traits such as pagination, rate limits, authentication needs, or what 'all' entails (e.g., all accessible projects). This leaves significant gaps for an agent to understand how the tool behaves.

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?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'projects' entail, how they are returned, or any constraints like ordering or limits. For a tool that likely returns a list of projects, more context is needed to guide an agent effectively.

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?

The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but this is acceptable given the lack of parameters, aligning with the baseline expectation for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and resource ('projects from your article queue'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_project_articles' or 'search_projects', which likely retrieve similar data with different scopes or filters.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'get_project_articles' or 'search_projects'. The description implies it retrieves all projects, but without context on filtering or limitations, usage scenarios are unclear.

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

search_projectsC

Search projects by name

ParametersJSON Schema

Name	Required	Description	Default
`projectName`	Yes	The project name to search for (partial match)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions searching by name but doesn't describe traits like pagination, result format, error handling, or performance implications. For a search tool with zero annotation coverage, this is a significant gap in transparency.

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?

The description is a single, efficient sentence with zero waste, front-loading the core functionality ('Search projects by name'). It is appropriately sized for a simple tool with one parameter.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the search returns, how results are structured, or any behavioral nuances. For a search tool, this leaves critical gaps in understanding its operation and output.

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?

The schema description coverage is 100%, with the parameter 'projectName' documented as 'The project name to search for (partial match)'. The description adds no additional meaning beyond what the schema provides, such as search syntax or examples, so it meets the baseline score when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('search') and resource ('projects'), and specifies the search criterion ('by name'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_projects', which might also retrieve projects, so it doesn't reach the highest score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'get_projects' or other siblings. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesAug 18, 2025
- First observedcreate_article
- First observedget_article
- First observedget_project_articles
- First observedget_projects
- First observedsearch_projects

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Disambiguation4/5

Most tools have distinct purposes, but 'get_projects' and 'search_projects' could cause some confusion as both retrieve project information, though 'search_projects' adds filtering by name. The article-related tools (create_article, get_article, get_project_articles) are clearly differentiated by their specific actions and scopes.

Naming Consistency5/5

All tools follow a consistent verb_noun naming pattern (e.g., create_article, get_article, get_project_articles, get_projects, search_projects). The structure is uniform throughout, using snake_case and clear action-object pairs, making the tool set predictable and easy to understand.

Tool Count5/5

With 5 tools, the server is well-scoped for managing articles and projects, covering core operations without bloat. Each tool serves a clear purpose, such as creation, retrieval, and listing, which aligns with typical CRUD needs for this domain.

Completeness3/5

The tool set covers basic retrieval and creation for articles and projects, but there are notable gaps in update and delete operations. For example, there is no tool to update or delete articles or projects, which could limit agent workflows that require full lifecycle management.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

agentwork-mcp A
io.github.ferm-ai
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
Agent Orchestration Autonomous Agents App Automation
2
Subfeed MCP
app.subfeed.mcp
Official MCP server for subfeed.app — the cloud for agents. 15+ tools for AI agents to register, build, and deploy other agents. Zero human required. Start here: subfeed.app/skill.md
Agent Orchestration Cloud Platforms Autonomous Agents
2
LovableOAuth
dev.lovable
Official MCP server for Lovable, the AI-powered full-stack app builder.
Developer Tools AI & Machine Learning
24
mcp-nanobanana-proOAuth
io.github.AceDataCloud
MCP server for NanoBanana AI image generation and editing
Image & Video Processing Multimedia Processing
27

Related MCP Servers

PostIdentity MCP Serverofficial
Social Media Marketing
PostIdentity
A
license
Not graded
quality
D
maintenance
Official MCP server for PostIdentity - Generate AI-powered social media posts, threads, and replies from any MCP-compatible AI assistant with identity management and refinement capabilities.
Updated 8 months ago (2026-01-14 21:24 UTC)
36
1
MIT
Publora MCP Serverofficial
Social Media Marketing
publora
A
license
B
quality
C
maintenance
Official MCP server for Publora that enables AI assistants to schedule posts, manage accounts, and retrieve analytics across multiple social media platforms through natural language.
Updated 2 months ago (2026-06-30 11:47 UTC)
18
16
5
MIT
@formacv/mcp
CRM AI & Machine Learning
Rocketech-Software-Development
A
license
A
quality
D
maintenance
Official MCP server for FormaCV, enabling AI-powered CV formatting, anonymization, tailoring, and ATS push-back from AI agents like Claude Desktop and Cursor.
Updated 4 months ago (2026-05-06 18:37 UTC)
8
55
1
MIT
linklight
Marketing Search
grodgers1-ctrl
A
license
A
quality
A
maintenance
The MCP server for SEO. Find prospects, draft outreach, and monitor backlinks from your AI agent.
Updated a month ago (2026-08-01 15:42 UTC)
14
MIT

Appeared in Searches

A content research and creation service for article writing with SEO optimization

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/pushkarsingh32/semantic-pen-mcp-server'

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

Semantic Pen MCP Server

Quick Setup (Recommended)

One-Click Install for Cursor

For Claude Code

For Cursor

For Windsurf

Features

Available Tools

get_projects

get_project_articles

search_projects

create_article

get_article

Example Usage

Getting Your API Key

Manual Installation (Alternative)

Troubleshooting

Support

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

PostIdentity MCP Serverofficial

Publora MCP Serverofficial

Appeared in Searches

Latest Blog Posts

MCP directory API

`get_projects`

`get_project_articles`

`search_projects`

`create_article`

`get_article`