Skip to main content
Glama

Order Message Read Tool

order-message-read
Read-only

List messages for a visible order, including whether each message is staff-only. Requires order_number; supports filtering, sorting and pagination.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number. Default 1.
sortNoSort fields. Append :asc or :desc for direction (default :asc). Example: ["created_at:desc"]. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, review, media.
limitNoResults per page. Default 20, max 100.
actionYesAction to perform.
filtersNoPurity filter object. Keys are field names, values are operator objects. Example: {"status":{"$eq":"active"}}. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, review, media.
order_numberYesOrder number. Required for all actions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / filters / description
      Previous value: -"Purity filter object. Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":\"active\"}}. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, media."New value: +"Purity filter object. Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":\"active\"}}. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, review, media."
    • changedInput schema / properties / sort / description
      Previous value: -"Sort fields. Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, media."New value: +"Sort fields. Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, review, media."
  2. Changed2 schema fields changed
    • changedInput schema / properties / filters / description
      Previous value: -"Purity filter object. Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":\"active\"}}. Available fields: id, user_id, order_id, ticket_id, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, media."New value: +"Purity filter object. Keys are field names, values are operator objects. Example: {\"status\":{\"$eq\":\"active\"}}. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, media."
    • changedInput schema / properties / sort / description
      Previous value: -"Sort fields. Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, user_id, order_id, ticket_id, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, media."New value: +"Sort fields. Append :asc or :desc for direction (default :asc). Example: [\"created_at:desc\"]. Available fields: id, user_id, order_id, ticket_id, reviewed_media_id, review_action, date_seen, ip_address, message, staff_only, via, is_auto_generated, email_id, created_at, updated_at, messages.id, messages.user_id, messages.order_id, messages.ticket_id, messages.reviewed_media_id, messages.review_action, messages.date_seen, messages.ip_address, messages.message, messages.staff_only, messages.via, messages.is_auto_generated, messages.email_id, messages.created_at, messages.updated_at, user, order, ticket, notifications, reactions, media."
  3. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety is covered. The description adds useful behavioral context beyond the schema: the 'visible order' precondition, the staff-only field in results, and support for filtering, sorting, and pagination. It does not contradict the annotations.

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 one concise, front-loaded sentence that states the main action first, then the key prerequisite and capabilities. No filler or redundancy; every clause contributes useful information.

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?

The description gives a workable overview for a basic list call, but it does not define what makes an order 'visible' nor describe the output shape beyond the staff-only flag. With no output schema, some return-structure information would help; still, the rich parameter schema compensates partially.

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 schema already documents all parameters in detail. The description adds a high-level statement about requiring order_number and supporting pagination/sorting/filtering, but it does not explain parameter meanings beyond what the schema provides. 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?

The description uses a specific verb and resource — 'List messages for a visible order' — and adds a distinguishing detail: 'including whether each message is staff-only.' This clearly separates it from write siblings like order-message-write and from ticket-message-read by scoping to orders.

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 the use case (reading messages for a specific order) and states a prerequisite ('Requires order_number'), but it does not explicitly contrast with alternatives such as ticket-message-read or order-message-write. Usage context is present, but when-not-to-use guidance is absent.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources