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., "@microCMS Document MCP Server How do I publish draft content via API in microCMS?"
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.
microCMS ドキュメントにアクセスするための Model Context Protocol (MCP) サーバーです。
この MCP サーバーは、microCMSの提供するドキュメントへのアクセスを提供します。
AI アシスタントが最新のドキュメント内容を検索・取得できるようにします。
Related MCP server: colyseus-docs-mcp
Cursorに導入する場合、以下のリンクをブラウザに貼り付けてインストールできます。
cursor://anysphere.cursor-deeplink/mcp/install?name=microcms-document&config=eyJjb21tYW5kIjoibnB4IC15IG1pY3JvY21zLWRvY3VtZW50LW1jcC1zZXJ2ZXIifQ%3D%3DClaude Codeに導入する場合、以下のコマンドを実行で設定を追加できます。
claude mcp add microcms-document -- npx -y microcms-document-mcp-serverClaude Desktopに導入する場合、MCPBファイルを使って簡単にインストールできます。
リリースページ から最新の microcms-document-mcp-server.mcpb をダウンロード
ダウンロードしたmcpbファイルをダブルクリックで開く
その他のMCPクライアントに導入する場合、設定ファイルに以下を追加してください。
{
"mcpServers": {
"microcms-document": {
"command": "npx",
"args": ["-y", "microcms-document-mcp-server"]
}
}
}セットアップ後、microCMSについての質問をするとAIが必要に応じてドキュメントを読み、回答します。
チャットの文章に use microcms-docs-mcp と書くと明示的にMCPの利用を依頼することもできます。
microCMSの仕様について質問する
microCMSで、下書きで登録済みのコンテンツをAPI経由で公開したい。
どのようなリクエストを送ればいい？microCMSのドキュメントを読みながら実装してもらう
microCMSで、特定の日付以降に更新されたコンテンツの一覧を取得するスクリプトを作ります。
- 環境変数でサービスIDとAPIキーを指定
- コマンドライン引数でAPIエンドポイントと基準となる日付を指定
- 結果は整形して表示
言語はJavaScriptでお願いします。
use microcms-docs-mcpmicroCMSの一般的な情報を返します。
docs ディレクトリ内の利用可能なドキュメントファイル名の配列を返します。
指定されたドキュメントファイルの内容を取得します。
このプロジェクトは MIT ライセンスの下で公開されています。
microCMSについての質問に答える場合、まずこのツールを利用します。docs/general.md の内容を返します。これにはmicroCMS全体の概要や共通情報が書かれています。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states that the tool returns the content of a specific markdown file, which is helpful. However, it does not disclose any potential side effects, rate limits, authentication needs, or error behavior. The transparency is adequate but could be improved.
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 concise, consisting of two short sentences in Japanese. It front-loads the purpose and provides immediate value without any extraneous information.
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 simplicity (no parameters, no output schema), the description provides enough context: what the tool does and when to use it. It could be more explicit about the format of the returned content, but overall it is complete for its purpose.
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 tool has zero parameters, so the schema description coverage is effectively 100%. The description adds no parameter information, but with zero parameters, this is acceptable. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to answer questions about microCMS by returning the content of docs/general.md. It specifies the action (fetch) and resource (general.md), and implicitly distinguishes from siblings like list_documents and search_document.
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 explicitly says 'first use this tool' when answering questions about microCMS, providing clear usage context. While it does not list alternatives or when-not-to-use, it implies that for general info this tool is primary, and siblings are for specific document listing/search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
microCMSについての質問に答える場合に利用します。ドキュメントディレクトリのファイル名一覧を返します。カテゴリーを指定することで特定のサブディレクトリのみを対象にできます。
まだ fetch_general で全体情報を取得していない場合は、最初に fetch_general を実行してください。
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | 検索するカテゴリー（マニュアル: manual, content-api, management-api, image-api, mcp-server）。指定しない場合は全カテゴリーを対象とします。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the burden. It describes the output (list of filenames) and filtering by category. However, it does not mention any side effects, permissions, or limitations, though for a read-only list tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and contains no unnecessary words. Every sentence adds relevant information.
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 simplicity, the description covers the essential behavior. It mentions the prerequisite of fetch_general. It could be more explicit about default behavior (all categories) but is sufficiently complete for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter schema has 100% coverage with clear enum descriptions. The description adds value by explaining that specifying a category targets a specific subdirectory, which aids understanding beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of filenames in the document directory and is used for answering questions about microCMS. It distinguishes from siblings like fetch_general (overall info) and search_document (searching content).
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 clear context for when to use (answering microCMS questions) and explicitly recommends running fetch_general first if not done. It does not explicitly state when not to use, but the prerequisite guidance is valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
microCMSについての質問に答える場合に利用します。ドキュメントから指定されたファイルを検索し、中身を返します。カテゴリーを指定することで特定のサブディレクトリのみを対象にできます。
まだ fetch_general で全体情報を取得していない場合は、最初に fetch_general を実行してください。
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | 検索するファイル名（拡張子を含む） | |
| category | No | 検索するカテゴリー（manual, content-api, management-api, image-api, mcp-server）。指定しない場合は全カテゴリーから検索します。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It describes the core action (search and return contents) and mentions category filtering but lacks details on error handling, multiple matches, or response format. The prerequisite advice adds transparency but overall could be richer.
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 concise with three sentences, each providing value: purpose, category usage, and a prerequisite note. The prerequisite sentence could be positioned earlier for better front-loading, but overall it is not overly verbose.
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 tool with two parameters and no output schema, the description covers purpose, category usage, and a critical prerequisite. It mentions returning contents, which substitutes for an output schema. However, it does not specify behavior for non-existent files or multiple matches, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal meaning beyond the schema: it clarifies that category restricts to a subdirectory, which is already implied in the schema's enum descriptions. No additional detail on filename format or required extension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is used for answering questions about microCMS by searching for a specified file and returning its contents. It distinguishes itself from siblings by specifying the use case and mentioning prerequisites against fetch_general.
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 states when to use (when answering questions about microCMS) and provides a when-not-to-use condition (if fetch_general hasn't been run, execute it first), referencing the sibling tool fetch_general as an alternative.
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.2.5fetch_generallist_documentssearch_documentScored across 3 tools
Each tool serves a distinct purpose: fetch_general provides an overview, list_documents enumerates available files, and search_document retrieves specific file content. No overlap.
All tools use the verb_noun naming pattern with underscores (fetch_general, list_documents, search_document), providing clear and predictable naming.
Three tools are appropriate for a documentation server: one for overview, one for listing, one for retrieval. The count is well-scoped for the stated purpose.
The toolset covers basic read operations but lacks full-text search across all documents. However, the workflow (general → list → search) enables comprehensive Q&A, so only a minor gap exists.
Retrieve information from the Medusa documentation to assist you with your Medusa development.
Search the SiteGPT documentation: setup, features, API reference, troubleshooting.
Search and read Vector Panda docs: API operations, pricing, storage tiers, measured benchmarks.
Search the Cerebrium docs: deployment, cerebrium.toml, hardware, endpoints. Also sends feedback.
