Skip to main content
Glama

scrapewise_preview_scraper_preview_rule

Read-onlyIdempotent
        Applies a single PostProcessRule to a user-provided sample value and returns the
        derived output without persisting anything or running a real scrape. Useful for
        validating a rule's parameters before saving it onto a scraper config. For
        CURRENCY_CONVERT rules, also returns the FX rate and rateDate used. One rule, one value:
        conditions and choice groups are not checked here.

        Rule kinds and params:
          - CURRENCY_CONVERT: params {from, to} (3-letter codes). Writes outputField (value not
            rounded) plus ONE shared pair per target currency per row: <to>_rate and
            <to>_rate_date (to lower-cased, e.g. eur_rate, eur_rate_date; ECB rate and date).
            Every CURRENCY_CONVERT rule with the same `to` shares the pair; all rules of one run
            use one rate table. An identity in-place rule (overwritesRawField=true and from = to)
            only cleans the number and writes no pair. Row markers: RULE_RATE_CONFLICT:<to>_rate
            when two rules on one row need two different rates (both values kept, no pair);
            RULE_UNUSABLE:<to>_rate when the row already had its own <to>_rate / <to>_rate_date
            (kept untouched) and the computed one differs.
          - ENUM_MAP: params {mapping: {rawValue: mappedValue}, default}. mapping must be
            non-empty, or empty ({}) with a default: then default is a fixed value written on
            every row.
          - REGEX_CLEAN: params {keep: "[A-Za-z0-9]"} (a simple character class).
          - QUANTITY_NORMALIZE ("price per unit"): params {quantityField OR quantityValue,
            targetQuantity}. output = row[sourceField] / divisor * targetQuantity, rounded
            half-up to 4 decimals (price 7.5, pack 100, target 50 -> 3.75). Divisor = exactly
            one of: quantityField (a scraped field such as pack_grams, or the output of an
            earlier NUMBER_EXTRACT / QUANTITY_NORMALIZE rule) or quantityValue (a fixed number
            > 0 and <= 1000000; e.g. minor units 2500 -> 25.00 with quantityValue 100,
            targetQuantity 1; kg -> g with quantityValue 1, targetQuantity 1000).
            targetQuantity is a number > 0 and <= 1000000. When the source or quantity is
            missing, not an unambiguous number ("1.000" is refused), zero/negative, the result
            is out of range or rounds to 0, the rule writes NO column for that row (never 0 or
            null) and this preview returns `skipped` with the reason. Cannot be combined with
            overwritesRawField=true.
          - NUMBER_EXTRACT ("take a number from text"): params {units}. Reads the number
            written right BEFORE one of the unit words in a text column, times that unit's
            factor; NUMBER output, 4 decimals. units = a preset name (WEIGHT_G, VOLUME_ML,
            PIECES — see scrapewise_get_scraper_config_parameters postProcessUnitPresets) or a
            list of 1-20 {token, factor} (factor default 1). The unit listed first wins:
            "0.66 lb 300 g" with WEIGHT_G -> 300; "100m/50g" with [{token:"g"}] -> 50;
            "3.53 oz" with WEIGHT_G -> 100.0738. Never guesses: multipacks ("3x100g"),
            grouped numbers ("1 500 g"), ranges ("50-100 g"), ambiguous numbers ("1.000 g"),
            zero or no match -> skipped. Reads the first 2,000 characters.
        Ordered chaining (on a saved scraper): rules run top to bottom once. The output of an
        EARLIER QUANTITY_NORMALIZE or NUMBER_EXTRACT rule may be read by a later
        CURRENCY_CONVERT or QUANTITY_NORMALIZE rule as sourceField, and by a later
        QUANTITY_NORMALIZE as quantityField. Example: rule 1 QUANTITY_NORMALIZE
        price/pack_grams*50 -> price_per_50g, rule 2 CURRENCY_CONVERT price_per_50g DKK->EUR
        -> price_per_50g_eur. Outputs of CURRENCY_CONVERT, ENUM_MAP and REGEX_CLEAN cannot be
        read; ENUM_MAP, REGEX_CLEAN and NUMBER_EXTRACT read scraped fields only. Rejected at
        save (400): reading a later rule's output or a shared <to>_rate / <to>_rate_date
        column, or a later rule writing a column an earlier rule reads.

        Args:
          - body (PostProcessRulePreviewRequest, required):
            - rule (PostProcessRule): the rule definition (kind, sourceField,
              outputField, outputType, params).
            - sampleValue (any): the input value to apply the rule to.
            - sampleQuantity (any, optional): QUANTITY_NORMALIZE with quantityField only —
              the pack size to divide by (placed on the sample row under the rule's
              quantityField). Omit it to see how the rule behaves when the quantity is
              missing. Ignored when the rule uses quantityValue.

        Returns:
          PostProcessRulePreviewResponse with output (the derived value), and for
          CURRENCY_CONVERT rules: rate + rateDate. `skipped` (text) when the rule ran but
          could produce no value for this sample (QUANTITY_NORMALIZE). On invalid rule
          params or unhandled error, returns an `error` field instead of `output`.

        Examples:
          - Use when: "what would REGEX_CLEAN do to '$1,234.56'?" → preview with that rule
          - Use when: "price per 50 g for a 100 g ball at 7.50?" → QUANTITY_NORMALIZE with
            sampleValue 7.5, sampleQuantity 100, params {quantityField: "pack_grams",
            targetQuantity: 50} → output 3.75
          - Use when: "what pack size is in 'Hygge Wool 100 g'?" → NUMBER_EXTRACT with
            sampleValue "Hygge Wool 100 g", params {units: "WEIGHT_G"} → output 100
          - Don't use when: you want the rule applied to actual scraped data → save the
            rule on the scraper config and run a fresh scrape

        Error Handling:
          - 400 if request body validation fails.
          - 200 with `error` field for rule-execution failures (intentional non-throw
            shape so the agent can iterate on rule params without exception handling).
          - 401 Unauthorized.

