Zendesk Live MCP

build_ticket_dashboard

Fetches and reconciles all matching Zendesk tickets into one dataset, then generates multiple dashboard breakdowns (status, priority, type, etc.) for complete management reporting.

Instructions

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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "build_ticket_dashboard"
  }
}

Input Schema

Name	Required	Description
`months`	No
`filters`	No
`dimensions`	No	Dashboard sections, for example Status, Priority, Type, Created Month.
`limit_per_section`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Aug 6, 2026

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.

Deploy Server