Skip to main content
Glama
Sign In
Zendesk MCP Server by Fruggr

Zendesk MCP Server by Fruggr

by fruggr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Reply on My Request

add_request_comment

Reply publicly to one of your own Zendesk requests, optionally attach files, and confirm the resulting status so you know if the reply reopened a solved request.

Instructions

Reply on one of the signed-in user's own requests, optionally attaching files. Returns confirmation with the request's status after the reply, which matters because replying on a request that was already solved REOPENS it — Zendesk moves it back to open, and the user should know that is what their message did. The comment is always public: end users cannot post internal notes, and Zendesk silently ignores any attempt to mark one private. A closed request rejects new comments outright. Agents replying to a requester want add_public_comment, or add_private_note for an internal note.

Input Schema

NameRequiredDescriptionDefault
bodyYesThe message to send. Visible to the support agents on the ticket and included in their email notification. Sent as plain text: neither Markdown nor HTML is rendered for an end user (both show as literal text), so write it without formatting markup.
request_idYesNumber of the request to reply on, as shown by list_requests.
attachmentsNoFiles to attach to this reply, such as a screenshot or a log, with their content base64-encoded.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.9.1

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses the non-obvious side effect that replying to a solved request REOPENS it, that comments are always public because end users cannot post internal notes and private flags are silently ignored, and that a closed request rejects comments outright. These are exactly the behavioral traits an agent could not infer from readOnlyHint/destructiveHint/idempotentHint.

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?

Front-loads purpose, then conventions, then alternatives, so an agent gets the essentials in the first clause. A few phrases are rhetorically padded ('which matters because', 'the user should know that is what their message did') though they do carry meaning about user-facing consequences.

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

Completeness5/5

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

For a mutating, attachment-bearing tool with no output schema, the description covers the return value (confirmation with the request's status), side effects, and a failure mode. It gives the agent everything needed to call it correctly and to anticipate the consequence.

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 100%, so the parameters are already documented, including plain-text body rendering and base64 attachment limits. The description adds only that files are optionally attached to the reply, which is largely a restatement of the schema. Baseline 3 is appropriate.

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?

States a specific verb and resource — 'Reply on one of the signed-in user's own requests' — and scopes it to the caller's own requests, with optional file attachments. It is immediately distinguishable from the named siblings add_public_comment and add_private_note.

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?

Explicitly routes the agent: agents replying to a requester should use add_public_comment, and internal notes belong to add_private_note. It also names a condition under which the call is unnecessary or unsafe (a closed request rejects comments), leaving nothing to inference.

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

Deploy Server

Other Tools