Skip to main content
Glama
Sign In
deenesjakoruzh
erickwendel-contributions-mcp

erickwendel-contributions-mcp

by jdoliveirasa
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

erickwendel-contributions-mcp

CI Status npm version npm downloads

Erick Wendelの貢献を様々なプラットフォームでクエリするためのツールを提供するModel Context Protocol (MCP) サーバーです。Claude、Cursorなどを使用して、自然言語で講演、ブログ記事、動画を検索できます。このプロジェクトは、Cursor IDEのデフォルトエージェント（トライアル版）を使用して構築されました。

クイックスタート

このMCPサーバーは、インストール不要でClaude DesktopやCursorから直接使用できます：

{
  "mcpServers": {
    "erickwendel-contributions": {
      "command": "npx",
      "args": ["-y", "@erickwendel/contributions-mcp"]
    }
  }
}

以下の設定を追加してください：

  • Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json (macOS)

  • Cursor: ~/.cursor/mcp.json

Related MCP server: mintlify-mcp

利用可能なツール

このMCPサーバーは以下の機能を提供します：

ツール

  • get-talks: オプションのフィルタリング付きで、ページネーションされた講演リストを取得します

    • ID、タイトル、言語、都市、国、年によるフィルタリングをサポート

    • 言語、国、または都市ごとにグループ化された件数を返すことが可能

  • get-posts: オプションのフィルタリングとページネーション付きで記事を取得します

    • ID、タイトル、言語、ポータルによるフィルタリングをサポート

  • get-videos: オプションのフィルタリングとページネーション付きで動画を取得します

    • ID、タイトル、言語によるフィルタリングをサポート

  • check-status: APIが稼働中であり応答しているかを確認します

プロンプト

  • find-content: タイプ、トピック、言語を指定して特定のコンテンツを検索するクエリを生成します

  • summarize-activity: 年ごとのコンテンツ活動の要約を作成します

リソース

  • erickwendel://about: サーバー情報と機能のメタデータ

  • erickwendel://statistics: コンテンツ統計と利用可能なクエリ

AIツールとの統合

MCPサーバーの機能を確認する

MCP Inspectorを使用して、このMCPサーバーの機能を確認できます：

npm run inspect

これにより、利用可能なすべてのツール、そのパラメータ、および使用方法が表示されます。

セットアップ

  1. Node.js v20以上を使用していることを確認してください

node -v
# v20.x.x or higher

  1. このリポジトリをクローンします：

git clone https://github.com/erickwendel/erickwendel-contributions-mcp.git
cd erickwendel-contributions-mcp

  1. 依存関係をインストールします：

npm ci

  1. サーバーを実行します：

npm start

AIツールとの統合

Cursorのセットアップ

~/.cursor/mcp.json に以下の設定を追加します：

{
  "mcpServers": {
    "erickwendel-contributions": {
      "command": "npx",
      "args": ["-y", "@erickwendel/contributions-mcp"]
    }
  }
}

左下のドロップダウンで「Agent」を選択してCursorチャットをエージェントモードにし、「how many videos were published about JavaScript in 2024（2024年にJavaScriptについて公開された動画は何本ありますか）」と質問してみてください：

ローカル開発

ローカル開発の場合は、プロジェクトへの絶対パスを使用してください：

{
  "mcpServers": {
    "erickwendel-contributions": {
      "command": "node",
      "args": ["--experimental-strip-types", "ABSOLUTE_PATH_TO_PROJECT/src/index.ts"]
    }
  }
}

Claude Desktopのセットアップ

  1. Claudeの設定を開く

  2. Developerタブをクリック

  3. 設定の編集をクリック

  4. コードエディタで設定ファイルを開く

  5. ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) に以下の設定を追加します：

{
  "mcpServers": {
    "erickwendel-contributions": {
      "command": "npx",
      "args": ["-y", "@erickwendel/contributions-mcp"]
    }
  }
}

ローカル開発

ローカル開発の場合は、プロジェクトへの絶対パスを使用してください：

{
  "mcpServers": {
    "erickwendel-contributions": {
      "command": "node",
      "args": ["--experimental-strip-types", "ABSOLUTE_PATH_TO_PROJECT/src/index.ts"]
    }
  }
}

MCPHostとOllama（無料の代替手段）

Claude DesktopやCursorにアクセスできない場合は、無料の代替手段としてMCPHostとOllamaを使用できます。

  1. MCPHostをインストールします：

go install github.com/mark3labs/mcphost@latest

  1. 設定ファイルを作成します（例: ./mcp.jsonc）：

{
  "mcpServers": {
    "erickwendel-contributions": {
      "command": "npx",
      "args": ["-y", "@erickwendel/contributions-mcp"]
    }
  }
}

  1. Ollamaで実行します：

