What can you do with this server?

Manage a Lontar blog via MCP: read published content and perform authenticated post management. * list_posts — list published posts (paginated) * get_post — fetch a published post by slug, including rendered HTML * list_drafts — list draft posts (requires token) * create_post — create a draft (or scheduled post with published_at) * update_post — update a post’s title, body, excerpt, or publish date by slug * delete_post — permanently delete a post * publish_post — publish a draft by setting published_at to now * unpublish_post — clear published_at to unpublish a post

Which integrations are available for this server?

Provides tools for managing a blog through the Lontar headless blogging API, which is built on Laravel. Allows AI agents to list, create, update, delete, publish, and unpublish posts, as well as manage drafts.

How do I use lontar-mcp?

1. Click on "Deploy 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., "@lontar-mcp list published posts" 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.

lontar-mcp

by thesimonharms

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Moved. This GitHub copy is an archive. Use the Forgejo repository.
Canonical repository: https://git.simonharms.com/thesimonharms/lontar-mcp

lontar-mcp

MCP server that gives AI agents full blog management over a Lontar headless blogging API — list and read published posts, draft new content, publish, update, and delete.

Lontar is a Laravel package; this server talks to its HTTP API so agents can manage a blog without touching the CMS UI.

Tools

Tool	Auth	Description
`list_posts`	No	List published posts (paginated)
`get_post`	No	Get a published post by slug, including rendered HTML body
`list_drafts`	Yes	List draft posts (paginated)
`create_post`	Yes	Create a new post (draft by default)
`update_post`	Yes	Update an existing post by slug
`delete_post`	Yes	Permanently delete a post
`publish_post`	Yes	Publish a draft (sets `published_at` to now)
`unpublish_post`	Yes	Unpublish a post (clears `published_at`)

`list_posts` / `list_drafts`

Parameter	Type	Default	Description
`page`	`number`	`1`	Page number

`get_post`

Parameter	Type	Description
`slug`	`string`	Post slug

`create_post`

Parameter	Type	Default	Description
`title`	`string`	—	Post title (slug auto-generated)
`body`	`string`	—	Post body (Markdown)
`excerpt`	`string`	—	Short excerpt
`published_at`	`string`	—	ISO 8601 date; omit to save as draft

`update_post`

Parameter	Type	Description
`slug`	`string`	Current post slug
`title`	`string`	New title (regenerates slug)
`body`	`string`	New body (Markdown)
`excerpt`	`string \| null`	New excerpt
`published_at`	`string \| null`	New publish date, or `null` to unpublish

`delete_post` / `publish_post` / `unpublish_post`

Parameter	Type	Description
`slug`	`string`	Post slug

All tool responses are JSON strings in the MCP text content field.

Related MCP server: Ghost MCP

Install

npm install lontar-mcp

Or clone and build locally:

git clone https://github.com/thesimonharms/lontar-mcp.git
cd lontar-mcp
npm install
npm run build

Requires Node.js 18+.

Environment variables

Variable	Required	Description
`LONTAR_API_URL`	Yes	API base URL, e.g. `https://example.com/api`
`LONTAR_API_TOKEN`	For write ops	Laravel Sanctum bearer token

MCP configuration

Cursor / Claude Desktop

{
  "mcpServers": {
    "lontar": {
      "command": "node",
      "args": ["C:/absolute/path/to/lontar-mcp/dist/index.js"],
      "env": {
        "LONTAR_API_URL": "https://your-blog.example.com/api",
        "LONTAR_API_TOKEN": "your-sanctum-token"
      }
    }
  }
}

If installed globally or via npx:

{
  "mcpServers": {
    "lontar": {
      "command": "npx",
      "args": ["lontar-mcp"],
      "env": {
        "LONTAR_API_URL": "https://your-blog.example.com/api",
        "LONTAR_API_TOKEN": "your-sanctum-token"
      }
    }
  }
}

Examples

List published posts

{ "page": 1 }

Get a post

{ "slug": "hello-world" }

Create a draft

{
  "title": "My New Post",
  "body": "# Hello\n\nMarkdown content here.",
  "excerpt": "A short summary"
}

Publish a draft

{ "slug": "my-new-post" }

Development

