Skip to main content
Glama
Subrat2018

Zendesk Live MCP

by Subrat2018
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Zendesk Live MCP

Read-only MCP server for complete, reconciled reporting from live Zendesk data.

It is designed for Cursor and other MCP clients. It does not use an archived SQLite database and does not modify Zendesk records.

Goal

Expose read-only Zendesk reporting tools to Cursor so users can ask questions like:

  • Give me a dashboard for last 6 months tickets based on Version.

  • Give me a report for customer XYZ grouped by Primary Area for Improvement for last 3 months.

  • Give me a report for assignee grouped by customers for last 3 months.

Related MCP server: flin-shopify-analytics-mcp

Requirements

  • Windows, macOS, or Linux

  • Python 3.10 or newer

  • Zendesk account with permission to read the required tickets and metadata

  • Zendesk API token

  • Cursor or another stdio-compatible MCP client

Install From Source

Clone the repository and enter its directory:

git clone https://github.com/Subrat2018/ZendeskLiveMCP.git
cd ZendeskLiveMCP

Create and activate a virtual environment:

python -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install -e .

On macOS or Linux:

python3 -m venv .venv
source .venv/bin/activate
python -m pip install -e .

Copy .env.example to .env and enter the Zendesk credentials:

ZENDESK_SUBDOMAIN=your-subdomain
ZENDESK_EMAIL=you@example.com
ZENDESK_API_TOKEN=your-token

# Optional:
# ZENDESK_BASE_URL=https://your-subdomain.zendesk.com

Required values:

  • ZENDESK_SUBDOMAIN: the part before .zendesk.com

  • ZENDESK_EMAIL: email belonging to the Zendesk API-token owner

  • ZENDESK_API_TOKEN: Zendesk API token, not the account password

Use a dedicated read-only reporting/service account where possible.

Verify

List the available live Zendesk report fields:

python -m zendesk_mcp list-fields

Example report:

python -m zendesk_mcp report --field "Version" --months 6

Customer-filtered report:

python -m zendesk_mcp report --field "Primary Area for Improvement" --months 3 --filter Customer=XYZ

Cursor MCP Config

Use the absolute path to the virtual-environment Python executable. On Windows:

{
  "mcpServers": {
    "zendesk-live": {
      "type": "stdio",
      "command": "C:/path/to/zendesk-live-mcp/.venv/Scripts/python.exe",
      "args": ["-m", "zendesk_mcp"],
      "cwd": "C:/path/to/zendesk-live-mcp"
    }
  }
}

On macOS or Linux:

{
  "mcpServers": {
    "zendesk-live": {
      "type": "stdio",
      "command": "/path/to/zendesk-live-mcp/.venv/bin/python",
      "args": ["-m", "zendesk_mcp"],
      "cwd": "/path/to/zendesk-live-mcp"
    }
  }
}

Fully restart Cursor after changing its MCP configuration.

Test

Run the offline test suite:

python -m unittest discover -s tests -v

The tests cover complete-dataset caching, exact calendar-month handling, and rejection of reports whose ticket counts do not reconcile.

Architecture

See ARCHITECTURE.md for the component design, complete-report algorithm, correctness contract, cache behavior, security model, and failure handling.

MCP Tools

  • build_ticket_dashboard: preferred tool for dashboards with several sections; fetches tickets once.

  • list_report_fields: returns a compact list of available fields by default.

  • dashboard_by_field: groups recent tickets by one field.

  • run_ticket_report: supports filters plus one or more group-by fields.

  • search_live_tickets: searches live tickets and returns compact ticket rows.

  • get_live_ticket_detail: fetches one live ticket with optional comments.

Notes

  • This tool is read-only.

  • It uses live Zendesk APIs, not the local SQLite archive.

  • Metadata lookups are cached under ZendeskMCP/.cache to reduce Zendesk API calls.

  • Complete live ticket windows are cached for 30 minutes so follow-up reports reuse the same reconciled dataset.

  • Reports use Zendesk Search Count and include every matching ticket.

  • Date windows with up to 1,000 tickets use the faster Search API and are reconciled by unique ticket ID.

  • Larger windows are automatically split into smaller date slices so each query stays within Zendesk's 1,000-result search limit.

  • Cursor-paginated Search Export is used only if a single day exceeds 1,000 tickets.

  • Search Export uses Zendesk's recommended page size of 100 for reliable performance with archived tickets.

  • Tickets are deduplicated by Zendesk ticket ID.

  • A report is returned only when the count before export, count after export, and unique exported ticket count match.

  • Report responses include report_mode, completeness, zendesk_api_requests, cache_hit, and elapsed_seconds.

  • Reports include a UTC generation timestamp and note Zendesk's possible search-index delay for newly changed records.

  • Use build_ticket_dashboard for multi-section dashboards instead of asking for separate reports.

