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

A Model Context Protocol (MCP) server that provides tools to query Erick Wendel's contributions across different platforms. Query talks, blog posts, and videos using natural language through Claude, Cursor or similars. This project was built using Cursor IDE with the default agent (trial version).

Quick Start

Use this MCP server directly with Claude Desktop or Cursor without installation:

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

Add this configuration to:

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

  • Cursor: ~/.cursor/mcp.json

Related MCP server: mintlify-mcp

Available Tools

This MCP server provides the following capabilities:

Tools

  • get-talks: Retrieves a paginated list of talks with optional filtering

    • Supports filtering by ID, title, language, city, country, and year

    • Can return counts grouped by language, country, or city

  • get-posts: Fetches posts with optional filtering and pagination

    • Supports filtering by ID, title, language, and portal

  • get-videos: Retrieves videos with optional filtering and pagination

    • Supports filtering by ID, title, and language

  • check-status: Verifies if the API is alive and responding

Prompts

  • find-content: Generate queries to find specific content by type, topic, and language

  • summarize-activity: Create summaries of content activity by year

Resources

  • erickwendel://about: Server information and capabilities metadata

  • erickwendel://statistics: Content statistics and available queries

Integration with AI Tools

Inspect MCP Server Capabilities

You can inspect this MCP server's capabilities using the MCP Inspector:

npm run inspect

This will show you all available tools, their parameters, and how to use them.

Setup

  1. Make sure you're using Node.js v20+

node -v
# v20.x.x or higher

  1. Clone this repository:

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

  1. Install dependencies:

npm ci

  1. Run the server:

npm start

Integration with AI Tools

Cursor Setup

Add the following configuration to ~/.cursor/mcp.json:

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

Make sure Cursor chat is in Agent mode by selecting "Agent" in the lower left side dropdown, then ask "how many videos were published about JavaScript in 2024":

Local Development

For local development, use the absolute path to the project:

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

Claude Desktop Setup

  1. Go to Claude settings

  2. Click in the Developer tab

  3. Click in edit config

  4. Open the config in a code editor

  5. Add the following configuration to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):

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

Local Development

For local development, use the absolute path to the project:

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

MCPHost with Ollama (Free Alternative)

If you don't have access to Claude Desktop or Cursor, you can use MCPHost with Ollama as a free alternative.

  1. Install MCPHost:

go install github.com/mark3labs/mcphost@latest

  1. Create a config file (e.g. ./mcp.jsonc):

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

  1. Run with Ollama:

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

Local Development

For local development, update the config:

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

Example Queries

Here are some examples of queries you can ask Claude, Cursor or any MCP Client:

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

  1. "Show me talks in Spanish"

  1. "Find posts about WebXR"

Development

Features

  • Built with Model Context Protocol (MCP)

  • Full MCP Capabilities: Tools, Prompts, and Resources

  • Type-safe with TypeScript and Zod schema validation

  • Native TypeScript support in Node.js without transpilation

  • Generated SDK using GenQL

  • Modular architecture with separation of concerns

  • Standard I/O transport for easy integration

  • Structured error handling

  • Compatible with Claude Desktop, Cursor, and MCPHost (free alternative)

Note: This project requires Node.js v23+ as it uses the native TypeScript support added in the last year.

Architecture

The codebase follows a modular structure:

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

Testing

To run the test suite:

npm test

For development mode with watch:

npm run test:dev

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Author

Erick Wendel

License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

4 tools
check_statusA

Check if the API is alive and responding.

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

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

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

ParametersJSON Schema
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
    D
    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.
    9 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.
    6 npm
    1
    MIT