ITOC360 MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ITOC360_TOKEN | Yes | Source token from the ITOC360 source page | |
| ITOC360_BASE_URL | No | Override the API host | https://api.itoc360.app |
| ITOC360_TIMEOUT_MS | No | Per-request timeout in milliseconds | 30000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| send_alertA | 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. |
| resolve_alertA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
send_alert and resolve_alert are mutually exclusive lifecycle actions with no semantic overlap. An agent cannot confuse raising an alert with resolving one.
Both tools follow the same verb_noun pattern: send_alert and resolve_alert. The naming is perfectly consistent and predictable.
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.
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.