Skip to main content
Glama
deenesjakoruzh
jdoliveirasa

erickwendel-contributions-mcp

by jdoliveirasa
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

erickwendel-contributions-mcp

CI Status npm version npm downloads

Сервер протокола контекста моделей (MCP), предоставляющий инструменты для запроса информации о вкладе Эрика Венделя на различных платформах. Запрашивайте выступления, публикации в блогах и видео с помощью естественного языка через Claude, Cursor или аналогичные инструменты. Этот проект был создан с использованием IDE Cursor с агентом по умолчанию (пробная версия).

Быстрый старт

Используйте этот 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: Статистика контента и доступные запросы

Интеграция с ИИ-инструментами

Проверка возможностей MCP-сервера

Вы можете проверить возможности этого MCP-сервера с помощью MCP Inspector:

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

Интеграция с ИИ-инструментами

Настройка Cursor

Добавьте следующую конфигурацию в ~/.cursor/mcp.json:

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

Убедитесь, что чат Cursor находится в режиме Agent, выбрав "Agent" в выпадающем списке в левом нижнем углу, затем спросите "how many videos were published about JavaScript in 2024":

Локальная разработка

Для локальной разработки используйте абсолютный путь к проекту:

{
  "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?"

  1. "Show me talks in Spanish"

  1. "Find posts about WebXR"

Разработка

Особенности

  • Создано с использованием протокола контекста моделей (MCP)

  • Полные возможности MCP: Инструменты, Промпты и Ресурсы

  • Типобезопасность с использованием TypeScript и валидации схем Zod

  • Нативная поддержка TypeScript в Node.js без транспиляции

  • Сгенерированный SDK с использованием GenQL

  • Модульная архитектура с разделением ответственности

  • Стандартный транспорт ввода-вывода для легкой интеграции

  • Структурированная обработка ошибок

  • Совместимость с Claude Desktop, Cursor и MCPHost (бесплатная альтернатива)

Примечание: Для этого проекта требуется Node.js v23+, так как он использует нативную поддержку TypeScript, добавленную в прошлом году.

Архитектура

Кодовая база следует модульной структуре:

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

Вклад в проект

Вклад приветствуется! Пожалуйста, не стесняйтесь отправлять Pull Request.

Автор

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
ResponsivenessNo issues

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.
    17 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.
    14 npm
    1
    MIT