Skip to main content
Glama

hpe-networking-mcp — инструментарий HPE Networking MCP

License Python MCP CI Docs Release Image

hpe-networking-mcp banner showing 6,144 generated operations, 6,728 backend tools, 3 minimal router tools, and nine platform surfaces with optional local RAG

Баннер показывает актуальное состояние внутреннего каталога: большая поверхность инструментов остаётся доступной по запросу, тогда как сам MCP-клиент по умолчанию видит только три роутер-инструмента.

Низкотокеновый сервер Model Context Protocol (MCP) для автоматизации HPE Networking: Aruba Central, HPE GreenLake Platform (GLP), ClearPass, Juniper Mist, Apstra, автоматизация миграции ArubaOS 8, EdgeConnect, HPE Aruba UX и Axis Atmos Cloud.

MCP позволяет ИИ-клиенту — Claude Code, Copilot, Cursor, VS Code или любому другому узлу, поддерживающему MCP — обращаться к общему инструментарию вместо отдельного плагина для каждого вендора. hpe-networking-mcp — один из таких серверов: подключите к нему любой MCP-клиент, и он откроет доступ к поисковому каталогу операций HPE Networking через компактную поверхность с низким расходом токенов.

hpe-networking-mcp даёт ИИ-клиентам, работающим через MCP, низкопотребляющий по токенам способ искать документацию Aruba/HPE, сверяться с точными деталями OpenAPI, проверять состояние Central, запускать сценарии устранения неполадок, управлять конфигурацией, выполнять защищённые миграции ArubaOS 8 и применять защищённые операции GreenLake Platform. Он построен на прямых REST-вызовах через httpx.

Полное визуальное описание той же информации — выбор аудитории, диаграммы и схема безопасности записи — находится на сайте hpe-networking-mcp на GitHub Pages. Этот README намеренно короткий; канонические руководства лежат в docs/.

Почему роутер важен

Подключите ваш MCP-клиент к одному серверу: src/hpe_networking_mcp/mcp_servers/tool_router.py. Рекомендуемый профиль minimal держит видимый клиенту список инструментов из трёх позиций, обеспечивая доступ ко всем внутренним каталогом:

  1. find_tool — найти нужный внутренний инструмент.

  2. invoke_read_tool — выполнить только читающий вызовы.

  3. invoke_tool — выполнить только намеренные операции записи/удаления.

Related MCP server: Network AI Assistant

Для кого это

Вы…

Начни с

Впервые используете MCP

Пятиминутный быстрый старт без учётных данных ниже, затем Начало работы

Сетевой оператор Aruba

Примеры промптов и Типовые продуктовые сценарии

Разработчик hpe-networking-mcp

Как работают MCP и RAG, Обзор архитектуры и Руководство для контрибьюторов

Пятиминутный быстрый старт без учётных данных

Проверьте установку и запустите MCP HTTP-сервер, прежде чем добавлять какие-либо учётные данные Aruba Central или GreenLake Platform.

Вариант A — используйте опубликованный образ (без клонирования репозитория):

docker run -d --name hpe-networking-mcp \
  -p 127.0.0.1:8010:8010 \
  -e MCP_HOST=0.0.0.0 \
  -e MCP_ALLOWED_HOSTS='127.0.0.1:*,localhost:*' \
  -e MCP_ALLOWED_ORIGINS='http://127.0.0.1:*,http://localhost:*' \
  ghcr.io/secure-ssid/hpe-networking-mcp:latest

Как только запуск завершится (за несколько секунд), curl http://127.0.0.1:8010/livez ответит {"status":"ok"}. Публикация только на loopback не выводит сервер за пределы вашей локальной сети; форма allowlist с host:* обязательна, если MCP_HOST не указывает на loopback. Индекс спецификаций OpenAPI встроен в образ во время сборки; для семантического ранжирования дополнительно нужна пересборка с экстразависимостями индексации (--build-arg INSTALL_EXTRAS=ingestion, см. Production deployment).

Вариант B — сборка из исходников (добавляет мастер настройки, диагностику doctor и локальный инструментарий для индекса):

git clone https://github.com/secure-ssid/hpe-networking-mcp.git
cd hpe-networking-mcp
python3 scripts/setup_wizard.py --yes --skip-credentials
uv run hpe-mcp-doctor
MCP_PORT=8010 bash scripts/run_http_router.sh

