Return authoritative metadata about the Netmiko MCP server and its inventory.

MANDATORY — call this tool FIRST on EVERY user message that mentions, asks about, or relates to network devices, routers, switches, firewalls, show commands, device inventory or device groups, before any other netmiko tool and before answering from memory, system prompt, or RAG/FAQ.

It reports which inventory backend is active (Fedele or the local YAML file) and, for the local file, how old it is. That matters: operating from a stale local inventory can send a command to the wrong box.

This tool does NOT reach any network device. For "is the MCP alive" call netmiko.health_check. To actually query a device, use netmiko.send_show_command.

Returns: str: JSON with version, author, description, inventory, capabilities, command_policy and tool_routing. command_policy is "file" when the operator's allow/deny list is in force and "fallback" when no policy file exists — in that case a warning field says so, only a handful of read-only commands will be accepted, and you must relay that warning to the user instead of treating the denials as device failures.

List the commands this server will accept, and where that policy comes from.

CALL THIS AFTER A REFUSAL, BEFORE RETRYING. A Security Error: Command ... is not permitted means the command is outside the operator's policy. Do not guess a variant and do not abbreviate — read the policy here, pick a command that is actually allowed, and if nothing fits, tell the user which command was refused and what the allow list does cover.

Also useful when the user asks what they can run on this deployment.

ANSWERING "which commands are available for Juniper / Huawei / Cisco": the lists are flat, because the operator writes one policy for the whole estate. Filter it yourself by dialect — you know the CLIs, and device_types_in_inventory tells you which platforms are actually present. show route* and show chassis* are Junos, display * is Huawei VRP and HPE Comware, show ip route is Cisco-style, and show version happens to work on several. Under the fallback, allowed_commands_by_platform already carries that split, verbatim and exact — use it as given instead of re-deriving it. Two rules when you answer:

• Never list a command that is not in allowed_commands. It will be refused.

• Say when the answer is empty: an allow list written for one vendor covers nothing on another, and that is the operator's doing, not a device fault.

policy_source says who wrote the policy in force:

• "file" — the operator's allow/deny list, at command_file.

• "fallback" — no policy file exists on this deployment, so only a small built-in read-only set runs. warning explains it; relay that to the user, because every other refusal follows from it and looks like a device problem otherwise.

How the lists are read (getting this wrong wastes attempts, and every attempt is audited):

• Deny wins over allow, always.

• The allow list does NOT cover abbreviations: show version does not permit sh ver. Send full commands.

• The deny list DOES cover abbreviations of the same word count: a deny on configure also blocks conf.

• * is a glob and only ever appears at the end. cmd* swallows whatever follows; cmd * requires at least one more word and does not match cmd on its own.

• Anything the allow list does not name is denied.

Returns: str: JSON with policy_source, command_file, allowed_commands, denied_commands, their counts, a rules object, device_types_in_inventory, and — only under the fallback — allowed_commands_by_platform and a warning.

Check whether the Netmiko MCP server itself is responsive and correctly configured.

IMPORTANT: If the user message involves network devices, call netmiko.get_metadata FIRST.

This checks the MCP server, NOT any network device and NOT the inventory backend reachability. "¿Está arriba el router X?" is not this tool — that requires actually running a command against the device with netmiko.send_show_command.

Returns: str: JSON with available, version, inventory_backend, credential_source and command_policy ("file" or "fallback"). When command_policy is "fallback" a warning field explains that no policy file exists and only built-in read-only commands run; report that warning to the user.

List every device group defined in the inventory.

IMPORTANT: If the user message involves network devices, call netmiko.get_metadata FIRST.

Groups are what netmiko.send_show_command_to_group accepts. Call this before assuming a group name exists — never invent one.

Returns: str: JSON with groups (list of group-name strings) and count.

List devices from the inventory, without credentials.

IMPORTANT: If the user message involves network devices, call netmiko.get_metadata FIRST.

Use this to discover exact device names before running a command. Device names are the only handle the other tools accept — never pass an IP address or a hostname you inferred.

Connect to one network device over SSH and run a single show command.

IMPORTANT: If the user message involves network devices, call netmiko.get_metadata FIRST.

The command is validated against the operator's allow/deny list before execution. A rejection is NOT a bug and NOT something to work around: report it to the user and say which command was refused. Do not retry with an abbreviation — abbreviations are covered by the deny list, not by the allow list.

SYNTAX IS PER-PLATFORM. Netmiko drives 177 base device_types (416 with variants) from 102 vendors and their CLIs are NOT interchangeable. Check the device's device_type with netmiko.list_devices first and use that platform's syntax: Cisco IOS/Arista/Juniper use show ..., Huawei VRP and HPE Comware use display ..., MikroTik RouterOS uses /system resource print, F5 tmsh uses list/show with its own grammar. Never translate a command from one family to another by analogy, and never probe variants to see which one is accepted — each attempt is audited and may be denied for a different reason.

Run the same show command concurrently on every device of a group.

IMPORTANT: If the user message involves network devices, call netmiko.get_metadata FIRST.

The command is validated once before any connection is opened, so a denied command reaches no device at all. Per-device failures are returned per device: a partial result is normal and must be reported as partial, never summarised as if every device answered.

A GROUP MAY MIX PLATFORMS. The same command string is sent to every member, so a group holding both Cisco IOS and Huawei VRP devices will fail on half of them whatever you send — show version is invalid on VRP, display version is invalid on IOS. Check device_type across the group with netmiko.list_devices first; if the group is heterogeneous, issue one netmiko.send_show_command per platform instead of forcing a single string onto all of them.

List the output files already saved on disk for a device, group, or all devices.

IMPORTANT: If the user message involves network devices, call netmiko.get_metadata FIRST.

Outputs land here when save_output=True was used or when a command exceeded save_threshold. Read them with netmiko.read_device_output.

Read a previously saved output file for one device, with pagination.

IMPORTANT: If the user message involves network devices, call netmiko.get_metadata FIRST.

The response header states the line range and the total line count. When lines remain, a continuation hint gives the offset to use next. Do not report a total based on a page you have not finished reading.

Read the audit trail: what this server was asked to do, and what happened.

Answers questions about PAST activity — "everything done on SW-CORE-01", "the last 6 netmiko actions", "which commands were refused this week", "who touched that switch and with which credential". It reads the audit records only; it never opens a connection and never returns device output.

Every argument is a filter, combined with AND. Leave one empty to not filter on it. Translate what the user asked into these arguments — do not ask for everything and sift through it.

The audit trail rotates daily and this reads the rotated files too, but only what is still on disk. files_scanned and oldest_available in the response say how far back the answer actually reaches: if the period the user asked about is older than that, say so instead of reporting "nothing happened".

matched is how many records satisfied the filters; returned is how many came back in this call. When they differ, the response is one page — never report returned as a total.

Calling this tool writes a tool_invocation record of its own — reading the trail is itself auditable — but those records are hidden from the results by default, so "the last 6 actions" is about the network and not about your own questions. audit_queries_hidden says how many were left out.