high-performance-mcp-server
Servidor MCP de Alto Rendimiento
Un servidor de Model Context Protocol (MCP) modular y de alto rendimiento, construido con TypeScript y el moderno SDK de MCP v2 (@modelcontextprotocol/server). Incluye perfiles de seguridad seguros por defecto, instrucciones de servidor conscientes del perfil, prompts MCP modulares, acceso de solo lectura al espacio de trabajo con búsqueda y privacidad de rutas del host, HTTP Streamable, transporte Stdio, agrupación reutilizable de subprocesos de trabajo, caché LRU de producción con protección contra avalanchas de un solo vuelo y telemetría estructurada.
Estado del Proyecto: Vista Previa Pública (v0.1.0)
[!NOTA] Estado:
0.1.0Vista Previa Pública. Este paquete proporciona herramientas MCP seguras por defecto, inspección de espacio de trabajo de solo lectura y ejecución de trabajadores de alto rendimiento. Requiere Node.js >= 22.0.0.
Related MCP server: VSCode LSP MCP Server
Características
Arquitectura MCP v2 Moderna: Construido nativamente sobre
@modelcontextprotocol/servercon validación estándar de JSON Schema draft 2020-12 y soporte completo del protocolo 2026-07-28.Soporte de Doble Transporte: Ejecútese sin problemas sobre entrada/salida estándar (
stdio) o HTTP Streamable moderno (node:http+/mcp).Instrucciones de Servidor Conscientes del Perfil: Instrucciones dinámicas del servidor que guían a los LLM conectados sobre flujos de trabajo recomendados, secuenciación de herramientas y límites de seguridad según el perfil activo.
Prompts MCP Modulares: Prompts de tareas reutilizables (
explore_workspace,find_and_explain,review_file,trace_symbol) expuestos exclusivamente en los perfilesworkspaceyall.Perfiles de Herramientas Seguros por Defecto: El perfil
safepredeterminado expone cero inspección de sistema de archivos o hardware. Opt-in explícito paraworkspace,diagnostics,benchmark,adminoall.Privacidad de Rutas del Host y Espacio de Trabajo de Solo Lectura: Acceso seguro a directorios en lista blanca con prevención de traversal de rutas y escapes de enlaces simbólicos, mapeo de raíces lógicas (
root-1,root-2), límites estrictos de 1 MiB y protección de archivos binarios sin exponer rutas absolutas del host a clientes o modelos.Búsqueda de Espacio de Trabajo v1: Búsqueda rápida y acotada de archivos y texto literal (
search_files,search_text) con directorios ignorados por defecto, concurrencia acotada, mapeo de coordenadas y cancelación por parte del cliente.Grupo de Subprocesos de Trabajo: Descargue tareas pesadas de CPU del bucle de eventos de Node.js con recuperación automática del ciclo de vida e invariantes sin desviación.
Caché LRU de Producción: Caché con límite de memoria, soporte de TTL y coalescencia de solicitudes de un solo vuelo para eliminar avalanchas de caché.
Registro Estructurado Interno: Registro JSON seguro para stdio exclusivamente en
stderr.
Inicio Rápido
Configuración del Cliente MCP (Claude Desktop, Cursor, etc.)
Agregue a su configuración de MCP (por ejemplo, claude_desktop_config.json):
Perfil Seguro Predeterminado (Stdio)
{
"mcpServers": {
"high-performance-mcp": {
"command": "npx",
"args": [
"-y",
"high-performance-mcp-server"
]
}
}
}Perfil de Espacio de Trabajo de Solo Lectura
{
"mcpServers": {
"workspace-mcp": {
"command": "npx",
"args": [
"-y",
"high-performance-mcp-server",
"--profile=workspace",
"--root=/path/to/project"
]
}
}
}Desarrollo Local / Ejecución desde el Código Fuente
# Clone and build
git clone https://github.com/eminyilmz/high-performance-mcp-server.git
cd high-performance-mcp-server
npm install
npm run build
# Run default safe profile
node dist/index.js
# Run workspace profile with allowlisted root
node dist/index.js --profile=workspace --root=.Perfiles Seguros por Defecto
Para proteger las máquinas host y prevenir el consumo no intencionado de recursos o la fuga de metadatos, las herramientas, recursos, instrucciones y prompts se categorizan en perfiles de seguridad:
Perfil | Categorías Incluidas | Herramientas Expuestas | Prompts | Caso de Uso |
|
|
| (ninguno) | Cero inspección del host, cero acceso al sistema de archivos, cero mutación. Seguro para exposición pública. |
|
|
|
| Inspección de archivos y directorios de solo lectura estrictamente limitada a directorios |
|
|
| (ninguno) | Observabilidad de procesos y sistemas para monitorear la salud y el retraso del bucle de eventos. |
|
|
| (ninguno) | Pruebas de referencia de cálculo de números primos intensivos en CPU y pruebas del grupo de trabajadores. |
|
|
| (ninguno) | Observabilidad con mutación administrativa del estado del runtime (purgar caché, restablecer métricas). |
|
| Las 17 herramientas registradas | Los 4 prompts de espacio de trabajo | Catálogo completo de herramientas y prompts. |
Instrucciones del Servidor y Prompts
Instrucciones del Servidor Conscientes del Perfil
Cuando un cliente MCP se conecta, el servidor entrega instrucciones concisas y adaptadas al perfil a través del protocolo MCP:
safe: Indica al modelo que la inspección del sistema de archivos y del hardware no está disponible.workspace: Describe la secuencia de investigación recomendada (workspace_roots->search_files/search_text->file_info->read_text_file), refuerza las restricciones de solo lectura y enfatiza el uso de rutas relativas a la raíz.diagnosticsybenchmark: Guía la interpretación de métricas observacionales y advierte contra invocaciones innecesarias de cómputo intensivo en CPU.admin: Señala que las operaciones de mutación afectan solo a las cachés locales del proceso y al estado de telemetría.
Prompts MCP Modulares
Cuando se ejecuta en el perfil workspace o all, el servidor expone prompts modulares que proporcionan flujos de trabajo estructurados para tareas comunes de ingeniería:
Prompt | Argumentos | Propósito |
|
| Guía al modelo a través de una exploración estructurada de una raíz de espacio de trabajo en lista blanca usando búsqueda e inspección de archivos. |
|
| Localiza código o configuración relevante mediante búsqueda de texto literal y lee los archivos definitorios para producir una explicación. |
|
| Formula una revisión estructurada y de solo lectura de un archivo de texto especificado dentro del espacio de trabajo. |
|
| Rastrea declaraciones, referencias y sitios de uso de un símbolo a través del espacio de trabajo. |
[!NOTA] Los argumentos de los prompts se tratan como datos de tarea acotados y se escapan antes de insertarse en las plantillas de prompts MCP reutilizables. Los prompts no ejecutan E/S directa del sistema de archivos por sí mismos; la lectura y búsqueda real de archivos la realiza el modelo utilizando herramientas y recursos MCP estándar bajo estrictos controles de lista blanca de raíces.
Acceso de Solo Lectura al Espacio de Trabajo
El acceso al sistema de archivos está deshabilitado por defecto. Para habilitar el acceso de solo lectura al espacio de trabajo, especifique explícitamente --profile=workspace (o --profile=all) y al menos un directorio --root en lista blanca:
# POSIX / macOS / Linux
npx high-performance-mcp-server --profile=workspace --root=/home/user/my-project
# Windows
npx high-performance-mcp-server --profile=workspace --root="C:\Projects\app"
# Multiple roots
npx high-performance-mcp-server --profile=workspace --root=./packages/core --root=./packages/cliGarantías y Restricciones de Seguridad
Privacidad de Rutas del Host: Las rutas absolutas configuradas del sistema de archivos permanecen internas al servidor. La herramienta
workspace_rootsy el recursoworkspace://rootsdevuelven identificadores de raíz lógicos (id: "root-1",name: "my-project") en lugar de rutas absolutas del host:{ "roots": [ { "id": "root-1", "name": "my-project" } ] }Lista Blanca Estricta: Solo se pueden acceder a los directorios
--rootpasados explícitamente. Se permiten un máximo de 16 raíces únicas (y un máximo de 64 rutas crudas antes de la deduplicación).Solo Lectura: No existen funciones de mutación del sistema de archivos (
writeFile,unlink,rm,mkdir,rename, etc.) en el código del servidor.Protección contra Traversal y Enlaces Simbólicos: Las rutas de destino se canonicalizan usando
fs.realpathy se verifican estrictamente para que nunca escapen de los límites de la raíz.Errores Saneados: Las respuestas de error hacen referencia solo a IDs de raíz lógicos, nombres de raíz y rutas relativas solicitadas, asegurando que las estructuras de directorios internas nunca se filtren.
Límites de Lectura de Archivos: El límite de lectura de texto predeterminado es de 256 KiB; el límite superior estricto es de 1 MiB (
MAX_TEXT_READ_BYTES).Detección de Archivos Binarios: Los archivos que contienen bytes NUL (
\0) son rechazados porread_text_filepara prevenir la contaminación del contexto.Recursos MCP: Expone
workspace://roots(lista estática de raíces) yworkspace://file/{rootId}{?path}(lector de texto dinámico).
Búsqueda en el Espacio de Trabajo
El perfil workspace proporciona herramientas de búsqueda acotadas y de solo lectura:
search_files:Busca nombres de archivos y directorios usando coincidencia de subcadenas literales.
Filtra por tipo (
file,directory,all), sensibilidad a mayúsculas y ruta de inicio.Omite directorios comunes de compilación/vendor (
.git,node_modules,.next,dist,build,target, etc.) por defecto. PaseincludeIgnored: truepara buscarlos.Nunca atraviesa directorios de enlaces simbólicos/junctions para prevenir ciclos de recursión y escapes.
search_text:Busca archivos de texto UTF-8 usando coincidencia literal acotada con concurrencia fija (8 trabajadores).
Devuelve línea, columna y fragmentos de vista previa recortados (hasta 300 caracteres) basados en 1.
Soporta filtros de extensión de archivo (por ejemplo,
extensions: [".ts", ".md"]oextensions: ["ts", "md"]).Omite automáticamente archivos binarios (bytes NUL) y archivos mayores de 1 MiB (
MAX_SEARCH_FILE_BYTES).Límites: Valores predeterminados estrictos (
maxResults: 100[máx. 500],maxFiles: 5000[máx. 50000],timeoutMs: 10000[máx. 30000]).Totalmente cancelable mediante
AbortSignaldel cliente.
Interfaz de Línea de Comandos (CLI)
Usage:
high-performance-mcp-server [options]
Options:
--transport=<stdio|http> Transport protocol to run (default: stdio)
--port=<number> HTTP server port (default: 3000, only for http transport)
--profile=<profile> Security tool profile (default: safe)
--root=<path> Allowlisted read-only workspace root (repeatable, max 16)
--list-tools Display available tools for the active profile and exit
--help, -h Show this help message and exit
--version, -v Show version and exitEjemplos
# Start default safe server on stdio
high-performance-mcp-server
# List tools available under the workspace profile
high-performance-mcp-server --profile=workspace --list-tools
# Run Streamable HTTP transport on port 8080 with workspace profile
high-performance-mcp-server --transport=http --port=8080 --profile=workspace --root=./projectDetalles del Transporte HTTP
Cuando se inicia con --transport=http, el servidor lanza un transporte HTTP Streamable usando el node:http integrado de Node.js:
Endpoint:
http://127.0.0.1:<port>/mcpSeguridad: El servidor se vincula estrictamente a
127.0.0.1y valida los encabezadosHostyOriginpara proteger contra el rebinding de DNS y la falsificación de solicitudes entre sitios.Advertencia: No exponga el transporte HTTP directamente a redes no confiables sin un proxy inverso o puerta de enlace autenticada.
Variables de Entorno
Variable | Type | Predeterminado | Descripción |
|
|
| Anulación del perfil de herramientas predeterminado ( |
|
|
| Anulación del puerto HTTP predeterminado (entero estricto 1-65535) |
|
| (ninguno) | Matriz JSON de raíces del espacio de trabajo (p. ej. |
|
|
| Número de hilos de trabajo creados en el pool (1 a 16) |
|
|
| Número máximo de entradas en la caché LRU (1 a 10000) |
|
|
| Tiempo de vida (TTL) de cada entrada de la caché LRU en milisegundos (5 minutos) |
Desarrollo
# Install dependencies
npm install
# Run code generator and TypeScript typecheck
npm run typecheck
# Execute unit, security, search, and modern protocol integration test suites
npm test
# Build production bundle
npm run build
# Validate npm package payload without publishing
npm run pack:check
# Run package payload security & privacy scan
npm run security:package
# Run end-to-end tarball installation smoke test
npm run smoke:packageArquitectura
MCP Clients (Claude Desktop, Cursor, Custom SDK Clients)
│
┌───────────────┴───────────────┐
▼ ▼
Stdio Transport Streamable HTTP Transport
(process.stdin / stdout) (127.0.0.1:3000/mcp)
│ │
└───────────────┬───────────────┘
▼
McpServer Instance
(Profile-Aware Server Instructions)
│
┌───────────────┴───────────────┐
▼ ▼
Tool & Prompt Profiles Internal Telemetry
(safe, workspace, diag, ...) (Metrics & Stderr Logger)
│ │
├──────► Read-Only Workspace, Search, Resources & Prompts (Allowlisted Roots, Host Privacy)
│
├──────► In-Memory LRU Cache (Single-Flight Stampede Protection)
│
└──────► Reusable Worker Thread Pool (CPU Offloading)Seguridad
El perfil de seguridad predeterminado (
safe) garantiza que no se exponga ninguna inspección del sistema de archivos o del hardware sin una aceptación explícita.El acceso de solo lectura al espacio de trabajo aísla estrictamente el acceso a archivos en los directorios
--rootconfigurados, sin revelar rutas absolutas del sistema de archivos del host.Las instrucciones y las indicaciones del servidor refuerzan la secuenciación segura de las herramientas y los límites explícitos de las tareas con escape de caracteres.
El transporte Stdio reserva
stdoutexclusivamente para mensajes JSON-RPC; todos los registros internos de depuración y telemetría se enrutan astderr.El transporte HTTP aplica una validación estricta del origen localhost y de la cabecera Host.
Para obtener más detalles, revisa SECURITY.md.
Contribuciones y lanzamientos
¡Las contribuciones y los comentarios son bienvenidos! Por favor, lee CONTRIBUTING.md para obtener detalles sobre el estilo de código, las convenciones de desarrollo de herramientas, los requisitos de pruebas y el flujo de trabajo de lanzamientos para mantenedores.
Licencia
Este proyecto se distribuye bajo la Licencia MIT.
Available Tools
2 toolsechoEcho ToolA
Echoes back the provided message
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The message to echo back |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It accurately states that the tool returns the provided message, which is the only meaningful behavioral trait. No side effects, auth, or rate limits are relevant for this simple operation.
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, front-loaded sentence that contains zero filler. Every word earns its place, and the structure is ideal for such a minimal tool.
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 extreme simplicity—one parameter, no output schema, no annotations—the description fully covers the operation. There is nothing missing that an agent would need to select and invoke this tool correctly.
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%, and the 'message' parameter is already fully documented in the schema. The tool description adds no additional semantic value beyond the schema, meeting the baseline for high coverage.
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 'Echoes' with a clear object 'the provided message', making the tool's function obvious. It distinguishes from sibling 'ping' by implication (echo vs. connectivity check), but does not explicitly differentiate.
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 use case is implied by the simple definition—'if you need to echo a message, use this tool'—but there is no explicit when-to-use guidance or mention of the sibling tool 'ping'. For such a trivial tool, the implication is adequate but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pingPingA
Checks whether the MCP server is responsive
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not explicitly mention side effects or whether the operation is read-only. However, the nature of a ping implies a non-destructive check, so it is somewhat transparent.
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 easy to understand and directly conveys the purpose.
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 description covers the primary purpose but does not specify the return value or output format, which might be ambiguous without a schema. It could be improved by indicating the type of response expected.
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?
There are no parameters, so the schema covers all aspects. No additional parameter explanation is needed.
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's function as a server responsiveness check, distinguishing it from the sibling 'echo' tool which likely echoes input.
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 it (for health checks), and the context of only one sibling ('echo') makes the usage scenario unambiguous, though it does not explicitly state alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
The two tools have entirely distinct purposes: echo returns a message, while ping checks server responsiveness. There is no overlap or ambiguity in their functionality.
Both tool names are single, lowercase verbs (echo, ping) that clearly describe their actions. The naming style is perfectly consistent and predictable.
With only 2 tools, the server is at the lower boundary of what feels minimal. While each tool serves a purpose, the set is extremely thin for a server named 'high-performance', which typically implies broader functionality.
The tool surface is almost nonexistent for a general-purpose server. While echo and ping are fully realized for their narrow functions, there are no operations that would support meaningful workflows, leaving significant gaps in coverage for any real domain.
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
A MCP server built for developers enabling Git based project management with project and personal…
A simple Typescript MCP server built using the official MCP Typescript SDK and smithery/cli. This…
An MCP server for deep research or task groups
The official Svelte MCP server providing docs and autofixing tools for Svelte development
Related MCP Servers
- AlicenseBqualityDmaintenanceTypeScript-based MCP server designed to enhance code editing experiences by providing features such as hover information, code completion, and diagnostics.32026MIT
- AlicenseNot gradedqualityAmaintenanceAn MCP server that exposes Language Server Protocol features to external clients, allowing access to hover information, definitions, completions, references, and rename functionalities.1640MIT
- AlicenseAqualityDmaintenanceA lightweight MCP server that provides 40 tools for TypeScript/JavaScript refactoring and code intelligence, directly mapping to TypeScript's tsserver protocol commands for accurate structural changes and workspace analysis.40343MIT
- AlicenseNot gradedqualityCmaintenanceA TypeScript-based MCP server that enables code search, file reading, and project management via the GitLab API.251ISC
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/AnIayana/high-performance-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server