Ожидаемые результаты:

  • Мастер печатает каждый выполненный этап и завершается сводкой о готовности настройки; никаких вызовов к Central/GLP не выполняется. На хостах Windows собирайте и запускайте из оболочки с переводами строк LF (WSL2 или настроенный checkout) — строки CRLF ломают входные скрипты в Docker-сборках.

  • doctor.py отчитывается о проверках локальных зависимостей, путей конфигурации и индекса — всё возвращает OK или список того, что стоит исправись, без обращения к какому-либо API вендора.

  • HTTP-роутер выводит строку Uvicorn running on http://127.0.0.1:8010 и продолжает работать в активном режиме.

Подключите любой MCP-совместимый клиент к http://127.0.0.1:8010/mcp и попробуйте поиск инструмента без учётных данных:

find_tool("list Aruba Central devices")

Ожидаемый результат: ранжированные совпадения читаются прямо из локального индекса инструментов, который только что построил мастер, каждое помеченное своей capability и состоянием write-gate. Никаких обращений к API вендора не происходит.

Подключение в вашем клиенте

Направьте любой MCP-совместимый клиент на http://127.0.0.1:8010/mcp (или конфигурацию stdio hpe-mcp-router) — и он увидит только три роутер-инструмента. Готовые конфиги для Claude, Copilot, VS Code, Cursor и других — в "MCP client recipes"; поставляемые примеры лежат в examples/mcp-clients/.

Поиск по документации — это отдельная локальная сборка

ask_docs и вся остальная RAG-поверхность требуют корпус прозы, которого этот проект сознательно не поставляет. Этот корпус — собранные веб-краулером материалы документации вендоров, и перепубликовывать их не в нашей власти — см. ingestion/source_manifest.json, который всегда гласил «Do not commit scraped content». Соберите его самостоятельно, приняв на себя условия каждого вендора:

uv run --extra ingestion python ingestion/ingest_docs.py

Закладывайте на это время. Сам обход измеряется часами, а первый RAG-запрос дополнительно загружает клиент эмбеддингов nomic-embed-text-v1.5 размером ~250 МБ в ваш кэш Hugging Face. Без учётных данных не значит офлайн: быстрый старт выше не требует вендорских учётных данных, но и сборка корпуса, и первый запрос требуют доступа в сеть.

Безопасность записи в двух словах

  • find_tool только ищет в локальном каталоге инструментов; он никогда не вызывает API вендора.

  • invoke_read_tool блокирует любой внутренний инструмент, который не помечен как read-only.

  • invoke_tool намеренно помечен как деструктивный, потому что он может выполнять и write/деструктивные внутренние инструменты — используйте его только тогда, когда это действительно задумана операция записи.

  • При поддержке сначала используйте dry_run=True; реальное выполнение потребует либо confirm=True, либо запроса подтверждения через MCP, в зависимости от схемы инструмента.

  • Запись включается вручную (opt-in) на каждой платформе, включая Central: при профиле по умолчанию HPE_MCP_ACCESS_PROFILE=custom гейт записи каждой платформы закрыт, пока вы его не открыли. Используйте safe-read-only, чтобы заблокировать любые записи голосов от персональных гейтов платформ, или full-read-write, чтобы включить обычные записи на каждой подключенной платформе.

  • Полный режим чтения/записи не отменяет dry-run, подтверждение, запрос через MCP и выделенную защиту, например отдельный гейт отката AOS8.

  • Учётные данные хранятся в config/credentials.yaml или переменных окружения и никогда не коммитятся.

Переменная

По умолчанию

Эффект

HPE_MCP_ACCESS_PROFILE

custom

safe-read-only запрещает все записи; full-read-write разрешает все; custom использует гейты платформ ниже

HPE_MCP_<PLATFORM>_WRITES

0

Установите 1, чтобы открыть инструменты записи и удаления для этой платформы

Деструктивные операции (reboot_device, disconnect_client) ограничиваются то ли флагом, что и записи — отдельного «операционного» уровня, который бы это обходил, нет.

Полную модель discovery/диспетчеризации/безопасности записи см. в Tool router.

