Skip to main content
Glama
viralitymedia

Growwer MCP server

by viralitymedia
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List your orders

growwer_list_orders
Read-onlyIdempotent

List and filter orders by state, project, media, or dates, and sort by update time or use updatedSince to track changes.

Instructions

Use this when the user asks about the orders they bought, or to follow them: lists them with filters on state, project and dates; 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.
projectIdNoOnly the orders of this project 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.8/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavioral value: the delta/polling pattern using updatedAt sort with updatedSince to see only what changed.

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 front-loaded sentence that opens with the usage trigger, then the capabilities. Slightly run-on with semicolons, but nothing redundant or 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?

With 7 optional params, no output schema and only annotations for safety, the description covers the call trigger and the polling trick but says nothing about what a page of orders looks like or how pagination/limit-offset behave in the result. Adequate but leaves a clear gap for a read tool with no return schema.

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% and every parameter is documented there, including the enum, the 422 refusal on unknown states, and ISO-8601 formatting. The description merely summarizes the filter set, adding no syntax or semantics beyond the schema – baseline 3.

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?

Specific verb and resource with scope: "lists them with filters on state, project and dates". The phrase "the orders they bought" implicitly scopes it to buyer orders, distinguishing it from growwer_list_seller_orders without naming that sibling explicitly.

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?

Gives a clear trigger ("when the user asks about the orders they bought, or to follow them") and encodes the polling pattern via sort=updatedAt plus updatedSince. It stops short of naming alternatives like growwer_get_order for a single order or the seller-side list.

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