MCP-Telecom
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_TELECOM_DEVICES_FILE | No | Path to the devices YAML configuration file. Defaults to 'devices.yaml' in the current working directory. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| show_bgp_summaryA | Show BGP neighbor summary on a network device. Returns the BGP peering table with neighbor states, prefixes received, and session uptime. Works across all supported vendors. Args: device: Name of the device as defined in devices.yaml |
| show_bgp_neighborsA | Show detailed BGP neighbor information on a network device. Returns per-neighbor details including state, AS number, messages sent/received, and hold time. Args: device: Name of the device as defined in devices.yaml |
| show_routing_tableA | Show the IP routing table on a network device. Returns all routes with protocol, next-hop, metric, and preference. Args: device: Name of the device as defined in devices.yaml |
| show_ospf_neighborsA | Show OSPF neighbor adjacencies on a network device. Returns OSPF neighbor states, interface associations, and dead intervals. Args: device: Name of the device as defined in devices.yaml |
| show_mpls_lspA | Show MPLS Label Switched Paths on a network device. Returns LSP status, tunnel endpoints, and label bindings. Args: device: Name of the device as defined in devices.yaml |
| show_interfacesA | Show interface status summary on a network device. Returns all interfaces with admin/operational status, speed, and description. Args: device: Name of the device as defined in devices.yaml |
| show_interface_detailA | Show detailed statistics for a specific interface. Returns counters, errors, CRC, drops, utilization, MTU, and speed for the specified interface. Args: device: Name of the device as defined in devices.yaml interface: Interface name (e.g., 'Gi0/0/0', '1/1/1', 'ge-0/0/0') |
| show_lldp_neighborsA | Show LLDP neighbor discovery information. Returns connected neighbors with their system name, port ID, and capabilities — useful for topology discovery. Args: device: Name of the device as defined in devices.yaml |
| show_lag_statusB | Show Link Aggregation Group (LAG/Port-Channel/Bundle) status. Returns LAG member ports, their states, and aggregate bandwidth. Args: device: Name of the device as defined in devices.yaml |
| show_arp_tableA | Show the ARP table on a network device. Returns IP-to-MAC address mappings for all entries in the ARP cache. Args: device: Name of the device as defined in devices.yaml |
| show_mac_tableB | Show the MAC address table on a network device. Returns MAC addresses, VLANs, and associated interfaces. Args: device: Name of the device as defined in devices.yaml |
| show_system_infoA | Show system information including version, uptime, and hardware. Returns device platform, software version, uptime, serial number, and hardware details. Args: device: Name of the device as defined in devices.yaml |
| show_alarmsA | Show active alarms and alerts on a network device. Returns current alarm conditions including severity, timestamp, and description. Args: device: Name of the device as defined in devices.yaml |
| show_ntp_statusA | Show NTP synchronization status on a network device. Returns NTP peers, stratum, offset, and synchronization state. Args: device: Name of the device as defined in devices.yaml |
| show_cpuB | Show CPU utilization on a network device. Returns CPU usage per core/process to identify resource bottlenecks. Args: device: Name of the device as defined in devices.yaml |
| show_memoryB | Show memory utilization on a network device. Returns memory pool usage, free/used/total memory statistics. Args: device: Name of the device as defined in devices.yaml |
| show_environmentA | Show environmental monitoring on a network device. Returns power supply, fan, and temperature sensor readings. Args: device: Name of the device as defined in devices.yaml |
| show_log_eventsA | Show recent log/syslog messages from a network device. Returns the most recent event log entries for troubleshooting. Args: device: Name of the device as defined in devices.yaml |
| backup_configA | Backup the running configuration of a network device. Fetches the full running config and saves a timestamped copy locally. Returns the configuration content and the backup file path. Args: device: Name of the device as defined in devices.yaml |
| compare_configsA | Compare the current running config with a previous backup. Performs a diff between the live running configuration and a saved backup file, highlighting additions and removals. Args: device: Name of the device as defined in devices.yaml backup_file: Path to the backup file to compare against |
| run_commandA | Run any read-only (show) command on a network device. For safety, only read-only commands are permitted. Configuration commands are blocked. Use this when you need a specific command not covered by the dedicated tools. Args: device: Name of the device as defined in devices.yaml command: The CLI command to execute (must start with 'show', 'display', 'ping', or 'traceroute') |
| run_vendor_operationA | Run a named operation using the vendor-specific command mapping. This automatically translates the operation name to the correct CLI command for the device's vendor. Use 'list_device_capabilities' to see available operations. Args: device: Name of the device as defined in devices.yaml operation: Operation name (e.g., 'bgp_summary', 'interfaces', 'alarms') |
| list_devicesA | List all configured network devices. Returns the names, hosts, vendors, and ports of all devices available for interaction. |
| list_device_capabilitiesA | List all supported operations for a specific device. Shows what commands are available for this device based on its vendor type. Use the operation names with the 'run_vendor_operation' tool. Args: device: Name of the device as defined in devices.yaml |
| health_checkA | Check reachability and response time for devices. Tests SSH connectivity and measures response time. If no device is specified, checks all configured devices. Args: device: Optional device name. If omitted, checks all devices. |
| get_audit_logA | Retrieve recent entries from the command audit log. Shows what commands have been executed, when, on which device, and whether they succeeded. Args: count: Number of recent entries to retrieve (default: 25) |
| show_nokia_servicesB | Show Nokia SR OS service summary (VPRN, VPLS, SAP). Nokia-specific tool for viewing all configured services. Only works on Nokia SR OS devices. Args: device: Name of a Nokia SR OS device |
| netconf_get_configA | Retrieve device configuration via NETCONF (structured XML/YANG). Uses NETCONF protocol instead of SSH CLI scraping. Returns structured XML data. Requires ncclient: pip install mcp-telecom[netconf] Args: device: Name of the device as defined in devices.yaml source: Config datastore — 'running', 'candidate', or 'startup' |
| netconf_get_operationalB | Retrieve operational state via NETCONF using YANG models. Uses pre-defined YANG filters for common operations. Supported operations: system_info, interfaces, bgp_summary, routing_table. Args: device: Name of the device as defined in devices.yaml operation: YANG operation (e.g. 'system_info', 'interfaces') |
| netconf_capabilitiesB | List NETCONF/YANG capabilities advertised by a device. Shows all YANG modules the device supports, useful for understanding what structured data you can retrieve. Args: device: Name of the device as defined in devices.yaml |
| telemetry_subscribeA | Start a gNMI streaming telemetry subscription for a device. Subscribes to OpenConfig telemetry paths and caches the latest values for querying. Use telemetry_query to read collected data. Args: device: Name of the device as defined in devices.yaml paths: Comma-separated telemetry path names or OpenConfig paths interval_ms: Collection interval in milliseconds (default: 10000) |
| telemetry_queryA | Query the latest telemetry data collected for a device. Returns the most recent values for all subscribed telemetry paths. Start a subscription first with telemetry_subscribe. Args: device: Name of the device as defined in devices.yaml |
| telemetry_historyB | Get historical telemetry values for trend analysis. Returns time-series data for a specific telemetry path on a device. Args: device: Name of the device as defined in devices.yaml path: Telemetry path name (e.g. 'interface_counters') count: Number of historical data points (default: 20) |
| telemetry_list_subscriptionsA | List all active telemetry subscriptions. |
| telemetry_unsubscribeC | Stop a telemetry subscription for a device. Args: device: Name of the device to stop collecting from |
| telemetry_list_pathsA | List all pre-defined telemetry path shortcuts. Shows the available shortcut names and their corresponding OpenConfig YANG paths for use with telemetry_subscribe. |
| discover_topologyA | Discover network topology by collecting LLDP data from all devices. Connects to each configured device (or specified subset), collects LLDP neighbor information, and builds a topology map showing how devices are interconnected. Args: devices: Comma-separated device names. Empty = all devices. |
| show_topologyA | Show the discovered network topology as an ASCII diagram. Displays all discovered devices and their interconnections. Run discover_topology first to collect data. |
| show_topology_jsonA | Export the network topology as JSON. Returns the topology in structured JSON format for programmatic use or integration with visualization tools. |
| show_topology_mermaidA | Export the network topology as a Mermaid diagram. Returns Mermaid-formatted graph that can be rendered in Markdown, GitHub, or documentation tools. |
| find_pathA | Find the shortest path between two devices in the topology. Uses BFS on the LLDP-discovered topology to find the shortest path between two network devices. Args: source: Source device name target: Target device name |
| show_device_neighborsB | Show all discovered neighbors for a specific device. Lists every direct connection found via LLDP/CDP for the device. Args: device: Name of the device |
| snmp_getA | Poll SNMP OIDs from a network device. Retrieves specific SNMP MIB values. Accepts OID names or dotted notation. Requires pysnmp: pip install mcp-telecom[snmp] Args: device: Name of the device as defined in devices.yaml oids: Comma-separated OID names or numbers community: SNMPv2c community string (default: public) |
| snmp_walkA | Walk an SNMP MIB subtree on a network device. Retrieves all OIDs under the specified base OID. Useful for interface tables, routing tables, etc. Args: device: Name of the device as defined in devices.yaml base_oid: Base OID to walk (default: IF-MIB ifTable) community: SNMPv2c community string |
| snmp_device_overviewA | Get a quick SNMP-based overview of a device. Polls system MIB, interface counts, and uptime in a single request. Args: device: Name of the device as defined in devices.yaml community: SNMPv2c community string |
| parallel_commandA | Run a read-only command on multiple devices simultaneously. Executes the same CLI command across all (or specified) devices in parallel using a thread pool. Much faster than querying one-by-one. Args: command: CLI command to run (must be read-only) devices: Comma-separated device names. Empty = all devices. max_workers: Max concurrent threads (default: 10) |
| parallel_operationA | Run a vendor-mapped operation on multiple devices simultaneously. Translates the operation name to the correct vendor CLI command for each device and runs them all in parallel. Args: operation: Operation name (e.g. 'bgp_summary', 'interfaces') devices: Comma-separated device names. Empty = all devices. max_workers: Max concurrent threads (default: 10) |
| compare_devicesA | Compare command output across multiple devices. Runs the same operation on multiple devices and highlights differences. Useful for finding configuration drift or inconsistencies. Args: operation: Operation name (e.g. 'system_info', 'ntp_status') devices: Comma-separated device names. Empty = all devices. |
| parallel_health_checkA | Health-check multiple devices in parallel. Tests SSH reachability and response time for all specified devices simultaneously. Much faster than sequential health checks. Args: devices: Comma-separated device names. Empty = all devices. |
| compliance_checkA | Check a device's running config against security best practices. Evaluates the running configuration against 20+ compliance rules covering NTP, SSH, SNMP, AAA, passwords, and more. Returns a scored report with pass/fail per rule and remediation advice. Args: device: Name of the device as defined in devices.yaml |
| compliance_check_ruleA | Check a specific compliance rule against a device. Args: device: Name of the device as defined in devices.yaml rule_name: Name of the compliance rule to check |
| compliance_list_rulesA | List all available compliance rules and their descriptions. |
| pool_statsA | Show connection pool statistics. Returns counts of active, idle, and total persistent SSH connections per device. Useful for monitoring connection reuse. |
| clab_generateB | Generate a Containerlab topology for lab testing. Creates a containerlab YAML topology file that mirrors your production device inventory, or uses a pre-built test scenario. Args: scenario: Test scenario — 'basic', 'mpls_core', 'datacenter', 'isp_edge', or 'inventory' (uses your devices.yaml) |
| clab_devices_yamlB | Generate a devices.yaml for a Containerlab lab. Creates a MCP-Telecom devices.yaml that connects to the management IPs of a containerlab deployment, so you can instantly start using MCP-Telecom against your lab. Args: scenario: Which lab scenario to generate for |
| clab_scenariosA | List available Containerlab test scenarios. Shows pre-built lab topologies you can deploy for testing MCP-Telecom without production network access. |
| start_dashboardC | Get instructions to start the web dashboard. The dashboard provides a real-time view of all device statuses with auto-refreshing device cards. Requires: pip install mcp-telecom[dashboard] Args: port: HTTP port for the dashboard (default: 8080) |
| start_metrics_endpointA | Get instructions to start the Prometheus metrics exporter. Exposes /metrics endpoint for Grafana dashboards. Tracks device reachability, command execution counts, and compliance scores. Requires: pip install mcp-telecom[metrics] Args: port: HTTP port for Prometheus metrics (default: 9090) |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| troubleshoot_bgp | Step-by-step BGP troubleshooting workflow for a device. |
| troubleshoot_interface | Step-by-step interface troubleshooting workflow. |
| network_health_audit | Comprehensive network device health audit. |
| compare_device_pair | Compare two devices side-by-side for consistency checks. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| resource_device_inventory | Full inventory of all configured network devices. |
| resource_supported_vendors | List of all supported network equipment vendors. |
| resource_audit_log | Recent command audit log entries. |
| resource_topology | Current network topology in JSON format. |
| resource_compliance_rules | Available compliance rules in JSON format. |
| resource_pool_stats | Connection pool statistics. |
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/Avinash-Amudala/MCP-Telecom'
If you have feedback or need assistance with the MCP directory API, please join our Discord server