This server gives AI clients three CreatorOS capabilities for web content and voice generation.
Extract web pages to Markdown: Use creatoros_extract to fetch a public URL and return clean, noise-free Markdown by stripping ads, navigation, cookie banners, and scripts while preserving headings, lists, tables, and code blocks.
Run live web search with automatic page extraction: Use creatoros_search to search the live web and automatically extract deep Markdown from up to 5 top-ranked result pages.
Generate neural voice audio: Use creatoros_speak to convert English text into natural speech audio with selectable voices (anna, charles, alba, stuart_bell).
Support AI-assisted research and documentation workflows: Ideal for summarizing docs, reading articles, gathering current information, and producing narrated audio from within Claude Desktop, Cursor, Windsurf, or Zed.
Official Model Context Protocol (MCP) server for CreatorOS. Connects Claude Desktop, Cursor, Windsurf, and Zed directly to the high-throughput CreatorOS Web-to-Markdown extraction engine, autonomous agent web search, and neural text-to-speech studio.
Zero dependencies. Instant startup (<1s).
Tool | Description |
| Converts any public web page URL into clean, noise-free Markdown with headers, tables, and article metadata stripped of ads and navigation boilerplate. |
| Autonomous multi-URL agent live search. Retrieves fresh web search results and auto-extracts deep Markdown from top matching pages. |
| Generates natural, human-cadence English voice speech audio from text using CreatorOS Neural Voice Studio ( |
Related MCP server: crw-mcp
Add this to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"creatoros": {
"command": "npx",
"args": ["-y", "creatoros-mcp"]
}
}
}Optional: If you have an active CreatorOS Developer Pass key, provide it in env:
{
"mcpServers": {
"creatoros": {
"command": "npx",
"args": ["-y", "creatoros-mcp"],
"env": {
"CREATOROS_API_KEY": "YOUR_CREATOROS_PASS_KEY"
}
}
}
}In Cursor, open Settings → Features → MCP Servers.
Click + Add New MCP Server.
Fill in:
Name: creatoros
Type: command
Command: npx -y creatoros-mcp
Click Save. Cursor Composer will now automatically call creatoros_extract or creatoros_search whenever you ask questions about live web documentation!
"Extract the documentation at https://fastapi.tiangolo.com/tutorial/first-steps/ and summarize it."
"Search for the latest Python 3.13 changelog and give me the code examples."
"Synthesize an audio announcement for our product release using the Anna voice."
Free Tier: 20 web extractions / hour with no API key required.
Pro Tier: Pass-holders get up to 500,000 monthly extractions, dedicated concurrency, and priority voice queues. Get your pass at https://thecreatoros.dev/#passes.
MIT © CreatorOS
Extracts readable main content from any public web page URL and converts it into clean, noise-free Markdown optimized for LLM context, summarization, and RAG pipelines. Strips advertisements, navigation headers, cookie banners, and scripts while preserving headings, lists, tables, and code blocks.
When to use:
Call this tool when the user provides a specific URL or asks to read, scrape, summarize, or analyze documentation, blog posts, news articles, or API references from the web.
When NOT to use:
Do not use for keyword searches without a known URL (use creatoros_search instead).
Do not use for private intranet pages or sites behind interactive authentication/login walls.
Behavior:
Idempotent and read-only. Does not mutate server state.
Returns extracted Markdown as plain text.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The fully-qualified HTTP or HTTPS URL of the public web page to fetch and convert (e.g. "https://docs.python.org/3/tutorial/"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it declares read-only/idempotent behavior, states no server state is mutated, describes what content is stripped (ads, nav, cookie banners, scripts) and what is preserved, and specifies the return format as plain-text Markdown. It stops short of covering failure modes or rate limiting, so it is strong but not exhaustive.
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?
Front-loaded summary followed by clearly labeled use/avoid/behavior sections, which makes scanning easy. Slightly padded by the marketing-tinged 'optimized for LLM context, summarization, and RAG pipelines' clause that doesn't change agent behavior.
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 one-parameter read tool with no output schema and no annotations, the description covers purpose, exclusions, safety profile, transformation behavior, and return type. An agent has everything needed to call it correctly and interpret the response.
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 a single required 'url' parameter already documented with format, pattern, and an example. The description reinforces the 'public web page' constraint but adds no syntax or format detail beyond the schema, so baseline 3 applies.
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?
States a specific verb and resource ('extracts readable main content from any public web page URL' and 'converts it into clean Markdown'), and explicitly distinguishes itself from the sibling creatoros_search by scope (known URL vs. keyword search). An agent can pick between the two without opening either 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?
Has explicit 'When to use' and 'When NOT to use' sections, naming the alternative tool (creatoros_search) for the no-URL case and excluding auth-walled/intranet pages. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes an autonomous live web search for fresh information and automatically extracts deep Markdown content from the highest-ranking search result pages. Combines web search retrieval and web scraping in a single step for AI agents.
When to use:
Use when you need real-time, up-to-date web information, breaking news, latest documentation, or answers to queries where no specific target URL is provided.
When NOT to use:
If the user has already provided an exact web URL to scrape, use creatoros_extract instead.
Behavior:
Read-only and non-destructive.
Returns a structured Markdown document containing top ranked titles, URLs, text snippets, and extracted page content.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | The maximum number of top search results to return and extract (integer between 1 and 5). Default is 5. | |
| query | Yes | The search query keywords or question to look up on the live web (e.g. "Python 3.13 release changelog features", "FastAPI production best practices"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does declare read-only/non-destructive semantics plus the return shape (titles, URLs, snippets, extracted page content). It omits operational traits like latency/cost of scraping up to five pages, rate limits, or what happens when extraction fails on a page.
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?
Front-loaded with the core action, then cleanly sectioned into When to use / When NOT to use / Behavior. Slight redundancy in restating that it combines search and scraping 'in a single step', but overall tight and scannable.
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?
There is no output schema, and the description compensates by enumerating the returned Markdown document contents. For a simple two-parameter retrieval tool this is nearly sufficient; only failure modes and cost/time expectations are left unaddressed.
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 both parameters are already documented with bounds, defaults, and examples, making 3 the baseline. The description adds only that results are 'highest-ranking' and top-ranked; it says nothing about the trade-off of increasing limit (more pages scraped, slower/heavier).
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?
States a concrete verb+resource pair: performs a live web search and extracts Markdown from top-ranking result pages. It also distinguishes itself from the sibling scraping tool, so an agent can tell the two apart without opening either 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?
Provides an explicit 'When to use' (real-time info, breaking news, latest docs, no target URL given) and 'When NOT to use' that names creatoros_extract as the alternative for exact URLs. Clear positive and negative routing conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Converts English text into natural, studio-quality speech audio with human inflection and cadence using the CreatorOS Neural Voice Studio. Returns a playable audio URL or audio stream.
When to use:
Use when the user requests spoken voice responses, podcast narration, voiceover scripts, or audio synthesis of text.
When NOT to use:
Do not use for text extraction, web scraping, or non-audio tasks.
Behavior:
Synthesizes neural audio on demand. Free tier supports up to 250 characters per generation; Pro Pass supports up to 5,000 characters.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The English script to convert into voice audio (up to 250 characters free, 5000 characters with Pro Pass). | |
| voice | No | The voice persona to use: "anna" (warm female), "charles" (deep male), "alba" (bright male), or "stuart_bell" (documentary narrator). Default is "anna". | anna |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the key operational constraint: 250 characters on free tier versus 5,000 with Pro Pass, plus what the call returns. It does not cover latency, failure behavior when the character limit is exceeded, or how long the generated audio is retained.
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?
Clearly front-loaded with the core action, then structured into when/when-not/behavior blocks that are easy to scan. Slight redundancy in repeating the character limits already stated in the schema keeps it off a 5.
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 two-parameter synthesis tool with no output schema, the description covers purpose, the return value, and the tier-based input ceiling, which is enough to call it correctly. Edge cases like what happens on exceeding the limit or unsupported language are unaddressed.
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 both 'text' and 'voice' are already fully documented, including the enum persona meanings and the default. The description's character-limit note merely restates what the schema field already says, adding no new parameter guidance; baseline 3 applies.
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?
States a precise verb+resource: converting English text into speech audio via a named engine, and adds the return shape (playable audio URL or audio stream). The 'when NOT to use' clause (no text extraction, no web scraping) carves it away from the sibling tools creatoros_extract and creatoros_search.
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?
Explicitly enumerates when to invoke it (spoken responses, podcast narration, voiceover, audio synthesis) and when not to, which routes the agent away from the non-audio siblings. The only thing left implicit is naming the siblings outright, but their domains are covered.
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.
v1.0.1creatoros_extract3 fields changedInput schema / properties / url / descriptionPrevious value: -"The public web page URL to fetch and convert into Markdown (e.g. https://example.com/blog)."New value: +"The fully-qualified HTTP or HTTPS URL of the public web page to fetch and convert (e.g. \"https://docs.python.org/3/tutorial/\")."Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / url / patternAdded value: +"^https?:\\/\\/.+"creatoros_search7 fields changedInput schema / properties / limit / defaultAdded value: +5Input schema / properties / limit / descriptionPrevious value: -"Maximum number of search results to return (1 to 5). Default is 5."New value: +"The maximum number of top search results to return and extract (integer between 1 and 5). Default is 5."Input schema / properties / limit / maximumAdded value: +5Input schema / properties / limit / minimumAdded value: +1Input schema / properties / query / descriptionPrevious value: -"The search query to look up (e.g. \"latest Python 3.13 release notes\", \"FastAPI RAG tutorial\")."New value: +"The search query keywords or question to look up on the live web (e.g. \"Python 3.13 release changelog features\", \"FastAPI production best practices\")."Input schema / properties / query / maxLengthAdded value: +250Input schema / properties / query / minLengthAdded value: +2creatoros_speak6 fields changedInput schema / properties / text / descriptionPrevious value: -"The English text script to convert into voice audio (up to 250 characters free, 5000 characters with Pro Pass)."New value: +"The English script to convert into voice audio (up to 250 characters free, 5000 characters with Pro Pass)."Input schema / properties / text / maxLengthAdded value: +5000Input schema / properties / text / minLengthAdded value: +1Input schema / properties / voice / defaultAdded value: +"anna"Input schema / properties / voice / descriptionPrevious value: -"Voice persona: \"anna\" (warm female), \"charles\" (deep male), \"alba\" (bright male), \"stuart_bell\" (narrator). Default is \"anna\"."New value: +"The voice persona to use: \"anna\" (warm female), \"charles\" (deep male), \"alba\" (bright male), or \"stuart_bell\" (documentary narrator). Default is \"anna\"."Input schema / properties / voice / enumAdded value: +[
+ "anna",
+ "charles",
+ "alba",
+ "stuart_bell"
+]v0.1.0creatoros_extractcreatoros_searchcreatoros_speakScored across 3 tools
Each tool targets a distinct capability: URL-to-Markdown extraction, query-based web search, and text-to-speech. The descriptions explicitly cross-reference each other ('use creatoros_search instead', 'use creatoros_extract instead'), leaving no realistic path for misselection even where extract and search both return Markdown.
All three tools use the same creatoros_ prefix followed by a single clear verb (extract, search, speak). No mixing of camelCase, noun-phrases, or version suffixes; the pattern is fully predictable.
Three tools is on the lean side but each covers a genuinely separate operation with no filler or redundant variants. Slightly thin for a server branded as a general 'creator' platform, but well-scoped for the read-and-speak niche it actually covers.
The read (extract/search) and output (speak) lifecycle is fully covered with no dead ends within the stated scope, and read-only behavior is explicit. Minor gaps exist—no batch/multi-URL extraction, no summarization or caching of fetched content—but agents can work around these by chaining calls.
Clean Markdown and AI-readability scoring for any URL. Built for AI agents.
Web pages as clean Markdown and JSON for AI agents, in fewer tokens, with an Evidence Record.
Web search and any page as LLM-ready Markdown for AI agents. Free keyless tier, no signup.
Web data extraction and browser workflows for AI assistants.
