Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@erickwendel-contributions-mcp Show me talks in Spanish"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that exposes tools to query Erick Wendel's contributions across talks, blog posts, and videos. Use this server with MCP-aware clients such as Claude Desktop, Cursor, or any compatible MCP runtime.
Tools: get-talks, get-posts, get-videos, check-status
Prompts: find-content, summarize-activity
Resources: erickwendel://about, erickwendel://statistics
Built with: Node.js, TypeScript, MCP SDK, Zod
Requires: Node.js >=20.0.0
Related MCP server: MCP Docs RAG Server
Query talks, posts, and videos using structured MCP tool calls
Support filtering by ID, title, language, city, country, year, and portal
Provide metadata and resource endpoints for server discovery
Enable prompt-driven queries for content search and high-level summaries
Run locally or consume directly from npm using npx
git clone https://github.com/erickwendel/erickwendel-contributions-mcp.git
cd erickwendel-contributions-mcp
npm ci
npm start
npm startruns the server on STDIO usingnode --experimental-strip-types --no-warnings src/index.ts.
npm start — Run the MCP server locally
npm run dev — Run the server with --inspect and file watching
npm run inspect — Inspect the MCP capabilities with the MCP Inspector
npm test — Run unit tests
npm run lint — Lint source and test files
npm run lint:fix — Fix lint issues where possible
Use this package directly without cloning the repository:
{
"mcpServers": {
"erickwendel-contributions": {
"command": "npx",
"args": ["-y", "@erickwendel/contributions-mcp"]
}
}
}get-talks
Filters: id, title, language, city, country, year
Supports pagination and grouped counts by language/country/city
get-posts
Filters: id, title, language, portal
Supports pagination
get-videos
Filters: id, title, language
Supports pagination
check-status
Confirms the server is alive and responding
find-content
Build a query for talks, posts, or videos using topic and language filters
summarize-activity
Generate a summary of content activity, optionally filtered by year
erickwendel://about — Information about Erick Wendel and server metadata
erickwendel://statistics — Content statistics and recommended queries
Add or update ~/.cursor/mcp.json with:
{
"mcpServers": {
"erickwendel-contributions": {
"command": "npx",
"args": ["-y", "@erickwendel/contributions-mcp"]
}
}
}For local development, point Cursor to the local project entry file:
{
"mcpServers": {
"erickwendel-contributions": {
"command": "node",
"args": ["--experimental-strip-types", "/absolute/path/to/project/src/index.ts"]
}
}
}Add the same MCP server definition to ~/Library/Application Support/Claude/claude_desktop_config.json on macOS:
{
"mcpServers": {
"erickwendel-contributions": {
"command": "npx",
"args": ["-y", "@erickwendel/contributions-mcp"]
}
}
}For local development, use the local project path instead of npx.
If you prefer a free MCP runtime, use MCPHost together with Ollama:
go install github.com/mark3labs/mcphost@latestCreate a config file, for example ./mcp.jsonc:
{
"mcpServers": {
"erickwendel-contributions": {
"command": "npx",
"args": ["-y", "@erickwendel/contributions-mcp"]
}
}
}Then run:
ollama pull MODEL_NAME
mcphost --config ./mcp.jsonc -m ollama:MODEL_NAMEUse your MCP client to ask questions such as:
"How many talks were given in 2023?"
"Show me talks in Spanish"
"Find posts about WebXR"
"List videos in Portuguese"
Entry point: src/index.ts
MCP server configuration: src/config/api.ts
Tools implementation: src/tools/talks.ts, src/tools/posts.ts, src/tools/videos.ts, src/tools/status.ts
GraphQL and type helpers: erickwendel-sdk/
Node.js >=20.0.0
npm
MIT
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.
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 pointTo run the test suite:
npm testFor development mode with watch:
npm run test:devContributions are welcome! Please feel free to submit a Pull Request.
Repository code: Erick Wendel
This project is licensed under the MIT License - see the LICENSE file for details.
Check if the API is alive and responding.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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 a list of posts with optional filtering and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Filter posts by ID | |
| skip | No | Number of posts to skip | |
| limit | No | Maximum number of posts to return | |
| title | No | Filter posts by title | |
| portal | No | Filter posts by portal | |
| language | No | Filter posts by language |
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.
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.
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.
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.
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.
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 a list of talks with optional filtering and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Filter talks by ID | |
| city | No | Filter talks by city | |
| skip | No | Number of talks to skip | |
| year | No | Filter talks by year | |
| limit | No | Maximum number of talks to return | |
| title | No | Filter talks by title | |
| country | No | Filter talks by country | |
| group_by | No | Group counts by a specific field (language, country, city) | |
| language | No | Filter talks by language (e.g., 'spanish', 'english', 'portuguese' or direct codes like 'es', 'en', 'pt-br') | |
| count_only | No | If true, returns only the count without talk details |
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.
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.
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.
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.
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.
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 a list of videos with optional filtering and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Filter videos by ID | |
| skip | No | Number of videos to skip | |
| limit | No | Maximum number of videos to return | |
| title | No | Filter videos by title | |
| language | No | Filter videos by language |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.4check_statusget_postsget_talksget_videosScored across 4 tools
Each tool targets a distinct content type (talks, posts, videos) or a health check, with no overlap in purpose. Agents can easily choose the right tool based on the resource they need.
All tool names follow a clear verb_noun pattern: get_talks, get_posts, get_videos, and check_status. The use of 'get' for content retrieval and 'check' for status is consistent and predictable.
Four tools is well-scoped for a contributions server that retrieves talks, posts, videos, and API status. Each tool earns its place without redundancy or excess.
The server covers the main content types (talks, posts, videos) with list retrieval and filtering, plus a health check. A minor gap is the lack of single-item retrieval, but filtering likely covers that need.
An MCP server that gives your AI access to the source code and docs of all public github repos
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
