User request
    ↓
MCP client (for example, Codex)
    ↓
nexus_list_operations / nexus_describe_operation
    ↓
OpenAPI registry selects a documented operation
    ↓
nexus_read or prepare/apply change workflow
    ↓
Nexus client builds the URL, parameters, body, and authentication headers
    ↓
Nexus Dashboard Infrastructure or Manage API
    ↓
Structured result returned to the MCP client

Operation ID: getClusterStatus
Method:       GET
Path:         /cluster/status

https://YOUR-DASHBOARD/api/v1/infra/cluster/status

ND-External-MCP/
├── .gitignore
├── README.md
├── nexus-dashboard.env.example     # Safe configuration template
├── run_server.py                    # Loads local settings and starts the server
├── pyproject.toml
├── setup.py
├── src/
│   └── nexus_dashboard_mcp/
│       ├── __init__.py
│       ├── server.py                # MCP protocol and tool definitions
│       ├── openapi_registry.py      # Loads/searches OpenAPI operations
│       ├── client.py                # Authentication, HTTP, validation, safety
│       └── specs/
│           ├── nexus_dashboard_infrastructure_v_1_1_1_136.json
│           └── nexus_dashboard_manage_v_1_1_1_411.json
└── tests/
    └── test_server.py

git clone https://github.com/YOUR-ACCOUNT/ND-External-MCP.git
cd ND-External-MCP

cp nexus-dashboard.env.example nexus-dashboard.env

NEXUS_DASHBOARD_URL=https://nd.example.com

NEXUS_API_TOKEN=
NEXUS_USERNAME=your-username
NEXUS_PASSWORD=your-password

NEXUS_API_TOKEN=paste-your-bearer-jwt-here

NEXUS_AUTH_COOKIE=paste-your-authcookie-value-here

NEXUS_INSECURE_TLS=true

[mcp_servers.nexus_dashboard]
command = "python3"
args = ["/ABSOLUTE/PATH/TO/ND-External-MCP/run_server.py"]
startup_timeout_sec = 30

{
  "mcpServers": {
    "nexus-dashboard": {
      "command": "python3",
      "args": ["/ABSOLUTE/PATH/TO/ND-External-MCP/run_server.py"]
    }
  }
}

Use Nexus Dashboard to get the cluster status.

Create a network in fabric1.

Operation ID: manage:createNetworks
Method:       POST
Path:         /fabrics/{fabricName}/networks

Using Nexus Dashboard, examine <target> for <purpose>.
Collect <specific data> using read-only operations.
Do not make configuration changes.
Summarize the result as <table/checklist/report>, and identify missing or unavailable data.

Use Nexus Dashboard to get the current cluster status. Summarize the overall
state, every node, firmware versions, bootstrap state, incomplete stages, and
failed tasks. Use read-only operations only.

Create a read-only Nexus Dashboard platform health report. Include cluster
status, configured nodes, software version, integration summary, licensing
status, backup status, and recent audit records. Separate healthy, warning,
failed, and unavailable checks.

Check whether the Nexus Dashboard cluster is ready for troubleshooting work.
Verify that nodes are active and core infrastructure services completed. Show
the API evidence supporting each conclusion.

List every fabric known to Nexus Dashboard. Return a table with fabric name,
type, status, and important summary fields. Highlight fabrics that are not
healthy or have incomplete information. Do not make changes.

Compare all fabrics using fabric summary, switch summary, interface summary,
inventory summary, segmentation summary, and policy summary. Rank the fabrics
that need investigation, and explain the evidence without changing anything.

Build a complete read-only operational profile for fabric <FABRIC>. Include:
- fabric status and summary;
- switch inventory and switch states;
- interface overview;
- physical and logical links;
- configured networks and VRFs;
- segmentation and policy summaries;
- traffic categories;
- cluster flow-collection settings;
- switches and interfaces eligible for flow telemetry;
- relevant flow-telemetry VRF, tenant, and L3Out information;
- recent fabric audit records.

Return an executive summary followed by detailed tables. Clearly label any
requested data that the bundled APIs cannot provide. Do not make changes.

Investigate fabric <FABRIC> as if it has an intermittent traffic problem.
Collect fabric status, switches, interface overview, links, networks, VRFs,
traffic categories, flow-collection settings, and available flow-telemetry
configuration. Identify suspicious gaps and propose the next read-only checks.
Do not apply remediation.

For fabric <FABRIC>, show the current traffic categories and explain their
configuration. Also list switches that support interface flow telemetry and
show the available telemetry interfaces. Use read-only operations only.

For ACI fabric <FABRIC>, inventory the flow-telemetry scope: supported switches,
interfaces, tenants, VRFs, L3Outs, and encapsulations available through the
Manage API. Summarize what is configured versus merely eligible.

Get the Nexus Dashboard cluster flow-collection settings and compare them with
the flow-telemetry capabilities exposed for fabric <FABRIC>. Identify obvious
configuration gaps, but do not change the settings.

Collect a troubleshooting bundle for switch <SWITCH_ID> in fabric <FABRIC>.
Include fabric status, switch details, expected-versus-running configuration
diff, pending configuration, deployment history, interfaces, and interface
overview. Summarize likely issues and do not make changes.

For interface <INTERFACE> on switch <SWITCH_ID> in fabric <FABRIC>, retrieve
interface details and the single-interface configuration difference. Explain
the intended configuration, running difference, and safest next step.

Show every switch in fabric <FABRIC>, including its role and status. Then inspect
only switches with unhealthy or incomplete state and summarize the evidence.
Do not execute CLI commands or configuration changes without asking me first.

For fabric <FABRIC>, list all networks and VRFs. Show network-to-VRF relationships,
VLAN IDs, network status, gateway information when returned, and any obvious
duplicates or missing relationships. Use read-only operations only.