Optimized Cursor Prompts

These prompts are written to minimize Zendesk API calls and OpenAI token usage. They tell Cursor to use one MCP call, avoid duplicate reports, and reuse cached ticket data.

General Management Dashboard

Use the zendesk-live MCP build_ticket_dashboard tool exactly once.
Create an executive dashboard for tickets created during the last 6 months.
Include breakdowns by Status, Priority, Type, and Created Month.
Limit each displayed section to 15 results.
Do not call list_report_fields and do not run separate reports for each section.
Show total tickets, important trends, and a concise management summary.
Present the dashboard only if completeness.status is passed.
Show expected_count, unique_ticket_count, cache_hit, and zendesk_api_requests.

Priority Over Time

Use the zendesk-live MCP build_ticket_dashboard tool exactly once.
Create a dashboard for the last 6 months using Priority and Created Month as dimensions.
Do not make separate MCP calls for Priority and Created Month.
Present the result as a priority distribution, monthly trend, key observations, and management actions.
Confirm that completeness.status is passed before presenting conclusions.

Status, Time, and Priority

Use build_ticket_dashboard exactly once for tickets created during the last 6 months.
Use the dimensions Status, Created Month, and Priority.
Use limit_per_section 20.
Do not call run_ticket_report separately for each dimension.
Summarize status distribution, monthly ticket volume, priority distribution, and notable risks.
Include the completeness reconciliation values.

Ticket Volume by Month

Use build_ticket_dashboard exactly once.
Create a ticket-volume dashboard for the last 12 months using Created Month as the primary dimension.
Also include Status and Priority.
Do not call list_report_fields or make separate report calls.
Show the busiest months and confirm the report reconciliation passed.

Agent and Time

Use the zendesk-live MCP build_ticket_dashboard tool exactly once.
Create a dashboard for the last 3 months using Assignee and Created Month as dimensions.
Use limit_per_section 20.
Do not run separate reports for each agent.
Show ticket distribution by agent, monthly volume, workload concentration, and unassigned tickets.
Do not present the report if completeness.status is not passed.

Customer and Agent

Use build_ticket_dashboard exactly once for tickets created during the last 3 months.
Use Customer and Assignee as dimensions.
Use limit_per_section 25.
Do not call run_ticket_report separately for customers and agents.
Summarize the highest-volume customers, busiest agents, workload concentration, and any unspecified values.
Show expected_count and unique_ticket_count.

One Customer Grouped by Agent

Replace XYZ with the required customer name.

Use build_ticket_dashboard exactly once.
Create a dashboard for customer XYZ covering the last 3 months.
Apply one filter: Customer contains XYZ.
Use Assignee, Status, Priority, and Created Month as dimensions.
Do not make separate MCP calls.
Show agent workload, ticket status, priority mix, monthly volume, and key observations.
Present results only when completeness.status is passed.

One Agent Grouped by Customer

Replace AGENT NAME with the required Zendesk assignee.

Use build_ticket_dashboard exactly once.
Create a dashboard for assignee Tom covering the last 3 months.
Apply one filter: Assignee equals Tom.
Use Customer, Status, Priority, and Created Month as dimensions.
Do not make separate MCP calls.
Highlight the main customers handled by this agent and the ticket status and priority mix.
Present results only when completeness.status is passed.

Version and Area for Improvement

Use the zendesk-live MCP build_ticket_dashboard tool exactly once.
Create a dashboard for tickets created during the last 3 months.
Use Version, Primary Area for Improvement, Secondary Area for Improvement, and Created Month as dimensions.
Use limit_per_section 20.
Do not run separate reports for each custom field.
Summarize the most affected versions, main improvement areas, missing field values, and monthly trends.
Include the completeness reconciliation values.

