How do I use mcp-movabletype-writer?

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., "@mcp-movabletype-writer create a draft post about MCP server features" 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.

mcp-movabletype-writer

by burnworks

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

mcp-movabletype-writer

日本語

MCP server for Movable Type.

It lets MCP-compatible AI tools such as Claude Desktop work with Movable Type so that AI-generated drafts can be created and edited directly inside MT.

You can brainstorm articles with an AI assistant, store the result as a Movable Type draft, and iterate on the same draft by asking the AI to revise sections.

Features

🤖 AI integration: Post drafts to Movable Type straight from Claude Desktop or any MCP client.
💾 Session tracking: Remembers the last edited draft so multi-step rewrites stay in context.
✏️ Rewrite ready: “Fix this paragraph” style prompts update the current draft in place.
📝 Draft management: List drafts and inspect individual draft details.

For safety this server intentionally focuses on collaborative draft creation. It does not allow:

Deleting drafts or published entries.
Publishing drafts.
Editing already published entries or reverting them to drafts.

Related MCP server: mcp-media-engine

Requirements

Node.js 22.7.5 or newer (current LTS 24.x is recommended).
Movable Type 7 r.53xx or newer with Data API enabled.
- Tested with Data API v4 and later.

Installation

If you intend to run it via npx, you can skip this section and jump to “Using with npx”.

git clone https://github.com/burnworks/mcp-movabletype-writer.git
cd mcp-movabletype-writer
npm install
npm run build

or simply install from npm:

npm install mcp-movabletype-writer

Configuration

1. Prepare Movable Type

