Skip to main content
Glama
sakupi01

zenn-articles

by sakupi01

@sakupi01/zenn-articles

npm version Release Deploy Publish Docker image

An MCP Server for blog search functionality!

Available as Local Package and Remote Server.

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-articles

To 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-articles

Add 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 test

Changelog

See the Releases page.

License

Released under the MIT License. See the LICENSE file for details.

Available Tools

2 tools
get_eg_cy_fe_articleC

Get A first article from frontend weekly articles as an example

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.6/5.0
Behavior2/5

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.

Conciseness3/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose3/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query. Multiple keywords separated by spaces are searched as OR conditions
limitNoMaximum number of results to return (default: 10, max: 100)
offsetNoResult offset (default: 0)
orderNoSort order: desc - newest first (default), asc - oldest firstdesc

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 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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

  1. 2 tool updatesv1.2.2
    • First observedget_eg_cy_fe_article
    • First observedsearch_cy_fe_articles

TDQS

C2.9/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: one retrieves a specific example article, the other searches articles by various criteria. There is no overlap.

Naming Consistency4/5

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.

Tool Count2/5

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.

Completeness2/5

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

ActivityMaintained
ResponsivenessNo issues

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

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    An 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.
    22
    MIT
  • A
    license
    A
    quality
    B
    maintenance
    An 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.
    2
    374
    MIT

Latest Blog Posts

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