zenn-articles
Provides tools to search Zenn articles by title, description, tags, and content, and a prompt to generate frontend weekly content summaries from URLs in the style of Cybozu Frontend Weekly.
Click on "Install 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., "@zenn-articlessearch for articles on React Server Components"
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.
@sakupi01/zenn-articles
An MCP Server for blog search functionality!
Available as Local Package and Remote Server.
Docker Image: sakupi/zenn-articles
Package: @sakupi01/zenn-articles
Remote Server: https://mcp.sakupi01.com/mcp
Usage
Using in MCP Client
You can use @sakupi01/zenn-articles MCP server in MCP Client with the following methods:
Use as Local MCP Server
Option 1: Use Docker Image
# Pull the Docker image from Docker Hub
docker pull sakupi/zenn-articlesTo use Docker Image, add the following style of setting to your Host:.
For example, claude_desktop_config.json:
{
"mcpServers": {
"@sakupi01.com/mcp": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"--network=host",
"sakupi/zenn-articles"
]
}
}
}Option 2: Use npx
# Run the MCP server directly using npx
npx @sakupi01/zenn-articlesAdd the following settings to your MCP client configuration:
{
"mcpServers": {
"zenn-articles": {
"command": "npx",
"args": [
"@sakupi01/zenn-articles"
]
}
}
}Running the MCP Server Locally
import { runServer } from "@sakupi01/zenn-articles/remote";
// Start server with default settings (port 8000)
runServer();Then, Add http://localhost:8000/mcp as the server URL to your MCP Client.
Using the Remote MCP Server
You can use the already deployed MCP server as an API endpoint:
"mcp": {
"servers": {
"sakupi01-mcp": {
"type": "http",
"url": "https://zenn-mcp.sakupi01.com/mcp"
}
}
}Related MCP server: Keenable MCP Server
Available Tools
Blog Search Tool (search_cy_fe_articles)
Search blog posts by title, description, URL, tags, and content.
Multiple keywords separated by spaces are treated as OR conditions.
Parameters
query: Search query (required, 1-100 characters)limit: Maximum number of results to return (optional, default: 10, max: 100)offset: Result offset (optional, default: 0)order: Sort order (optional, "desc" (newest first) or "asc" (oldest first), default: "desc")
Example Response
{
"total": 1,
"offset": 0,
"limit": 2,
"order": "desc",
"query": {
"original": "Form Control",
"keywords": [
"form",
"control"
],
"exactPhrases": []
},
"results": [
{
"title": "Form Control Styling Level 1 など: Cybozu Frontend Weekly (2025-03-25号)",
"pubDate": "2025-03-28T03:00:00.000Z",
"description": "サイボウズ社内では毎週火曜日にFrontend Weeklyと題し「一週間の間にあったフロントエンドニュースを共有する会」を開催しています。",
"link": "https://zenn.dev/cybozu_frontend/articles/frontend_weekly_example",
"content": "こんにちは!サイボウズ株式会社フロントエンドエンジニアの[saku (@sakupi01)](https://x.com/sakupi01)です。\n\n# はじめに\n\nサイボウズ社内では毎週火曜日にFrontend Weeklyと題し「一週間の間にあったフロントエンドニュースを共有する会」を開催しています。\n\n今回は、2025/03/25のFrontend Weeklyで取り上げた記事や話題を紹介します。",
"tags": [
"CybozuFrontendWeekly",
"frontend"
],
"score": 10
}
]
}Available Prompts
Frontend Weekly Content Generation (fe-weekly)
Generate frontend weekly content summaries for given URLs in the style of Cybozu Frontend Weekly.
Parameters
urls: A list of URLs to generate frontend weekly content for
Example Usage
# In Claude Desktop
@zenn-articles fe-weekly urls="https://example.com/article1\nhttps://example.com/article2"The prompt uses the blog search tool internally to find related content and provides consistent, well-formatted summaries with:
Brief description (about 2-3 lines)
Context about the technology or feature
Future implications or considerations
Follows Cybozu Frontend Weekly style guidelines
Running Tests
Install dependencies and run tests:
pnpm testChangelog
See the Releases page.
License
Released under the MIT License. See the LICENSE file for details.
Available Tools
2 toolsget_eg_cy_fe_articleC
Get A first article from frontend weekly articles as an example
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, authentication needs, or rate limits. It only states a basic action without elaboration.
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 very concise (one sentence, 10 words) but the phrasing is awkward ('Get A first article'). It is front-loaded but sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description is somewhat complete in stating the basic purpose. However, it fails to explain what 'first article' means or the behavior of the tool, leaving ambiguity.
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 0 parameters, so schema coverage is 100%. The description adds minimal value by vaguely indicating what the tool returns, but it does not clarify selection criteria like 'first article'. A score of 3 is appropriate as it provides some context but lacks precision.
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 states the verb 'Get' and resource 'article', but the phrasing 'A first article' is ambiguous. It could mean the first article or any example article. It does not distinguish from the sibling tool 'search_cy_fe_articles'.
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 alternatives. No context, 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.
search_cy_fe_articlesB
Search items by title, description, URL, tags, and content. Multiple keywords separated by spaces are searched as OR conditions
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query. Multiple keywords separated by spaces are searched as OR conditions | |
| limit | No | Maximum number of results to return (default: 10, max: 100) | |
| offset | No | Result offset (default: 0) | |
| order | No | Sort order: desc - newest first (default), asc - oldest first | desc |
TDQS
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 does not disclose whether the tool is read-only, authentication needs, rate limits, or any side effects. The behavioral impact is unclear beyond the search action.
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 two short sentences, front-loading the purpose and key behavioral note about OR conditions. No 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?
For a search tool with 4 parameters (all described) and no output schema, the description covers the search scope and query behavior. It could mention response format or pagination details, but limit/offset are self-explanatory. Nearly 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% with all parameters described. The description repeats the OR condition already stated in the query parameter description, adding no new meaning. Baseline 3 is appropriate given high schema coverage.
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 what the tool does ('Search items by title, description, URL, tags, and content') and includes a specific verb ('Search') and resource. However, it does not explicitly differentiate from the sibling tool 'get_eg_cy_fe_article', which appears to fetch a single 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 guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description only implies usage for searching without context.
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. Dates show when Glama detected each change.
2 tool updates
v1.2.2- First observed
get_eg_cy_fe_article - First observed
search_cy_fe_articles
TDQS
The two tools have clearly distinct purposes: one retrieves a specific example article, the other searches articles by various criteria. There is no overlap.
Both tools use a consistent verb_noun pattern in snake_case. However, the use of cryptic abbreviations like 'eg_cy_fe' reduces readability but maintains consistency.
With only 2 tools, the server feels too thin for its apparent domain of managing articles. Even for a read-only article server, one would expect more retrieval options or related operations.
The tool surface is severely incomplete. The domain likely involves articles (CRUD, listing), but only a get-example and search are provided. Missing: create, update, delete, list all, get by ID, etc.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Cloudflare Workers MCP server: embedding-search
Cloudflare Workers MCP server: ai-changelog-writer
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAn MCP server that provides code search capabilities for AI tools and LLMs using Zoekt, allowing for searching across codebases with advanced query syntax and content fetching.22MIT

Keenable MCP Serverofficial
AlicenseAqualityBmaintenanceAn MCP server that enables web search and page content retrieval via the Keenable API, supporting search with filters and fetching clean markdown content from indexed URLs.2374MIT- AlicenseAqualityDmaintenanceMCP server for searching and retrieving Japanese laws from the e-Gov API, enabling natural language queries for legal information.313MIT
- FlicenseAqualityDmaintenanceAn MCP server that automatically generates technical blog posts using AI (Gemini and Claude), supporting various input types, styles, and collaborative workflow.10-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sakupi01/zenn-articles'
If you have feedback or need assistance with the MCP directory API, please join our Discord server