Integrates with Zoho Site24x7 REST API for managing monitors, reports, operations, MSP/BU customers, and more.
Click on "Install 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., "@site24x7-code-mode-mcp list all monitors in my account"
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.
Status: public beta (
v0.1.0-beta.1). Verification status is tracked below.
A Model Context Protocol server for the Zoho Site24x7 REST API, built on the code-mode pattern: instead of mapping each of the hundreds of Site24x7 endpoints to its own MCP tool, this server exposes exactly two tools (site24x7_search and site24x7_execute) and a JavaScript sandbox where the LLM writes real code against a flat site24x7.* surface.
This is the same architecture used by the sibling repos:
make-code-mode-mcp — Make.com Web API v2
unraid-code-mode-mcp — Unraid 7.2+ GraphQL API
unifi-code-mode-mcp — UniFi Network + Site Manager APIs
fortimanager-code-mode-mcp — FortiManager JSON-RPC
What's different about Site24x7:
Zoho OAuth 2.0 with a permanent refresh token (Self Client flow). New auth pattern for this family.
MSP / Business Unit tenancy — a second axis of tenancy inside a single OAuth identity, expressed as Cookie: zaaid=<customer_id>. First-class in this server, not bolted on.
No public OpenAPI spec. We scrape the official REST reference into a bundled JSON spec at build time.
git clone https://github.com/jmpijll/site24x7-code-mode-mcp
cd site24x7-code-mode-mcp
npm install --legacy-peer-deps
cp .env.example .env
# Fill in SITE24X7_CLIENT_ID / SECRET / REFRESH_TOKEN / ZONE — see "Authentication" below.
npm run build
node dist/index.js # stdio mode (default)
# or, for multi-tenant HTTP mode:
MCP_TRANSPORT=http MCP_HTTP_PORT=8000 node dist/index.jsThen wire it into your MCP client:
Cursor — uses .cursor/mcp.json shipped in this repo.
opencode — uses opencode.json shipped in this repo.
Claude Code / Claude Desktop / Codex / Continue / Cline / Zed / MCP Inspector — see docs/usage.md.
Related MCP server: Datadog MCP Server
Site24x7 reuses Zoho's accounts service for OAuth 2.0. The only practical long-lived option for a local MCP is the Self Client → refresh token flow.
Flow | Why we don't use it |
Web-server authorization-code | Needs a callback URL — impossible for a local MCP. |
Access-token only | Expires every hour — terrible UX. |
Legacy | Deprecated by Zoho for new integrations. |
Self Client refresh-token | What we use. One-time setup, permanent refresh token, automatic per-tenant access-token rotation. |
Open the Zoho API console for your data center:
Zone | Console URL |
US ( | |
EU ( | |
India ( | |
Australia ( | |
China ( | |
Japan ( | |
Canada ( | |
UK ( | |
UAE ( | |
Saudi Arabia ( |
Click Add Client → Self Client → Create. Note the Client ID and Client Secret.
Go to the Generate Code tab on the same Self Client and fill in:
Scope: the scopes you want available to the MCP, comma-separated. Pick from the table below. For a typical "full admin + MSP" deployment:
Site24x7.Admin.All,Site24x7.Account.All,Site24x7.Reports.All,Site24x7.Operations.All,Site24x7.Msp.All,Site24x7.Bu.AllDescription: anything ("site24x7 code-mode mcp" works).
Time Duration: 10 Minutes (the maximum; you only need a minute or two).
Click Create. Copy the displayed code (the grant token).
Exchange the grant token for a refresh token using curl (run within 10 minutes of step 3):
curl -X POST 'https://accounts.zoho.com/oauth/v2/token' \
-d "client_id=$CLIENT_ID" \
-d "client_secret=$CLIENT_SECRET" \
-d "code=$GRANT_CODE" \
-d "grant_type=authorization_code" Replace accounts.zoho.com with the accounts host for your zone (accounts.zoho.eu, accounts.zoho.in, etc.). The response includes:
{
"access_token": "1000.xxx",
"refresh_token": "1000.yyy",
"expires_in": 3600,
"token_type": "Bearer"
} Keep the refresh_token — it's permanent. The access_token is throwaway; the MCP server will mint fresh ones automatically.
Drop the values into .env:
SITE24X7_CLIENT_ID=1000.xxx
SITE24X7_CLIENT_SECRET=xxx
SITE24X7_REFRESH_TOKEN=1000.yyy
SITE24X7_ZONE=comScope family | What it grants | Levels |
| Users, license, account-wide data |
|
| Monitors, profiles, third-party integrations |
|
| Reports and monitor status |
|
| IT Automation, maintenance, status pages |
|
| MSP-level operations |
|
| Business-Unit-level operations |
|
Pick the narrowest set of scopes that covers your intended use. The MCP server tells the LLM, per operation, which scope it needs — so a scope-aware 403 always has actionable context.
curl -X POST 'https://accounts.zoho.com/oauth/v2/token/revoke?token=YOUR_REFRESH_TOKEN'Or via the Zoho web UI: https://accounts.zoho.com/u/h#sessions/refreshtokens.
If your Zoho identity is an MSP user (or a BU portal user), one Self Client / refresh token lets you operate against any customer / BU under your portal — but you must tell each API call which customer to act on via Cookie: zaaid=<customer_zaaid>. This server makes that ergonomic.
In the sandbox:
site24x7.listCustomers();This returns [{ name, zaaid, ... }] from /api/short/msp/customers (or /api/short/bu/business_units if SITE24X7_ACCOUNT_TYPE=bu).
site24x7.withCustomer('658123456', function (s) {
return s.monitors.list();
});withCustomer re-injects the cookie for every call inside the closure. Outside the closure, the active zaaid reverts to whatever was in scope when you entered.
var customers = site24x7.listCustomers();
var summary = [];
for (var i = 0; i < customers.length; i++) {
var c = customers[i];
var status = site24x7.withCustomer(c.zaaid, function (api) {
return api.request({ method: 'GET', path: '/api/current_status' });
});
summary.push({
name: c.name,
zaaid: c.zaaid,
down: (status && status.monitors_status && status.monitors_status.down) || 0,
});
}
summary;When the server runs with MCP_TRANSPORT=http, each request can override the active customer via the X-Site24x7-Zaaid header. The full multi-tenant contract:
Header | Required | Notes |
| yes | Zoho Self Client client ID |
| yes | Zoho Self Client client secret |
| yes | Permanent refresh token |
| yes | One of |
| no | Default |
| no |
|
See docs/multi-tenant.md for the full architecture.
The server speaks to two hosts per zone — Zoho accounts (for OAuth) and Site24x7 (for API calls). Both are routed automatically from SITE24X7_ZONE.
Zone ( | Zoho accounts | Site24x7 API |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
See SKILL.md for the operating manual aimed at the model
writing the JavaScript. TL;DR:
site24x7.request({ method, path, query?, body?, version?, zaaid? })
site24x7.<tag>.<op>(args) // typed accessor
site24x7.callOperation('opId', args) // flat lookup
site24x7.listCustomers() // MSP/BU enumeration
site24x7.withCustomer(zaaid, fn) // scoped customer override (sync)
site24x7.zaaid // active zaaid (or undefined)All variables are documented in .env.example. Highlights:
Variable | Default | Notes |
|
|
|
|
| HTTP port (only if |
|
| Comma-separated origin allowlist |
| — | Zoho Self Client credentials |
|
| Data center (see table above) |
| — | (Optional) default MSP/BU customer scope |
|
|
|
|
| Per-execute API call budget |
|
| Wall-clock deadline (ms) |
|
| On-disk cache root |
This is v0.1.0-beta.1. Honest verification surface:
Surface | Verified |
Unit tests (Vitest, in-process) | ✅ |
Integration tests ( | ✅ |
MCP Inspector CLI smoke ( | ✅ |
Live read-only sweep against a real Site24x7 tenant | ⏳ pending credentials |
Live MSP customer round-trip via | ⏳ pending credentials |
OpenCode end-to-end LLM round-trip | ⏳ pending credentials |
Cursor / Claude Code / Claude Desktop / Continue / Cline / Aider / Zed | ⏳ |
Mutating live operations | ⛔ deliberately not run until you give us a lab tenant |
Other zones beyond the one your refresh token lives in | ⏳ |
Cloudflare Workers full transport | ⛔ 501 scaffold only (parity with sibling repos) |
Long-running soak / stability | ⏳ |
This table updates honestly as we verify more — if a row is not ticked here, we haven't tested it. Verification reports are welcome (see CONTRIBUTING.md).
AGENTS.md — contributor guide and architectural invariants
SKILL.md — operating manual for the MCP client / LLM
docs/architecture.md — the code-mode pattern and how this server implements it
docs/multi-tenant.md — env vs headers vs withCustomer, including MSP/BU
docs/security.md — threat model, credential handling, sandbox boundary
docs/usage.md — every supported MCP client and how to wire it in
docs/opencode-skill.md — opencode-specific install + recipes
docs/cursor-skill.md — Cursor-specific install + recipes
examples/site24x7-expert-agent/ — drop-in Site24x7-expert persona for any agent platform
MIT.
Run Site24x7 API calls by writing JavaScript that uses the site24x7 namespace.
Surface:
site24x7.<tag>.<operationId>(args) — typed call. Args are auto-routed: keys matching path or query params from the spec are placed correctly; remaining keys form the JSON body for POST/PUT/PATCH. Override with { pathParams: {...}, query: {...}, body: {...}, version: '2.1', zaaid: '...' }.
site24x7.callOperation(operationId, args) — flat lookup by id.
site24x7.request({ method, path, query?, body?, version?, zaaid? }) — raw HTTP escape hatch (e.g. for endpoints not yet in the spec).
site24x7.spec — { title, sourceUrl, generatedAt, operationCount } for diagnostics.
site24x7.listCustomers() — MSP/BU customer enumeration (uses /api/short/msp/customers or /api/short/bu/business_units based on accountType).
site24x7.withCustomer(zaaid, async fn) — run fn(site24x7) with the closure scoped to a customer. Restores the previous zaaid on exit, even on throw. Must be awaited.
site24x7.zaaid — the currently active zaaid (or undefined).
Operations are async — use await. Top-level await is not supported; wrap in an async IIFE:
(async () => {
const status = await site24x7.request({ method: 'GET', path: '/api/current_status' });
return status;
})()(async () => {
const customers = await site24x7.listCustomers();
const out = [];
for (const c of customers) {
const status = await site24x7.withCustomer(c.zaaid, async (s) => {
return s.request({ method: 'GET', path: '/api/current_status' });
});
out.push({ name: c.name, zaaid: c.zaaid, down: status?.monitors_status?.down ?? 0 });
}
return out;
})()Errors are prefixed with a structured tag:
[site24x7.HttpError] HTTP 403 GET /api/users (operation requires scope(s) \Site24x7.Admin.Read` — confirm your refresh token grants them)`
[site24x7.MissingZaaidError] operation "..." requires a zaaid in scope (operation mspOnly=true). Hint: call site24x7.listCustomers() and wrap the call in site24x7.withCustomer(zaaid, ...).
[site24x7.MissingCredentialsError] ... when no Zoho OAuth credentials are configured
[site24x7.UnknownOperationError] ... when the operationId doesn't exist in the spec
Per-execute API call ceiling (default 50, configurable via SITE24X7_MAX_CALLS_PER_EXECUTE).
Sandbox memory + 30 s deadline.
Credentials never enter the sandbox.
Site24x7 enforces its own per-token rate limit (~10 req/s on most plans). 429 triggers one polite retry.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | JavaScript code to execute against the live Site24x7 API. Wrap async work in an IIFE. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses async nature, top-level await restrictions, error prefixes, limits (max calls, timeout), credentials handling, and retry on 429. This is thorough behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with sections for surface, recipe, errors, limits. It is front-loaded with the main purpose and each paragraph adds value. Could be slightly more concise but efficient for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and one parameter, the description covers usage, errors, limits, and MSP pattern comprehensively. It lacks explicit return value format but demonstrates it in examples, making it nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with only one parameter `code` described minimally. The description adds significant meaning: code format (IIFE), namespace usage, error handling patterns, and MSP recipe, far exceeding the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run Site24x7 API calls by writing JavaScript that uses the `site24x7` namespace.' This is a specific verb (execute) and resource (Site24x7 API), and it distinguishes from the sibling tool `site24x7_search` by being a general execution tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive usage patterns: typed calls, operationId, raw HTTP, MSP recipe, and error handling. It implicitly differentiates from `site24x7_search`, but lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Site24x7 REST API spec by writing JavaScript.
The sandbox is read-only — no network. Use this tool to discover what to call before invoking site24x7_execute.
spec — { title, sourceUrl, generatedAt, operationCount, tags[] }. null if no spec is loaded.
searchOperations(query, limit?) — text-ranked search; default limit 25.
getOperation(operationId) — full operation including parameters, requiredScopes, mspOnly / buOnly flags. Returns null if no such id.
findOperationsByPath(substring) — list operations whose path contains the substring (case-insensitive).
findOperationsByTag(tag) — list operations in a tag (e.g. 'monitors', 'msp', 'business_units').
console.log() — captured into the tool output.
// All operations tagged "monitors"
findOperationsByTag('monitors');// Top 10 hits for "msp customer"
searchOperations('msp customer', 10);// Full detail on the create-monitor op
getOperation('post_monitors');| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | JavaScript code to execute against the bundled spec. The final expression is returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description fully discloses behavioral traits: 'The sandbox is read-only — no network.' It also lists available globals and their behaviors (searchOperations, getOperation, etc.), providing comprehensive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headings, bullet points, and code blocks. It front-loads the purpose and usage guidance, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's context given the lack of output schema. It explains how `console.log` is captured and that the final expression is returned. However, it could explicitly mention error handling or return format for edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters (single `code` parameter). The description adds value by explaining that the final expression is returned and provides examples of usage patterns, though the schema already describes the parameter well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search' and resource 'Site24x7 REST API spec'. It explicitly distinguishes from the sibling tool `site24x7_execute` by noting 'Use this tool to discover what to call before invoking site24x7_execute'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool ('discover what to call') versus the sibling tool ('before invoking site24x7_execute'). It also implies not to use for execution since the sandbox is read-only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0-beta.1site24x7_executesite24x7_searchThe two tools have clearly distinct purposes: one for discovering API operations via read-only search, and one for executing API calls. There is no functional overlap.
Both tools follow a consistent 'site24x7_verb' pattern with snake_case, making them predictable and easy to parse.
Two tools are too few for a full API surface; the design essentially reduces the interface to a generic code execution sandbox. This feels thin even if intended as a flexible escape hatch.
The tool set provides no specific CRUD or lifecycle operations; it relies entirely on writing custom code. This is severely incomplete for the stated scope of a Site24x7 API wrapper.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
A Model Context Protocol server for Wix AI tools
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jmpijll/site24x7-code-mode-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
