oxidized-mcp

Overview Schema Source Related Servers Discussions Admin

List Nodes

list_nodes

Read-onlyIdempotent

Retrieve an inventory of network devices managed by Oxidized, with optional filtering by group, model, status, or name to isolate specific nodes.

Instructions

List nodes (network devices) managed by Oxidized.

Returns each node's name, full name (group/name), IP, group, model, last run status and time, and last run details. Node vars are redacted unless redaction is disabled in the server configuration. Pass a group or model on large installations: they are filtered by Oxidized itself, so only matching nodes are transferred. The group must match exactly; use find_nodes when unsure of the name.

Input Schema

TableJSON Schema

Name	Required	Description
`group`	No	Only nodes in this group - exact, case-sensitive name as shown by list_nodes (e.g. 'core'); 'default' selects nodes without a group
`limit`	No	Maximum nodes to return
`model`	No	Only nodes of this Oxidized model (e.g. 'IOS', 'JunOS', 'RouterOS'); built-in model names are case-insensitive
`offset`	No	Number of matching nodes to skip
`status`	No	Only nodes whose last run had this status (e.g. 'success', 'no_connection', 'fail', 'never')
`name_contains`	No	Only nodes whose name, full name or IP contains this text (case-insensitive)

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 26, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the mutation profile. The description adds meaningful behavioral detail: node vars are redacted unless server redaction is disabled, and filtering is done server-side so only matching nodes are transferred. This goes beyond annotations and helps the agent set expectations.

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 a tight two-sentence paragraph. It front-loads the core purpose and return fields, then delivers usage advice and a pointer to an alternative. Every sentence earns its place; no filler or redundancy.

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 read-only listing tool with an output schema already present, the description covers the return shape, filtering behavior, redaction caveat, and large-installation recommendations. Nothing an agent needs to decide when and how to call it is missing. The combination of schema, annotations, and description is fully self-sufficient.

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 description coverage is 100%, so parameters are already documented. The description enriches semantics by explaining when to pass group/model ('on large installations') and clarifies that group matching is exact and case-sensitive, with 'default' selecting nodes without a group. This practical guidance adds value beyond the 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 starts with a clear verb-resource pair: 'List nodes (network devices) managed by Oxidized.' It then enumerates the exact fields returned (name, full name, IP, group, model, last run status/time, details), making the tool's function unambiguous. It also implicitly distinguishes from siblings by pointing to find_nodes for fuzzy group name lookup.

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?

Explicitly recommends passing group or model filters on large installations and explains why (server-side filtering reduces transfer). It also gives a precise when-not: 'use find_nodes when unsure of the name' for groups, directing the agent to the correct alternative.

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

Deploy Server