e18e-module-replacements-mcp
This MCP server helps you find lighter, faster, or native alternatives to common JavaScript/Node.js packages using the e18e project's curated replacement data.
Look up replacements (
lookup_replacement): Search for a specific module, API, or feature by name (e.g.,axios,Array.from,deep-merge) and get recommendations from three categories:Native APIs – built-in browser/Node.js API replacements (e.g.,
is-array→Array.isArray())Micro-utilities – packages replaceable by simple code snippets (e.g.,
array-flatten→array.flat(Infinity))Preferred modules – better, lighter third-party alternatives (e.g.,
axios→fetch,ofetch,ky)
Scan project dependencies (
scan_dependencies): Provide a map of package names and versions (from yourpackage.json) to get a report of which packages have recommended replacements, along with suggested alternatives and reference URLs.
The server is designed to integrate with AI assistants (e.g., Claude Desktop, VS Code/GitHub Copilot, Cursor, Windsurf) to automatically surface module replacement suggestions.
Allows configuration with Windsurf (Codeium's AI editor) to provide module replacement lookup and dependency scanning tools.
Allows configuration with VS Code (GitHub Copilot) to provide module replacement lookup and dependency scanning tools.
Click on "Install 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., "@e18e-module-replacements-mcpWhat's a lighter alternative to lodash?"
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.
e18e Module Replacements MCP Server
An MCP (Model Context Protocol) server that exposes e18e module replacement data. It helps AI assistants suggest lighter, faster, or native alternatives to common JavaScript/Node.js packages.
What it does
The e18e project ("ecosystem performance") maintains curated lists of JavaScript module replacements — lighter alternatives, native API equivalents, and simple code snippets that can eliminate unnecessary dependencies.
This MCP server fetches three manifests from the e18e/module-replacements repository at startup and exposes them as tools:
Manifest | Description | Example |
native.json | Features replaceable by native browser/Node.js APIs |
|
micro-utilities.json | Tiny packages replaceable by code snippets |
|
preferred.json | Modules with better, lighter alternatives |
|
Related MCP server: mcp-npm-tools
Prerequisites
Node.js >= 18
Installation
Option 1: Use directly with npx (no install needed)
No installation required — just reference it in your MCP config (see below). The package is fetched and run automatically.
Option 2: Global install
npm install -g e18e-module-replacements-mcpOption 3: Build from source
git clone https://github.com/santoshyadavdev/e18e-module-replacements-mcp.git
cd e18e-module-replacements-mcp
npm install
npm run buildConfiguration
Add the server to your AI assistant's MCP configuration. The examples below use npx so there's nothing to install. If you installed globally or built from source, replace npx with the path to the binary.
Claude Desktop
Open your Claude Desktop config file:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"e18e-module-replacements": {
"command": "npx",
"args": ["-y", "e18e-module-replacements-mcp"]
}
}
}Then restart Claude Desktop.
VS Code (GitHub Copilot)
Create or edit .vscode/mcp.json in your workspace (or add to your user settings):
{
"servers": {
"e18e-module-replacements": {
"command": "npx",
"args": ["-y", "e18e-module-replacements-mcp"]
}
}
}Cursor
Open Cursor Settings → MCP and add a new server:
Name:
e18e-module-replacementsType:
commandCommand:
npx -y e18e-module-replacements-mcp
Windsurf
Add to your ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"e18e-module-replacements": {
"command": "npx",
"args": ["-y", "e18e-module-replacements-mcp"]
}
}
}Tools
lookup_replacement
Search for a replacement by feature name, API name, or module name. Searches across all three manifests with case-insensitive partial matching.
Input:
{ "name": "axios" }Example output:
## axios
**Source:** preferred
**Type:** module
**Replacements:** fetch, ofetch, ky
**URL:** https://e18e.dev/guide/module-replacements/fetchMore examples:
Query | What you get |
| Preferred replacements: |
| Native API — link to MDN docs |
| Preferred replacements: |
| Micro-utility snippet: |
scan_dependencies
Scan a dependency map (like the dependencies field from package.json) and find which packages have recommended replacements.
Input:
{
"dependencies": {
"axios": "^1.6.0",
"chalk": "^5.3.0",
"express": "^4.18.0",
"lodash": "^4.17.21"
}
}Example output:
Found 3 dependency replacement(s):
- **axios** → fetch, ofetch, ky
https://e18e.dev/guide/module-replacements/fetch
- **chalk** → picocolors, ansis
https://e18e.dev/guide/module-replacements/chalk
- **lodash** → es-toolkit
https://e18e.dev/guide/module-replacements/lodashUsage tips
Once the MCP server is connected to your AI assistant, you can ask things like:
"Is there a lighter alternative to chalk?"
"Scan my package.json dependencies for replacements"
"What's the native replacement for is-array?"
"Can I replace moment with something smaller?"
The AI assistant will automatically use the lookup_replacement and scan_dependencies tools to answer.
Remote Server (Cloudflare Workers)
This MCP server can also be deployed as a remote HTTP server on Cloudflare Workers.
Local Development
npm run dev:workerThe server starts at http://localhost:8787/mcp.
Deploy
# First time: authenticate with Cloudflare
npx wrangler login
# Deploy to Workers
npm run deployYour server will be available at https://e18e-module-replacements-mcp.<your-account>.workers.dev/mcp.
Add to GitHub Copilot
Go to your GitHub organization/repo settings → Copilot → MCP Servers
Click "Add MCP Server"
Label:
e18e-module-replacementsServer URL:
https://e18e-module-replacements-mcp.<your-account>.workers.dev/mcpAuthentication: None
Click "Connect"
Development
npm run dev # Watch mode — rebuilds on file changes
npm run dev:worker # Run Workers dev server locallyHow it works
On startup (stdio) or first request (Workers), the server fetches all three e18e manifests from GitHub
Manifests are cached in memory for the lifetime of the server process (or Workers isolate)
The server communicates over stdio (local) or HTTP (Workers) using the MCP protocol
If a manifest fails to load (e.g., no internet), the server still starts — tools will return an error message for the missing data source
License
MIT
Available Tools
2 toolslookup_replacementB
Search for a JavaScript module or API replacement across native APIs, micro-utilities, and preferred module mappings from the e18e project
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A feature name, API name, or module name to search for (e.g. 'axios', 'Array.from', 'deep-merge') |
TDQS
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 search (presumably read-only) but does not disclose safety, side effects, or behavioral traits. For a lookup tool, this is a partial gap.
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 clear and free of fluff. Every part is meaningful, and no unnecessary information is included.
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?
The tool is simple but lacks an output schema. The description does not explain what the search returns (e.g., a list of replacements, package names, etc.), leaving the agent without full context of the result format.
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 input schema has 100% description coverage for the single parameter 'name', including examples. The description does not add additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
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 verb ('Search for'), the resource ('a JavaScript module or API replacement'), and the scope ('across native APIs, micro-utilities, and preferred module mappings from the e18e project'). It is specific and distinguishes from the sibling tool 'scan_dependencies'.
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 the tool is for finding replacements from the e18e project but provides no explicit guidance on when to use it versus alternatives like 'scan_dependencies'. No when-not-to-use or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_dependenciesB
Scan a list of dependencies (from package.json) and find which ones have recommended replacements from the e18e project
| Name | Required | Description | Default |
|---|---|---|---|
| dependencies | Yes | A map of package names to versions, like the dependencies field from package.json |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states what the tool does but does not mention permissions, side effects (likely none), error handling, or output format. For a scanning tool, this is minimal transparency.
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 directly explains the tool's purpose without unnecessary words. Every part adds value, and it is front-loaded with the key action.
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 one parameter and no output schema, the description is adequate but could be improved. It mentions the input format (from package.json) but does not describe the output structure, which might be important for the agent to understand the result format.
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 input schema already describes the parameter as a map of package names to versions, like package.json dependencies. The description adds context about e18e project but does not significantly enhance parameter understanding beyond the schema. With 100% schema coverage, baseline 3 is appropriate.
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 scans a list of dependencies (from package.json) and finds recommended replacements from the e18e project. It specifies the verb 'scan', the resource 'dependencies', and the outcome. The sibling tool lookup_replacement implies this tool handles multiple dependencies, distinguishing it effectively.
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 does not provide explicit guidance on when to use this tool versus the alternative lookup_replacement. It only implies that it operates on a list, but no when-to-use or when-not-to-use conditions are stated.
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. Dates show when Glama detected each change.
2 tool updates
v1.0.0- First observed
lookup_replacement - First observed
scan_dependencies
TDQS
The two tools have clearly distinct purposes: lookup_replacement searches for a specific module replacement, while scan_dependencies processes a list of dependencies. No ambiguity between them.
Both tools follow a consistent verb_noun pattern using snake_case: lookup_replacement and scan_dependencies. The naming is predictable and uniform.
With only 2 tools, the surface is thin for the domain of module replacements. While the tools cover individual lookup and bulk scanning, the count is at the lower boundary of reasonable scope.
The tools cover the two main use cases: searching for a single replacement and scanning a dependency list. A minor gap is the lack of a tool to list all possible replacements, but the core functionality is present.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
The official e18e MCP server keeping your agent in check from installing bloated dependencies.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
An MCP server that gives your AI access to the source code and docs of all public github repos
MCP server for building and testing AI agents with multi-model experimentation and insights.
Related MCP Servers
- AlicenseAqualityCmaintenanceMCP server that provides npm package information for AI agents during TypeScript development.7191MIT
- AlicenseAqualityDmaintenanceMCP server providing npm registry search, package details, dependency auditing, bundle size estimation, and package comparison tools for AI agents.551MIT
- AlicenseAqualityDmaintenanceMCP server providing dependency and package management tools for AI agents. Analyze licenses, find outdated packages, visualize dependency trees, estimate bundle sizes, and audit security vulnerabilities.549MIT
- AlicenseAqualityAmaintenanceStop your AI agent from rebuilding what already exists. MCP server that checks GitHub, npm and Python repos for maintained alternatives before you scaffold.21285MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/santoshyadavdev/e18e-module-replacements-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server