NetClaw and Equinix Fabric: giving an investigation its provider-side evidence

Equinix's September 24 announcement adds Network Edge visibility to the Fabric MCP server. The announcement gave NetClaw another useful source of evidence: the provider side of a path that may also cross a cloud, a virtual router and an enterprise network.

Consider a request: "Our cloud path is congested. Find the constraint, propose a change, and carry it out once approved." A device showing a healthy interface cannot answer the whole question. NetClaw can ask an Equinix specialist about the provider resources, a cloud specialist about the far side, and a device specialist about the local handoff. Each keeps its own credentials and supplies scoped evidence to the Border. The investigation joins resource identifiers and timestamps, not merely familiar names.

What's actually in the repo today

NetClaw now ships two skills against a single upstream service, Equinix's official Fabric MCP:

• equinix-fabric-operations — connections, ports, Cloud Routers, routing, filters, service profiles and telemetry. Reads are open; creates, updates and actions require an exact, approved change request.
• equinix-network-edge — Network Edge visibility: list_devices, list_metros, list_device_types, list_accounts, list_acls, list_aclTemplates, list_project. This surface is visibility-only — there is no create_device, update_acl or delete_device to invent, because Equinix hasn't shipped one.

Both skills route through one MCP process (equinix-mcp, scripts/equinix-stdio.py), gated by EQUINIX_ENABLED and, separately, EQUINIX_ALLOW_WRITES. Writes go through a local policy layer (scripts/lib/equinix/policy.py) that computes an exact digest of the tool, its arguments and a baseline ID, and will only execute once that digest matches an externally approved ServiceNow change record. Enabling write mode or granting broad OAuth consent is not the same thing as an approved change — the gate checks the change record itself.

I want to be direct about where this stands: I don't have a live Equinix tenant connected yet. Nothing below is a report of an investigation actually run against production Equinix infrastructure. It's what's configured, what the official MCP documents, and the workflow NetClaw is built to carry out once a real account is behind it.

Three workflows worth demonstrating

Trace an edge ACL association. Find Network Edge devices associated with a particular ACL template, locate their metros, then examine the corresponding Fabric and cloud paths. The answer should distinguish an allowed rule from proven reachability. Device CLI checks stay with the platform that owns that device.

Review and execute a bandwidth change. Read the connection and its dependencies, collect relevant performance evidence, and propose a target bandwidth with costs, impact and verification. Prepare the exact MCP call and bind its digest to a human-approved ServiceNow change. Execute only in Implement, then re-read provider state and measure the path again. The interesting result is a defensible change record, not just a successful API response.

Investigate apparent redundancy. Compare provider connections and routers with cloud and local routing evidence. Two named connections do not prove independent failure domains. Report what is known, what needs confirmation, and what simulation predicts. Turn that evidence into a sourced diagram or review document using NetClaw's existing visualization and document skills.

Operations with an approval boundary

This integration goes beyond reads, and that's exactly where NetClaw adds its own gate on top of Equinix's. An observed baseline and an exact call digest bind execution to the approved change; an unapproved record, a blocking incident, or an unavailable audit trail stops the write. There are real limits worth stating plainly: the official Fabric MCP exposes no delete tools, and the Network Edge tools are visibility, not device CRUD. A plan must not promise rollback the tools can't perform, and provisioning needs read-back verification — an ambiguous timeout must never trigger another billed create.

The outcome I want to demonstrate, once this is running against a real tenant, is a coherent chain: scoped evidence, a reviewed proposal, externally approved execution, fresh verification, and an audit trail. The MCP supplies the provider interface. NetClaw's skills and specialist members supply the operational workflow around it.

Try it

Set EQUINIX_ENABLED=true to bring the two skills into your catalog; leave EQUINIX_ALLOW_WRITES at its default false until you've reviewed the CR-gating in scripts/lib/equinix/policy.py for your own environment. Details and the full tool catalog are in the NetClaw repository.

Have a real Equinix tenant and want to help verify this against it? That's exactly the next step, and I'd welcome the help — bring it to the contribution guide.