Skip to main content
Glama
itoc360

ITOC360 MCP Server

Official
by itoc360
README.md
# ITOC360 MCP Server

An [MCP](https://modelcontextprotocol.io) server that lets AI agents raise and resolve incidents in [ITOC360](https://www.itoc360.com).

When an agent notices something a human needs to act on, it calls `send_alert`. ITOC360 pages whoever is on call through the tenant's escalation policy — SMS, voice call, mobile push, email — and keeps escalating until someone acknowledges. When the problem clears, the agent calls `resolve_alert` and the page stops.

## Requirements

- Node.js 20 or newer
- An ITOC360 account and a **source token**

## Getting a token

1. Sign in to ITOC360 and open **Sources**
2. Create a source (a Prometheus/Alertmanager source works — this server speaks that format)
3. Copy the source token

The token identifies both the tenant and the source, so keep it secret.

## Configuration

Add the server to your MCP client. For Claude Desktop, edit `claude_desktop_config.json`:

```json
{
  "mcpServers": {
    "itoc360": {
      "command": "npx",
      "args": ["-y", "@itoc360/mcp"],
      "env": {
        "ITOC360_TOKEN": "your-source-token"
      }
    }
  }
}
```

For Claude Code:

```bash
claude mcp add itoc360 --env ITOC360_TOKEN=your-source-token -- npx -y @itoc360/mcp
```

### Environment variables

| Variable | Required | Default | Purpose |
|---|---|---|---|
| `ITOC360_TOKEN` | yes | — | Source token from the ITOC360 source page |
| `ITOC360_BASE_URL` | no | `https://api.itoc360.app` | Override the API host |
| `ITOC360_TIMEOUT_MS` | no | `30000` | Per-request timeout in milliseconds |

## Tools

### `send_alert`

Raises an alert and starts the escalation policy.

| Argument | Required | Description |
|---|---|---|
| `fingerprint` | yes | Stable identifier for the problem, e.g. `checkout-api::latency` |
| `summary` | yes | One-line title shown as the alert headline |
| `description` | no | Longer explanation on the alert detail page |
| `severity` | no | `critical`, `error`, `warning` (default) or `info` |
| `labels` | no | Extra key/value labels, e.g. `{"service": "checkout"}` |
| `generator_url` | no | Link back to the dashboard or run that surfaced the problem |

### `resolve_alert`

Closes an alert raised earlier and stops further escalation.

| Argument | Required | Description |
|---|---|---|
| `fingerprint` | yes | Must match the fingerprint used to raise the alert |
| `summary` | yes | One-line note recorded with the resolution |
| `description` | no | Longer explanation of what resolved the problem |

## Fingerprints and deduplication

The fingerprint is how ITOC360 decides whether two alerts describe the same problem.

Reuse the same fingerprint for the same underlying issue. Raising an alert again with a fingerprint that is already open updates the existing alert rather than opening a second one and paging someone twice — which is why both tools are safe to retry.

`resolve_alert` needs the same fingerprint to find the alert and close it, so pick something an agent can reconstruct: `service::check` reads better than a random UUID.

## Wire format

This server posts the Prometheus Alertmanager webhook body, byte-compatible with the other ITOC360 SDKs. An alert raised from here deduplicates against one raised from the Go, Python, Node or .NET SDK as long as the fingerprints match.

## Using the client directly

The package also exports the pieces the server is built from, for use outside MCP:

```ts
import { Itoc360Client, Severity } from '@itoc360/mcp';

const client = new Itoc360Client({ token: process.env.ITOC360_TOKEN });

await client.sendAlert({
  fingerprint: 'checkout-api::latency',
  summary: 'Checkout API p99 above 2s',
  severity: Severity.Critical,
  labels: { service: 'checkout', env: 'prod' },
});
```

Failures raise typed errors: `ValidationError` before anything is sent, `ApiError` (with `unauthorized`, `subscriptionInactive` and `retryable` flags) for a non-2xx response, and `TransportError` when the request never reached ITOC360.

## Development

```bash
npm install
npm test        # builds, then runs the unit and MCP protocol tests
```

## License

Apache-2.0

TDQS

A4.2/5.0

Scored across 2 tools

Disambiguation5/5

send_alert and resolve_alert are mutually exclusive lifecycle actions with no semantic overlap. An agent cannot confuse raising an alert with resolving one.

Naming Consistency5/5

Both tools follow the same verb_noun pattern: send_alert and resolve_alert. The naming is perfectly consistent and predictable.

Tool Count3/5

At only two tools, the server is on the thin side, but the narrow alerting domain justifies a minimal surface. It feels borderline rather than fully well-scoped.

Completeness4/5

The core send/resolve alert lifecycle is covered, including update semantics via fingerprint reuse. However, there is no way to list or inspect alert status, which is a minor gap.

Maintenance

ActivityMaintained
ResponsivenessNo issues