Состояние проекта

Область

Текущее состояние

Каталог инструментов

Неаддитивные профили: 380 основных инструментов / 2842 опциональных стартовых read-only / 5822 опциональных стартовых read-write; всего backend-API REST/OpenAPI платформ: 6,711; только протокол Central Streaming: 1; кросс-платформенное здоровье сайтов: 1; полный серверный индекс: 6,728; direct-all: 6,736

Итоги по возможностям (API платформ)

3,159 read / 165 diagnostic / 2,545 write / 842 destructive

RAG

392,471 фрагмент прозы в LanceDB по 30 собранным источникам

Структурированный поиск

2,734 эндпоинта, 6,363 схемы, 31,432 поля, 104 бюллетени, 345 записей жизненного цикла

Происхождение API

реестры Aruba ReadMe, официальные источники Mist/Apstra, закреплённые снимки GLP и EdgeConnect, SHA-закреплённый генератор Axis

Дополнительные платформы

ClearPass, Mist, Apstra, the AOS8, EdgeConnect, UXI, Axis Atmos Cloud, с Akivatlosн инструменты design без учётных данных

Безопасность

Гейты записи по платформам, dry-run + подтверждение, HTTP-host/origin/bearer-контроль, конфигурация live-test под учётными записями

Полные счётчики инструментов по каждому бэкенду приведены в Каталоге инструментов. Всё, что добавлено в последнем тегированном релизе, описано в примечаниях к выпуску 0.9.0, а воспроизводимые сравнения инструментов и бенчмарков — в матрице функциональных разрывов.

Руководства по задачам

Задача

Руководство

Полная настройка, учётные данные и подключение MCP-клиента

Начало работы

Готовые конфигурации stdio- или streamable HTTP-клиента для копирования/вставки

Рецепты для MCP-клиентов

Режимы маршрутизатора, наборы инструментов и безопасная диспетчеризация — подробно

Маршрутизатор инструментов

Реальные промпты с ожидаемой формой вызовов

Примеры промптов

Включение ClearPass, Mist, Apstra, AOS8, EdgeConnect, UXI или Axis

Дополнительные продукты: с чего начать

Типизированная дорожная карта продуктовых рабочих процессов

Продуктовые рабочие процессы

Решение проблем с настройкой, учётными данными, HTTP или каталогом

Устранение неполадок

Архитектура, потоки данных и схемы безопасности

Обзор системы

Количество инструментов и охват по каждому бэкенду

Каталог инструментов

Полный визуальный портал по задачам

hpe-networking-mcp GitHub Pages

Все страницы документации, сгруппированные по назначению

docs/README.md

Миграция с secure-ssid/centralmcp

MIGRATION.md

Вклад, поддержка или сообщения об уязвимостях

CONTRIBUTING.md, SUPPORT.md, SECURITY.md

История версий

CHANGELOG.md

Основы локальной настройки

Стандартный профиль MCP-клиента остаётся минимальным:

HPE_MCP_ROUTER_MODE=minimal
HPE_MCP_TOOLSETS=central,glp,rag

Дополнительные продукты включайте только при необходимости:

HPE_MCP_ACCESS_PROFILE=custom
HPE_MCP_PRODUCTS=clearpass,mist,apstra,aos8,edgeconnect,uxi,axis,design
HPE_MCP_PRODUCT_ACCESS=read-only

Продукт

Переменные

ClearPass

CLEARPASS_BASE_URL, CLEARPASS_API_TOKEN

Juniper Mist

MIST_HOST, MIST_API_TOKEN

Apstra

APSTRA_BASE_URL, предпочтительно APSTRA_USERNAME/APSTRA_PASSWORD, опционально APSTRA_API_TOKEN

ArubaOS 8

AOS8_BASE_URL, предпочтительно AOS8_USERNAME/AOS8_PASSWORD, опционально AOS8_API_TOKEN, опционально AOS8_CLIENT_IP, опционально AOS8_SESSION_TTL_SECONDS

EdgeConnect

EDGECONNECT_BASE_URL, EDGECONNECT_API_TOKEN, опционально EDGECONNECT_AUTH_HEADER, специфичная для endpoint EDGECONNECT_AI_SESSION_AUTHORIZATION

