Skip to main content
Glama
viralitymedia

Growwer MCP server

by viralitymedia
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List the orders you sell

growwer_list_seller_orders
Read-onlyIdempotent

Lists a seller's orders across their media, with state, media, and pagination filters; sort by updatedAt and use updatedSince to see only changed orders.

Instructions

Use this when the user, as a seller, asks about the orders placed on their medias, or to follow them: lists them with filters; sort by updatedAt with updatedSince to see only what changed.

Input Schema

NameRequiredDescriptionDefault
sortNo`-createdAt`, newest first, or `updatedAt`, least recently changed first. Orders of the same instant come in id order.-createdAt
limitNoOrders per page, 1 to 100.
stateNoOnly the orders in one of these states, comma-separated. An unknown state is refused with 422 and the list of valid ones.
offsetNoOrders to skip.
mediaIdNoOnly the orders on this media of yours.
updatedSinceNoOnly the orders whose `updatedAt` is at or after this instant, an ISO-8601 date-time with its offset (send `+` as `%2B`).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine context beyond them: the incremental-sync pattern of pairing updatedAt with updatedSince to see only what changed, which is not derivable from 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the triggering condition, with the operative detail (filters, the updatedAt/updatedSince pairing) after the colon. The colon-and-semicolon construction is a bit dense but nothing is wasted.

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?

For a read-only list tool with 6 fully documented parameters this is largely adequate, but there is no output schema and the description never indicates what a listed order contains or how paging results are returned, leaving the agent to guess the response shape.

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 would be 3, but the description adds cross-parameter meaning the schema does not: it explains that sort=updatedAt must be combined with updatedSince to track changes, not just what each field does in isolation.

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?

It states a concrete verb (lists) and resource (orders placed on the seller's medias) and scopes it explicitly to the seller role, which separates it from buyer-side siblings like growwer_list_orders. It stops short of naming that sibling outright, so the differentiation is implied rather than stated.

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?

'Use this when the user, as a seller, asks about the orders placed on their medias, or to follow them' gives a clear triggering context, and the updatedSince tip supplies a concrete follow-up workflow. No explicit exclusion or hand-off to growwer_list_orders or growwer_get_seller_order is given, so it is not a full when/when-not treatment.

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