npm run build   # bundle server to dist/
npm start       # run on stdio
npm test        # build + run cobasaja tests

Tests live in tests/ and use cobasaja to spawn the server over stdio against an in-memory mock API, asserting tool behaviour end-to-end.

License

MIT © Simon Harms

Available Tools

8 tools

create_postA

Create a new blog post. Requires LONTAR_API_TOKEN. Slug is auto-generated from the title. Omit published_at to create a draft.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Post title
`body`	Yes	Post body (Markdown)
`excerpt`	No	Short excerpt
`published_at`	No	ISO 8601 publish date; omit to save as draft

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description fully covers behavioral traits. It discloses that slug is auto-generated, token requirement, and draft vs. published behavior. It does not mention return value or potential side effects, but covers essential behaviors.

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?

Two concise sentences, no unnecessary words, front-loaded with the core purpose. Every sentence provides value.

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

Completeness4/5

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

Given no output schema, the description could specify return value, but it covers creation behavior, required auth, and parameter semantics adequately. For a 4-param tool with good schema descriptions, it is reasonably complete.

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 coverage is 100%, so baseline is 3. The description adds meaning for the published_at parameter ('omit to create draft') and implies title affects slug. However, it does not add significant detail for title, body, or excerpt beyond the schema.

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

Purpose5/5

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

The description explicitly states 'Create a new blog post', which is a specific verb and resource. It distinguishes from sibling tools like delete_post, get_post, etc., by focusing solely on creation.

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

Usage Guidelines4/5

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

The description explains when to use (to create a new post) and provides key guidance: requires LONTAR_API_TOKEN, and omitting published_at creates a draft. However, it does not explicitly contrast with similar sibling tools like publish_post or update_post.

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

delete_postA

Permanently delete a post by slug. Requires LONTAR_API_TOKEN.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Post slug to delete

TDQS

A3.7/5.0

Behavior3/5

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

States 'permanently delete' indicating irreversibility, and mentions auth requirement. However, with no annotations, it doesn't disclose side effects, idempotency, or return behavior.

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?

Single sentence of 8 words, front-loaded with verb and resource. All information is essential with no redundancy.

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

Completeness3/5

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

Given simplicity (1 param, no output schema), description covers core functionality and requirement. Lacks detail on success/error responses or confirmation steps.

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 coverage is 100% with parameter slug described as 'Post slug to delete'. The description adds no extra meaning beyond the schema.

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

Purpose5/5

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

Description clearly states 'Permanently delete a post by slug' with a specific verb and resource. It distinguishes from sibling tools like create_post, get_post, and list_posts.

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

Usage Guidelines3/5

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

Mentions required token (LONTAR_API_TOKEN) but does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives. Implies use for deletion but lacks exclusions.

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

get_postA

Get a single published post by slug. Returns full post data including body and rendered_body (HTML).

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Post slug

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided, so the description carries the burden. It states the return includes 'full post data including body and rendered_body (HTML).' For a simple read-only tool, this is sufficient. It does not discuss auth or rate limits, but these are minor.

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?

Two sentences: the first clearly states the core purpose, the second adds return details. No wasted words, front-loaded.

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

Completeness5/5

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

Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers purpose and return value completely. No gaps.

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 coverage is 100% with the slug parameter described as 'Post slug'. The description adds that it is for a published post, but does not add syntax or format details. Baseline of 3 is appropriate as schema does the heavy lifting.

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

Purpose5/5

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

The description clearly states 'Get a single published post by slug.' It specifies the action (get) and the resource (a single published post). This distinguishes it from sibling tools like list_posts (which returns multiple) and create_post (which creates).

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

Usage Guidelines4/5

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

The description implicitly indicates usage: when you need one specific published post by slug. It does not explicitly mention when not to use or alternatives, but the context is clear given the sibling list.

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

list_draftsA

List draft posts (paginated). Requires LONTAR_API_TOKEN. Returns title, slug, excerpt, and created_at.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No	Page number (default: 1)

TDQS

A4/5.0

Behavior4/5

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

Discloses pagination, required authentication, and return fields. No annotations exist, so description handles transparency well, but could mention default page size or order.

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?

Two sentences, front-loaded with purpose, no wasted words. Efficient and clear.

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

