Agent access (MCP)¶

Danbyte can answer questions from an AI assistant: "which hosts in this prefix are down, and where are they physically?", "what changed on this device in the last 48 hours?", "which hardware goes end of support next year?". The assistant reaches Danbyte directly, so the correlations that make the data useful - health, location, lifecycle, history - stay together instead of being copy-pasted apart.

It speaks the Model Context Protocol, which Claude Desktop, Claude Code, Cursor and VS Code all support, and it runs entirely on your box. No cloud service, no model shipped by us, nothing sent anywhere.

It is off until you turn it on, like the other integrations. For a chat inside Danbyte instead of your own client, see Ask Danbyte.

Turning it on¶

Settings → Integrations has two switches:

With the first switch off, the endpoint answers "Integration not enabled" and the Agent access page is hidden. Both are per tenant, and both need a tenant admin.

Turning the first one on adds Integrations → Agent access, where you connect a client, set limits and read the call log.

Connecting a client¶

Make an API token first, under Settings → Preferences → API tokens. A read-only token is the right default: it cannot write even if writes are on and the assistant is asked to.

The Agent access page prints the exact snippet for each client with this deployment's own URL. In short:

claude mcp add --transport http danbyte https://danbyte.example.com/api/mcp/ \
  --header "Authorization: Token <your-token>"

{
  "mcpServers": {
    "danbyte": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://danbyte.example.com/api/mcp/",
               "--header", "Authorization: Token <your-token>"]
    }
  }
}

{
  "mcpServers": {
    "danbyte": {
      "url": "https://danbyte.example.com/api/mcp/",
      "headers": { "Authorization": "Token <your-token>" }
    }
  }
}

{
  "servers": {
    "danbyte": {
      "type": "http",
      "url": "https://danbyte.example.com/api/mcp/",
      "headers": { "Authorization": "Token ${input:danbyte_token}" }
    }
  },
  "inputs": [{ "id": "danbyte_token", "type": "promptString",
               "description": "Danbyte API token", "password": true }]
}

Keep the token out of anything you commit. Revoking it cuts the assistant off at once.

What an assistant can do¶

With writes on, five more: create, update, delete, connect and terminate. A delete has to name the object it removes, so a mistaken instruction cannot take the wrong row.

connect cables two ports by their device and port names, and terminate lands a circuit's A or Z end at a site by name. Both exist because the payloads behind them take ids and nested shapes that an assistant gets wrong; naming the things a person would name removes the guesswork, and a wrong port name is answered with the ports the device actually has. A circuit end is named by its circuit and its side ("A" or "Z"), since it has no port name of its own.

What keeps it safe¶

• It is the token's access, not a new one. Every call goes through the same API, serializers, permissions and site scoping as the browser. A site-scoped account's assistant sees one site. An object the token cannot see reads as "not found", never "forbidden", so the endpoint never confirms that something exists.
• Tokens only. Session cookies are refused, so there is no way to ride a logged-in browser session.
• Read-only means read-only. A read-scope token is refused before any tool runs.
• Secrets never leave. Credentials are write-only in the API already; on top of that, anything the secret classifier recognises is stripped from every answer.
• Answers are capped at the row limit you set, and an assistant is always told when a result was cut short, so it does not conclude it saw everything.
• Everything is logged. Recent calls shows the tool, the object type, the account and token, the row count and any error, 25 at a time and newest first. That is how you answer "what has it actually read".
• Rate limited to 120 calls a minute per token.
• Writes land in the change log under the token's account, with the same before-and-after detail as any other change.

An honest note: an assistant with a broad token can read broadly, exactly as the person could. The narrowing that matters is the token's own permissions - give an assistant a purpose-made account rather than your own.

Limits¶

On the Agent access page:

• Rows per answer - the cap for every list and search. Default 50.
• Object types - restrict agents to a subset (say devices, IPs and prefixes). Empty means every type the token already allows.

Troubleshooting¶

Calls and their errors are on the Agent access page, which is the first place to look. A failure that never reaches Danbyte leaves nothing there - if the log is empty, the client never connected.

A self-signed certificate¶

Most MCP clients run on Node, which refuses a certificate it cannot chain to a trusted root and reports DEPTH_ZERO_SELF_SIGNED_CERT before the request leaves the machine. Danbyte is answering fine; the client never asks. curl -k https://your-danbyte/api/mcp/ returning 401 confirms that: alive, listening, wanting a token.

Best fix: give Danbyte a certificate the client already trusts - one from your internal CA, or Let's Encrypt if the host is reachable. Then nothing needs configuring on the client at all.

Otherwise, trust that one certificate rather than turning verification off. Export it:

openssl s_client -connect your-danbyte:443 -showcerts </dev/null 2>/dev/null \
  | openssl x509 > ~/danbyte-ca.pem

and point Node at it with NODE_EXTRA_CA_CERTS=/path/to/danbyte-ca.pem in the environment your client starts in, then restart the client.

Do not reach for NODE_TLS_REJECT_UNAUTHORIZED=0. It disables verification for every connection that process makes, not just the one to Danbyte.

Keep the token out of shared files¶

Most clients store the token in plain text in their own config, which is readable by anything running as you. Two things make that survivable: give the assistant a read-only token, and give it a narrow account rather than your own. Then a leaked token reads a subset of your inventory instead of changing it. Revoke it under Settings → Preferences → API tokens the moment you suspect it.