HPE Aruba UXI

UXI_CLIENT_ID, UXI_CLIENT_SECRET, опционально UXI_BASE_URL, опционально UXI_TOKEN_URL

Axis Atmos Cloud

AXIS_BASE_URL, AXIS_API_TOKEN

Схемы проектирования сети (Draw.io / Graphviz / NeXt)

не требуются; опционально HPE_MCP_DIAGRAM_ICON_DIR

Полная модель настройки и безопасности описана в матрице дополнительных продуктов.

Для доверенного сеанса с полным доступом на запись используйте python3 scripts/setup_wizard.py --access-profile full-read-write, чтобы все устаревшие разрешающие механизмы были согласованы, либо автономный examples/mcp-clients/stdio/full-read-write.mcp.json.

В ../.claude/launch.json поставляется соответствующий минимальный профиль запуска hpe-networking-mcp для повседневной работы. find_tool по умолчанию не показывает полные JSON-схемы; include_schema=true запрашивайте только в том случае, если клиенту нужна полная форма параметров.

Создайте или обновите индекс инструментов маршрутизатора и базу данных API-спецификаций. Обе сущности получаются из закоммиченных в этот репозиторий OpenAPI-спецификаций, поэтому пересобираются детерминированно и не требуют скрейпинга:

uv run python scripts/ingest_tools.py --products all

Текстовый корпус для RAG собирается отдельно скриптом ingestion/ingest_docs.py, как описано в кратком руководстве выше. Он не распространяется как релизный артефакт.

Учётные данные, выбор региона, переменные окружения дополнительных продуктов и полный путь загрузки/обновления данных см. в разделе Начало работы.

Режим Streamable HTTP

MCP_PORT=8010 bash scripts/run_http_router.sh

Затем направьте любого MCP-совместимого клиента на http://127.0.0.1:8010/mcp. Сервер также открывает /livez, /readyz и /healthz. Привязка к адресам, отличным от loopback, требует явного указания MCP_ALLOWED_HOSTS/MCP_ALLOWED_ORIGINS и может быть защищена с помощью MCP_HTTP_BEARER_TOKEN. Готовые конфигурации stdio и HTTP для копирования/вставки — в рецептах для MCP-клиентов.

Структура проекта

src/hpe_networking_mcp/mcp_servers/     Low-token router + Central/GLP/RAG/optional-product servers
src/hpe_networking_mcp/pipeline/        httpx clients, 8-stage migration pipeline, SSID helpers
ingestion/       Docs/API scraping and LanceDB + SQLite index builders
docs/            Setup, router, architecture, product, and release guides
scripts/         Setup wizard, doctor wrapper, HTTP router helper, release validation
tests/           Unit, integration, and RAG eval coverage
config/          Credentials template; real credentials stay git-ignored
examples/        Tested, non-secret MCP client/prompt/runbook configuration examples
run_pipeline.py  Checkout wrapper for `hpe-mcp-run-pipeline`
run_ssid.py      Checkout wrapper for `hpe-mcp-run-ssid`

Полная карта репозитория, включая генерируемые и игнорируемые git-ей пути, находится в разделе Обзор системы.

Проверка

uv run pytest tests/unit -q
uv run python scripts/validate_release.py --catalog-products all --strict-tool-index --min-tools 6711

--min-tools 6711 задаёт нижнюю границу совместимости с платформенными API (это 6,711 инструментов платформенных API вендора), а не полное зарегистрированное количество инструментов бэкенда — 6,728, которое также включает протокол-инструмент Central Streaming, кроссплатформенный агрегатор site-health, локальную предварительную диагностику GLP и локальные инструменты без учётных данных. Проверка проходит на или выше этой нижней границы. Оба значения см. в Каталоге инструментов.

Помощник выпуска запускает модульные тесты, при наличии индексов — необязательные оценочные прогоны RAG/API, проверки нижней границы каталога инструментов и проверки актуальности локального индекса инструментов. Модульные тесты также включают статические проверки активного кода MCP/конвейера, включённых в репозиторий примеров конфигураций MCP с маленьким количеством токенов, локальных конфигурационных файлов, документации рута по продуктам и наборам инструментов, ограниченных универсальных GET-инструментов только для чтения, границ по умолчанию для списков MCP, ограничений top_k для RAG/поиска, публичных утверждений о количестве инструментов, обратных версией строк количества инструментов, отображаемых факт-утверждений о документах в RAG/индексе, отслеживаемых локальных Markdown-ссылок и изображений, метаданных sitemap и robots для Pages, документированных примеров аргументов маршрутизатора, таблицы имён инструментов в продуктовых рабочих процессах и таблиц переменных окружения для дополнительных продуктов в мастере.