Completeness4/5

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

Adequate for a simple list tool with one parameter. Covers purpose, auth, pagination, and output fields. Lacks detail on pagination limits or error handling.

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 already fully describes the 'page' parameter with description and constraints. Description adds no further meaning, so baseline 3 is appropriate.

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

Purpose5/5

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

Clearly states 'List draft posts (paginated)' with specific verb and resource. Distinguishes from sibling 'list_posts' which likely lists all posts, not just drafts.

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

Usage Guidelines3/5

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

Provides a prerequisite (LONTAR_API_TOKEN) but no guidance on when to use this tool versus alternatives like list_posts 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.

list_postsA

List published blog posts (paginated). Returns title, slug, excerpt, and published_at for each post.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No	Page number (default: 1)

TDQS

A3.8/5.0

Behavior3/5

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

No annotations exist, so the description carries the burden. It states pagination and the returned fields but does not disclose ordering, rate limits, or that it is read-only. The behavior is adequately implied for a simple list 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 that front-loads the action ('List published blog posts') and result ('Returns...'). No wasted words.

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

Completeness4/5

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

For a low-complexity tool with one optional parameter and no output schema, the description is sufficiently complete. It could optionally mention ordering but is not deficient.

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 only parameter, page, is already fully described in the input schema (type, default, min, max). The description only mentions 'paginated', adding no extra semantic meaning beyond schema coverage.

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

Purpose5/5

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

The description clearly states the tool lists published blog posts with pagination, and specifies the returned fields (title, slug, excerpt, published_at). This distinguishes it from sibling tools like list_drafts or get_post.

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

Usage Guidelines3/5

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

The description implies use for retrieving published posts but does not explicitly state when to use this tool over alternatives like list_drafts or get_post. No prerequisites or exclusions are mentioned.

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

publish_postB

Publish a draft post by setting published_at to now. Requires LONTAR_API_TOKEN.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Post slug to publish

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It reveals one side effect (setting published_at to now) but omits other behavioral details like reversibility, error cases, or confirmation. Minimal disclosure.

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?

Two concise sentences. First sentence front-loads the core action, second sentence adds important context. No redundant or unnecessary text.

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

Completeness3/5

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

Given simplicity (one param, no output schema, no annotations), the description is somewhat complete but lacks information about return value, error handling, and idempotency. Adequate for simple use, but gaps remain.

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 coverage is 100% with one parameter (slug) fully described. Description adds no extra 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.

Purpose5/5

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

Description clearly states verb (publish) and resource (a draft post), and specifies the mechanism (setting published_at to now). It effectively distinguishes from sibling tools like unpublish_post and create_post.

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?

Only mentions a required token (LONTAR_API_TOKEN). No guidance on when to use vs alternatives (e.g., update_post) or when not to use (e.g., already published). Usage context is implied but not explicit.

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

unpublish_postA

Unpublish a post by clearing published_at. Requires LONTAR_API_TOKEN.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Post slug to unpublish

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided; description only states 'clearing published_at' without detailing side effects (e.g., post becomes hidden, draft status, reversibility). Auth requirement noted but insufficient overall.

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?

Single sentence, front-loaded with verb, includes essential requirement. No wasted words.

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

Completeness4/5

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

Adequate for a simple tool: states action, method, auth. Lacks details on post-unpublish state, but low complexity makes it acceptable.

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 has 100% coverage for the single parameter 'slug' with clear description. Description adds no extra meaning beyond schema.

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

Purpose5/5

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

Description clearly states specific action ('Unpublish a post') and method ('clearing published_at'), with auth requirement. Distinguishes from sibling 'publish_post'.

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

Usage Guidelines3/5

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

Mentions prerequisite (LONTAR_API_TOKEN) but no explicit guidance on when to use versus alternatives like delete_post or update_post.

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

update_postA

Update an existing post by slug. Requires LONTAR_API_TOKEN. Only provided fields are changed.

ParametersJSON Schema

Name	Required	Description
`slug`	Yes	Current post slug
`title`	No	New title (regenerates slug)
`body`	No	New body (Markdown)
`excerpt`	No	New excerpt
`published_at`	No	New publish date, or null to unpublish

TDQS