Produce a segmentation review for fabric <FABRIC>. Include networks, VRFs,
segmentation resource summary, security groups, security contracts, and policy
summary. Identify potential capacity or consistency concerns without changing
configuration.

List the physical and logical links associated with fabric <FABRIC>. Correlate
them with the fabric switch inventory and identify links whose endpoints cannot
be matched to known switches. Do not make changes.

For switch <SWITCH_ID> in fabric <FABRIC>, compare expected and running
configuration, show pending configuration and deployment history, and explain
each drift item. Recommend a remediation plan but do not reconcile or deploy it.

Retrieve recent audit records for fabric <FABRIC>. Summarize who changed what,
the affected resources, timestamps, and failed operations. Do not expose tokens,
passwords, cookies, or other sensitive values in the response.

Find all read-only API operations related to configuration compliance,
deployment history, pending configuration, preview, and audit. Explain which
operation you would use for each troubleshooting stage before calling them.

Search the Nexus Dashboard API catalogue for read-only operations related to
<TOPIC>. Return operation ID, service, HTTP method, path, required parameters,
and a plain-language explanation. Do not call the operations yet.

Describe operation <OPERATION_ID>. Explain every path parameter, query parameter,
required JSON field, and enum in plain language. Provide a safe example payload
using placeholders, not real credentials or production values.

I want to implement this intended state in fabric <FABRIC>:
<DESCRIBE_INTENT>

Act as a change planner. First collect the current state using read-only APIs.
Then discover and describe the relevant write operations, identify every missing
input, check for conflicts, and propose an ordered implementation and rollback
plan. Do not prepare or apply any change until I approve the plan.

Plan a change for incident/change ticket <TICKET>. Compare current and intended
state, list the exact Nexus Dashboard operations that would be required, classify
their risk, state whether each operation is disruptive, and define verification
and rollback steps. This is planning only—do not prepare or apply requests.

Guide me through creating network <NETWORK> in fabric <FABRIC> with VLAN <VLAN>,
VRF <VRF>, subnet <SUBNET>, and gateway <GATEWAY>.

First read the existing fabric, VRFs, networks, and unused VLANs. Check for name,
VLAN, subnet, and VRF conflicts. Then describe the createNetworks request body
and propose an ordered plan covering creation, attachment, preview, deployment,
verification, and rollback. Do not prepare or apply anything yet.

Prepare the approved network-creation request for ticket <TICKET>. Show me the
exact operation, URL, masked JSON body, fingerprint, and change_id. Do not call
nexus_apply_change yet.

Apply only change_id <CHANGE_ID> using the configured approval code. Do not apply
any additional attachment or deployment operation. Return the complete API
status and then verify the network with a separate read-only request.

Now read the network and current attachments. Plan and prepare the attachment
of network <NETWORK> to switches/interfaces <TARGETS>. Stop after the preview.

Preview the pending network configuration for <NETWORK> in fabric <FABRIC>.
Explain the expected device changes and risks. If the preview is clean, prepare
the network deployment request but do not apply it.

Plan a new VRF <VRF> and network <NETWORK> in fabric <FABRIC>. Read existing VRFs,
networks, segmentation capacity, and unused VLANs. Determine the dependency
order, describe createVrfs and createNetworks, and produce a rollback plan.
Do not prepare or apply changes until I approve the plan.

Prepare only the VRF creation for ticket <TICKET>. Stop after returning the
masked preview and change_id. The network must remain out of scope until the VRF
is verified with a read-only call.

I intend to change interface <INTERFACE> on switch <SWITCH_ID> in fabric <FABRIC>
to <DESIRED_STATE>. Read the current interface, switch configuration diff, and
pending configuration. Describe the updateInterface schema, plan preview and
deployment, and stop before preparing any change.

Prepare the approved interface change for ticket <TICKET>. Do not deploy it.
After I review the change_id, separately preview the interface configuration
difference, and require another explicit approval before interface deployment.

Investigate configuration drift on switch <SWITCH_ID> in fabric <FABRIC>. Show
the diff, inline diff, pending configuration, and deployment history. Explain
whether reconciliation would overwrite intentional device-side changes. Produce
a remediation and rollback plan, but do not reconcile or deploy anything.

Prepare configuration-drift reconciliation for switch <SWITCH_ID> under ticket
<TICKET>. Return the preview and change_id only. Treat deployment as a separate
change requiring separate approval.

Investigate telemetry configuration for fabric <FABRIC>. Read cluster flow
collection settings and fabric telemetry capability/configuration. Determine
whether resync or retry is appropriate, explain the difference, and produce a
plan. Do not call telemetryResync, resyncTelemetryConfig, or retryTelemetryConfig.

Prepare only the approved telemetry resync for fabric <FABRIC> under ticket
<TICKET>. Show the exact target list and masked request. Do not apply it until I
approve the returned change_id.

Return a short executive summary, an evidence table with operation IDs, a list
of risks ranked by severity, and recommended next read-only checks.

Separate confirmed facts from inferences. For every inference, identify the API
fields that support it. Mark unavailable data explicitly.

Compare the current result with the intended state I provided. Do not assume a
missing field is healthy, and do not recommend a write operation without first
describing its schema and rollback implications.

NEXUS_WRITE_ENABLED=true
NEXUS_WRITE_CONFIRMATION=a-private-user-controlled-approval-code

NEXUS_ALLOW_DISRUPTIVE=true

nexus_dashboard_infrastructure_v_1_1_1_136.json
nexus_dashboard_manage_v_1_1_1_411.json

NEXUS_OPENAPI_SPECS_DIR=/absolute/path/to/specs

python3 -m unittest discover -s tests -v