A
licenseA
qualityD
maintenanceEnables AI agents to audit and analyze Zendesk instances through a read-only MCP interface, providing tools for triggers, automations, analytics, and cross-reference queries.
74
MIT
triage-mcp
by aminafara123
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., "@triage-mcpanything urgent sitting in the triage queue?"
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.
triage-mcp
An MCP server over my ai-triage-agent queue. A local LLM classifies support tickets and drafts replies, a human approves or rejects every one, and this server lets any MCP-capable AI client read that queue and the decision log.
It answers questions like "whats waiting for review?" or "what did I reject this week and why?" straight from the files the agent writes. Four tools, all read-only. The model can look at the queue but it cant approve, reject or send anything.
Tools
Tool | What it does |
| Counts for inbox, pending review by priority, outbox and logged decisions |
| Tickets waiting for review, most urgent first, optional priority filter |
| Latest human decisions from the audit log, newest first |
| Search the decision log by id, outcome, category, priority or reject reason |
Related MCP server: Ticket Queue MCP Server
Setup
pipx install triage-mcpuvx triage-mcp works too if you prefer no install. Hacking on a clone instead:
python3 -m venv .venv
.venv/bin/pip install mcpIt reads ~/aiProjects/aminWork/automation-portfolio/ai-triage-agent/. Point TRIAGE_DATA_DIR at your own data folder if your copy lives somewhere else.
Wire it into Claude Code:
claude mcp add triage -- triage-mcpRunning from a clone, point it at the venv instead:
claude mcp add triage -- /path/to/triage-mcp/.venv/bin/python /path/to/triage-mcp/triage_mcp.pyDemo
What it looks like from Claude Code:
> anything urgent sitting in the triage queue?
⏺ triage · pending_items()
2 pending item(s):
demo-014 P1 security_incident -> security-team (high): User entered their password on a fake helpdesk link and asks what to do next.
demo-017 P3 software_issue -> service-desk (medium): Spreadsheet app crashes when opening one monthly report file.
⏺ One P1. demo-014 looks like a phishing hit and is routed to security.
Id review that one first. The Excel crash can wait.The tickets above are demo data. The format is exactly what the server returns.
Design notes
Read-only by construction. No tool writes to the queue, the outbox or the log. Approving stays in
review.pywith a human at the keyboard.Only metadata crosses the protocol. Ticket bodies, extracted entities and reply text never leave the server. Summaries and reject reasons are cut to 100 characters with emails and home paths masked.
Small on purpose. One file, standard library plus the
mcpSDK.
Honest notes
It only reads what ai-triage-agent has already written. With an empty
pending/folder most answers are zeros, which is normal between triage runs.The masking is regex based. It catches emails and home paths, not names written into a summary.
All ticket content in the demo and the tests is made up. The logic is tested against a synthetic queue in
test_server.py. Runpython test_server.py.
About
Al Amin Bashir Afara, Dubai · github.com/aminafara123 · linkedin.com/in/aminafara
Available Tools
4 toolspending_itemsBRead-onlyIdempotent
Tickets waiting for human review, most urgent first, with category, route, model confidence and a short summary. Optional priority filter like "P1".
| Name | Required | Description | Default |
|---|---|---|---|
| priority | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the sorting order ('most urgent first') and the returned fields, which is useful context beyond annotations, but does not disclose rate limits, auth needs, or pagination 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?
Two sentences, tightly written, front-loading the core purpose followed by the return shape and optional filter. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return value explanation isn't required, and annotations cover safety. However, the description omits parameter format details (e.g., valid priority values) and does not explain pagination or result limits, leaving gaps for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter 'priority' has no description in the schema. The description mentions 'Optional priority filter like "P1"', which provides a concrete example value and clarifies the parameter's purpose, but lacks format details or enum alternatives. Given low coverage, more compensation is expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: tickets waiting for human review, returning urgent-first with category, route, model confidence and a short summary. This is specific and distinguishable from siblings like queue_status, recent_decisions, and search_decisions, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (waiting for human review) but provides no explicit when-to-use or when-not-to-use guidance, nor does it name alternatives. The priority filter mention is a usage hint, but the guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
queue_statusBRead-onlyIdempotent
Counts across the pipeline: inbox, pending review by priority, outbox, and logged decisions by outcome.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the value that results are broken down by queue stage and by priority/outcome, but says nothing about freshness, cost, or whether counts are live.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, and the core concept (counts across the pipeline) is front-loaded. It is efficient, though the trailing breakdown list is dense.
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?
With an output schema covering return shape and annotations covering the safety profile, the description only needs to convey scope; it does so by enumerating the counted dimensions. Nothing critical to calling it is missing, though the lack of routing against siblings is the one gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4 per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (counts) and the resources it aggregates (inbox, pending review by priority, outbox, logged decisions by outcome). An agent can tell it is a status/summary tool, though it never names or differentiates itself from the siblings (pending_items, recent_decisions, search_decisions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not-to-use, or alternative routing is given. The agent must infer that this is the summary tool versus the listing tools (pending_items, recent_decisions) purely from the word 'counts' and the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recent_decisionsBRead-onlyIdempotent
The latest human decisions from the audit log, newest first: what the AI proposed and whether the reviewer approved, edited or rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the shape of the underlying data (proposal vs. approval/edit/rejection), but says nothing about truncation, pagination, or how 'latest' is bounded — real behavioral gaps for a list endpoint.
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?
One sentence, front-loaded with the resource and scope, and the colon-clause about record contents is information-dense with no filler. Nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and annotations cover safety. What remains missing is any treatment of the limit parameter and any routing guidance versus the three siblings — enough that the definition is only minimally viable for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter (limit, default 10) has 0% schema description coverage and the description never mentions it, so an agent gets no guidance on the maximum, default behavior, or whether omitting it returns everything. The description does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific resource (human decisions from the audit log) and states ordering plus the content of each record (proposal + reviewer outcome). It doesn't explicitly distinguish itself from the sibling search_decisions, but the 'latest/newest first' framing makes the recency scope clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'latest ... newest first' suggests this is the recency view rather than a query tool, but the description never states when to prefer it over search_decisions or how it relates to queue_status/pending_items. No prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_decisionsBRead-onlyIdempotent
Case-insensitive search over the decision log by ticket id, outcome, AI category, priority or reject reason.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is low. The description usefully adds that matching is case-insensitive and which fields are searched, but says nothing about match type (substring vs exact), result limits, or ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with no filler; the searchable-field list is the densest useful information it carries. It could be marginally tighter but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and annotations cover the safety profile. Still, for a search tool with a single undocumented free-text parameter, the definition omits match semantics and result behavior, leaving the agent to guess at query construction.
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 0% for the single 'query' parameter, so the description must carry the burden. It partially does so by enumerating the searchable fields, but doesn't explain syntax, whether the value spans all fields or one, or how multiple terms combine.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (decision log), and enumerates the searchable fields (ticket id, outcome, AI category, priority, reject reason). This lets an agent distinguish it from the sibling recent_decisions, though the differentiation is implicit rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is given, no prerequisites, and no alternatives named despite three siblings (queue_status, pending_items, recent_decisions). The agent must infer that this is the free-text lookup tool for the decision log.
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.
4 tool updates
v1.0.1- First observed
pending_items - First observed
queue_status - First observed
recent_decisions - First observed
search_decisions
TDQS
A3.5/5.0
Scored across 4 tools
Disambiguation4/5
Each tool has a distinct primary purpose: queue_status gives counts, pending_items lists reviewable tickets, recent_decisions browses the audit log, and search_decisions queries that same log. There is mild overlap between queue_status/pending_items and between recent_decisions/search_decisions, but the descriptions clearly separate them.
Naming Consistency4/5
All names use consistent snake_case and follow a two-part modifier+noun pattern (queue_status, pending_items, recent_decisions, search_decisions). The only minor deviation is search_decisions using a verb_noun form while the others are noun/noun or adjective/noun.
Tool Count5/5
Four tools is well-scoped for a read-oriented triage inspection/audit server. Each tool covers a distinct facet (status counts, pending list, recent decisions, decision search) without redundancy.
Completeness3/5
The surface covers read/inspection operations well, but there is no tool to submit a decision (approve, edit, reject) or otherwise act on a ticket. For a triage workflow, that is a notable missing write operation that limits the set to monitoring only.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Read-only, deterministic AI triage and readiness tools implementing Sophon's published rubrics.
A paid remote MCP for AI SDK data query MCP, built to return verdicts, receipts, usage logs, and aud
Read-only MCP tools for AI agent discovery, structured resources, and NIULAI information.
Read-only GitHub bounty, agent harness, Actions failure, flake, and MCP tool-drift decisions.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceEnables AI clients to access and manage an internal support ticket queue through MCP tools, resources, and prompts, including searching and viewing tickets, adding comments, closing tickets with confirmation, reading knowledge base articles, and viewing queue summaries over OAuth-secured Streamable HTTP.-
- AlicenseBqualityCmaintenanceEnables MCP-compatible agents to perform read-only incident investigations by querying logs, building timelines, searching runbooks, validating evidence, and creating ticket drafts only with explicit approval.7MIT
- FlicenseNot gradedqualityAmaintenanceEnables AI agents and MCP clients to query and debug trace data, sessions, exceptions, route decisions, metrics, prompts, datasets, and annotation queues. Supports configurable tool groups and read-only safety modes.-