[runtime hint] This tool returns JSON-as-text — its response shape is dynamic (per-scraper itemsConfig, file binary, etc.) so the MCP outputSchema is omitted. Do not rely on the presence of any specific field in the response; treat the result as a string-or-object blob and parse defensively.

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": {
      "body": "<body>"
    },
    "name": "scrapewise_preview_scraper_preview_rule"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so safety is covered; the description adds real value beyond that with the non-throw 200-with-`error` shape (explicitly so agents can iterate without exception handling), 400/401 behavior, `skipped` semantics for QUANTITY_NORMALIZE, and the 2,000-character read limit for NUMBER_EXTRACT. However, a large share of the text documents save-time chaining/rejection rules for a saved scraper rather than this tool's own behavior, which dilutes the transparency payoff for the preview call itself.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

Purpose, scope, and the use/don't-use guidance are correctly front-loaded, and the Args/Returns/Examples/Error Handling structure is easy to scan. But the block runs roughly 700 words, and the long 'Ordered chaining' paragraph plus the 'Rejected at save (400)' sentence describe saved-scraper configuration semantics rather than what this preview tool does, so not every sentence earns its place.

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?

For a tool with a nested body object, five rule kinds, and no output schema, the definition is complete: it documents the return shape (output, plus rate/rateDate for CURRENCY_CONVERT, `skipped`, or `error`), the error status codes, and per-kind computation rules with worked numeric examples. An agent has everything needed to construct a valid preview request and interpret the response.

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?

With 0% schema description coverage, the description carries the full burden and mostly succeeds: it explains the nested rule object (kind, sourceField, outputField, outputType, params), documents per-kind params in detail, and gives precise semantics for sampleQuantity including 'omit it to see how the rule behaves when the quantity is missing' and 'Ignored when the rule uses quantityValue'. The gaps are the outputType enum values (TEXT/NUMBER/URL/IMAGE/CONSTANT/BOOLEAN/MIXED_NUMBER/HIDDEN) and overwritesRawField, which are only obliquely covered via the 'identity in-place rule' note.

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 opening sentence names a specific verb and resource ('Applies a single PostProcessRule to a user-provided sample value') and immediately bounds scope: no persistence, no real scrape, one rule, one value, conditions/choice groups not checked. That is enough to separate it from scrape-related siblings like preview_reapply_rules or get_scraper_group_post_process_rules without opening any schema.

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?

Usage is explicit in both directions: 'Useful for validating a rule's parameters before saving it' plus three concrete 'Use when' scenarios and a 'Don't use when' line routing the agent to saving the rule on the config and running a fresh scrape. The scope exclusion ('One rule, one value: conditions and choice groups are not checked here') removes a likely mis-invocation.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.