F
licenseNot graded
qualityD
maintenanceEnables AI-driven incident response by connecting Claude to monitoring tools like Prometheus, Grafana, Loki, PagerDuty, and Slack for automated investigation and runbook generation.
9
-
ITOC360 MCP Server
Officialby itoc360
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@ITOC360 MCP Serversend alert for checkout-api latency"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
ITOC360 MCP Server
An MCP server that lets AI agents raise and resolve incidents in ITOC360.
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
Related MCP server: PagerDuty MCP Server
Getting a token
Sign in to ITOC360 and open Sources
Create a source (a Prometheus/Alertmanager source works — this server speaks that format)
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:
{
"mcpServers": {
"itoc360": {
"command": "npx",
"args": ["-y", "@itoc360/mcp"],
"env": {
"ITOC360_TOKEN": "your-source-token"
}
}
}
}For Claude Code:
claude mcp add itoc360 --env ITOC360_TOKEN=your-source-token -- npx -y @itoc360/mcpEnvironment variables
Variable | Required | Default | Purpose |
| yes | — | Source token from the ITOC360 source page |
| no |
| Override the API host |
| no |
| Per-request timeout in milliseconds |
Tools
send_alert
Raises an alert and starts the escalation policy.
Argument | Required | Description |
| yes | Stable identifier for the problem, e.g. |
| yes | One-line title shown as the alert headline |
| no | Longer explanation on the alert detail page |
| no |
|
| no | Extra key/value labels, e.g. |
| 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 |
| yes | Must match the fingerprint used to raise the alert |
| yes | One-line note recorded with the resolution |
| 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:
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
npm install
npm test # builds, then runs the unit and MCP protocol testsLicense
Apache-2.0
Available Tools
2 toolsresolve_alertResolve an ITOC360 alertAIdempotent
Close an alert that was raised with send_alert, stopping further escalation. The fingerprint must match the one used to raise it. Resolving an alert that is already closed is harmless.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| summary | Yes | One-line note recorded with the resolution, e.g. "Checkout API latency recovered". | |
| description | No | Longer explanation of what resolved the problem. | |
| fingerprint | Yes | Fingerprint of the alert to close. Must match the value used when it was raised. |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey idempotence (idempotentHint=true) and non-destructiveness (destructiveHint=false). The description adds contextual detail about stopping escalation and requiring a matching fingerprint, but does not go much beyond the annotations. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The action, object, key constraint, and idempotence note are all front-loaded and each sentence carries necessary meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool with no output schema, the combination of description and schema is complete. The agent knows what the tool does, how to identify the target alert, and what to expect when retrying or double-resolving.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description restates the fingerprint-matching constraint already present in the schema, but adds little semantic value beyond it. The summary and description parameters are already well explained in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Close'), a specific resource ('an alert'), and ties it to its sibling tool send_alert, so an agent can immediately distinguish resolve_alert from send_alert. It also states the key consequence ('stopping further escalation'), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly communicates this is for closing alerts raised via send_alert, and notes that resolving an already-closed alert is harmless. It does not explicitly list exclusions or say 'use send_alert instead when raising', but the pairing is strongly implied and sufficient for a two-tool context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_alertRaise an ITOC360 alertAIdempotent
Raise an alert in ITOC360, which pages whoever is on call through the tenant escalation policy (SMS, voice call, push, email). Reusing a fingerprint updates the existing alert rather than opening a new one, so this is safe to call again for an ongoing problem. Only raise alerts for real problems that a human needs to act on.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| labels | No | Extra key/value labels, e.g. {"service": "checkout", "env": "prod"}. | |
| summary | Yes | One-line title shown as the alert headline, e.g. "Checkout API p99 above 2s". | |
| severity | No | Severity ITOC360 maps onto alert priority. Defaults to "warning". | |
| description | No | Longer explanation shown on the alert detail page. | |
| fingerprint | Yes | Stable identifier for the underlying problem, e.g. "checkout-api::latency". Reuse the same value for the same problem: ITOC360 updates the existing alert instead of opening a second one, and resolve_alert needs this value to close it. | |
| generator_url | No | Link back to the dashboard or run that surfaced the problem. |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that calling pages the on-call via the escalation policy (SMS, voice, push, email) and explains the idempotency mechanism (updates existing alert on fingerprint reuse). This adds meaningful context beyond the annotations, which only state idempotentHint without explaining the behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying distinct value: purpose with paging, idempotency behavior, and a usage guardrail. Front-loaded with the core purpose and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description covers the key behavioral aspects: paging, idempotency, and caution about when to raise. It doesn't explain return values or error conditions, but those are not explicitly required given the annotations and schema. Overall, it provides enough for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already well-documented. The description adds no additional parameter semantics; the fingerprint reuse behavior is already captured in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool raises an alert in ITOC360 and explains its paging effect. It distinguishes from the sibling resolve_alert by the action (raise vs. resolve), even though the sibling is not explicitly named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to call: 'Only raise alerts for real problems that a human needs to act on' and explains that reusing a fingerprint is safe for ongoing problems. However, it does not explicitly mention when to use resolve_alert instead, relying on the sibling name for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0- First observed
resolve_alert - First observed
send_alert
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
Related MCP Connectors
Manage incident alerts, events, and workflows with custom automations
AI agents for federal IT & pharma: alert triage, ICAM, helpdesk, incidents, ticket routing.
- mttrlyOAuthcom.mttrly
AI-powered incident management and server monitoring via MCP.
AI agent run monitoring with incident replay and SLA receipts.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables AI assistants to manage PagerDuty incidents, view alerts, and check on-call schedules with both read-only and write operations.9Apache 2.0
- FlicenseNot gradedqualityDmaintenanceEnables AI agents to interact with PagerDuty services, incidents, schedules, and on-call management through natural language.-
- FlicenseNot gradedqualityCmaintenanceMCP server exposing ServiceNow, Jira, and PagerDuty as unified tools for AI agents, enabling incident management, issue tracking, and on-call operations.-