Enables queuing and reviewing short-form post drafts for LinkedIn, X, and Meta Threads through Buffer.
Allows publishing long-form Markdown articles to Dev.to.
Allows sending content to Make webhooks for custom automation pipelines.
Allows publishing long-form articles to Medium.
Allows sending content to n8n webhooks for custom automation pipelines.
Allows generating and submitting Reddit posts formatted for specific subreddits.
Allows sending content to Slack via webhooks for custom pipelines.
Allows publishing long-form articles to Substack.
Allows sending content to Telegram via webhooks for custom pipelines.
Allows generating and queuing bite-sized posts for Meta Threads.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OmniPress MCP Turn my API docs into a LinkedIn article and a Twitter thread, sanitizing any secrets."
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.
🇺🇸 English | 🇧🇷 Português | 📖 GitHub Wiki
The Universal Agentic Publishing Protocol & Distribution Engine for AI Agents via Model Context Protocol (MCP)
OmniPress MCP is an open-source, domain-agnostic agentic publishing protocol. It empowers AI agents (like Antigravity, Claude, or ChatGPT) to ingest raw thoughts, codebases, research papers, court rulings, policy memos, or market data, and transform them into authoritative long-form publications and multi-channel social campaigns.
OmniPress is designed to be truly "Omni":
Omni-Domain: Universal ingestion engine extensible via modular niche skills.
Omni-Platform: Native distribution across LinkedIn, X (Twitter), Meta Threads, Reddit, Webhooks (n8n/Make), and Markdown archives.
Omni-Runtime: Zero-dependency Node.js engine + full Python FastMCP implementation.
Modern knowledge workers, developers, researchers, and specialists spend hours translating their work into different formats across fractured social platforms.
OmniPress solves this by providing a unified Agentic Publishing Pipeline:
┌─────────────────────────────────────────────────────────────────────────┐
│ 1. UNIVERSAL INTAKE │
│ Raw Thoughts • Code Diffs • Whitepapers • Tax Rulings • Research Data │
└────────────────────────────────────┬────────────────────────────────────┘
│
┌────────────────────────────────────▼────────────────────────────────────┐
│ 2. MODULAR SKILL RUNTIME │
│ Each niche has a dedicated skill directing tone, style & jargon: │
│ ├── Tech & Software Architecture ├── Tax, Law & Forensic Auditing │
│ ├── Public Governance & GovTech ├── Finance, Crypto & Markets │
│ └── Scientific & Academic Research └── Product & Founder Journey │
└────────────────────────────────────┬────────────────────────────────────┘
│
┌────────────────────────────────────▼────────────────────────────────────┐
│ 3. PRIVACY & SANITIZATION SHIELD │
│ Automated masking of API keys, client secrets, court case IDs, & PII │
└────────────────────────────────────┬────────────────────────────────────┘
│
┌────────────────────────────────────▼────────────────────────────────────┐
│ 4. MULTI-PLATFORM SYNDICATION │
│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐│
│ │ LinkedIn │ │ X (Twitter) │ │ Meta Threads │ │ Reddit ││
│ │ (Leadership) │ │ (Threads) │ │ (Bite-sized) │ │ (Subreddits) ││
│ └───────┬───────┘ └───────┬───────┘ └───────┬───────┘ └───────┬───────┘│
│ │ │ │ │ │
│ └─────────────────┴────────┬────────┴─────────────────┘ │
│ ▼ │
│ ┌────────────────────────┐ │
│ │ Long-form .md Archive │ │
│ │ (Substack/Medium/Blog) │ │
│ └────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────┘Related MCP server: automate-idea-to-social-mcp
OmniPress separates the distribution engine (MCP tools) from the domain intelligence (Agent Skills).
You can author any kind of article by simply enabling or creating a specialized skill in .agents/skills/<niche>:
tech-architecture: Deep code walkthroughs, system trade-offs, and GitHub release announcements.
tax-and-legal: Authoritative tax analyses, compliance reviews, and judicial forensics with strict court secrecy (segredo de justiça) compliance.
govtech-civic: Public policy commentary, municipal modernization, and public transparency.
science-research: Academic breakdowns, literature digests, and scientific methodology.
founder-buildinpublic: Product updates, transparent metrics, and startup lessons.
Before anything is staged or published, OmniPress runs an automated security and privacy scan:
Credentials: Masks API keys, JWT tokens, Bearer secrets, and private IPs.
Legal/PII: Masks judicial process numbers (CNJ standard), tax IDs (CPF/CNPJ), phone numbers, and emails.
One core thought produces five synchronized assets:
Long-Form Article: Clean Markdown with rich YAML frontmatter for Substack, Medium, Jusbrasil, Dev.to, or static site generators.
LinkedIn Post: Attention-retaining opening, bulleted takeaways, discussion prompt, and hashtags.
X (Twitter) Thread: 3–5 tweet narrative arc.
Meta Threads Post: Conversational, community-focused insight.
Reddit Submission: Problem-first, authentic breakdown formatted for specific subreddits (r/programming, r/webdev, r/SideProject, r/direito).
Node.js (18+): Zero dependencies—uses native stdio, fetch, and crypto. No npm install needed!
Python (3.10+): FastMCP server with modular adapter inheritance (BasePublisherAdapter).
Run the 6-scenario automated test suite on Node.js:
npm test
# or directly: node tests/test_omnipress.jscp .env.example .env(OmniPress works out-of-the-box even without API keys by saving articles locally and formatting copy ready for manual pasting).
See the Setup & Account Configuration Guide (docs/SETUP_GUIDE.md) to connect:
Buffer: For LinkedIn, X, and Meta Threads draft review.
Reddit: For direct subreddit posting via official Reddit Script App.
Webhooks: For custom pipelines in n8n, Make, Slack, or Telegram.
Configure OmniPress globally in ~/.gemini/config/mcp_config.json:
{
"mcpServers": {
"omnipress": {
"command": "node",
"args": ["C:/Users/Ismael/projects/omnipress-mcp/src/server.js"],
"env": {
"ARTICLES_DIR": "C:/Users/Ismael/projects/omnipress-mcp/articles"
}
}
}
}Technology & Architecture:
"OmniPress: Analyze our database caching architecture in
src/cache. Draft an in-depth technical article, a LinkedIn lessons-learned post, and an X thread."
Tax, Law & Public Administration:
"OmniPress: Break down the constitutional implications of the new Tax Reform on municipal software licensing. Generate an article with YAML frontmatter, a LinkedIn post, and a Reddit breakdown for r/direito."
Founder & Build-in-Public:
"OmniPress: Write a launch announcement for our open-source release. Prepare a LinkedIn post, a Threads teaser, and submit a self-post to Reddit r/SideProject."
Tool | Purpose |
| Archives long-form article locally with YAML frontmatter organized by |
| Queues short-form post/thread to LinkedIn, X, Threads, or Reddit in Draft/Review mode. |
| Standalone utility to scan text for credentials, PII, or confidential court IDs without publishing. |
| Lists recently archived articles and metadata. |
GitHub Wiki: Comprehensive architectural deep dives and runbooks.
Creating Niche Skills Guide: How to build custom skills for your specific domain.
Distributed under the MIT License.
Scans text for sensitive judicial lawsuit numbers (CNJ), tax IDs (CPF/CNPJ), emails, or PII without publishing.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to scan for PII |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it usefully discloses that the operation does not publish. However, it does not state what happens to detected PII, whether data is stored or transmitted, or what the result format is, which matters for a sensitive-data scanner.
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?
One sentence, no filler, and the key behavioral constraint 'without publishing' is included without bloating the description. 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?
For a one-parameter tool the description is fairly complete, but with no output schema it does not mention what the tool returns or how detections are reported. Since this is an inspection tool, the absence of result-format information is a notable gap, though not enough to make the tool unusable.
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 schema already fully documents the single text parameter, so the baseline is 3. The description adds value by enumerating specific detection targets (CNJ, CPF/CNPJ, emails, PII), giving the parameter semantic grounding beyond 'Text to scan for PII'.
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 'scans' with the target resource (text) and names the sensitive entities detected (CNJ, CPF/CNPJ, emails, PII). The phrase 'without publishing' clearly distinguishes it from sibling publishing tools.
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 'without publishing' caveat and the inspect verb imply this is a pre-publication safety check, and the sibling list makes the contrast with publish/queue/list tools obvious. It does not explicitly state when-not-to-use, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists recently saved articles in the local archive.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of articles to return (default 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'Lists' implies a read-only operation and 'local archive' scopes the data source, but the description does not clarify ordering, non-destructiveness, or the meaning of 'recently saved.' Adequate for a simple read tool, but not rich.
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?
One focused sentence with no filler. The action and resource are front-loaded, making the purpose immediately understandable.
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 tool's low complexity, one documented optional parameter, and no annotations, the description is nearly complete. It could mention return format or ordering, but nothing essential is missing for an agent to invoke it correctly.
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%, and the single optional parameter 'limit' is already described with its default value. The description adds no parameter meaning, but it does not need to because the schema fully documents it.
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: 'Lists recently saved articles in the local archive.' This clearly distinguishes it from sibling tools like omnipress_publish_article and omnipress_queue_post, which imply write operations.
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 makes the tool's purpose clear but does not explicitly say when to choose it over alternatives or when not to use it. Sibling names imply different operations, but the usage context is left to inference rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Saves a complete, publication-ready long-form article to the local archive with YAML frontmatter. Runs automatic legal/PII de-identification.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Array of keyword tags | |
| title | Yes | Article title | |
| author | No | Author name | |
| category | No | Topic category (technology, tributario, pericia, govtech) | |
| sanitize | No | Whether to sanitize court numbers and PII (default true) | |
| content_markdown | Yes | Complete article in GitHub-flavored Markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it runs automatic legal/PII de-identification, which is a meaningful behavioral trait. However, it does not mention side effects (e.g., overwriting existing articles), required permissions, or whether the operation is reversible. The absence of annotations makes this gap more significant.
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 concise sentences, front-loaded with the primary purpose and followed by a key behavior. No redundancy or filler. The structure is efficient 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?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description covers the core function but omits important context: return values, error behavior, idempotency, and how it fits into the workflow with siblings. It is adequate but not fully complete.
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%, so all parameters are already documented. The description does not add extra meaning to any parameter beyond what the schema provides, though it implicitly relates to the 'sanitize' parameter via the de-identification mention. Per the baseline rule, this scores 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 action ('Saves a complete, publication-ready long-form article') and the target ('to the local archive with YAML frontmatter'), and it notes the de-identification behavior. It is distinguishable from siblings (queue_post, inspect_content, list_recent) by its explicit 'save' verb, though it does not explicitly contrast with queue_post, which could be ambiguous.
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 the siblings. It does not mention prerequisites, typical workflow (e.g., after queueing), or any conditions that would favor this tool over omnipress_queue_post or omnipress_inspect_content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queues a post or thread to social platforms (LinkedIn, X, Threads via Buffer, or Reddit) in Draft/Review mode.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Post text or thread segment | |
| title | No | Optional post title (used for Reddit or headline feeds) | |
| sanitize | No | Whether to sanitize sensitive IDs before queuing (default true) | |
| platforms | No | Target platforms: ["linkedin"], ["x"], ["threads"], ["reddit:subreddit_name"], or ["all"] | |
| media_urls | No | Optional media URLs or links | |
| schedule_time | No | Optional ISO timestamp or schedule format |
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 does add one meaningful behavior—queuing to Draft/Review mode—but it omits other important traits such as whether the action is reversible, whether authentication or platform configuration is required, what happens after queueing, or what response the agent should expect.
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, front-loaded sentence with no filler. It communicates the core action, target platforms, and mode efficiently.
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?
The tool has 6 parameters and no output schema, yet the description gives no information about return values, scheduling semantics, platform-specific constraints, or when queueing should be preferred over publishing. The schema covers the parameters, but the description leaves too much operational context missing for an agent to invoke the tool confidently.
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 parameters are already fully documented in the schema. The description does not add parameter-level detail beyond what the schema provides, which matches the baseline of 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 uses a specific verb ('Queues') with a clear resource ('a post or thread') and names the target platforms. It also states that the post is placed in Draft/Review mode, which distinguishes it from a publishing action like the sibling omnipress_publish_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?
No explicit guidance is given about when to use this tool versus alternatives such as omnipress_publish_article. The Draft/Review mode implies a pre-publication use case, but the description never states the conditions or exclusions that would steer an agent toward or away from this tool.
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.
v0.1.0omnipress_inspect_contentomnipress_list_recentomnipress_publish_articleomnipress_queue_postScored across 4 tools
Each tool performs a clearly distinct operation: publishing an article, queueing a social post, scanning content for PII, and listing archived articles. There is no functional overlap between the tools.
All tools share the omnipress_ prefix and use snake_case action-first names. The only minor inconsistency is list_recent lacking a noun object compared to the verb_noun pattern of the other tools.
Four tools is well-scoped for a focused content workflow: inspect, publish, queue, and list. Each tool earns its place without unnecessary bloat.
The core workflow of scanning, publishing, queueing, and listing is covered. Minor lifecycle gaps exist, such as no article retrieval/editing or queue management, but agents can work around them for the apparent purpose.
Publish articles and notes under your own byline, to a readership of other AI agents.
Draft, schedule and publish social posts to nine platforms from any AI agent.
Create, manage, publish, and analyze Inblog content through AI agents.
Guarded agent surface for X & LinkedIn: discover, score, and draft in your voice. No key can post.
