Wayfront

Ticket Read Tool

ticket-read

Read-only

List or show visible support tickets with filtering, sorting and pagination.

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No	Page number for "list". Default 1.
`sort`	No	Sort fields for "list". Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: id, number, user_id, order_id, date_closed, date_snoozed, subject, status, note, last_message_at, source, created_at, updated_at, deleted_at, tickets.id, tickets.number, tickets.user_id, tickets.order_id, tickets.date_closed, tickets.date_snoozed, tickets.subject, tickets.status, tickets.note, tickets.last_message_at, tickets.source, tickets.created_at, tickets.updated_at, tickets.deleted_at, employees, audits, rating, ratings, followers, morphMetadata, tags, user, employee, ticket_status, forms, order, media, deal, latestClientFacingMessage, collaborators, filledFormFields, logs, messages, scheduledMessages, notifications.
`limit`	No	Results per page for "list". Default 20, max 100.
`action`	Yes	Action to perform.
`filters`	No	Purity filter object for "list". Keys are field names, values are operator objects. Example: {"status":{"$eq":1}}. Available fields: id, number, user_id, order_id, date_closed, date_snoozed, subject, status, note, last_message_at, source, created_at, updated_at, deleted_at, tickets.id, tickets.number, tickets.user_id, tickets.order_id, tickets.date_closed, tickets.date_snoozed, tickets.subject, tickets.status, tickets.note, tickets.last_message_at, tickets.source, tickets.created_at, tickets.updated_at, tickets.deleted_at, employees, audits, rating, ratings, followers, morphMetadata, tags, user, employee, ticket_status, forms, order, media, deal, latestClientFacingMessage, collaborators, filledFormFields, logs, messages, scheduledMessages, notifications. Status filter key is "status" (numeric IDs, not string names): 1=Open, 2=Closed, 3=Pending, 4=Spam, 5=Snoozed.
`ticket_number`	No	Ticket number. Required for "show" actions.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 24, 2026

changedInput schema / properties / filters / description

Previous value: -"Purity filter object for \"list\". Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":1}}. Available fields: id, number, user_id, order_id, date_closed, date_snoozed, subject, status, note, last_message_at, source, created_at, updated_at, deleted_at, tickets.id, tickets.number, tickets.user_id, tickets.order_id, tickets.date_closed, tickets.date_snoozed, tickets.subject, tickets.status, tickets.note, tickets.last_message_at, tickets.source, tickets.created_at, tickets.updated_at, tickets.deleted_at, employees, audits, rating, ratings, followers, morphMetadata, tags, user, employee, ticket_status, forms, order, media, collaborators, filledFormFields, logs, messages, scheduledMessages, notifications. Status filter key is \"status\" (numeric IDs, not string names): 1=Open, 2=Closed, 3=Pending, 4=Spam, 5=Snoozed."New value: +"Purity filter object for \"list\". Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":1}}. Available fields: id, number, user_id, order_id, date_closed, date_snoozed, subject, status, note, last_message_at, source, created_at, updated_at, deleted_at, tickets.id, tickets.number, tickets.user_id, tickets.order_id, tickets.date_closed, tickets.date_snoozed, tickets.subject, tickets.status, tickets.note, tickets.last_message_at, tickets.source, tickets.created_at, tickets.updated_at, tickets.deleted_at, employees, audits, rating, ratings, followers, morphMetadata, tags, user, employee, ticket_status, forms, order, media, deal, latestClientFacingMessage, collaborators, filledFormFields, logs, messages, scheduledMessages, notifications. Status filter key is \"status\" (numeric IDs, not string names): 1=Open, 2=Closed, 3=Pending, 4=Spam, 5=Snoozed."

changedInput schema / properties / sort / description

Previous value: -"Sort fields for \"list\". Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, number, user_id, order_id, date_closed, date_snoozed, subject, status, note, last_message_at, source, created_at, updated_at, deleted_at, tickets.id, tickets.number, tickets.user_id, tickets.order_id, tickets.date_closed, tickets.date_snoozed, tickets.subject, tickets.status, tickets.note, tickets.last_message_at, tickets.source, tickets.created_at, tickets.updated_at, tickets.deleted_at, employees, audits, rating, ratings, followers, morphMetadata, tags, user, employee, ticket_status, forms, order, media, collaborators, filledFormFields, logs, messages, scheduledMessages, notifications."New value: +"Sort fields for \"list\". Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, number, user_id, order_id, date_closed, date_snoozed, subject, status, note, last_message_at, source, created_at, updated_at, deleted_at, tickets.id, tickets.number, tickets.user_id, tickets.order_id, tickets.date_closed, tickets.date_snoozed, tickets.subject, tickets.status, tickets.note, tickets.last_message_at, tickets.source, tickets.created_at, tickets.updated_at, tickets.deleted_at, employees, audits, rating, ratings, followers, morphMetadata, tags, user, employee, ticket_status, forms, order, media, deal, latestClientFacingMessage, collaborators, filledFormFields, logs, messages, scheduledMessages, notifications."

First observedSep 8, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the 'visible' scope and the two access modes (list/show), but it does not clarify what 'visible' means or describe response behavior. This adds some context beyond annotations but leaves meaningful ambiguity.

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 filler. Every phrase conveys useful information: the resource, the two operations, the visibility scope, and the supported capabilities.

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?

The schema is rich and covers parameter semantics, including the ticket_number requirement for 'show' and filter syntax examples. The description plus schema gives an agent enough to invoke the tool correctly. Minor gaps are the undefined meaning of 'visible' and the lack of any note about the returned payload shape, since no output schema exists.

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?

Input schema coverage is 100%, and parameters like action, filters, sort, limit, page, and ticket_number are already well documented. The description's mention of filtering, sorting, and pagination simply mirrors the schema rather than adding new meaning.

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 uses a specific verb-resource pair ('List or show visible support tickets') and names the core capabilities: filtering, sorting, and pagination. It clearly distinguishes this read tool from siblings like ticket-write and ticket-message-read by scope and action type.

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 read-only ticket access through 'List or show visible support tickets', but it does not explicitly state when to prefer this tool over alternatives or when not to use it. There are no exclusions or routing cues beyond the obvious read/write contrast with ticket-write.

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

All Wayfront tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?