Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.equinix.dev/llms.txt

Use this file to discover all available pages before exploring further.

The catalog wraps two real Equinix MCP servers and one preview surface. This page lists every tool a package may expose, classified by mode.
Tool inventories below come from the Equinix MCP product docs at docs.equinix.com/equinix-api/mcp-servers/overview/. The classifications (read vs mutating) are part of the package-anatomy contract — they’re how mcp.json declares which tools require a confirmation envelope.

​
Servers

Fabric MCP

https://mcp.equinix.com/fabric — Cloud Router, Connection, Network, Port, Service Profile, Service Token, Streams.

Peering Insights MCP

https://mcp.equinix.com/peeringInsights — Equinix Internet Exchange and peering workflows.

Agent Factory

github.com/equinix/agent-factory — preview agent definitions, not a hosted MCP server.

​
Read tools

Read tools run freely. They never require a confirmation envelope.
  • search_router — list routers in a project / metro
  • get_router_package — load a single router’s package
  • search_routes — query route advertisements
  • search_connection — list connections by metro and provider
  • get_connection — fetch a single connection
  • search_service_profiles — find service profiles by category
  • search_network — list Fabric networks
  • search_port — list ports by metro
  • get_port_capacity — read port capacity headroom
  • search_stream — list telemetry streams
  • get_stream_attachment — fetch an attachment
  • search_stream_alert_rule — list alert rules
  • search_metros — list available metros
  • search_service_profiles — find provider service profiles

​
Mutating tools

Every mutating tool is gated. The agent never receives a tool result directly — it receives a confirmation envelope.
The envelope is the only response shape until all blocked_by items resolve and a human confirms. equinix.dev surfaces mutating calls in the Approve stage.
{
  "tool": "equinix_fabric_create_cloud_router",
  "mode": "mutating",
  "requires_confirmation": true,
  "blocked_by": [
    "official_quote_missing",
    "developer_app_missing",
    "account_assets_missing"
  ]
}
  • create_router — provisions a new Cloud Router
  • update_router — mutates package, BGP, or routing policy
  • create_router_commands — runs operational commands
  • load_routes — pushes route filters and aggregations
  • create_connection — provisions a new Fabric Connection
  • update_connection — mutates bandwidth, peering, etc.
  • delete_connection — tears down a connection
  • create_network, update_network, delete_network
  • create_stream, update_stream, create_subscription
  • create_service_token, revoke_service_token

​
Mutation policy

Every package’s mcp.json declares the policy. Today every package ships with the same value: 
{
  "mcp": {
    "mutation_policy": "blocked_by_default_requires_human_confirmation"
  }
}
This is enforced at the Local Explorer layer (which never executes a mutating call) and re-enforced at the customer-tenant layer (which requires the developer app and the readiness gates to all pass first).
A reviewer auditing this contract should grep the catalog for "mutation_policy" and verify the value is blocked_by_default_* for every package. Any other value is a violation.

​
Where to add a new MCP tool

If a new mutating tool ships in the upstream Equinix MCP server:
1

Add the tool to the package's mcp.json

Append to either read_tools or mutating_tools. Decide based on whether the tool causes a state change.
2

Update the tool inventory here

Add it under the appropriate accordion above. Include the one-line description from the upstream docs.
3

Run the catalog smoke tests

equinix-dev catalog --smoke verifies every package’s mcp.json parses and every listed tool resolves against the documented Equinix MCP surface.