Version, Component, and Issue Type

Use build_ticket_dashboard exactly once for the last 6 months.
Use Version, Component, Issue Type, and Created Month as dimensions.
Use limit_per_section 20.
Do not call list_report_fields unless a requested field is rejected.
Identify the versions and components generating the most tickets and summarize the issue-type distribution.
Do not present conclusions unless completeness.status is passed.

Production Issues by Impact

Use build_ticket_dashboard exactly once for the last 6 months.
Apply one filter: Environment equals Production.
Use Impact, Priority, Status, Component, and Created Month as dimensions.
Use limit_per_section 20.
Do not make separate MCP calls.
Focus the summary on high-impact production risks and recurring components.
Include expected_count and unique_ticket_count.

Escalated Tickets

Use build_ticket_dashboard exactly once for the last 6 months.
Apply one filter: Escalated equals true.
Use Customer, Assignee, Priority, Status, and Primary Area for Improvement as dimensions.
Use limit_per_section 20.
Do not run separate reports.
Summarize which customers, agents, priorities, and improvement areas appear most often.
Confirm completeness.status is passed.

Open High-Priority Tickets

Use build_ticket_dashboard exactly once for the last 3 months.
Apply these filters:
- Priority in high, urgent
- Status not_in solved, closed
Use Customer, Assignee, Component, and Created Month as dimensions.
Do not call separate report tools.
Present the result as a concise operational risk dashboard.
Show the completeness reconciliation values.

Detailed Cross-Grouped Report

Use this pattern only when a combined row for each field combination is required. It uses run_ticket_report once rather than multiple calls.

Use the zendesk-live MCP run_ticket_report tool exactly once.
For the last 3 months, group tickets by Assignee and Customer together.
Use limit 50 and include_examples false.
Do not call list_report_fields unless the tool rejects a field.
Present the returned combinations in a table sorted by ticket_count.
Mention completeness.status, expected_count, unique_ticket_count, cache_hit, and zendesk_api_requests.

Filtered Cross-Grouped Report

Use run_ticket_report exactly once.
For customer XYZ during the last 3 months:
- Filter Customer contains XYZ
- Group by Primary Area for Improvement and Version together
- Use limit 40
- Keep include_examples false
Do not call any other Zendesk report tool.
Summarize the largest field combinations only if completeness.status is passed.

Prompt Guidelines

  • Use build_ticket_dashboard for several independent dashboard sections.

  • Use run_ticket_report only when fields must be combined into rows, such as Assignee + Customer.

  • Include exactly once to discourage Cursor from issuing duplicate MCP calls.

  • Avoid list_report_fields when the field names are already known.

  • Ask Cursor to mention completeness.status, expected_count, unique_ticket_count, zendesk_api_requests, and cache_hit.

  • Require completeness.status to be passed before the report is presented as final.

  • Follow-up queries should use the same month window so the 30-minute complete ticket cache can be reused.

  • Narrow the date range or add a customer, agent, status, or priority filter when faster execution is needed.

Available Tools

6 tools
build_ticket_dashboardB

Preferred tool for complete management dashboards. Fetches and reconciles every matching ticket, then produces multiple breakdowns from one shared dataset. Call this exactly once per dashboard.

ParametersJSON Schema
NameRequiredDescriptionDefault
monthsNo
filtersNo
dimensionsNoDashboard sections, for example Status, Priority, Type, Created Month.
limit_per_sectionNo

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses that the tool fetches and reconciles every matching ticket and produces breakdowns from one shared dataset, hinting at heavy or expensive work and the importance of a single call. However, it does not mention permissions, side effects, rate limits, or what the response contains.

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?

The description is two sentences with no fluff. The first sentence establishes purpose and preference; the second explains core behavior and a critical usage constraint. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex (multiple breakdowns, shared dataset, 4 params) but has no output schema and minimal annotations. The description leaves out return format, data volume implications, how filters/dimensions interact, and what 'breakdowns' concretely means. This is incomplete for an agent deciding whether and how to invoke it.

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 only 25% (only 'dimensions' has a description). The tool description mentions 'matching ticket' and 'breakdowns,' which vaguely relates to filters and dimensions, but does not explain months, limit_per_section, or how they influence the result. This is insufficient compensation for the low schema coverage.

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 the tool fetches and reconciles every matching ticket, then produces multiple breakdowns. It distinguishes itself as the 'preferred tool for complete management dashboards' and includes a unique instruction to call exactly once, which differentiates it from sibling tools. However, it does not explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: it is preferred for complete management dashboards and should be called exactly once per dashboard. This implies when to use it, but it does not mention when not to use it or explicitly point to alternatives like dashboard_by_field or run_ticket_report.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

