TopicForge is a programmatic SEO and content generation platform for creating, managing, and exporting AI-generated articles at scale.
topic_cluster: Expand a seed topic into 3–100 programmatic SEO article ideas, complete with ICP targeting, search intent, and writer guidance.
faq_schema: Generate FAQ questions and FAQPage JSON-LD markup for answer hub SEO optimization.
meta_description: Create 150–160 character meta descriptions from a page title and optional body snippet.
run_batch: Launch a batch job to generate multiple publish-ready articles simultaneously, with options for concurrency (up to 10 parallel workers), auto-approval, auto-publishing, and translation into Spanish, French, or German.
get_batch_status: Poll a running batch job to track per-item progress and view completed article previews.
get_article: Fetch a generated article by ID, including its markdown body and metadata.
export_markdown: Export a generated article as markdown for CMS import.
get_generation_settings: Read workspace voice profile, product facts, and effective generation settings.
update_generation_settings: Update workspace generation settings used by batch jobs.
Official MCP server for TopicForge — programmatic SEO batch jobs and growth tools.
npx -y @topicforge/mcpCreate an API key at topicforge.net/app/settings/api-keys.
{
"mcpServers": {
"topicforge": {
"command": "npx",
"args": ["-y", "@topicforge/mcp"],
"env": {
"TOPICFORGE_API_KEY": "tf_live_..."
}
}
}
}claude mcp add topicforge -e TOPICFORGE_API_KEY=tf_live_... -- npx -y @topicforge/mcpOne-click install buttons and more clients: topicforge.net/developers
Related MCP server: Citare
Variable | Required | Description |
| Yes | Workspace API key |
| No | API base (default |
Tool | Description |
| Expand a seed topic into 15–25 article ideas |
| FAQ questions + FAQPage JSON-LD |
| 150–160 char meta description |
| Launch a credit-debited batch job (pay per article) |
| Poll batch job progress |
| Fetch article by ID |
| Export article as markdown |
| Read workspace voice profile, product facts, and effective settings |
| Update workspace generation settings used by |
Pay per article — $10 single, volume packs from $3.99/article. Pricing
This repo is a public mirror of the MCP package in the TopicForge monorepo. To build from source:
npm install
npm run build
npm startRelease tarball (fallback install):
npx -y https://topicforge.net/mcp/topicforge-mcp-1.0.0.tgzSmithery: https://smithery.ai/servers/topicforge/topicforge-mcp
Developer docs: https://topicforge.net/developers
MCP server card (tool metadata): https://topicforge.net/.well-known/mcp/server-card.json
OpenAPI: https://topicforge.net/openapi.json
MCP registry name: net.topicforge/mcp
Export a generated article as markdown for CMS import.
| Name | Required | Description | Default |
|---|---|---|---|
| articleId | Yes | Article ID to export |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. 'Export' implies a read operation, but no details on side effects, permissions, or whether exporting modifies the article. Adequate but could be more explicit about non-destructive 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?
Single, front-loaded sentence with no wasted words. Clearly communicates the tool's purpose.
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 simplicity (1 parameter, no output schema), description is reasonably complete. Missing details like return format or prerequisite that article be generated, but overall sufficient for a straightforward export operation.
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 description for articleId. Description adds no additional meaning beyond the schema; 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?
Description clearly states verb 'Export', resource 'generated article', output format 'markdown', and purpose 'for CMS import'. It is specific and distinguishes from sibling tools like faq_schema or get_article.
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 when a generated article needs to be exported for CMS, but provides no explicit guidance on when to use vs alternatives, prerequisites (e.g., article must be generated), or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a topic into FAQ questions and FAQPage JSON-LD for answer hub SEO.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Optional email for follow-up | ||
| context | No | Optional background context | |
| topicTitle | Yes | Topic or question for FAQ generation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden. It indicates the output (FAQ questions and JSON-LD) but does not disclose any side effects, permissions, or constraints (e.g., whether the operation is read-only or modifies state). It is minimally adequate.
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 of 10 words, tightly packed with essential information. No repetition or unnecessary detail.
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 low complexity (1 required param, no output schema), the description is mostly sufficient but omits details like the format of the JSON-LD output or how it integrates with other tools. It is adequate but not thorough.
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 input schema already describes all parameters with 100% coverage. The description does not add extra meaning beyond restating the schema's purpose ('turn a topic into...'), so it meets the baseline without enhancement.
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's action ('Turn a topic into FAQ questions and FAQPage JSON-LD') and its purpose ('for answer hub SEO'), effectively distinguishing it from sibling tools that handle exports, articles, batches, meta descriptions, and topic clusters.
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 provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. An agent would have to infer usage solely from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a generated article by ID including markdown body and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| articleId | Yes | Article ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. States it returns 'markdown body and metadata' but does not mention if operation is read-only, authentication needs, or that article must exist as a generated article.
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 action verb, no wasted words. Efficiently conveys core functionality.
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?
For a simple tool with one parameter and no output schema, the description sufficiently covers the operation and expected return. Minor gap: no description of metadata structure.
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 one parameter described as 'Article ID'. Description adds no additional meaning beyond the schema, so baseline 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 'Fetch', resource 'generated article by ID', and return content 'markdown body and metadata'. Distinguishes from siblings like 'get_batch_status' or 'export_markdown' by focusing on a single article retrieval.
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 explicit guidance on when to use this tool versus alternatives such as 'export_markdown'. Lacks prerequisites or conditions (e.g., article must be generated first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll a batch job for per-item status and completed article previews.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | Batch job ID returned from run_batch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral transparency. It discloses that the tool polls (implying repeated, non-destructive calls) but omits details on error handling, rate limits, or what happens if the job ID is invalid. Minimal context beyond the action.
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 front-loads the key action and outputs. Every word is relevant, with no wasted text.
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 simple input (one parameter) and no output schema, the description is moderately complete. However, it lacks details about the returned data format, how to interpret statuses, and error scenarios, which would be helpful for a polling 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% for the single parameter 'jobId', and the schema already describes it as 'Batch job ID returned from run_batch'. The tool description adds no additional meaning to the parameter, so the 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 uses a specific verb ('Poll') and resource ('batch job'), and specifies the outputs ('per-item status and completed article previews'). It clearly distinguishes from sibling tools like 'run_batch' (creates jobs) and 'get_article' (single article).
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 does not provide guidance on when to use this tool versus alternatives. It implies polling after run_batch but does not explicitly state this, nor does it mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a 150–160 character meta description from a title and optional snippet.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Optional email for follow-up | ||
| title | Yes | Page or article title | |
| bodySnippet | No | Optional body snippet for context |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It specifies the output length but does not disclose the return format (likely a string), nor potential side effects, authentication needs, or rate limits. The generative nature is implied but not fully transparent.
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?
A single sentence that front-loads the action and key constraint (character count). No redundant words; every part 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?
For a simple tool with 3 parameters and no output schema, the description is brief but slightly incomplete: it omits the 'email' parameter and does not specify the return value (a string). The character range is good, but the missing parameter coverage reduces completeness.
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 field descriptions. The description adds the 150-160 character constraint not in the schema, but fails to mention the 'email' parameter. It adds meaningful context for 'title' and 'bodySnippet', justifying above-baseline scoring.
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 it generates a meta description from a title and optional snippet, specifying the character range (150-160). This verb+resource combination is distinct from sibling tools like export_markdown or faq_schema.
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 generating meta descriptions but provides no explicit guidance on when to use it versus alternatives. No exclusions or when-not examples are given, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch a batch job to generate publish-ready articles for multiple topics. Debits workspace credits.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Batch job name | |
| topics | Yes | Topics to generate | |
| autoApprove | No | Auto-approve after generation (default true) | |
| autoPublish | No | Auto-publish after approve (default false) | |
| concurrency | No | Parallel article workers (default 3, max 10) | |
| translateLocales | No | Locales to translate into after generation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It discloses credit consumption, which is important. However, it omits details like asynchronous nature, duration, error handling, or return value. The mention of 'generate' implies creation but lacks specifics on what happens after launch.
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 filler. The first sentence states purpose, the second adds a critical side effect. Every word is necessary.
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 6 parameters and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., batch ID), how to track progress, or what happens after launch. The schema covers parameters, but return value and behavior are left ambiguous.
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 the schema already documents all parameters. The description adds only 'multiple topics' which aligns with the topics array parameter. No additional semantic enrichment beyond the schema.
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 action (launch) and resource (batch job) and specifies the outcome (generate publish-ready articles for multiple topics). It also notes the cost (debits workspace credits). This distinguishes it from sibling tools like get_article or get_batch_status.
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 versus alternatives. It does not mention prerequisites, when not to use, or contrast with siblings like topic_cluster or faq_schema. The only hint is the credit cost, but no explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Expand one seed topic into a configurable set of programmatic SEO article ideas with ICP, search intent, and guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Optional email for follow-up | ||
| industry | No | Optional industry or vertical | |
| seedTopic | Yes | Seed topic to expand into a cluster | |
| topicCount | No | Number of article topics to generate (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It tells that the tool generates ideas with ICP, search intent, and guidance, and mentions 'configurable set' (related to topicCount). However, it does not disclose side effects, rate limits, or consequences of parameters like topicCount limits.
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?
A single sentence that is front-loaded with the verb and resource, containing no redundant words. Every phrase contributes to understanding the tool's purpose.
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?
Despite no output schema, the description sufficiently describes the output nature. For a tool with 4 parameters (1 required) and no nested objects, the description covers the core behavior. It could be more explicit about return format, but it is adequate.
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%, and the description adds value by introducing 'ICP, search intent, and guidance' which are not in the schema, enriching the meaning of the output. The description also hints at configurability via topicCount.
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 uses a specific verb ('Expand') and resource ('one seed topic'), clearly stating the output is 'a configurable set of programmatic SEO article ideas with ICP, search intent, and guidance'. This distinguishes it from sibling tools like export_markdown or get_article, which are not about expansion.
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 generating article ideas from a seed topic, but it lacks explicit guidance on when to use this tool versus alternatives, or any exclusions or prerequisites. It does not mention when not to use it.
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.
export_markdownfaq_schemaget_articleget_batch_statusmeta_descriptionrun_batchtopic_clusterThis server cannot be installed
All seven tools have clearly distinct purposes: ideation, batch generation, status polling, fetching, exporting, and SEO metadata generation. No overlap in functionality.
All tool names use snake_case with a consistent verb_noun pattern (e.g., export_markdown, run_batch, topic_cluster).
Seven tools is well-scoped for a content generation and SEO tool, covering the key stages of the workflow without being overwhelming or too sparse.
The tool surface covers ideation, batch generation, retrieval, export, and SEO metadata. Missing individual article generation and listing, but core workflow is complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Draft SEO blog articles from topic to ready-to-review post.
Full-cycle SEO automation for AI agents: technical audits, SEO articles, machine-readable pricing.
SEO research SaaS exposed as 30+ MCP tools. Forge niche analysis, plans, and writer-ready briefs.
SEO, competitor and AI-search data, plus blog management — draft, schedule and publish posts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TopicForge/topicforge-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
