Skip to main content
Glama
santoshyadavdev

e18e-module-replacements-mcp

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

is-arrayArray.isArray()

micro-utilities.json

Tiny packages replaceable by code snippets

array-flattenarray.flat(Infinity)

preferred.json

Modules with better, lighter alternatives

axiosfetch / ofetch / ky

Related MCP server: mcp-npm-tools

Prerequisites

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-mcp

Option 3: Build from source

git clone https://github.com/santoshyadavdev/e18e-module-replacements-mcp.git
cd e18e-module-replacements-mcp
npm install
npm run build

Configuration

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

  • Windows: %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-replacements

  • Type: command

  • Command: 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/fetch

More examples:

Query

What you get

"axios"

Preferred replacements: fetch, ofetch, ky

"Array.from"

Native API — link to MDN docs

"deep-merge"

Preferred replacements: defu, @fastify/deepmerge

"array-flatten"

Micro-utility snippet: array.flat(Infinity)

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/lodash

Usage 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:worker

The server starts at http://localhost:8787/mcp.

Deploy

# First time: authenticate with Cloudflare
npx wrangler login

# Deploy to Workers
npm run deploy

Your server will be available at https://e18e-module-replacements-mcp.<your-account>.workers.dev/mcp.

Add to GitHub Copilot

  1. Go to your GitHub organization/repo settings → Copilot → MCP Servers

  2. Click "Add MCP Server"

  3. Label: e18e-module-replacements

  4. Server URL: https://e18e-module-replacements-mcp.<your-account>.workers.dev/mcp

  5. Authentication: None

  6. Click "Connect"

Development

npm run dev          # Watch mode — rebuilds on file changes
npm run dev:worker   # Run Workers dev server locally

How it works

  1. On startup (stdio) or first request (Workers), the server fetches all three e18e manifests from GitHub

  2. Manifests are cached in memory for the lifetime of the server process (or Workers isolate)

  3. The server communicates over stdio (local) or HTTP (Workers) using the MCP protocol

  4. 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 tools
lookup_replacementB

Search for a JavaScript module or API replacement across native APIs, micro-utilities, and preferred module mappings from the e18e project

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesA feature name, API name, or module name to search for (e.g. 'axios', 'Array.from', 'deep-merge')

TDQS

B3.4/5.0
Behavior2/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 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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
dependenciesYesA map of package names to versions, like the dependencies field from package.json

TDQS

B3.3/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

  1. 2 tool updatesv1.0.0
    • First observedlookup_replacement
    • First observedscan_dependencies

TDQS

A3.7/5.0
Disambiguation5/5

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.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern using snake_case: lookup_replacement and scan_dependencies. The naming is predictable and uniform.

Tool Count3/5

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.

Completeness4/5

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

ActivitySlowing
ResponsivenessSyncing

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

Related MCP Servers

Latest Blog Posts

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