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

Un servidor de Model Context Protocol (MCP) que proporciona herramientas para consultar las contribuciones de Erick Wendel en diferentes plataformas. Consulta charlas, publicaciones de blog y videos usando lenguaje natural a través de Claude, Cursor o similares. Este proyecto fue construido usando el IDE Cursor con el agente predeterminado (versión de prueba).

Inicio rápido

Usa este servidor MCP directamente con Claude Desktop o Cursor sin necesidad de instalación:

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

Añade esta configuración a:

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

  • Cursor: ~/.cursor/mcp.json

Related MCP server: mintlify-mcp

Herramientas disponibles

Este servidor MCP proporciona las siguientes capacidades:

Herramientas

  • get-talks: Recupera una lista paginada de charlas con filtrado opcional

    • Admite filtrado por ID, título, idioma, ciudad, país y año

    • Puede devolver conteos agrupados por idioma, país o ciudad

  • get-posts: Obtiene publicaciones con filtrado y paginación opcionales

    • Admite filtrado por ID, título, idioma y portal

  • get-videos: Recupera videos con filtrado y paginación opcionales

    • Admite filtrado por ID, título e idioma

  • check-status: Verifica si la API está activa y respondiendo

Prompts

  • find-content: Genera consultas para encontrar contenido específico por tipo, tema e idioma

  • summarize-activity: Crea resúmenes de la actividad de contenido por año

Recursos

  • erickwendel://about: Información del servidor y metadatos de capacidades

  • erickwendel://statistics: Estadísticas de contenido y consultas disponibles

Integración con herramientas de IA

Inspeccionar las capacidades del servidor MCP

Puedes inspeccionar las capacidades de este servidor MCP usando el Inspector MCP:

npm run inspect

Esto te mostrará todas las herramientas disponibles, sus parámetros y cómo usarlas.

Configuración

  1. Asegúrate de estar usando Node.js v20+

node -v
# v20.x.x or higher

  1. Clona este repositorio:

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

  1. Instala las dependencias:

npm ci

  1. Ejecuta el servidor:

npm start

Integración con herramientas de IA

Configuración de Cursor

Añade la siguiente configuración a ~/.cursor/mcp.json:

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

Asegúrate de que el chat de Cursor esté en modo Agente seleccionando "Agent" en el menú desplegable de la parte inferior izquierda, luego pregunta "how many videos were published about JavaScript in 2024":

Desarrollo local

Para el desarrollo local, usa la ruta absoluta al proyecto:

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

Configuración de Claude Desktop

  1. Ve a la configuración de Claude

  2. Haz clic en la pestaña Developer

  3. Haz clic en edit config

  4. Abre la configuración en un editor de código

  5. Añade la siguiente configuración a ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):

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

Desarrollo local

Para el desarrollo local, usa la ruta absoluta al proyecto:

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

MCPHost con Ollama (Alternativa gratuita)

Si no tienes acceso a Claude Desktop o Cursor, puedes usar MCPHost con Ollama como alternativa gratuita.

  1. Instala MCPHost:

go install github.com/mark3labs/mcphost@latest

  1. Crea un archivo de configuración (ej. ./mcp.jsonc):

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

  1. Ejecuta con Ollama:

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

Desarrollo local

Para el desarrollo local, actualiza la configuración:

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

Ejemplos de consultas

Aquí tienes algunos ejemplos de consultas que puedes hacer a Claude, Cursor o cualquier cliente MCP:

  1. "How many talks were given in 2023?"

  1. "Show me talks in Spanish"

  1. "Find posts about WebXR"

Desarrollo

Características

  • Construido con Model Context Protocol (MCP)

  • Capacidades MCP completas: Herramientas, Prompts y Recursos

  • Tipado seguro con TypeScript y validación de esquemas Zod

  • Soporte nativo de TypeScript en Node.js sin transpilación

  • SDK generado usando GenQL

  • Arquitectura modular con separación de responsabilidades

  • Transporte de E/S estándar para una fácil integración

  • Manejo de errores estructurado

  • Compatible con Claude Desktop, Cursor y MCPHost (alternativa gratuita)

Nota: Este proyecto requiere Node.js v23+ ya que utiliza el soporte nativo de TypeScript añadido el último año.

Arquitectura

La base de código sigue una estructura modular:

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

Pruebas

Para ejecutar el conjunto de pruebas:

npm test

Para el modo de desarrollo con watch:

npm run test:dev

Contribuciones

¡Las contribuciones son bienvenidas! Por favor, siéntete libre de enviar un Pull Request.

Autor

Erick Wendel

Licencia

Este proyecto está bajo la Licencia MIT - consulta el archivo LICENSE para más detalles.

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