Auth0 User Monitor
Allows monitoring and managing Auth0 users by collecting summaries, detecting suspicious admin accounts based on failed login thresholds, and auto-blocking them. Provides tools to retrieve user summaries, trigger collections, block suspicious users, list reports, and adjust scheduling.
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., "@Auth0 User Monitorshow me the latest user summary"
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.
День 18 — Планировщик и фоновые задачи (Auth0 user-monitor)
Отдельный MCP-сервер БЕЗ LLM (чистый код), который работает 24/7: по расписанию (раз в 10 минут) собирает сводку по пользователям тенанта Auth0, кладёт отчёт в SQLite и авто-блокирует подозрительных админов. Сводка отдаётся по запросу мгновенно из БД. Плюс набор скриптов, моделирующих жизненный цикл пользователей (создание → роли/доступ → активность → блокировка → удаление).
Что внутри
Файл | Роль |
| MCP-сервер (без LLM) — tools + фоновый планировщик (stdio / |
| Фоновый поток: раз в N сек собирает сводку, авто-блокирует подозрительных, пишет в БД. |
| Сбор сводки из РЕАЛЬНОГО Auth0 (users, roles, last_login, fp-логи, доступ к приложениям). |
| SQLite-хранилище отчётов. |
| Скрипты моделирования жизненного цикла пользователей (запускаются вручную). |
| Минимальный MCP-клиент для проверки. |
| Транспорт к Auth0 (с retry на 429, полные HTTP-логи, маскирование секретов). |
Related MCP server: Auth0 User Monitor MCP Server
MCP-инструменты (без LLM)
Tool | Что делает |
| Последний отчёт из БД (собран по расписанию) — мгновенно, без обращения к Auth0. |
| Собрать свежий отчёт сейчас, сохранить, вернуть (заодно авто-блок подозрительных). |
| Найти админов с ≥ порога неудачных входов и заблокировать; вернуть id. |
| История отчётов (время + итоги). |
| Сменить период сбора (сек) и/или порог подозрительности. Сохраняется, действует сразу. |
Сводка по пользователю: email, статус (blocked), last_login, logins_count,
роли, признак admin, доступ к приложениям (apps), число неудачных входов
(failed_logins), флаг suspicious.
Подозрительный = admin-роль И ≥ AUTH0_SUSPICIOUS_THRESHOLD (по умолч. 5)
неудачных входов И не заблокирован. Порог и интервал — через env.
Как это «по-настоящему» (анализ осуществимости)
Всё, что можно — реально в тенанте; то, что Auth0 «из коробки» не даёт — решено явно:
Требование | Реализация |
Создание / отключение ( | ✅ напрямую Management API |
Роли (выдача/отзыв) | ✅ |
| Реальные входы через ROPG (password-realm grant) → Auth0 проставляет настоящий |
«Неудачные входы с неправильным паролем» | Реальные |
«Доступ к приложениям» | В Auth0 нет прямой связи user→app; моделируется списком в |
Низкий rate-limit dev-тенанта | Retry на |
Search-индекс | Списки пользователей берём через обычный |
Для ROPG скрипт setup создаёт изолированные удаляемые ресурсы: отдельное
regular-web приложение day18-simulator (с password-realm grant) и отдельную
БД-коннекшн day18-sim-db (включены и симулятор, и M2M-клиент). cleanup всё
удаляет. Секрет симулятора лежит в .sim_state.json (в .gitignore).
Запуск
pip install -r requirements.txt
cp .env.example .env # AUTH0_DOMAIN / CLIENT_ID / CLIENT_SECRET1. Сервер 24/7 (отдельный процесс):
python3 server.py --http # http://127.0.0.1:8766/mcp, планировщик внутри
# короткий интервал для проверки:
AUTH0_SUMMARY_INTERVAL=60 python3 server.py --http2. Запросы (другой терминал):
python3 client.py --http --call get_user_summary
python3 client.py --http --call collect_now
python3 client.py --http --call block_suspicious_users3. Смоделировать «видимость» (создаёт реальные демо-объекты в тенанте):
python3 simulate.py scenario # users + роли + доступ + реальные входы + блокировка
python3 simulate.py list
python3 simulate.py cleanup # удалить всё: users + connection + app + rolescenario создаёт 6 пользователей: 2 админа (day18-admin1/2) и 4 обычных;
выдаёт роли/доступ; делает реальные входы; day18-admin2 получает 6 неудачных
входов (станет подозрительным → сервер заблокирует), day18-user3 тоже 6
неудачных, но он НЕ админ → НЕ блокируется; day18-user4 отключается.
Переменные окружения
Env | По умолч. | Назначение |
|
| Период сбора (сек). |
|
| Порог неудачных входов для подозрительного админа. |
|
| Файл SQLite с отчётами. |
Агент (день 18): чат + панель инструментов
Лёгкий LLM-агент, подключённый ТОЛЬКО к монитору дня 18 (без старого Auth0 98-инструментного MCP). Интерфейс — только чат и описание инструментов сервера.
Файл | Роль |
| Минимальный веб: чат + панель «🧰 Инструменты MCP-сервера». |
| Простой агент: диалог + function-calling по тулзам монитора (без этапов/инвариантов/памяти). |
| MCP-клиент/мост к монитору (HTTP по URL или stdio). |
| Транспорт к DeepSeek (function-calling). |
# 1) монитор (24/7) в одном терминале:
python3 server.py --http
# 2) агент-чат в другом:
MONITOR_URL=http://127.0.0.1:8766/mcp uvicorn web:app --reload # http://127.0.0.1:8000Примеры запросов в чате: «покажи сводку», «собери сейчас», «заблокируй подозрительных», «меняй расписание на 5 минут». Агент сам вызывает нужный инструмент монитора; под ответом видно 🔧 какой тул был вызван.
Сам MCP-сервер по-прежнему без LLM. LLM использует только агент.
Авто-обновление на стороне агента (аналог «loop»)
auto_refresh.py — фоновый поток-таймер в агенте: пока включено, каждые N секунд
сам вызывает collect_now у монитора, чтобы данные обновлялись без запроса
пользователя. Это «loop», но реализованный в приложении (Claude Code /loop —
фича харнесса, повторно запускающая ассистента; здесь — обычный поток).
Настройка: чекбокс «Авто-обновление данных» + интервал в минутах (по умолчанию
5 мин, минимум 30 сек). Env: AUTO_REFRESH=1, AUTO_REFRESH_INTERVAL=300.
В UI — строка статуса последнего обновления; в чат добавляется ♻ авто-обновление
при каждом новом сборе. Эндпоинты GET/POST /auto.
Архитектура (24/7)
┌─ scheduler (поток, раз в N сек) ─┐
client / агент ─MCP─▶ server.py ─▶ collector ─HTTPS─▶ Auth0 Mgmt API
│ ├─ users + roles + last_login
│ ├─ logs (type:fp) → failed_logins
│ └─ auto-block (admin + ≥5) → PATCH blocked
▼
summary_store (SQLite) ◀── get_user_summary читает отсюдаСервер не использует LLM. Скрипты симуляции — отдельно, их запускают вручную.
This server cannot be deployed
Maintenance
Related MCP Connectors
A paid remote MCP for CLI tool MCP, built to return verdicts, receipts, usage logs, and audit-ready
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Monitor MCP servers, API contracts and AI outputs for schema drift. Alerts on breaking changes.
A paid remote MCP for AI SDK eval dashboard, built to return verdicts, receipts, usage logs, and aud
Related MCP Servers
- FlicenseNot gradedqualityFmaintenanceMCP server that provides access to Auth0 Management API v2, offering read-only tools grouped by categories for querying Auth0 resources.-
- FlicenseNot gradedqualityFmaintenanceEnables monitoring Auth0 users by collecting summaries, storing reports in SQLite, and auto-blocking suspicious admins, all through MCP tools without an LLM.-
- AlicenseBqualityBmaintenanceLocal MCP server for inspecting and managing an allowlisted Discord server via Discord's REST API, with safety modes, idempotent JSON blueprints, and destructive-operation safeguards.271MIT
- AlicenseNot gradedqualityAmaintenanceA lightweight, self-hosted MCP server that provides a small set of administration tools for a single Minecraft Java Edition server, including whitelist management, broadcasting, kicking, backups, and monitoring, with secure RCON-based operations and audit logging.2MIT