Skip to main content
Glama
WYRE-AI

gorelo-mcp

by WYRE-AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

gorelo_list_ticket_comments

Read-only

Retrieve comments from a ticket using cursor pagination, ordered oldest-first by default for conversation flow. Supports sorting and filtering by conversation type.

Instructions

Lists the comments on a ticket using cursor pagination. Comments read oldest-first by default, like a conversation top to bottom.

Input Schema

NameRequiredDescriptionDefault
cursorNoOpaque pagination cursor from a previous page; omit for the first page.
sortByNoSort field: createdOn.
pageSizeNoNumber of items per page. Clamped to 1–200 (default 50).
ticketIdYesTicket identifier.
sortOrderNoSort direction: asc (default) or desc.
conversationIdNoIdentifier of the single conversation to read, from the conversations endpoint. Requires a single conversationType.
conversationTypeNoKinds to include: 1 Public, 2 Private, 3 Side Conversation, 4 Approval. Comma-separated on its own; a single value when paired with conversationId.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv1.1.1
    • addedInput schema / properties / conversationId / description
      Added value: +"Identifier of the single conversation to read, from the conversations endpoint. Requires a single conversationType."
    • addedInput schema / properties / conversationType / description
      Added value: +"Kinds to include: 1 Public, 2 Private, 3 Side Conversation, 4 Approval. Comma-separated on its own; a single value when paired with conversationId."
    • addedInput schema / properties / conversationType / items
      Added value: +{
+  "type": "string"
+}
    • changedInput schema / properties / conversationType / type
      Previous value: -"string"New value: +"array"
    • addedInput schema / properties / cursor / description
      Added value: +"Opaque pagination cursor from a previous page; omit for the first page."
    • addedInput schema / properties / pageSize / description
      Added value: +"Number of items per page. Clamped to 1–200 (default 50)."
    • changedInput schema / properties / pageSize / type
      Previous value: -"number"New value: +"integer"
    • addedInput schema / properties / sortBy / description
      Added value: +"Sort field: createdOn."
    • addedInput schema / properties / sortOrder / description
      Added value: +"Sort direction: asc (default) or desc."
    • removedInput schema / properties / sortOrder / enum
      Removed value: -[
-  "asc",
-  "desc"
-]
    • addedInput schema / properties / ticketId / description
      Added value: +"Ticket identifier."
  2. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

readOnlyHint=true already establishes this is a safe read, lowering the burden. The description adds useful behavioral context about default ordering (oldest-first, conversational), but does not address pagination limits, empty-ticket behavior, or return format.

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?

Two short sentences, front-loaded with the core purpose. The 'like a conversation top to bottom' analogy is mildly decorative but helps convey default ordering, so it earns its place reasonably well.

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 no output schema and seven parameters, the description leaves the return shape (fields per comment, cursor wrapper) unexplained. It is adequate for a read-only list call backed by rich param docs, but stops short of the detail needed to know what comes back.

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 coverage is 100%, so all seven parameters are already documented in the schema, including cursor, pageSize clamping, sortOrder default, and conversationType values. The description only reinforces the sortOrder default and adds no semantics beyond the schema; baseline 3 applies.

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+resource (lists comments on a ticket) and adds cursor pagination scope. It is distinguishable from gorelo_get_ticket_comment and gorelo_create_ticket_comment, though it doesn't explicitly name siblings or differentiate from gorelo_list_ticket_conversations.

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 implied by the verb and the required ticketId; the description tells the agent comments read oldest-first 'by default,' hinting at sort behavior. But there is no explicit when-to-use guidance or exclusion pointing to the conversations endpoint or get_ticket_comment.

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