For AI agents and assistants
Bring your own AI.
Witina AI speaks MCP. Connect Claude, ChatGPT, or an agent you wrote yourself to your live network — real running config, real topology, real incidents — and let it draft changes it isn't allowed to run.
https://app.witinaai.com/mcp
Your AI, not ours
No model of ours reads your network. You connect the assistant you already trust, under your own account with it.
Ground truth, not guesses
Running config, interfaces, VLANs, MAC tables, routes, spanning tree, LLDP neighbours — the same collected state the product runs on.
It can't push config
Two of the nine tools write, and both write into a draft change management. A person reviews it and runs it.
The problem
Your team is already asking an AI about your network.
They paste a config fragment into a chat window and ask what's wrong with it. The model does its best with a screenshot's worth of context: it can't see what's on port 12, which VLANs actually exist on that switch, where the spanning-tree root moved to last Tuesday, or whether the device has been answering polls at all this week. So it produces something plausible, and a human has to work out whether plausible is true.
The missing piece was never a smarter model. It was giving the model the facts — and a way to act on them that a network team would actually sign off on.
Four things that stay true.
Handing an AI a connection to live network gear is a security decision before it's a productivity one. So these are constraints in the architecture, not settings you have to remember to turn on.
It reads the truth, not a screenshot
The agent gets the state the platform already collected — running config and its history, interfaces, VLANs, the MAC forwarding table, routes, spanning tree, LLDP neighbours, wireless. Reads are passive: nothing is probed on demand, so pointing an AI at your network can't put load on it. Every answer carries a timestamp, so the agent can tell fresh state from stale.
It can never do more than you can
An agent's permissions are the role you granted it, intersected with your own permissions, in the one context you pinned it to. That intersection is recomputed on every single request — so the moment you lose a permission, the agent loses it too. It cannot outlive or outrank the person who authorized it.
It proposes; you execute
What an agent produces is a draft change management — the same reviewed, approved, snapshotted, roll-back-able object a human change goes through. It does not execute. Execution is a separate permission that most agents are never granted, and every action records that an agent was behind it, so the audit trail always distinguishes the AI from the person.
It's your AI, not ours
There's no model of ours in this path and no network data leaving for one. Our own alerting stays deliberately deterministic — named rules you can reason about, not a model guessing. The judgement is your assistant's, the facts are ours, and the line between them is one you can see.
The tool surface
Nine tools. Here's all of them.
Not a teaser — this is the complete surface an agent sees when it connects. The full JSON schemas are published too, so you can hand them to your own AI before you connect anything.
01
Orient
Work out what it is allowed to do before it does anything.
- whoami
- Its own identity and the effective permissions it holds in this context.
- describe
- A resource type's fields and filters — so it queries from documentation, not from guesses.
02
Read the network
Inventory first, then drill into anything that looks interesting.
- list_resources
- Devices, gateways, incidents and change managements as compact summaries, filtered and capped.
- get_resource
- Full detail on one of them, permission-checked against that specific record.
03
Read the device
Eleven aspects of observed state, through one tool.
- get_device_state
- overview, config, config_history, interfaces, vlans, mac_table, routes, stp, neighbors, wireless, monitoring.
04
Diagnose
Answer the question the ticket actually asked.
- check_connectivity
- "Why can't A reach B?" — per-hop link, VLAN, STP and routing checks against collected state, with a verdict and its stated limits.
05
Propose
Only two tools in the whole surface write, and both write into a draft.
- create_change_management
- Opens a draft change. It does not execute.
- list_cm_task_catalog
- The operations that device's vendor profile actually supports — so the agent picks a real one instead of inventing a command.
- add_cm_task
- Adds a device operation to the draft, ready for a human to review and run.
Want the schemas, not the summary?
The exact tools/list response — every
input and output JSON Schema — is published as a static file, along with a
written explanation of the authorization model.
Connecting takes about a minute.
There's no API key to mint, copy, or leak. The client registers itself and you approve it in the browser, signed in as you.
-
01
Point your client at the endpoint
Any MCP client that speaks OAuth discovers everything it needs from the URL and registers itself. Nothing for you to provision, and a registered client has no access at all until step two.
-
02
Approve it, as you
You sign in and choose two things: which context the agent may see — one organization or division — and whether it may only read and plan, or also execute. Most agents get read and plan.
-
03
It stays scoped, live
From then on every request re-checks the agent's permissions against yours and against the specific record it's touching. Revoke it whenever you like, from the console.
# the whole configuration
$ https://app.witinaai.com/mcp
# everything else — client registration, consent,
# token issue and renewal — is standard OAuth 2.1.
Authorization
An agent is not a user, and not an API key.
It connects as a service principal: its own identity, pinned to one context, that consumes no seat and shows up distinctly in the audit trail. It authenticates with a short-lived opaque token — stored hashed, bound to the specific resource it was issued for, and renewed by a rotating refresh token whose reuse is detected and punished.
But the token is not where its authority comes from. Permissions are resolved from the database on every request, through the same access-control engine the web console uses — never a second, parallel path that could drift from it.
Any one of these drops it to zero permissions
- You revoke the agent.
- You change your own password — every agent you authorized dies with the old credential.
- You lose access to the organization.
- The request arrives for a context the agent was not pinned to.
Note the second one. Rotating your own password is a kill switch for every AI agent you have ever authorized — no console visit required, and nothing to remember when someone leaves.
This whole site has a machine-readable twin.
If you're evaluating us with an AI in the loop — and you should be — don't make it scrape our marketing pages. Everything we claim is published as plain Markdown, written to be read by a model: what the product does, how it's built, what it costs, and where the edges are.
Start at /llms.txt, which indexes the rest.
# the index
# the corpus
# the comparisons
# the tool schemas
Watch an agent read your network and hand back a change.
Book a demo and we'll connect an assistant to a live network, ask it something hard, and let it show its work — including the part where it can't press go.