QuailOS

get_order_feedback

Read-onlyIdempotent

List customer feedback left on online orders (the Online Orders > Feedback tab): hatch-rate reports with eggs set/hatched, star rating and comments, plus shipping damage reports. Damage reports carry a masked contact (contactMasked) by default. Pass feedbackId to fetch one report directly. Pass includeContact: true to also get the full contact (email or phone as the customer entered it) in contact; this is only allowed for the farm's own owner/admin AI key with read/write scope, is denied for other roles and read-only keys, and every such access is audit-logged. Read-only. Requires farmId and apiKey authorization.

Input Schema

Name	Required	Description
`type`	No	Optional report type filter
`limit`	No	Optional max results (default 25, max 100)
`cursor`	No	Optional pagination cursor (nextCursor from a previous call)
`farmId`	Yes	The unique farm ID
`endDate`	No	Optional end date (YYYY-MM-DD in farm time or ISO datetime)
`orderId`	No	Optional order ID to match feedback for a single order
`isPublic`	No	Optional filter: true = shown in Farm Directory, false = private
`maxRating`	No	Optional maximum star rating 1-5 (hatch reports only)
`minRating`	No	Optional minimum star rating 1-5 (hatch reports only)
`startDate`	No	Optional start date (YYYY-MM-DD in farm time or ISO datetime)
`feedbackId`	No	Optional feedback report ID to fetch a single report (other filters are ignored). Returns notFound: true if it does not exist on this farm.
`includeContact`	No	Optional, default false. When true, damage reports also include `contact` (the full customer email/phone as stored). Requires the farm's own owner or admin AI key (not read-only); otherwise the call is rejected. Access is audit-logged.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 12, 2026

addedInput schema / properties / feedbackId

Added value: +{
+  "description": "Optional feedback report ID to fetch a single report (other filters are ignored). Returns notFound: true if it does not exist on this farm.",
+  "type": "string"
+}

addedInput schema / properties / includeContact

Added value: +{
+  "description": "Optional, default false. When true, damage reports also include `contact` (the full customer email/phone as stored). Requires the farm's own owner or admin AI key (not read-only); otherwise the call is rejected. Access is audit-logged.",
+  "type": "boolean"
+}

AddedOct 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/no-destructive, so the bar is lower, yet the description adds substantial behavior: damage contacts are masked by default, includeContact is gated to owner/admin read/write keys, denied for read-only keys and other roles, and every access is audit-logged. This is exactly the authorization and privacy context an agent needs.

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 the includeContact caveat, then authorization. Slightly dense with a trailing 'Read-only. Requires farmId and apiKey authorization' that partially repeats annotations, but nothing is wasted and it reads in priority order.

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?

With no output schema, the description still conveys the return shape (eggs set/hatched, star rating, comments, contactMasked, contact) and the notFound/authorization edge cases. For a 12-parameter read tool this is complete enough to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema for includeContact (permission gating, audit logging, what `contact` contains) and for feedbackId (single-report fetch, other filters ignored). It leaves limit/cursor/date/rating filters to the well-documented schema.

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+resource (list customer feedback on online orders) and enumerates the two report types, hatch-rate and shipping damage, which distinguishes it from siblings like get_orders and get_customer_details. An agent can identify the correct tool without opening the schema.

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?

Explains the two access patterns clearly: use feedbackId to fetch a single report, use includeContact:true only when the full contact is needed and the caller qualifies. It does not name a sibling alternative, but the conditional usage guidance is concrete rather than implied.

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

All QuailOS 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?