ollama pull MODEL_NAME
mcphost --config ./mcp.jsonc -m ollama:MODEL_NAME

ローカル開発

ローカル開発の場合は、設定を更新してください：

{
  "mcpServers": {
    "erickwendel-contributions": {
      "command": "node",
      "args": ["--experimental-strip-types", "ABSOLUTE_PATH_TO_PROJECT/src/index.ts"]
    }
  }
}

クエリの例

Claude、Cursor、またはその他のMCPクライアントで質問できるクエリの例をいくつか紹介します：

  1. "How many talks were given in 2023?（2023年には何件の講演が行われましたか？）"

  1. "Show me talks in Spanish（スペイン語の講演を見せて）"

  1. "Find posts about WebXR（WebXRに関する記事を探して）"

開発

特徴

  • Model Context Protocol (MCP) で構築

  • 完全なMCP機能: ツール、プロンプト、リソース

  • TypeScriptとZodスキーマバリデーションによる型安全性

  • トランスパイルなしのNode.jsでのネイティブTypeScriptサポート

  • GenQL を使用した生成済みSDK

  • 関心の分離によるモジュール式アーキテクチャ

  • 容易な統合のための標準I/Oトランスポート

  • 構造化されたエラーハンドリング

  • Claude Desktop、Cursor、MCPHost（無料の代替手段）と互換性あり

注: このプロジェクトは、昨年追加されたネイティブTypeScriptサポートを使用しているため、Node.js v23以上が必要です。

アーキテクチャ

コードベースはモジュール構造に従っています：

src/
  ├── config/      # Configuration settings
  ├── types/       # TypeScript interfaces and types
  ├── tools/       # MCP tool implementations
  ├── utils/       # Utility functions
  ├── services/    # API service layer
  └── index.ts     # Main entry point

テスト

テストスイートを実行するには：

npm test

ウォッチモードでの開発用：

npm run test:dev

コントリビューション

コントリビューションを歓迎します！お気軽にプルリクエストを送信してください。

著者

Erick Wendel

ライセンス

このプロジェクトはMITライセンスの下でライセンスされています。詳細は LICENSE ファイルを参照してください。

Available Tools

4 tools
check_statusA

Check if the API is alive and responding.

NameRequiredDescriptionDefault

No parameters

TDQS

A4/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 states the tool performs a liveness check, implying a read-only operation, but it does not disclose what response to expect, error behavior, or whether any side effects occur. This is adequate for a zero-parameter tool but lacks depth.

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 sentence, perfectly concise and front-loaded. It conveys the tool's purpose without any extraneous information or repetition of the tool name.

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 the tool's simplicity (zero parameters, no output schema, no annotations), the description adequately conveys the core purpose. It could be improved by mentioning the expected return value or how to interpret 'responding,' but for a basic health check, the description is sufficiently 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?

The tool has zero parameters, so the input schema fully covers any parameter semantics. The description adds no parameter details because none are necessary. Per the rubric, 0 parameters warrants a baseline score of 4.

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 uses a specific verb 'check' and clearly identifies the resource ('the API'), making the tool's purpose unambiguous. It is distinctly different from sibling tools like get_talks, get_posts, and get_videos, which retrieve content rather than verify API health.

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 usage: if you need to verify the API is alive, use this tool. However, there is no explicit guidance on when to use it versus alternatives, nor any mention of prerequisites or exclusions. The context of sibling get_* tools suggests a read-only health check, but this is not stated.

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

get_postsB

Get a list of posts with optional filtering and pagination.

NameRequiredDescriptionDefault
idNoFilter posts by ID
titleNoFilter posts by title
languageNoFilter posts by language
portalNoFilter posts by portal
skipNoNumber of posts to skip
limitNoMaximum number of posts to return

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations, the description carries the full burden, but it only says "Get a list of posts" and mentions filtering/pagination. It does not disclose whether the operation is read-only, requires authentication, has rate limits, or what the response structure is.

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 concise sentence that is front-loaded with the core action and resource. It avoids redundancy and is appropriately sized for a simple list operation.

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 6 optional parameters and no output schema, this description is minimal but functionally adequate. It lacks context on filtering semantics (e.g., exact vs partial match), ordering, or intended use cases, but the core purpose is clear.

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 baseline is 3. The description echoes the schema by mentioning "optional filtering" but adds no new detail about parameter values, defaults already in the schema, or filtering behavior.

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 gets a list of posts, using a specific verb ("Get") and resource ("posts"), and distinguishes it from siblings like get_talks and get_videos by the resource type.

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. It does not mention that get_talks or get_videos should be used for other content types, or any conditional context for choosing this tool.

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