dashboard_by_fieldB

Create one complete reconciled grouped breakdown. For several sections, use build_ticket_dashboard.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
monthsNo
filtersNo
field_nameYes

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden, but it only says 'Create' without explaining if it's a read-only report or a mutating operation, nor does it disclose any limitations such as pagination or defaults. The word 'Create' could mislead an agent into thinking it's a state-changing operation.

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 short sentences, front-loaded with the action, and no filler. The distinction from build_ticket_dashboard is efficient and valuable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 4 parameters, no annotations, no output schema, and the description is minimal. It lacks parameter explanations, behavioral details, and return expectations. The mention of 'reconciled' and 'complete' raises questions rather than answering them.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description provides no information about any parameters (field_name, limit, months, filters). The agent has to rely on names alone, which is insufficient.

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 states it creates a 'complete reconciled grouped breakdown', which is specific about the action and output. It also distinguishes from sibling build_ticket_dashboard by noting that tool is for several sections. However, 'reconciled' is not explained and could be ambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'For several sections, use build_ticket_dashboard', providing a clear alternative and a condition for when not to use this tool. However, it doesn't mention other sibling tools like run_ticket_report or list_report_fields, so coverage is partial.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_live_ticket_detailB

Fetch one live Zendesk ticket, optionally including comments.

ParametersJSON Schema
NameRequiredDescriptionDefault
ticket_idYes
include_commentsNo

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It indicates a read-only fetch via 'Fetch', but does not disclose potential limitations, authentication requirements, error behavior, or any other side effects. This is a significant gap for a tool with no annotation support.

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?

The description is a single, front-loaded sentence with no redundant information. It earns its place by stating the core action and the optional comment inclusion without wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description should help the agent understand what the response contains. It only says 'ticket' without specifying fields or structure. It also lacks information on error handling and edge cases, making it incomplete for a tool with no annotations and no output schema.

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%, so the description must compensate. It does clarify that ticket_id identifies the specific ticket and that include_comments optionally includes comments, adding meaning beyond the bare parameter names. However, it does not explain types or defaults (already in schema) or any additional semantics, so it is only partially compensating.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action: fetch a single live Zendesk ticket, with an optional comments flag. The verb 'Fetch' and resource 'one live Zendesk ticket' are precise, and it distinguishes from sibling tools like search_live_tickets and report tools by focusing on a single ticket detail.

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 for retrieving one specific ticket, but it does not explicitly state when to use this tool versus alternatives like search_live_tickets. There is no mention of exclusions or alternative tools, so the guidance is only implied by the tool's purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_report_fieldsA

List report field names. Results are metadata-cached and compact by default.

ParametersJSON Schema
NameRequiredDescriptionDefault
include_detailsNoReturn verbose field metadata only when explicitly needed.

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of disclosing behavior. It reveals that results are metadata-cached (performance/consistency behavior) and compact by default (response format). This goes beyond a simple restatement and gives useful context, though it does not mention potential staleness or whether the operation is read-only, which is likely but not stated.

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?

The description is exceptionally concise at two sentences, with the main purpose front-loaded and no filler. Every word earns its place, and the additional behavioral note is tightly integrated.

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?

For a simple one-parameter list tool with no output schema, the description covers the essential aspects: what it lists, the cached nature, and the default compact format. It lacks information about pagination or response shape, but given the low complexity and the parameter's schema description, the description is largely sufficient for an agent to use the tool correctly.

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?

The schema already provides 100% coverage for the sole parameter 'include_details' with a clear description, so the baseline is 3. The tool description adds contextual value by noting 'compact by default,' which pairs with the parameter's purpose, but it does not add new semantic information beyond what the schema already explains.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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 'report field names', which precisely defines the tool's function. It is distinct from sibling tools like 'build_ticket_dashboard' and 'run_ticket_report', which focus on dashboards and reports rather than listing field metadata.

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?

