Integrates with Zoho Site24x7 REST API for managing monitors, reports, operations, MSP/BU customers, and more.
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., "@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.
This Model Context Protocol server exposes site24x7_search and site24x7_execute.
The agent searches the API reference, then runs JavaScript inside a QuickJS WASM sandbox.
API calls go through the host; credentials remain outside the sandbox.
Use one namespace. site24x7.* covers monitoring and account operations.
Refresh OAuth automatically. Credentials and the in-memory access-token cache stay on the host.
Scope customer calls. withCustomer(zaaid, fn) selects an MSP customer or Business Unit and restores the previous scope.
Search offline. The bundled specification is generated from the API documentation.
Related MCP server: Datadog MCP Server
Install from source and point your MCP client at the built dist/index.js.
Node.js 22.19.0 or newer and npm. CI checks Node 22 and 24.
Zoho Self Client credentials and a refresh token for your Site24x7 data center.
git clone https://github.com/jmpijll/site24x7-code-mode-mcp.git
cd site24x7-code-mode-mcp
npm ci
cp .env.example .env
# Edit .env: SITE24X7_CLIENT_ID, SITE24X7_CLIENT_SECRET, SITE24X7_REFRESH_TOKEN and SITE24X7_ZONE.
npm run build
npm startThe shell examples use Bash. In PowerShell, use Copy-Item .env.example .env and
set variables with $env:NAME = 'value'.
Configure your MCP client with node /absolute/path/to/site24x7-code-mode-mcp/dist/index.js.
Use an absolute path and supply credentials through the client's environment configuration
when its working directory does not contain your .env file.
See the client setup and usage guide.
For hosted use, set MCP_TRANSPORT=http and follow the per-request credential contract.
Docker instructions are in docker-compose.yml.
After discovering the operation with the search tool, use the execute tool:
site24x7.request({ method: 'GET', path: '/api/current_status' });See the usage guide for search recipes, configuration and additional call shapes.
Area | Current boundary |
API reference | Bundled snapshot scraped from documentation; no live OpenAPI endpoint. |
Live coverage | Real-tenant, MSP/BU, client and mutation verification remain pending. |
Workers | Scaffold; the MCP transport adapter returns 501. |
Sandbox | Resource limits bound each invocation; allowed API calls still act with the supplied account's permissions. |
Mocked unit/integration coverage and MCP Inspector CLI smoke are recorded. Real-tenant and LLM-client verification remain pending. See the setup and verification reference for the detailed historical evidence and remaining work. New verification reports should identify the server revision, client, upstream version and operations actually exercised.
Public beta · v0.1.0-beta.1. Install from source; the package remains private and is not published to npm.
The host sends API requests to the service configured for this server. Tool results and captured sandbox logs are returned to your MCP client; that client may send them to its configured model provider. Spec caches may be written locally.
Keep .env files and credentials private. Redact account identifiers, IP addresses and
service data before sharing logs or verification reports. See SECURITY.md
for vulnerability reporting.
npm run checkcheck runs lint, formatting, typecheck, mocked tests and the build.
It also verifies the built MCP server version and its two tools without tenant credentials
or upstream network access. npm run cf:check validates the Worker bundle without deploying it. See CONTRIBUTING.md
for the repository layout and contribution checks, and AGENTS.md for
architectural invariants. Live API tests require separate credentials and verification scope.
MIT. Built with TypeScript, the MCP SDK and QuickJS, following the Cloudflare Code Mode pattern.
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.
v0.1.0-beta.1site24x7_executesite24x7_searchScored across 2 tools
The 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.
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
