mcp-typescript-starter
MCP TypeScript Starter
MCP Typescript Starter — это ориентированная на production основа для создания сервера Model Context Protocol на TypeScript. Он включает один типизированный пример инструмента, транспорты stdio и Streamable HTTP, строгую валидацию, тесты, защищённый контейнер и автоматическую публикацию в GHCR.
Склонируйте репозиторий, замените пример домена и сохраните инфраструктуру, котораая нужна настоящим серверам MCP.
Навигация
Related MCP server: mcp-server-http-streamable
Использование этого стартера
Нажмите Use his template на GitHub, чтобы создать новый MCP-сервер с независимой историей Git. После создания замените пример инструмента и обновите идентичность проека, следуя разделу Кастомизация стартера.
Сделайте форк этого репозитория, если хотите вернуть улучшения через pull request. Прежде чем отправить изменения, ознакомьтесь с разделом Вклад в проект.
Если этот стартер вам помог, поставьте звёздочку репозиторию. Это помогает другим TypeScript-разработчикам найти проек.
О проекте
Стартер демонстрирует полный путь от проверенного определения MCP-инструмента до видимого клиенту структурированного результата. Сервер использует теущий модульный MCP TypeScript SDK и веб-стандартную HTTP-модель Hono, а не собственный серверный фреймворк.
Транспорт stdio по умолчанию предназначен для локальных клиенов, котореые заускают сервер как дочерний процес. Streamable HTTP не сохраняет состояние и создаёт новый экземпляр MCP-сервера для кажого запроса, поэтоме его можно реплицировать без общего хранилища сессий.
Пример выполняется ограниченную работу в памяти. Здесь нет телеметрии, прикладной базы данных, постоянного хранилища, аутентификации или зависимости от внешних сервисов.
Возможности
Регистрирует инструменты со строгими входными и выходными схемами Zod.
Возвращает и человекочитаемый контент, и типизированный струкурированный контент.
Включает корректые аннотации безопасности MCP.
Поддерживает stdio и Stateless Streamable HTTP.
Использует Hono с валидацией Host и Origin против DNS rebinding.
Привязывает HTTP к loopback по умолчанию и требует список разрешённых для других интерфейсов.
Ограничивает входные данные инструментов и тела HTTP-запросов.
В режиме stdio сохраняет stdout исключительно для сообщений протокола MCP.
Обрабатывает SIGINT и SIGTERM с идемпотентным безопасным завершением работы.
Работает как не-root контейнер с поддержкой read-only-root-filesystem.
Тестирует конфигурацию, подклчение stdio, поведение MCP, маршруты Hono и реаьный HTTP-трафик.
Публикует мультиархитектурные образы только после усешного прохождения проверок качестка.
MCP-инструменты
echo
Возвращает проверенное сообщение и необязатеьные строковые метаданные. Он намеренно прост, чтобы репозиторий демонстрировал схемы MCP, регистрацию, аннотации и результаты без придумывания предмедной облати.
Пример ввода:
{
"message": "Hello, MCP!",
"metadata": {
"source": "example-client"
}
}Пример струкурированного вывода:
{
"message": "Hello, MCP!",
"metadata": {
"source": "example-client"
}
}Сообщения ограничены 10 000 символами. Медаданные принимают не более 20 записей; ключи ограничены 64 симолами, значения — 1 024 симолами.
Технологический стек
TypeScript со строгими правилами проека
Установка
Предварительные требования
Node.js 24+ и pnpm 11 для локальной разработки.
Docker и Docker Compose для развёртывания в контейнере.
Docker Compose
Рекомендованное HTTP-развёртывание использует опубликованный мультиархитектурный образ:
ghcr.io/lukegskw/mcp-typescript-starter:latestСкачайте пример Compose и укажите hostname, который будут использовать клиенты:
curl -O https://raw.githubusercontent.com/lukegskw/mcp-typescript-starter/main/compose.example.yaml
export MCP_ALLOWED_HOSTS='mcp.example.internal'
docker compose -f compose.example.yaml up -dЭндпоинты Streamable HTTP и health будут доступны по адресу:
http://<host>:3000/mcp
http://<host>:3000/healthzЧтобы опубликовать другой порт хоста, задайте MCP_PUBLISHED_PORT. Приложение по-прежнему использует порт 3000 внутри контейнера.
Тег latest сооствутствует последней усешной сборке из ветки по умолчанию. Используйте тег версии или неизменяемый тег sha-* для контролируемого развёртывания и отката.
Docker run
docker run -d \
--name mcp-typescript-starter \
--restart unless-stopped \
--read-only \
--user 10001:10001 \
--cap-drop ALL \
--security-opt no-new-privileges:true \
--tmpfs /tmp:size=16m,mode=1777 \
-e MCP_TRANSPORT=streamable-http \
-e MCP_HOST=0.0.0.0 \
-e MCP_ALLOWED_HOSTS=127.0.0.1,localhost,mcp.example.internal \
-p 3000:3000 \
ghcr.io/lukegskw/mcp-typescript-starter:latestСборка контейнера из исходников
git clone https://github.com/lukegskw/mcp-typescript-starter.git
cd mcp-typescript-starter
docker buildx build --load -t mcp-typescript-starter:local .Локальная установка Node.js
git clone https://github.com/lukegskw/mcp-typescript-starter.git
cd mcp-typescript-starter
pnpm install --frozen-lockfile
pnpm build
pnpm start -- --transport stdioДля локальной разработки со Streamable HTTP:
MCP_TRANSPORT=streamable-http pnpm devКонфигурация
Переменная | Обязательна | По умолчанию | Описание |
| Нет |
|
|
| Нет |
| Адрес привязки HTTP. |
| Нет |
| Пор прослушивания HTTP. |
| Вне loopback | Нет | Список разрешённых имён хостов Hos и Origin через запятую. |
Параметр командной строки --trаnsport переопределяет MCP_TRANSPORT. MCP_ALLOWED_HOS содежит имеа хостов, а не URL; включите все имеа хостов, которые используют легитимные клиенты и проверки состоня.
В примере конфигурации сервера нет секретов. Добавляйте учётные данные предмедной облати через платформу развёртывания или окружение, но никогда как аргументы MCP-инструментов или в файлах, попадающих в репозиторий.
Настройка MCP-клиента
Для клиента, который принимает определени сервера Streamable HTTP:
mcp_servers:
starter:
url: http://127.0.0.1:3000/mcpДля клиента, который заускает локальный stdio-сервер:
{
"mcpServers": {
"starter": {
"command": "node",
"args": [
"/absolute/path/to/mcp-typescript-starter/dist/main.js",
"--transport",
"stdio"
]
}
}
}Чтобы локальный клиент мог заускать контейнер через stdio, используйте docker run -i --rm и передавайте --transport stdio после имен образ. Параметр -i обязателен, чтобы клиент мог обмениваться MCP-сообщениями через стандатный ввод и вывод.
Форматы конфигурации клиенов различаются. Обратитесь к документации клиента за точной схемой и перезаустите или перезагрузите клиента после изменения определени сервера.
Кастомизация стартеа
Основные точки расширения намеренно просты:
Скопируйте или замените
src/tools/echo.ts.Определите строгие входные и выходные схемы перед написанием обработчика.
Зарегистрируйте инструмент в
src/server.ts.Добавьте тесты поведени MCP и любые интеграционные тесты предмедной облати.
Замените имя пакета, идентичность сервера, ссылки на образы и содержимое README.
Оставляйте модули инструментов ответственными за свои схемы и обработчики. Держите транспортные модули независимыми от доменных инструментов. Вводите сервисы или постоянное хранилище только тогда, когда этого требует реальное поведение.
Проверка
Запустите полный набор проверок репозитория:
pnpm install --frozen-lockfile
pnpm format:check
pnpm lint
pnpm typecheck
pnpm test:unit
pnpm test:integration
pnpm buildДля изменений контейнера:
docker buildx build --load -t mcp-typescript-starter:test .Наконец, подключите MCP-клиент и убедитесь, что echo отображается в списке и возвращает и текст, и структурированный контент. В HTTP-режиме убедитесь, что /healthz возвращает {"status":"ok"}.
Ограничения
Пример предоставляет один инструмент и не содежит ресурсов или промптов.
Streamable HTTP не имеет аутентификации. Ограничьте его loopback-интерфейсом, доверенной локальной сетью, VPN, частной контейнерной сетью или аутентифицирующим обратным прокси.
Списки разрешённых Hos и Origin предотвращают определённые классы атак DNS rebinding, но не аутентифицируют вызывающих.
HTTP-сервер не сохраняет состояние и не содежит общего постоянного хранилища или распределённой координации.
Ограничение частоты запросов, трассировка, метрики и доменное логирование не включены.
Репозиторий — это стартер из исходного кода, а не опубликованная npm-библиотека.
Изучите SECURITY.md прежде чем открывать HTTP-транспорт или сообщать о проблеме безопасности.
Вклад в проект
Вклад привествуется. Перед открытием pull request:
pnpm install --frozen-lockfile
pnpm format:check
pnpm lint
pnpm typecheck
pnpm test
pnpm build
docker buildx build --load -t mcp-typescript-starter:test .Изменени должны сохранть строгую типизацию, ограниченную валидацию, структурированные результаты MCP, чистоту протокола stdout, безопасные HTTP-настройки по умолчанию, детерминированные тесты и докуменатцию для видимого пользователю поведени. Не добавляйте абстракции без конкретного сценари их использоани.
Лицензия
MIT. См. LICENSE.
Available Tools
1 toolechoEchoBRead-onlyIdempotent
Echo a validated message and optional string metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | ||
| metadata | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | Yes | |
| metadata | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side-effect expectations. The description adds minimal behavioral context, mainly 'validated', which hints that inputs are checked but not how. No contradiction with annotations; the bar is lower, so a 3 is appropriate.
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, direct sentence with no unnecessary words. The verb is front-loaded, and the optional part is clearly flagged. 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?
For a trivial echo tool, the description is nearly sufficient. The output schema exists, and annotations cover read-only/idempotent behavior, so return-value details are not needed. The only gap is vague 'validated' wording, but the tool is simple enough that an agent can invoke it correctly with the given information.
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 0%, so the description must compensate. It names 'message' and 'optional string metadata', but the schema already provides types and constraints. Calling metadata 'string metadata' is potentially misleading because the schema defines metadata as an object with string values, not a string. This adds little value beyond the schema.
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 ('echo') and resource ('a validated message and optional string metadata'), making the core function clear. There are no sibling tools to differentiate from, so the lack of distinction is not a flaw. However, 'validated' is slightly ambiguous — it might imply an extra validation step that is actually handled by the schema.
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 given on when to use this tool or what to prefer it over. There are no siblings, but the description still does not state typical scenarios (e.g., debugging, round-trip testing). The intended usage is only implied by the verb 'echo'.
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 tool update
v0.1.0- First observed
echo
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion or overlap. The single 'echo' tool is clearly distinct by virtue of being the only tool available.
The single tool name 'echo' is short, clear, and directly describes its function. Since there is only one tool, naming consistency is trivially satisfied.
One tool feels minimal even for a starter server, but it is a common pattern for a simple template. The count is at the lower edge of being acceptable rather than egregiously insufficient.
The server only provides an echo function, which is useful for testing connectivity but lacks any real domain operations. There are no CRUD or workflow capabilities, representing a significant gap for any practical use beyond a basic demo.
Maintenance
Related MCP Connectors
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
A Model Context Protocol server for Wix AI tools
Ovanek MCP: Model Context Protocol server for Ovanek platform tools; writes are dry-run by default.
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA stateless Model Context Protocol server that implements a simple echo functionality with resource, tool, and prompt components, enabling LLMs to echo back messages through standardized MCP interactions.1ISC
- AlicenseNot gradedqualityDmaintenanceA minimal Model Context Protocol server that facilitates network-based client connections using Streamable HTTP transport. It provides a greeting tool and is optimized for consistent deployment across local environments, Docker, and Kubernetes.MIT
- AlicenseNot gradedqualityFmaintenanceA robust server implementing the Model Context Protocol with SSE and STDIO transport, enabling real-time communication and extensible tooling for AI models.402 npm4MIT
- AlicenseNot gradedqualityBmaintenanceProvides a production-ready Model Context Protocol server with dual STDIO and Streamable HTTP transports, enabling file operations, memory, database queries, RAG, web search, GitHub integration, background tasks, and prompt-based workflows.MIT