The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The mention of 'metadata-cached and compact' implies a lightweight use case, but this is not directly stated as a recommendation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_ticket_reportA

Run one complete reconciled report with combined group-by fields. Do not call this repeatedly to build a multi-section dashboard; use build_ticket_dashboard.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
monthsNo
filtersNo
group_byYes
include_examplesNo

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behavioral traits. However, it only mentions the report is 'reconciled' and not to call repeatedly. It does not state whether the operation is read-only, what side effects occur, or what happens if called repeatedly. The 'do not call repeatedly' note is more of a usage guideline than a behavioral disclosure.

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?

The description is two sentences, front-loaded with the core purpose and immediately followed by a clear usage exclusion. Every word earns its place—no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description gives purpose and usage, but with 5 parameters, no output schema, and no annotations, it leaves critical gaps: what 'reconciled' means, what the output format is, what each parameter does, and any side effects. This is not complete enough for an agent to confidently invoke without further clarification.

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%, so the description must compensate for parameter meaning. It only references 'combined group-by fields,' which touches on group_by but leaves limit, months, filters, and include_examples unexplained. This is insufficient for a 5-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Run one complete reconciled report with combined group-by fields.' It also distinguishes from sibling build_ticket_dashboard by explicitly saying not to use this tool repeatedly for dashboards. The verb 'run' and resource 'report' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when not to use the tool: 'Do not call this repeatedly to build a multi-section dashboard; use build_ticket_dashboard.' This clearly routes to the appropriate alternative sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_live_ticketsC

Search live Zendesk tickets with a Zendesk search query fragment and recent date window.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
monthsNo

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries the full burden of behavioral disclosure. It mentions 'live' and 'recent date window' but does not disclose return format, pagination behavior, the meaning of 'live', or how the date window is applied. This leaves significant unknowns for a search tool.

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?

The description is a single sentence with no wasted words and front-loads the verb 'Search'. However, it could benefit from a more structured presentation, such as mentioning key parameters or example usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 parameters, no annotations, no output schema, and several siblings, the description is under-specified. It does not explain the return format, the meaning of 'live', or how to construct the query, leaving the agent without enough context to reliably invoke the tool.

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%, so the description must compensate. It references a query fragment (mapping to 'query') and a recent date window (likely 'months'), but the 'limit' parameter is completely undocumented. The phrase 'recent date window' is vague and does not clarify the parameter's behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches live Zendesk tickets using a Zendesk search query fragment and a recent date window. This distinguishes it from sibling tools like get_live_ticket_detail (which retrieves a single ticket detail) and report-generation tools.

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 explicit guidance is given about when to use this tool versus alternatives. The description implies a search use case but does not mention exclusions or when to prefer sibling tools like get_live_ticket_detail or run_ticket_report.

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. Dates show when Glama detected each change.

  1. 6 tool updatesv1.0.0
    • First observedbuild_ticket_dashboard
    • First observeddashboard_by_field
    • First observedget_live_ticket_detail
    • First observedlist_report_fields
    • First observedrun_ticket_report
    • First observedsearch_live_tickets
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation3/5

The three reporting tools (build_ticket_dashboard, dashboard_by_field, run_ticket_report) have overlapping purposes as they all produce ticket reports, though descriptions distinguish complete dashboards from single breakdowns and custom grouped reports. An agent could still confuse dashboard_by_field with run_ticket_report, but the guidance (e.g., 'use build_ticket_dashboard') helps.

Naming Consistency4/5

Five tools follow a clear verb_noun pattern (list, build, run, search, get), but dashboard_by_field breaks the pattern with a noun-phrase style, creating a minor inconsistency.

Tool Count5/5

Six tools is a reasonable number for a Zendesk reporting server, with no redundant or extraneous tools.

Completeness4/5

The tool set covers field discovery, ticket searching, detail retrieval, and multiple reporting/breakdown capabilities. The only notable gap is the lack of a direct 'list all tickets' tool, but search_live_tickets can fulfill this, so it's a minor gap.

Maintenance

ActivityStale
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Subrat2018/ZendeskLiveMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server