A4.1/5.0

Behavior3/5

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

No annotations provided, so the description carries the burden. It discloses an authentication requirement and the partial-update behavior. However, it does not mention error handling, rate limits, or what happens if the slug is missing, leaving some gaps.

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?

Two concise sentences. The first sentence states the core purpose, and the second provides essential context. No wasted words.

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

Completeness3/5

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

For a tool with 5 parameters and no output schema, the description covers the basics but lacks details on return values, error scenarios, or how to obtain the slug. Given the simplicity of the tool, it is minimally complete.

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?

Schema coverage is 100%, so the schema already documents parameters. The description adds meaningful context beyond schema: 'New title (regenerates slug)' and 'New publish date, or null to unpublish' clarify side effects and null usage.

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

Purpose5/5

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

The description clearly states the action ('Update'), the resource ('an existing post'), and the identifier ('by slug'). This distinguishes it from sibling tools like create_post, delete_post, or publish_post.

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

Usage Guidelines4/5

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

The description explicitly mentions the required authentication token ('Requires LONTAR_API_TOKEN') and the update behavior ('Only provided fields are changed'). It does not provide explicit when-not-to-use comparisons but the guidelines are clear enough.

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.

8 tool updatesv1.0.0Jun 20, 2026
- First observedcreate_post
- First observeddelete_post
- First observedget_post
- First observedlist_drafts
- First observedlist_posts
- First observedpublish_post
- First observedunpublish_post
- First observedupdate_post

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-06-20 12:45 across 8 tools

Disambiguation5/5

Each tool targets a distinct action on posts or drafts: create, delete, get, list drafts, list published, publish, unpublish, update. No overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., create_post, list_drafts, publish_post), making predictions easy.

Tool Count5/5

8 tools cover the core blog post lifecycle without being excessive or too sparse. Each tool serves a clear role.

Completeness4/5

Covers full CRUD plus draft/publish state management. Minor gap: no search or filtering tools, but core workflow is complete.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

supportsheep
io.github.pooriaarab
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Customer Support Content Management Systems Marketing
1
qpost-mcp
io.github.arslan2012
MCP server for QPost — lets AI agents publish video and image posts to YouTube, TikTok, Instagram.
Social Media
1
blogbat
io.github.pooriaarab
Hosted MCP for BlogBat: read, write, generate, and publish blog articles and content.
Content Management Systems Marketing Workplace & Productivity
1
mcp-aichatOAuth
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2

Related MCP Servers

@alog-world/mcp
Content Management Systems Search Payments & Billing
asicojp
A
license
A
quality
D
maintenance
MCP server for Alog, an AI × Human blog platform. Enables AI agents to post logs, create and publish articles, search content, and interact socially on alog.world.
Updated 3 months ago (2026-06-11 14:35 UTC)
19
22 npm
1
MIT
Ghost MCP
Content Management Systems Developer Tools
workspace
A
license
A
quality
D
maintenance
An MCP server for interacting with Ghost CMS blogs through AI assistants, supporting both read-only content and full admin operations.
Updated 6 months ago (2026-03-03 16:52 UTC)
8
11 npm
2
ISC
writefreely-mcp-server
Content Management Systems Social Media
laxmena
A
license
A
quality
B
maintenance
An MCP server for WriteFreely that enables AI agents to publish and manage content on WriteFreely instances (including self-hosted instances and Write.as).
Updated 8 months ago (2026-01-16 01:40 UTC)
10
3
MIT
Agentic CMS
Content Management Systems Developer Tools Autonomous Agents
intellieffect
A
license
Not graded
quality
B
maintenance
Open-source MCP server that turns any CMS backend into an AI-agent-ready content management system. It provides tools for content CRUD, idea management, and publication tracking, with safety features requiring human approval for publishing.
Updated 2 months ago (2026-07-09 11:20 UTC)
MIT

lontar-mcp

Tools

list_posts / list_drafts

get_post

create_post

update_post

delete_post / publish_post / unpublish_post

Install

Environment variables

MCP configuration

Cursor / Claude Desktop

Examples

Development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`list_posts` / `list_drafts`

`get_post`

`create_post`

`update_post`

`delete_post` / `publish_post` / `unpublish_post`