Operate from where you already work
Drive ispforge with an AI assistant over MCP, or run day-to-day peering and alerts straight from Slack and Discord — every action through the same risk scoring, approval gates and audit trail as the portal. The AI proposes; a human still approves.
Describe the intent — ispforge does the rest, safely
ispforge runs a Model Context Protocol server with 50+ tools across read, write and lifecycle. Point Claude, Claude Code or any MCP client at it and the assistant can investigate your network and propose changes in plain language — you don't have to remember community values, prefix-list names, or vendor syntax. Every write becomes an intent: risk-scored, previewed as a diff, and gated on approval.
The AI proposes. A human approves. Everything is audited.
An AI-driven change takes exactly the path a human takes through the portal — kicked off in plain language instead of clicks.
Plain language
"Depref my Hetzner peer at edge1.lon by 50."
One MCP verb
Resolved to a single tool call with parameters.
Risk low / med / high
Blast radius and customer impact assessed.
Same gates as the portal
Subnet, RPKI, max-prefix, your approval policy.
Human signs off
Review the real diff; two-person rule optional.
Agent deploys, audited
Commit-confirmed, rollback armed, four audit rows.
The AI can't bypass policy
The intent pipeline runs the same validation an operator hits in the portal. A bad peer IP, an RPKI-invalid origin, a max-prefix out of bounds — refused at validate, never reaching a router. On top of that you scope each assistant:
- Per-key intent allow-list — this assistant may only propose the verbs you permit (e.g. TE overlays, not member invites).
- Blast-radius cap —
max_affected_targetsbounds how many sessions or routers one intent can touch. - Two-person rule — require a different approver from the proposer, enforced for cookie, user-JWT and API-key auth alike.
- Full audit chain — proposer → approver → worker → outcome, one row each, on every change.
Routine work flows; risky work waits for you
Runs immediately
Preview a router, refresh an IRR prefix set, acknowledge or resolve drift, sync from PeeringDB. Self-executes if you allow low-risk auto-approve — no round trip.
Needs a human
Deploy a router, assign a policy, accept or reject a peering request, edit inventory. Proposed, previewed, and held until someone approves.
Customer-affecting
Drain or disable a session, create a peering session. Always requires approval — a depref against a customer is rejected outright.
● MCP access is included on the ISP plan and up
Run peering from the chat you already live in
Native Slack and Discord bots — installed with OAuth in two clicks, no legacy webhooks. They post rich, formatted alerts and link straight to the right page in ispforge. From Discord, accept or decline peering requests on interactive buttons without leaving the channel. Prefer one-way? Telegram and email endpoints too.
Requests, in the channel
Inbound requests arrive with the peer's verified details; accept, decline, or open the request — all from chat. Accepts and declines notify the peer automatically.
Deploys & drift
Deployment success and failure, BGP drift detected, and session state changes land in your NOC channel with a View → link to the exact page.
Wherever your team is
Slack, Discord, Telegram and email endpoints, each installed independently per org. Send a test alert on setup to confirm delivery.
Portal, CLI, AI, or chat — same guardrails
Every path runs through the same intent pipeline and audit trail. Join the beta, wire up an assistant or a chat bot, and drive your network however you like.