get_talksA

Get a list of talks with optional filtering and pagination.

NameRequiredDescriptionDefault
idNoFilter talks by ID
titleNoFilter talks by title
languageNoFilter talks by language (e.g., 'spanish', 'english', 'portuguese' or direct codes like 'es', 'en', 'pt-br')
cityNoFilter talks by city
countryNoFilter talks by country
yearNoFilter talks by year
skipNoNumber of talks to skip
limitNoMaximum number of talks to return
count_onlyNoIf true, returns only the count without talk details
group_byNoGroup counts by a specific field (language, country, city)

TDQS

A3.5/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 burden. It mentions optional filtering and pagination, adding some behavioral context. However, it doesn't disclose details like whether count_only changes the response shape, how group_by interacts with filters, or any rate limits. It's acceptable but not rich.

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 concise sentence that captures the core functionality without waste. It is front-loaded with the main purpose and includes key capabilities (filtering, pagination) in an efficient way.

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 the tool has 10 parameters, no output schema, and no annotations, the description is minimal. It covers the basic purpose and mentions pagination/filtering, but it does not explain return values, edge cases, or how parameters combine. The schema descriptions help, but the overall context is not fully complete for a complex tool.

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%, meaning every parameter has a description in the schema. The tool description itself lists no parameter details, but since the schema already documents all ten parameters, the description does not need to repeat them. The baseline of 3 is appropriate because the schema does the heavy lifting.

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 states the tool lists talks with optional filtering and pagination, which is clear and specific. It does not explicitly distinguish it from sibling tools like get_posts or get_videos, but the resource 'talks' is unique enough that it's not misleading. The verb 'get a list' is clear.

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 this is for retrieving talk data, but it does not provide explicit when-to-use guidance or contrast with alternatives. Sibling tools are present, but no exclusions or preferred scenarios are given, so usage context is only implied.

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

get_videosA

Get a list of videos with optional filtering and pagination.

NameRequiredDescriptionDefault
idNoFilter videos by ID
titleNoFilter videos by title
languageNoFilter videos by language
skipNoNumber of videos to skip
limitNoMaximum number of videos to return

TDQS

A3.5/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 of behavioral disclosure. It conveys that the tool is read-only and supports filtering and pagination, but it does not disclose return format, default values, ordering, or other behaviors. This is acceptable for a simple list tool but leaves room for ambiguity.

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 sentence that is concise, front-loaded with the core purpose, and contains no filler or redundant information. Every word earns its place.

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?

With five parameters and no output schema, the description is simplistic. It covers the basic functionality but omits return structure and parameter behaviors (e.g., exact vs. partial matching, default pagination values). For a straightforward list tool, this is adequate but not complete, especially given the lack of annotations or output schema.

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%, with each parameter (id, skip, limit, title, language) described in the schema. The description adds a high-level mention of 'optional filtering and pagination' but no additional detail beyond the schema, 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?

The description clearly states the tool lists videos, using the verb 'Get' with the resource 'videos', and mentions optional filtering and pagination. It is specific enough to distinguish from sibling tools by resource name, though it does not explicitly differentiate itself from get_talks or get_posts beyond that.

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 when to use this tool: when listing videos with optional filters or pagination. However, it provides no explicit guidance on when not to use it or mention of alternatives like get_talks or get_posts, leaving usage context implied rather than explicit.

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.

  1. 4 tool updatesv1.1.4
    • First observedcheck_status
    • First observedget_posts
    • First observedget_talks
    • First observedget_videos
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.7/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a distinct resource or action: check_status is for API health, while get_posts, get_talks, and get_videos retrieve different content types. No overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using underscores (check_status, get_posts, get_talks, get_videos), making them predictable.

Tool Count5/5

With 4 tools, the set is well-scoped for a contributions-focused MCP, covering essential retrieval operations without being too sparse or bloated.

Completeness4/5

The tool surface provides read operations for all contribution types and a health check, but lacks write or update operations, which may be acceptable for a read-only server but leaves minor gaps.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Related MCP Connectors

Related MCP Servers

  • mintlify-mcp

    Vigtu
    A
    license
    Not graded
    quality
    C
    maintenance
    An MCP server that enables users to query any Mintlify-powered documentation site directly from Claude. It leverages Mintlify's AI Assistant API to provide RAG-based answers and code examples for various platforms like Agno, Resend, and Upstash.
    16 npm
    18
    MIT

  • exo

    guqing
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that ingests various data sources and uses LLMs to compile them into structured knowledge pages, enabling hybrid search and integration with AI coding tools like Claude Code and Cursor.
    17 npm
    1
    MIT