Смежные проекты и благодарности

hpe-networking-mcp — это независимый инструментарий HPE Networking MCP, который улучшается с учётом официальной экосистемы MCP и работ сообщества:

Отказ от ответственности

hpe-networking-mcp — независимый community-проект. Это не официальный продукт HPE или HPE Aruba Networking, и он не одобрен и не поддерживается компанией HPE.

Лицензия

MIT — см. лицензию репозитория. Сгенерированные метаданные API и ссылки на вышестоящие реализации upstream описаны в THIRD_PARTY_NOTICES.md.

Available Tools

3 tools
find_toolA
Read-onlyIdempotent

Find tools by query. Combines semantic search + tool-name keyword match.

Call this first when you need an action. The returned name is what you pass to invoke_read_tool for read-only tools or invoke_tool for writes. Results are deduplicated; exact METHOD /path or operationId matches are annotated match='exact' (including generated-only tools disabled by the current profile), semantic matches match='semantic', name-overlap matches match='keyword', and safety flags mirror backend ToolAnnotations. Results are compact by default; set include_schema=True only when you need the full JSON schema for a selected tool. Optional platform, server, normalized capability, curated/generated origin, and exact OpenAPI operation-ID filters apply to exact, keyword, and semantic matches.

Args: query: What you want to do. e.g. "create a VLAN", "disconnect a client". top_k: 1-10 results (default 5). include_schema: Include full JSON schemas in results. Defaults to False to keep MCP responses compact. platform: Filter by normalized platform, such as central, glp, mist, clearpass, or apstra. server: Filter by exact backend server name, such as central-monitoring. capability: Filter by read, diagnostic, write, or destructive. origin: Filter by curated or generated implementation. operation_id: Filter by an exact generated OpenAPI operationId.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
top_kNo
originNo
serverNo
platformNo
capabilityNo
operation_idNo
include_schemaNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Even beyond the readOnly, openWorld, idempotent, and destructive annotations, the description discloses deduplication behavior, the exact/semantic/keyword match categories, inclusion of generated-only disabled tools, safety-flag provenance, and compact-by-default responses. This is substantial behavioral transparency and does not conflict with any annotation.

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 front-loaded with the most important instructions ('Call this first'), followed by the dispatch contract, match behavior, filters, and parameter documentation. Despite its length, the content is dense with useful detail and parallel in structure, making it well organized for an 8-parameter discovery tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 8 parameters, multiple filter dimensions, sibling routing, and a rich output schema, the description is complete: it covers when to call it, what the results contain, how matches are labeled, how to control schema verbosity, and how to dispatch the selected tool. Nothing critical is left to inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the Args section fully compensates. It defines all 8 parameters, giving query example usage, top_k range and default, include_schema trade-offs, platform/server examples, capability values, origin values, and operation_id meaning. The description therefore adds crucial semantics that the schema alone entirely lacks.

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 begins with a specific action ('Find tools by query') and explains the search mechanism ('semantic search + tool-name keyword match'). It distinguishes itself from the sibling invoke tools by stating that the returned `name` is the value to pass to invoke_read_tool or invoke_tool, so the purpose is unmistakably a discovery tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description is prescriptive: 'Call this first when you need an action.' It also tells the agent when to use include_schema ('only when you need the full JSON schema'), when to keep responses compact, and how to route a discovered tool to the correct sibling. It also explains the conditions under which filters should be applied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

invoke_read_toolA
Read-onlyIdempotent

Call a read-only Aruba tool by name (from find_tool).

This refuses tools that are not annotated read-only. Use invoke_tool only for write/destructive tools after explicit user intent.

