An MCP server for Azure Service Bus

Setting it up

1. 1

   Run viewbus once and pick a subscription

   The MCP server reads the index the desktop app builds, so it needs the app to have run at least once. Every tool except get_status is scoped to the subscription selected in the app — the same scoping the sidebar uses.

2. 2

   Copy the config from Settings → MCP

   viewbus knows where its own viewbus-mcp binary landed, so it generates the snippet for you. Pick your client, hit copy, and paste it into that client's config file. The shapes look like this:

3. 3

   Restart the client

   The tools show up automatically. In Claude Code, /mcp confirms viewbus is connected. Ask it "what's in my viewbus index?" to check the wiring.

{
  "mcpServers": {
    "viewbus": {
      "command": "<path to viewbus-mcp>"
    }
  }
}

{
  "mcpServers": {
    "viewbus": {
      "command": "<path to viewbus-mcp>"
    }
  }
}

{
  "mcpServers": {
    "viewbus": {
      "command": "<path to viewbus-mcp>"
    }
  }
}

[mcp_servers.viewbus]
command = "<path to viewbus-mcp>"

{
  "servers": {
    "viewbus": {
      "type": "stdio",
      "command": "<path to viewbus-mcp>"
    }
  }
}

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "viewbus": {
      "type": "local",
      "command": ["<path to viewbus-mcp>"],
      "enabled": true
    }
  }
}

Replace <path to viewbus-mcp> with the real path — or skip the guesswork and copy the filled-in version from Settings → MCP in the app.

What the AI can do

Ten tools, all read-only. The first group reads the local index and works even with the app closed; the second queries live messages and needs the app running.

Index & search

get_status

Index state, selected subscription, last refresh, and whether live queries are available. Call it first.

list_namespaces

Every indexed namespace in the selected subscription.

list_queues

Queues under a namespace.

list_topics

Topics under a namespace.

list_subscriptions

Subscriptions under a topic.

get_resource

Full detail for one indexed resource by ID.

search_resources

Fuzzy search by name or path across queues, topics, and subscriptions.

Live messages

count_messages

How many messages match a filter — counts only, no bodies. Supports a breakdown by dead-letter reason.

peek_messages

Message summaries (sequence number, subject, IDs, delivery count, short body preview). Capped at 100 per call.

get_message_detail

The full body and all properties for one sequence number.

Filters run inside viewbus, not in the model's context: body-contains, enqueued-time range, session, message ID, correlation ID, subject, dead-letter reason, and custom properties. That keeps message bytes out of the conversation unless you actually ask for a body.

There is one write tool, upsert_theme, which lets an assistant author viewbus themes. It's off unless you enable it in settings.

Things worth asking it

• ›How many dead letters piled up on the orders topic between 11:00 and 15:00?
• ›Break those down by dead-letter reason.
• ›Find any queue related to refunds.
• ›Show me the five most recent MaxDeliveryCount failures and what they have in common.
• ›What's in message 18473?

What it can't do

Giving an AI access to production queues is worth thinking about, so the limits are hard ones:

• No writes to your bus. There is no send, resend, delete, dead-letter, or purge tool. A peek is non-destructive and doesn't touch delivery counts.
• No new credentials. The server never talks to Azure itself. It reads the local SQLite index, and live queries go through the running desktop app using the sign-in you already have.
• No network listener. stdio to the client, a local socket to the app. Nothing binds a port and nothing is reachable from your network.
• Scoped to one subscription. Tools only see the subscription selected in the app. Anything else returns an error rather than reaching across.

Message bodies you explicitly ask for do go to whichever AI provider your client uses — that's inherent to asking a model about them. viewbus itself sees none of it; see the privacy page.

Common questions