In both the system dashboard and the target website/blog dashboard enable Tools → Web Services → Data API.
Open the MT user profile that will run the API calls and note the username and Web Services Password (this is different from the regular CMS login password).
Confirm the Data API endpoint URL (e.g. https://example.com/your_mt_path/mt-data-api.cgi).

2. Configure Claude Desktop

Open claude_desktop_config.json.

File locations

Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

You can also open the file from Claude Desktop → Settings → Administrator.

Example configuration for a local build

Append the following block. args must contain the full path to dist/index.js.
On Windows, escape backslashes such as mcp-movabletype-writer\\dist\\index.js.

{
  "mcpServers": {
    "movabletype-writer": {
      "command": "node",
      "args": [
        "/full_path_to/mcp-movabletype-writer/dist/index.js"
      ],
      "env": {
        "MT_API_URL": "https://example.com/your_mt_path/mt-data-api.cgi",
        "MT_USERNAME": "your_username",
        "MT_PASSWORD": "your_webservice_password",
        "MT_API_VERSION": "5",
        "MT_CLIENT_ID": "your_client_id",
        "MT_REMEMBER": "1"
      }
    }
  }
}

MT_API_URL: URL to mt-data-api.cgi.
MT_USERNAME: Movable Type username.
MT_PASSWORD: Web Services Password from the MT user profile (do not use the normal login password).
MT_API_VERSION: Data API version in use, e.g. 5, 6, 7.
MT_CLIENT_ID: Any identifier composed of letters, _, or - (e.g. mcp-movabletype-writer).
MT_REMEMBER: remember flag (0/1). Leave it at 1 to keep sessions active until sign-out. Use 0 only if you need very short-lived tokens.

Changing MT_API_VERSION lets you point the same binary at MT Data API v4/v5/v6/v7 without rebuilding. MT_CLIENT_ID must be set; the server exits if it’s missing. Keeping MT_REMEMBER=1 reduces the chance of token expiry mid-session.

Using with npx

You can run the published package with npx. In that case point command to npx:

{
  "mcpServers": {
    "movabletype-writer": {
      "command": "npx",
      "args": [
        "mcp-movabletype-writer"
      ],
      "env": {
        "MT_API_URL": "https://example.com/your_mt_path/mt-data-api.cgi",
        "MT_USERNAME": "your_username",
        "MT_PASSWORD": "your_webservice_password",
        "MT_API_VERSION": "5",
        "MT_CLIENT_ID": "mcp-movabletype-writer",
        "MT_REMEMBER": "1"
      }
    }
  }
}

Use mcp-movabletype-writer@1.0.0 if you prefer to pin a specific version. The env settings are identical to a local build.

Advanced settings (power users)

Fine-tuning knobs that aren’t meant for day-to-day users live in internal-config.json. Copy internal-config.example.json to the project root (or wherever you run the server from), rename it to internal-config.json, and adjust the values.

requestTimeoutMs: Timeout (milliseconds) for Movable Type HTTP requests. Defaults to 30000.

If the file is missing or contains invalid JSON the server falls back to the built-in defaults, so it’s safe to experiment.

Usage

Basic flow

User: ブログID 1に「MTプラグイン開発入門」という記事の下書きを作成して

Claude: create_draftを実行...
→ 下書きを作成しました（ID: 123）

User: タイトルを「初心者向けMTプラグイン開発」に変更して

Claude: update_last_draftを実行...
→ 記事を更新しました（ID: 123）

User: 本文に「はじめに」のセクションを追加して

Claude: update_last_draftを実行...
→ 記事を更新しました（ID: 123）

Tips

If you manage multiple blogs, ask Claude to run list_sites and choose the correct blog_id from the result.
Claude may default to HTML output; if you prefer Markdown drafts, explicitly request “save in Markdown”.
Within a single conversation the server remembers the latest draft, so follow-up edits usually don’t require specifying entry_id.
To edit another draft, ask for list_recent_drafts, pick an ID from the list, and provide it to update_draft.

See the tool descriptions below for details.

Available tools

`list_sites`

Returns available blogs/sites.

Claude: list_sitesで確認...
→ ID: 1, Name: "Tech Blog"
→ ID: 2, Name: "News"

`create_draft`

Create a new draft.

Required: blog_id, title, body
Optional: tags, categories

`update_last_draft`

Update the most recently created/edited draft.

All parameters are optional; only supplied fields are changed.

`update_draft`

Update a draft by explicit ID.

Required: blog_id, entry_id
Optional: title, body, tags, categories

`get_draft`

Fetch draft details.

Required: blog_id, entry_id

`list_recent_drafts`

List recent drafts.

Required: blog_id
Optional: limit (default 10)

Session storage

Information about the most recent draft is stored at ~/.mcp-mt/session.json:

{
  "lastEntryId": 123,
  "lastBlogId": 1,
  "lastUpdated": "2025-11-07T10:00:00.000Z"
}

This lets update_last_draft run without specifying entry_id.

For developers

Using environment variables with `npm run dev`

If you want to iterate with npm run dev (tsx) instead of npm run build, copy the example env file:

cp .env.example .env

MT_API_URL=https://example.com/your_mt_path/mt-data-api.cgi
MT_USERNAME=your_username
MT_PASSWORD=your_webservice_password
MT_API_VERSION=5
MT_CLIENT_ID=your_client_id
MT_REMEMBER=1

Then run:

npm install
npm run dev

For debugging, tools like @modelcontextprotocol/inspector make it easy to connect and exercise the MCP server while you develop.

Troubleshooting

Authentication errors

Ensure MT_USERNAME, MT_PASSWORD (Web Services Password), and MT_CLIENT_ID are correct.
Verify the Data API is enabled and that mt-data-api.cgi is accessible.

Cannot find drafts

Use list_sites to confirm the correct blog_id.
Run list_recent_drafts to see available drafts and their IDs.

Session keeps resetting

Check that ~/.mcp-mt/session.json still exists.
Restarting Claude Desktop starts a new MCP session (and thus a blank session.json).

License

MIT

References

Available Tools

6 tools

create_draftA

Movable Typeに新しい下書き記事を作成します。作成した記事は自動的にセッションに記憶され、update_last_draftで編集可能になります。

ParametersJSON Schema

Name	Required	Description
`body`	Yes	記事本文（HTML可）
`tags`	No	タグの配列（オプション）
`title`	Yes	記事のタイトル
`blog_id`	Yes	ブログID（サイトID）
`categories`	No	カテゴリーIDの配列（オプション）

TDQS

A4/5.0

Behavior4/5

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

With no annotations supplied, the description carries the disclosure burden and delivers a meaningful stateful behavior: the created entry is automatically stored in session and becomes editable via update_last_draft. It still omits whether the draft is ever published, required permissions/auth, and what identifier (if any) comes back.

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 compact sentences with the core action front-loaded and the session/editing consequence second; every clause carries information and there is no filler.

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 creation tool with no output schema and no annotations, the description covers the key post-call behavior (session storage, subsequent editing path), which is what an agent most needs to know. It stops short of stating return values, error conditions, or permission requirements.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all five parameters (blog_id, title, body, tags, categories) are already documented in the schema. The description adds no additional meaning about parameter formats, constraints, or optionality, so the baseline 3 applies.

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?

States a specific verb and resource ('新しい下書き記事を作成します' – creates a new draft article in Movable Type), and explicitly names the sibling that handles the follow-up editing step (update_last_draft). An agent can distinguish this from update_draft/update_last_draft without opening any schema.

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 the usage flow (create, then edit the session-remembered draft with update_last_draft), which is useful routing context. But it gives no explicit when-to-use vs when-not guidance, prerequisites, or distinction from update_draft for existing drafts.

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

get_draftC

指定したIDの下書き記事の詳細を取得します。

ParametersJSON Schema

Name	Required	Description	Default
`blog_id`	Yes	ブログID（サイトID）
`entry_id`	Yes	記事ID

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of 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?

出力スキーマが存在しないため、返却値の説明責任は本来説明文が負うべきだが、下書き詳細が何を含むかの記述がない。単純な読み取りツールとしては最低限成立しているが、不完全な部分が残る。

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?

スキーマ記述カバレッジが100%であり、blog_id と entry_id の意味はスキーマ側で完全に説明されている。説明文は「指定したID」と述べるのみで、スキーマ以上の意味を付加していないため、ベースラインの3が妥当。

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

Purpose4/5

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

「取得します」という具体的な動詞と「下書き記事の詳細」という対象が明示されており、目的は明確。ただし list_recent_drafts や update_draft など類似の兄弟ツールとの違いには一切触れておらず、使い分けの判断材料を提供していない。

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?

「指定したID」という前提条件は示唆されているが、いつこのツールを使うべきか、あるいは list_recent_drafts や update_draft を代わりに使うべき状況についてのガイダンスが皆無である。

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

list_recent_draftsB

最近の下書き記事の一覧を取得します。記事IDやタイトルを確認できます。

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	取得する記事数（デフォルト: 10）
`blog_id`	Yes	ブログID（サイトID）

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It reveals the returned fields (IDs and titles) but says nothing about ordering/'recent' definition, pagination behavior, sorting, permissions, or whether all drafts or just a subset are returned. For a read tool with zero annotation coverage this is thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no waste, front-loading the core action and following with the returned content. Slightly under-specified rather than verbose, which is not a conciseness flaw.

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 simple 2-parameter read tool with no output schema, the description covers purpose and return content adequately. It omits ordering/pagination context, which the schema's default limit partly covers but '最近' remains undefined.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both blog_id and limit are already documented in Japanese within the schema. The description adds no parameter meaning beyond what the schema provides, making the baseline 3 appropriate.

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

Purpose4/5

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

States a specific verb+resource ('取得' + '最近の下書き記事の一覧') and clarifies the returned content (記事IDやタイトル). It implies a list of recent items versus the singular siblings (get_draft, update_draft), but never names those siblings explicitly.

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 word '最近' hints at scope, and the plural '一覧' implies use when browsing rather than fetching one draft. However, there is no explicit when-to-use, when-not-to-use, or named alternative among the siblings (get_draft, list_sites).

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

list_sitesA

利用可能なブログ（サイト）の一覧を取得します。blog_idを確認する際に使用します。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It conveys that this is an enumeration/lookup operation (implying read-only), but does not state auth requirements, whether results are complete or paginated, or what fields each site entry contains. Adequate but not rich for a no-annotation 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?

Two short sentences, zero waste, with the purpose front-loaded and the usage hint second. Appropriate size for a no-parameter lookup tool.

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 zero-parameter list tool with no output schema, the description covers what it returns (the list of sites) and why you would call it (to obtain blog_id). It is nearly complete; only the shape/fields of the returned site list is left unspecified.

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?

Zero parameters, so there is nothing to document and the baseline of 4 applies. The description does not need to explain input semantics beyond the absence of filters.

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

Purpose4/5

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

States a specific verb+resource: retrieving the list of available blogs (sites). Combined with the sibling set (all draft-related), an agent can tell this is the only tool that enumerates sites, though the description never names a sibling to contrast against.

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?

Explicitly gives the use case: 'use when checking blog_id.' That is a clear trigger condition. It does not name alternatives, but no sibling performs site enumeration, so no exclusion is needed.

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

update_draftB

指定したIDの下書き記事を更新します。明示的に記事IDを指定して編集したい場合に使用します。

ParametersJSON Schema

Name	Required	Description
`body`	No	新しい本文（オプション）
`tags`	No	新しいタグの配列（オプション）
`title`	No	新しいタイトル（オプション）
`blog_id`	Yes	ブログID（サイトID）
`entry_id`	Yes	記事ID
`categories`	No	新しいカテゴリーIDの配列（オプション）

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden for a mutation tool. It does not disclose whether the update is partial (leaving unspecified fields untouched), whether it requires auth/permissions, or what happens on an unknown ID — all left to inference from the optional params.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with the purpose front-loaded and the usage condition second. No wasted text, though very little total content is provided.

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 mutation tool with no annotations and no output schema, the description covers purpose and trigger adequately but is silent on update semantics, permissions, and error behavior. Combined with the fully documented schema, it is minimally viable rather than 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 description coverage is 100%, so the schema already documents all six parameters including the optional body/title/tags/categories. The description adds no format, constraint, or semantic detail beyond what the schema supplies, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb (更新) and resource (下書き記事) scoped by an explicit ID, which implicitly distinguishes it from update_last_draft and create_draft. It does not name the sibling directly, so it falls short of a 5.

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

Usage Guidelines4/5

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

The clause '明示的に記事IDを指定して編集したい場合に使用します' gives a clear usage condition that separates it from the implicit-target sibling update_last_draft. It never names the alternative tool or states exclusions, so it is not fully explicit.

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

update_last_draftC

最後に作成または編集した下書き記事を更新します。タイトル、本文、タグなどを部分的に更新できます。

ParametersJSON Schema

Name	Required	Description
`body`	No	新しい本文（オプション）
`tags`	No	新しいタグの配列（オプション）
`title`	No	新しいタイトル（オプション）
`categories`	No	新しいカテゴリーIDの配列（オプション）

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

2 文で無駄がなく、対象スコープが先頭に置かれている。ただし「など」で列挙を曖昧に終わらせており、もう一段の具体性の余地はある。

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

Completeness2/5

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

更新系ツールでありながらアノテーションも出力スキーマも無く、説明は 2 文のみ。「最後の下書き」の判定基準、対象が存在しない場合、同時編集時の挙動、update_draft との使い分けが欠けており、エージェントが正しく呼び出すには情報が足りない。

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?

スキーマ記述カバレッジが 100% で、各パラメータ（body, tags, title, categories）はスキーマ側で説明済み。説明文は「タイトル、本文、タグなど」と一部を列挙するに留まり、スキーマ以上の意味（形式・制約・カテゴリーIDの解決方法など）は付加していない。ベースラインの 3 が妥当。

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

Purpose4/5

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

明確な動詞＋リソース（下書き記事を更新）を述べ、対象を「最後に作成または編集した下書き」と限定している点で、ID 指定型の update_draft とはスコープが異なることが読み取れる。ただし兄弟ツール名を明示的に挙げてはいないため、選別は読み手の推論に委ねられている。

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?

「最後の下書きを更新する」という用途は暗示されるが、いつ update_draft ではなくこちらを使うべきか、対象下書きが存在しない場合どうなるか、といった条件や除外は一切述べられていない。兄弟に update_draft が存在する以上、選択指針の欠如は実害が大きい。

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.

6 tool updatesv1.0.1Sep 13, 2026
- First observedcreate_draft
- First observedget_draft
- First observedlist_recent_drafts
- First observedlist_sites
- First observedupdate_draft
- First observedupdate_last_draft

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

A3.6/5.0

Scored 2026-09-13 14:20 across 6 tools

Disambiguation4/5

Most tools have distinct roles (get, list, create, update, list_sites). update_last_draft and update_draft have overlapping functionality, but descriptions clearly differentiate session-based vs explicit-ID updates, making confusion unlikely.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (get_draft, list_recent_drafts, create_draft, update_last_draft, update_draft, list_sites). The convention is predictable and readable throughout.

Tool Count5/5

Six tools is well-scoped for a Movable Type draft management server. Each tool serves a clear purpose: create, read, list, update (two variants for convenience), and site listing for context.

Completeness4/5

Core draft lifecycle operations (create, read, list, update) are well covered, plus site listing. Minor gaps include no delete or publish operation and no explicit site/blog_id parameter on create_draft, but these are not critical for a draft-writing tool.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

slimaOAuth
io.github.slima-ai
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
Developer Tools
21
mcp-aichatOAuth
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2
OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
royal-mcpOAuth
com.royalplugins
Security-first WordPress MCP server. 129 tools for Claude, ChatGPT, Gemini. Free on wp.org.
Content Management Systems Developer Tools
29

Related MCP Servers

MCP Simple OpenAI Assistant
Agent Orchestration Communication
andybrandt
A
license
A
quality
D
maintenance
A simple MCP server for interacting with OpenAI assistants. This server allows other tools (like Claude Desktop) to create and interact with OpenAI assistants through the Model Context Protocol.
Updated a year ago (2025-09-12 21:22 UTC)
9
39
MIT
mcp-media-engine
Multimedia Processing AI & Machine Learning
Tr1ckyMag1ca1
A
license
A
quality
B
maintenance
MCP server for AI-powered image, audio, and video generation, enabling media creation directly from Claude, Cursor, and other MCP clients.
Updated 2 months ago (2026-07-14 15:20 UTC)
11
39 npm
MIT
@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
16 npm
1
MIT
blog-generator-mcp
AI & Machine Learning Content Management Systems Developer Tools
jiwon11
F
license
A
quality
D
maintenance
An MCP server that automatically generates technical blog posts using AI (Gemini and Claude), supporting various input types, styles, and collaborative workflow.
Updated 7 months ago (2026-02-07 08:40 UTC)
10
-

mcp-movabletype-writer

Features

Requirements

Installation

Configuration

1. Prepare Movable Type

2. Configure Claude Desktop

File locations

Example configuration for a local build

Using with npx

Advanced settings (power users)

Usage

Basic flow

Tips

Available tools

list_sites

create_draft

update_last_draft

update_draft

get_draft

list_recent_drafts

Session storage

For developers

Using environment variables with npm run dev

Troubleshooting

Authentication errors

Cannot find drafts

Session keeps resetting

License

References

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`list_sites`

`create_draft`

`update_last_draft`

`update_draft`

`get_draft`

`list_recent_drafts`

Using environment variables with `npm run dev`