Args: cursor: Opaque next_cursor value from a previous truncated response, to resume it from where it left off. Only ever returned by this tool for capability "read" tools -- it is process-local (invalidated by a server restart), integrity protected, time-limited, and bound to this exact tool name and these exact arguments. A malformed/tampered/expired/mismatched cursor returns an error and never reaches the backend.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
cursorNo
argumentsNo

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds significant behavioral detail beyond the annotations: it refuses non-read-only tools, and thoroughly explains cursor semantics including process-locality, integrity protection, time-limits, binding to tool name/arguments, and error behavior for invalid cursors. This goes well beyond the readOnlyHint/idempotentHint annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main purpose and usage guidance, followed by a structured 'Args' section that details cursor behavior. The cursor explanation is long but necessary and well-organized. Overall, it is appropriately concise without being under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a dispatcher tool with no output schema, the description covers the primary use case, restrictions, and error behavior for cursors. It could mention how arguments should be structured or what the return format looks like, but these are somewhat incidental given the tool's nature. It is sufficiently complete for an agent to invoke it correctly.

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 cursor parameter is explained in great detail, which is crucial for its opaque nature. However, the 'arguments' parameter is not described at all beyond the schema, and 'name' is only implied as coming from find_tool. With 0% schema description coverage, the description partially compensates but leaves gaps for the arguments parameter.

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 it calls a read-only Aruba tool by name, which is a specific verb-resource pairing. It distinguishes itself from the sibling invoke_tool by explicitly limiting to read-only tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to use this tool for read-only tools and to use invoke_tool for write/destructive tools after explicit user intent. This provides clear when-to-use and alternative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

invoke_toolA
Destructive

Call an Aruba tool by name (from find_tool). Arguments is a kwargs dict.

Example: invoke_tool("create_vlan", {"vlan_id": 200, "vlan_name": "Guest"})

Dispatches through the owning backend's MCPServer tool manager, so arguments get MCPServer validation/coercion and the router's request Context is forwarded — this is what lets the async, ctx-requiring destructive ops tools (reboot_device/port_bounce/poe_bounce/disconnect_client) reach their confirmation elicitation. (MCPServer injects ctx here and strips it from the published schema, so callers only pass name + arguments.)

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
argumentsNo

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations, the description reveals that arguments go through MCPServer validation/coercion, the router's request Context is forwarded, and destructive tools reach confirmation elicitation. This is rich behavioral detail that significantly helps an agent anticipate side effects and prerequisites.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose, followed by an example and then technical details. It is slightly dense but every sentence contributes value; the example and the explanation of ctx injection are both necessary for correct use.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's generic nature and absence of an output schema, the description covers purpose, usage, and behavior thoroughly. It does not mention return values or error handling, but for a dynamic dispatcher these may be tool-specific and not appropriate to detail. Overall, it is sufficiently complete for selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description compensates by explaining 'Arguments is a kwargs dict' and providing a working example. It clarifies that name comes from find_tool and that only name + arguments are passed. This adds meaningful semantics beyond the raw schema.

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 states a clear, specific action: 'Call an Aruba tool by name (from find_tool).' It provides a concrete example (invoke_tool("create_vlan", {...})) and distinguishes itself from siblings by mentioning its role in dispatching destructive ops tools, which is not true of invoke_read_tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: use this after find_tool to call any tool, and it explains how the dispatch works. However, it does not explicitly mention when to prefer invoke_read_tool or provide exclusion criteria, so it stops short of full guidelines.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a clearly distinct role: find_tool for discovery, invoke_read_tool for read-only execution, and invoke_tool for write/destructive execution. No overlapping purposes or ambiguous boundaries.

Naming Consistency4/5

Names follow a consistent snake_case verb_noun pattern. However, 'invoke_tool' is slightly ambiguous as it implies general invocation but actually handles only write/destructive tools, while 'invoke_read_tool' explicitly names its read-only scope.

Tool Count4/5

With only three tools, the set is minimal but appropriate for a meta-server that discovers and dispatches a larger underlying tool surface. It is not overly thin given the wrapper purpose.

Completeness5/5

The three tools form a complete workflow: find a tool, invoke read-only, or invoke write/destructive. No essential meta-operation is missing for the stated purpose of acting as a gateway.

Maintenance

ActivityMaintained
ResponsivenessResponsive

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/secure-ssid/hpe-networking-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server