Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

sevennow_promotion

Expand a 7NOW promotion into every item it covers in a store, including offer type, terms, and run dates. Use a promo_id and store_id to get a detailed breakdown, solving the need to see all products included in a single deal.

Instructions

List every item one 7NOW promotion covers. Expands one promotion into every item it applies to in a store, plus the promotion's own offer type, terms, and run dates. GET /7now/deals reads discount-to-item (here is a discounted product, here is why); this reads it the other way round (here is an offer, here is everything it covers) -- e.g. a "2 for $4" tea promotion expands to all five flavours in it. promo_id comes from GET /7now/deals' items[].promos[].id, and store_id from GET /7now/stores. An unknown promo_id returns 404.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
skipNoPagination offset. Defaults to 0.
limitNoMax items returned, 1-100. Defaults to 20.
promo_idYesPromotion id, from GET /7now/deals' items[].promos[].id.
store_idYes7NOW store id, from GET /7now/stores.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.16.2

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are provided, so the description carries the burden. It discloses that the tool expands a promotion to all items, includes offer type, terms, and run dates, and mentions the error behavior: 'An unknown promo_id returns 404.' It could mention pagination limits or rate limits, but the core behaviors are covered. Slight deduction because it doesn't describe what happens with an invalid store_id or the exact structure of the response, but the main functional behavior is transparent.

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 dense but well-organized, front-loading the core purpose before diving into the contrast with the sibling tool. Every sentence adds value: the first states the primary function, the second explains the reversal, the third gives a concrete example, and the fourth/ fifth specify parameter provenance and error handling. No fat or redundancy.

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?

For a tool with 4 parametersIan and no output schema, the description covers all essential aspects: purpose, direction, parameter sourcing, and error handling. It doesn't mention pagination defaults (but those are in the schema), nor does it describe the return structure in detail, but given no output schema, a brief mention of what the return contains (list of items plus offer details) might be helpful. The description does say it expands to 'every item it applies to' and includes 'offer type, terms, and run dates', which gives a good sense of the result. Slight deduction for lack of a note on the shape of the response, but overall it's complete enough for an agent to use correctly.

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. The description adds context about where each id comes from, which is valuable but not strictly new semantics beyond what the schema already states. It also implies that promo_id is the key input and store_id is the scope. However, there's no additional description of skip/limit beyond what the schema provides, so 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 clearly states the verb ('List every item'), the resource ('7NOW promotion'), and the scope ('expands one promotion into every item it applies to in a store'). It also distinguishes itself from the sibling GET /7now/deals by explaining the reverse direction of the relationship. Specific example ('2 for $4' tea promotion) reinforces comprehension.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool versus the alternative: 'GET /7now/deals reads discount-to-item... this reads it the other way round'. It also provides clear instructions on where to obtain the required parameters: promo_id from GET /7now/deals' items[].promos[].id, and store_id from GET /7now/stores. No ambiguity.

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

Install Server

Other Tools