Crawlora MCP

Official

by Crawlora-org

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

sevennow_promotion

Expand a 7NOW promotion into every item it covers in a given store, including offer type, terms, and run dates.

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "promo_id": "<promo_id>",
      "store_id": "<store_id>"
    },
    "name": "sevennow_promotion"
  }
}

Input Schema

Name	Required	Description
`skip`	No	Pagination offset. Defaults to 0.
`limit`	No	Max items returned, 1-100. Defaults to 20.
`promo_id`	Yes	Promotion id, from GET /7now/deals' items[].promos[].id.
`store_id`	Yes	7NOW store id, from GET /7now/stores.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.16.2Sep 10, 2026

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.

Deploy Server