Allows searching for related incidents, creating LINFRA tickets, and adding comments to tickets in Jira.
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., "@Channels MCP Server investigate cha3.abn.green.sophos"
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.
An MCP (Model Context Protocol) server for investigating and managing Sophos Channel Server incidents. Works with any AI tool that supports MCP — Kiro, Claude Desktop, Cursor, Cline, Windsurf, etc.
This MCP server enables AI assistants to autonomously investigate channel server incidents by:
Connecting to channel servers via SSH and reading logs, status files, and system state (read-only, no destructive commands)
Checking Zabbix for active alerts and acknowledging them with proper ticket references
Searching Jira for related past incidents and upstream dependencies (e.g., antispam-publishing outages)
Pattern matching — automatically identifies known root causes:
block_repeat_tarballs → upstream antispam-publishing server is down
disable_akamai_rsyncs → intentional DR setup, suppress alert
Channels overdue by millions of minutes → decommissioned, suppress
eicar.msg missing → AV deleted test file from old RPM, suppress
traffix.labs.sophos unreachable → dead DB dependency, suppress
large_file_alert → files over 3GB need rotation/compression
Creating LINFRA tickets with categorized findings and proper documentation
Following SOP — knows BOS=DR=P4, ABN=Primary=P3, and to check antispam-publishing first when multiple alerts fire
Channel server alerts often require manual SSH investigation, cross-referencing Jira for past incidents, checking upstream dependencies, and documenting findings. This MCP automates the entire workflow — the AI connects, investigates, correlates, and documents in minutes instead of hours.
Related MCP server: SSH MCP Server
Before setting up, you need:
SSH access to channel servers (your key must be authorized on the servers)
Zabbix API token from https://zabbix.sophosapps.com (User Settings → API Tokens)
Atlassian API token from https://id.atlassian.com/manage-profile/security/api-tokens
Node.js 18+ installed on your machine
git clone https://github.com/pavanbhatt19/labs.platform-infra.channels-mcp.git
cd labs.platform-infra.channels-mcp
npm installNo build step needed — dist/ is pre-built and included in the repo.
ssh-add ~/.ssh/id_rsaVerify it's loaded: ssh-add -l
SSH_AUTH_SOCK is auto-detected on macOS — you don't need to set it manually. The MCP will find your SSH agent socket automatically as long as your key is loaded with ssh-add.
Kiro (~/.kiro/settings/mcp.json):
{
"mcpServers": {
"channels": {
"command": "node",
"args": ["/full/path/to/labs.platform-infra.channels-mcp/dist/index.js"],
"env": {
"SSH_USERNAME": "your_ssh_username",
"ZABBIX_URL": "https://zabbix.sophosapps.com",
"ZABBIX_API_TOKEN": "your_zabbix_api_token",
"ATLASSIAN_HOST": "https://sophos.atlassian.net",
"ATLASSIAN_EMAIL": "your.name@sophos.com",
"ATLASSIAN_API_TOKEN": "your_atlassian_api_token"
}
}
}
}Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"channels": {
"command": "node",
"args": ["/full/path/to/labs.platform-infra.channels-mcp/dist/index.js"],
"env": {
"SSH_USERNAME": "your_ssh_username",
"ZABBIX_URL": "https://zabbix.sophosapps.com",
"ZABBIX_API_TOKEN": "your_zabbix_api_token",
"ATLASSIAN_HOST": "https://sophos.atlassian.net",
"ATLASSIAN_EMAIL": "your.name@sophos.com",
"ATLASSIAN_API_TOKEN": "your_atlassian_api_token"
}
}
}
}Cursor/Cline — same format, add to your MCP settings.
Ask your AI: "List all channel servers" or "Investigate cha3.abn.green.sophos"
Variable | Required | How to get it |
| Yes | Your SSH username for channel servers (e.g., |
| No (auto-detected) | Auto-detected on macOS. Only set manually if auto-detection fails. |
| Optional | Alternative to SSH agent: path to your key (e.g., |
| Optional | Passphrase for the private key (if using SSH_PRIVATE_KEY_PATH) |
| Yes |
|
| Yes | Zabbix → User Settings → API Tokens → Create |
| Yes |
|
| Yes | Your Sophos email (e.g., |
| Yes | https://id.atlassian.com/manage-profile/security/api-tokens → Create |
SSH_AUTH_SOCK is auto-detected on macOS — the MCP scans /var/run/com.apple.launchd.* to find the agent socket automatically
You do NOT need to hardcode it in the config (it changes on every reboot anyway)
Just make sure your key is loaded: ssh-add ~/.ssh/id_rsa before using the MCP
Verify your key is loaded: Run ssh-add -l — you should see your key listed. If it says "The agent has no identities", run ssh-add ~/.ssh/id_rsa first
The MCP connects as your SSH user and all commands run as the channel user via sudo su - channel -c "..."
Before your first use, confirm everything is ready:
# 1. Is your SSH key loaded?
ssh-add -l
# Should show your key. If not: ssh-add ~/.ssh/id_rsa
# 2. Can you SSH to a channel server manually?
ssh your_username@cha3.abn.green.sophos
# Should connect without password prompt. If not, your key isn't authorized on the server.
# 3. Is Node.js installed?
node --version
# Should be 18+You do NOT run npm run dev or node dist/index.js manually
Your AI tool (Kiro, Claude Desktop, etc.) reads the MCP config and starts the server process itself
After updating the config, restart your AI tool or reconnect MCP servers (Kiro: command palette → "MCP: Reconnect Servers")
If the MCP doesn't appear in your tool list, check the MCP server panel for errors
git pullIf you pull new changes, rebuild the dist:
git pull
npm run buildThen restart your AI tool or reconnect MCP servers.
All SSH commands are enforced to run as the channel user. The following commands are blocked and will throw an error:
Package management: yum, rpm install, apt, dnf, pip
File deletion: rm, rmdir
Service control: systemctl, service, kill, reboot
File manipulation: mv, cp, chmod, chown
Editors: vi, vim, nano
Channel updates: chwatcher, chupdate (investigation only, no modifications)
Read-only commands are allowed: tail, cat, ls, find, stat, grep, df, ps, python (for JSON parsing)
Tool | What it does | Safe? |
| Full auto-investigation: connects via SSH, reads all status JSONs, pattern matches, returns categorized findings | ✅ Read-only |
| Read latest chan.log entries for a specific channel path | ✅ Read-only |
| Check Jira for active antispam-publishing incidents (most common root cause) | ✅ Read-only |
| Get all active Zabbix alerts for a server | ✅ Read-only |
| Find files over 500MB that may trigger large_file_alert | ✅ Read-only |
| List all 13 channel servers with roles, priorities, Zabbix IDs | ✅ Read-only |
| Search Jira for past similar incidents | ✅ Read-only |
| Acknowledge Zabbix alerts with a message | ⚠️ Write |
| Create a LINFRA Jira ticket | ⚠️ Write |
| Add a comment to an existing Jira ticket | ⚠️ Write |
This MCP is designed to be safe by default:
All SSH commands are read-only (tail, cat, ls, stat, find, grep, python for JSON parsing)
NEVER runs: yum, rpm install, rm, service restart, config changes
Write operations (Zabbix ack, Jira tickets) require explicit tool calls — AI won't do these without your approval
Just ask your AI naturally:
"Investigate cha3.abn.green.sophos — we have alerts firing"
"Check if antispam-publishing is down"
"What are the active problems on cha7.bos.green.sophos?"
"Check the chan.log for /home/channel/channels/as/2.7.2.376379/b2/data on cha3.abn"
"Are there any large files on pmuedge.abn.green.sophos?"
"Search for past incidents related to block_repeat_tarballs"
"Create a LINFRA ticket for the dead channels on cha3.bos"
Server | Role | Priority | Notes |
cha1.abn.green.sophos | Primary (ABN) | P3 | |
cha2.abn.green.sophos | Primary (ABN) | P3 | |
cha3.abn.green.sophos | Primary (ABN) | P3 | Main AS/antispam server |
cha3.bos.green.sophos | DR (BOS) | P4 | Next business day |
cha4.abn.green.sophos | Primary (ABN) | P3 | |
cha5.abn.green.sophos | Primary (ABN) | P3 | Currently disabled |
cha6.abn.green.sophos | Primary (ABN) | P3 | Akamai channels |
cha6.bos.green.sophos | DR (BOS) | P4 | disable_akamai_rsyncs active |
cha7.abn.green.sophos | Primary (ABN) | P3 | datadir/import channels |
cha7.bos.green.sophos | DR (BOS) | P4 | disable_akamai_rsyncs active |
chmetrics.abn.green.sophos | Metrics (ABN) | P3 | |
chmetrics.bos.green.sophos | Metrics DR (BOS) | P4 | |
pmuedge.abn.green.sophos | PMU Edge (ABN) | P3 | bandwidth-stats.csv growth |
BOS (Boston) = DR = P4 — next business day, ignore until ABN is resolved
Multiple channel alerts? Check antispam-publishing first — it's almost always the root cause
Archiver2 alerts are byproducts of channel issues
"SSH connection failed: All authentication methods failed"
Load your key: ssh-add ~/.ssh/id_rsa
Verify: ssh-add -l should show your key
If your key has a passphrase and isn't in the agent, you must ssh-add it first
Test manually: ssh your_username@cha3.abn.green.sophos
"ZABBIX_API_TOKEN not configured"
Create a token: Zabbix → User icon → API Tokens → Create
Add it to your MCP env config
"ATLASSIAN_EMAIL and ATLASSIAN_API_TOKEN not configured"
Create token: https://id.atlassian.com/manage-profile/security/api-tokens
Use your @sophos.com email as ATLASSIAN_EMAIL
MCP not showing up in your AI tool?
Verify the path to dist/index.js is correct and absolute (e.g., /Users/yourname/labs.platform-infra.channels-mcp/dist/index.js)
Check Node.js is installed: node --version (need 18+)
Do NOT run npm run dev manually — the AI tool starts the server itself
Restart your AI tool after config changes, or reconnect MCP servers
Check the MCP server panel for error messages
"BLOCKED: Command contains X which is not allowed"
This means the command safety filter caught a dangerous operation
The MCP is read-only by design — it cannot run yum, rm, service restart, etc.
If you need to run a blocked command, do it manually via SSH
Tools appear but SSH fails silently
The SSH_AUTH_SOCK is auto-detected on macOS, but if it fails, set it explicitly:
echo $SSH_AUTH_SOCK # copy this valueThen add "SSH_AUTH_SOCK": "your_value" to the env config
Acknowledge Zabbix alerts with a message and ticket reference.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | ||
| event_ids | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry full behavioral burden. It states the action but does not disclose side effects (e.g., whether acknowledgments are persistent, if notifications are sent, or if it requires specific permissions). Minimal value beyond the tool name.
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 a single sentence, concise and to the point. While it lacks structured form (e.g., bullet points), it efficiently communicates the core purpose without extraneous content.
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, no annotations, and sibling tools with overlapping purposes, the description fails to provide complete context. It does not explain what the tool returns, side effects, or how it differs from related tools like add_ticket_comment, leaving gaps for correct invocation.
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 description coverage is 0%. The description mentions a 'ticket reference' but no such parameter exists in the schema (only event_ids and message). The meaning of 'message' and the format of event_ids are not explained, leaving ambiguity for the agent.
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 action (Acknowledge), resource (Zabbix alerts), and includes context (with a message and ticket reference). However, it does not differentiate from sibling tools like add_ticket_comment or get_server_problems, leaving some ambiguity about its unique role.
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?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or conditions. The agent is left to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a comment to an existing Jira ticket.
| Name | Required | Description | Default |
|---|---|---|---|
| comment | Yes | ||
| ticket_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like idempotency, error handling, or permissions. It only states the basic action, leaving the agent uninformed about side effects or constraints.
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 a single sentence and is concise. However, it could be structured to front-load key information or provide a brief bullet list of parameters.
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 the lack of annotations and output schema, the description is incomplete. It fails to mention that the ticket must exist, comment length limits, or return behavior, leaving significant gaps for the agent.
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 description coverage is 0%, and the description adds no information about parameters. The agent must rely solely on parameter names, which provide minimal semantic context beyond what is obvious.
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 action (add a comment) and the target (existing Jira ticket). It is specific and distinguishes this tool from siblings like 'create_linfra_ticket' which creates tickets.
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?
No usage guidelines are provided. The description does not specify when to use this tool over alternatives, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if there is an active incident for antispam-publishing.labs.sophos (most common root cause for multiple channel alerts).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description indicates a read-only check but does not detail response format or side effects. Adequate but not thorough.
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?
Single sentence conveys purpose and context with zero waste.
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?
Lacks description of return value or output format; for a simple check, it is functional but leaves out what the agent should expect.
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?
No parameters exist, so description adds no param info beyond schema; baseline 4 applies.
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?
Description clearly states the tool checks for an active incident on a specific resource and explains its relevance as a common root cause, differentiating it from sibling tools.
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?
Implicitly suggests use when multiple channel alerts appear, but lacks explicit when-to-use or 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.
Read the latest entries from a specific channel's chan.log. SAFE: read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | Lines to read (default 50) | |
| hostname | Yes | ||
| channel_path | Yes | Full path to channel dir |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior. It states 'SAFE: read-only', indicating no side effects, but does not detail limits, error conditions, or return format. This provides moderate transparency but leaves gaps.
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?
Description is extremely concise: one sentence plus a safety note. It is front-loaded with the verb ('Read') and contains no unnecessary words or repetition.
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 covers purpose and safety but omits details about the output format, error handling, and behavior when the file does not exist. For a simple read-only tool with no output schema, this is adequate but not 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 description coverage is 67%, with hostname lacking a description. The description adds no parameter-level meaning beyond the schema's existing descriptions for lines and channel_path, failing to compensate for the missing hostname 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 uses specific verbs ('Read') and resources ('latest entries from a specific channel's chan.log'), clearly distinguishing it from sibling tools like check_antispam_publishing and check_large_files, which operate on different resources.
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?
No guidance on when to use this tool versus alternatives; no description of context or exclusions. The description only states the basic function without helping the agent decide between this and other check tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check for large files on a channel server that may trigger large_file_alert. SAFE: read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| hostname | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It correctly labels the tool as read-only, but does not disclose output behavior, error cases, or any other behavioral traits beyond safety.
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 very concise, with purpose stated in the first sentence and safety in the second. It is front-loaded but could add more value without losing brevity.
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 the simple input (one string parameter) and no output schema, the description omits what the check returns, how to interpret results, and any prerequisites. It is not complete enough for an agent to use confidently.
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 0%, and the description does not mention the 'hostname' parameter beyond the phrase 'on a channel server'. No details on format, examples, or purpose are provided.
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 tool checks for large files on a channel server that may trigger an alert. It uses a specific verb and resource, but doesn't explicitly differentiate from sibling tools like check_channel_log or check_antispam_publishing.
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 no guidance on when to use this tool vs. alternatives. The 'SAFE: read-only' note implies it can be run harmlessly, but no when/when-not or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a LINFRA Jira ticket with investigation findings.
| Name | Required | Description | Default |
|---|---|---|---|
| summary | Yes | ||
| description | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states creation, but lacks details on permissions, idempotency, errors, or side effects.
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?
Single sentence is concise but under-specified; it sacrifices completeness for brevity.
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?
No output schema, no annotations, and minimal description leave major gaps: return value, failure modes, required permissions, and prerequisites are absent.
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 description coverage is 0%, and the description adds no meaning beyond parameter names. 'summary' and 'description' are self-explanatory but no format or constraints are given.
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?
Clearly states 'Create a LINFRA Jira ticket with investigation findings', specifying the verb, resource, and context. Distinguishes from siblings like 'add_ticket_comment'.
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?
No guidance on when to use this tool versus alternatives like 'add_ticket_comment' or 'search_related_incidents'. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all active Zabbix problems/alerts for a channel server.
| Name | Required | Description | Default |
|---|---|---|---|
| hostname | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It states the tool retrieves active problems/alerts but does not disclose rate limits, authentication needs, pagination, or whether the data is real-time. Does not explain what 'channel server' means or the scope of 'active'.
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 a single sentence, concise but lacking structure. It front-loads the purpose but omits important details. For a simple tool, the length is acceptable but could be improved with brief additional context.
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?
Without output schema or annotations, the description should explain the output (e.g., format, fields) and context (e.g., what constitutes an active problem, how Zabbix is used). It fails to provide enough for an agent to confidently invoke the tool.
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 sole parameter 'hostname' is a required string with no description in the schema (0% coverage). The description does not clarify its meaning (e.g., Zabbix hostname, server name, or IP) or provide any format constraints, leaving the agent to guess.
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 uses a specific verb 'get' and resource 'active Zabbix problems/alerts for a channel server', clearly distinguishing it from siblings like 'list_channel_servers' (which lists servers) and 'investigate_server' (which may provide broader analysis).
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?
No guidance on when to use this tool versus alternatives. Does not mention when to prefer it over 'investigate_server' or how it differs from 'acknowledge_alerts' or 'search_related_incidents'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to a channel server, check all status JSONs (chirp, chmedic, chcheck, large_file_alert), and return categorized findings. SAFE: read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| hostname | Yes | Channel server hostname (e.g., cha3.abn.green.sophos) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It explicitly states 'SAFE: read-only', which is a clear behavioral trait. It also explains that it connects to a server and checks specific JSON files. However, it does not detail what 'categorized findings' means or describe error handling, but for a read-only tool, this is mostly sufficient.
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?
Two sentences, no wasted words. The first sentence conveys the action and specifics, the second adds a safety qualifier. Perfectly concise and front-loaded.
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?
With one simple parameter and no output schema, the description is nearly complete. It covers purpose, actions, and safety. The only minor gap is that it does not explain the structure of 'categorized findings', but given the tool's simplicity, this is acceptable.
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 description coverage is 100% (the single parameter 'hostname' is documented with an example). The description adds no additional meaning beyond the schema's own description, so it meets the baseline but provides no extra value.
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 action ('Connect', 'check', 'return'), the resource ('channel server'), and the specific items checked ('chirp, chmedic, chcheck, large_file_alert'). It distinguishes from sibling tools by being comprehensive, covering multiple status JSONs, whereas siblings like check_channel_log or check_large_files are more specific.
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 implies a comprehensive health check but does not explicitly guide when to use this tool versus more targeted siblings. It lacks statements about when to choose this over alternatives, which reduces clarity for an AI agent deciding between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all channel servers with their roles, Zabbix IDs, and priorities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It describes the output but does not disclose any behavioral traits like authentication needs, rate limits, or potential side effects. For a simple read-only list, this is adequate but lacks depth.
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?
A single, direct sentence with no unnecessary words. Front-loaded with the key action and output details.
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 zero parameters and no output schema, the description is complete enough for a simple list. It specifies what is returned. Could mention if there are any defaults or limitations, but not strictly necessary.
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?
No parameters exist, so baseline is 4. The description adds no param info beyond the empty schema, but nothing is needed.
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 'List' and the resource 'channel servers', and specifies the returned fields (roles, Zabbix IDs, priorities). It distinguishes from sibling tools which are action-oriented (e.g., acknowledge_alerts, create_linfra_ticket).
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?
No guidance on when to use this tool versus alternatives. While it's the only server-listing tool among siblings, there is no explicit usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct action or resource (e.g., acknowledge_alerts vs. get_server_problems) with clear boundaries, so an agent can reliably select the correct tool.
All tool names follow a consistent verb_noun pattern using lowercase and underscores (e.g., check_channel_log, list_channel_servers) with no mixing of conventions.
10 tools are well-scoped for the channel server management domain, covering monitoring, alerting, and Jira integration without being overwhelming.
Core workflows (listing, investigating, acknowledging alerts, creating tickets) are present, but missing operations like closing incidents or updating alerts beyond acknowledgment create minor gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
AI-powered incident management and server monitoring via MCP.
Connect AI assistants to Xitoring monitoring: servers, uptime, incidents, metrics, SSL, and alerts.
AI agent run monitoring with incident replay and SLA receipts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pavanbhatt19/labs.platform-infra.channels-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
