Cisco Cucm MCP Server

@calltelemetry/cisco-cucm-mcp npm v0.7.1

Published by @calltelemetry — no publish provenance, so origin is unverified, but the source is public: the repository link below is self-declared yet readable, so you can inspect the code before adopting it.

MCP server for CUCM operational debugging: DIME logs, AXL config, RIS device status, PerfMon counters, service health, packet capture, and pcap analysis

Trust grade
A
93/100
Last scanned get badge →
Trust
A · 93/100
Adoption risk for you: the threat score, then adjusted down for blast radius, publisher verification and how much the scan could see. Deterministic; every point is auditable.
Capability
High
Blast radius if it went rogue — what the server’s tools could reach. Independent of trust.
Coverage
Source
How much the scan could actually inspect. Shallow coverage is stated, never hidden.
Share this Trust Score
𝕏 Share LinkedIn Reddit
A Why this grade threat 100 − adoption risk = 93/100

The grade answers one question — how safe is this server for you to adopt — so it is computed in two auditable stages. Nothing below is an opinion or an LLM's guess; every line is a real term the deterministic engine applied, and the same input always yields the same number.

1. Threat score — 100 − 0 = 100. What the published surface and source actually contain:

The deterministic scan raised no scored threat in the surface it inspected — the threat score stayed at 100. Capability observations and advisory notes are recorded but never lower it.

2. Client adoption risk — 100 − 7 = 93. Three small, subtract-only factors that reflect your risk in adopting it — a clean scan proves less on a powerful, unverified or barely-inspectable package, so the grade says so plainly:

PointsAdoption-risk factor
−6 capability blast radius (high) — client exposure if the model is manipulated
−1 publisher verification (public source) — no provenance, but the source is public and inspectable

Capability observations and info notes are shown under Findings but never scored. Open any row's finding below for the file, line and evidence behind a deduction.

Findings 1

high Shell/command execution in server code (build/index.js)MTC-SRC-002

In the server's implementation (`build/index.js:13`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: File as ts } from "node:child_process"; import { homedir as ss } from "node:os"; import { inflateRawSync as nt } from "n

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server build/index.js

Tools 64

Each tool and what it can reach — statically extracted from the published source.

  • axl_download_wsdlingests untrusted input
  • cdr_download_fileingests untrusted input
  • coordinated_capture_stop_analyzeingests untrusted input
  • download_batchingests untrusted input
  • download_fileingests untrusted input
  • packet_capture_download_from_stateingests untrusted input
  • packet_capture_stop_and_downloadingests untrusted input
  • phone_capture_downloadingests untrusted input
  • axl_describe_operationno sensitive capability
  • axl_executeno sensitive capability
Show 54 more tools ↓
  • axl_list_operationsno sensitive capability
  • cdr_get_file_listno sensitive capability
  • cdr_get_file_list_minutesno sensitive capability
  • cert_listno sensitive capability
  • cluster_health_checkno sensitive capability
  • coordinated_capture_startno sensitive capability
  • drf_backup_historyno sensitive capability
  • drf_backup_statusno sensitive capability
  • get_service_statusno sensitive capability
  • get_trace_configno sensitive capability
  • guess_timezone_stringno sensitive capability
  • list_node_service_logsno sensitive capability
  • list_services_extendedno sensitive capability
  • packet_capture_listno sensitive capability
  • packet_capture_startno sensitive capability
  • packet_capture_state_clearno sensitive capability
  • packet_capture_state_getno sensitive capability
  • packet_capture_state_listno sensitive capability
  • packet_capture_stopno sensitive capability
  • pcap_call_summaryno sensitive capability
  • pcap_protocol_filterno sensitive capability
  • pcap_rtp_streamsno sensitive capability
  • pcap_sccp_messagesno sensitive capability
  • pcap_sip_callsno sensitive capability
  • perfmon_add_counterno sensitive capability
  • perfmon_close_sessionno sensitive capability
  • perfmon_collect_counter_datano sensitive capability
  • perfmon_collect_session_datano sensitive capability
  • perfmon_list_counterno sensitive capability
  • perfmon_list_instanceno sensitive capability
  • perfmon_open_sessionno sensitive capability
  • perfmon_remove_counterno sensitive capability
  • phone_packet_capture_enableno sensitive capability
  • restart_serviceno sensitive capability
  • sdl_trace_call_flowno sensitive capability
  • sdl_trace_parseno sensitive capability
  • select_cm_deviceno sensitive capability
  • select_cm_device_allno sensitive capability
  • select_cm_device_by_ipno sensitive capability
  • select_cti_itemno sensitive capability
  • select_cti_tracesno sensitive capability
  • select_curri_logsno sensitive capability
  • select_logsno sensitive capability
  • select_logs_clusterno sensitive capability
  • select_logs_minutesno sensitive capability
  • select_sip_tracesno sensitive capability
  • select_syslog_minutesno sensitive capability
  • set_trace_levelno sensitive capability
  • show_network_clusterno sensitive capability
  • show_network_eth0no sensitive capability
  • show_statusno sensitive capability
  • show_versionno sensitive capability
  • start_serviceno sensitive capability
  • stop_serviceno sensitive capability

What this scan could not see

Versions 1

Scan history per published version. The engine is deterministic — the same version always yields the same score, so a changed score means the package itself changed.

VersionScoreFindingsEngineScanned
v0.7.1 latest A 93/100 1 1.13.0 2026-09-07

Embed this score

Show this server's live Trust Score in your README, docs or website. The badge is served straight from the registry and updates automatically after every rescan — no API key needed. It links back to this page, so anyone who sees the grade can also read the findings behind it instead of taking a number on faith.

MCP Trust Score: A · 93/100
Markdown (GitHub README)
[![MCP Trust Score](https://mcptrustchecker.com/registry/calltelemetry-cisco-cucm-mcp/badge.svg)](https://mcptrustchecker.com/registry/calltelemetry-cisco-cucm-mcp)
HTML
<a href="https://mcptrustchecker.com/registry/calltelemetry-cisco-cucm-mcp"><img src="https://mcptrustchecker.com/registry/calltelemetry-cisco-cucm-mcp/badge.svg" alt="MCP Trust Score" height="20"></a>
Prefer shields.io styling? Point it at https://mcptrustchecker.com/registry/calltelemetry-cisco-cucm-mcp/badge.json via https://img.shields.io/endpoint?url=…

Verify this score yourself

The score above is reproducible: the same package version always yields the same result. Run it locally or over the free API — no account, no LLM, fully deterministic.

npx mcptrustchecker scan @calltelemetry/cisco-cucm-mcp --online

Use the free API → How scoring works

More in Cloud & DevOps