Scrapewise

scrapewise_get_matcher_engine_setup

Read-onlyIdempotent

        Reads every engine setting of a group on the newer matching engine: master side, sources, joins
        (enrichment links), derived keys, ignore lists, codes, column roles, brand aliases, thresholds,
        pictures and the per-group engine switch. The same setup the portal canvas draws.

        Args:
          - id (string, path, required): the group's id.
          - include (string, query, optional): comma list of extra parts: draft (the saved draft that waits for
            the check), history (the newest 20 activated versions), fields (every field path with its kind and
            range — read it once before an edit).
          - paths (string, query, optional): comma list of setup paths to return instead of the whole setup,
            e.g. joins,columnsByScraper.<scraperId> (at most 50; each must start with a field name).
          - version (integer, query, optional): return that history version's setup instead of the active one
            (use it to restore: PUT it back as raw).
          - customerRef (string, query, optional): only for a Scrapewise admin key in Take Over.

        Returns:
          status (ACTIVE / PENDING / REJECTED / VALIDATOR_DOWN / NONE), problems and warnings of the newest
          check, editVersion (the version a PUT or PATCH must name), configHash, setupSource (db / file /
          default), fileDiffers, inEngine, the engine switch and raw (the active setup). 204 = no setup stored
          and the group is not on the newer engine. REJECTED = your last draft failed the check (see problems;
          the active setup is unchanged; your next save starts from the active setup, so send your whole change
          again; for UNKNOWN_KEY a refused change may still go live after a matcher update until you save
          again). VALIDATOR_DOWN = your draft is saved and waits for
          the check; the active setup is unchanged; do not resend. include=fields shows each field's writer
          (customer = the group's owner may change it; admin = Scrapewise only).

        Examples:
          - Use when: "show me the joins of group {id}" -> paths=joins.
          - Use when: "did my last change go live?" -> status ACTIVE and a new configHash, or REJECTED with problems.
          - Don't use when: you want the matching job (master list, runs, lines) -> scrapewise_get_matcher_job.

        Error Handling:
          - 400: a bad include / paths value (paths names an unknown field).
          - 404: unknown group, another customer's group, or an unknown version.
          - 409 TAKE_OVER_ACTIVE: end Take Over or send customerRef=<that customer's ref>.
          - 503 FIELD_LIST_UNKNOWN: paths asked before the matcher published its field list; read without paths.
          - 401 Unauthorized; 500 INTERNAL.

[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": {
      "id": "<id>"
    },
    "name": "scrapewise_get_matcher_engine_setup"
  }
}

Input Schema

Name	Required	Description
`id`	Yes
`paths`	No	Comma list of setup paths to return (at most 50), e.g. joins,columnsByScraper.<scraperId>.
`include`	No	Comma list: draft, history, fields.
`version`	No	A history version to return instead of the active setup.
`customerRef`	No	Admin keys in Take Over only: the customerUniqueRef of the customer the admin works for. Required then; leave it out otherwise.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already say readOnly/idempotent/non-destructive, yet the description adds substantial behavior: 204 means no setup and not on the newer engine, REJECTED leaves the active setup unchanged and the next save restarts from active, VALIDATOR_DOWN must not be resent, and editVersion is what a PUT/PATCH must name. Error handling (400/404/409 TAKE_OVER_ACTIVE/503 FIELD_LIST_UNKNOWN) and the runtime note about a dynamic string-or-object payload further cover what annotations cannot.

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?

Well structured and front-loaded: purpose sentence first, then Args, Returns, Examples, Error Handling, all labeled and scannable. It is long, and the Args block partially restates schema types/requiredness (string, path, required), which is the only place wording does not fully earn 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?

With no output schema, the description carries the return-shape burden and does so thoroughly: status enum values, problems/warnings, editVersion, configHash, setupSource, fileDiffers, inEngine, raw, plus the 204 special case. Combined with the error table and the runtime hint about defensive parsing, an agent has everything needed to call and interpret it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 80%, but the description goes well beyond it: include values are explained with intent (draft 'waits for the check', history 'newest 20 activated versions', fields 'every field path with its kind and range — read it once before an edit'), paths gets a hard limit of 50, a syntax example and a 'must start with a field name' rule, and customerRef is scoped to admin keys in Take Over. This is the kind of semantics an agent cannot infer from the schema alone.

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?

Opens with a specific verb and resource: reads every engine setting of a group on the newer matching engine, then enumerates the parts (master side, sources, joins, derived keys, ignore lists, codes, column roles, brand aliases, thresholds, pictures, engine switch). The scope phrase 'the same setup the portal canvas draws' gives an agent an unambiguous mental model, and it is clearly not the job/run tool.

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?

Provides explicit 'Use when' examples tied to concrete user phrasings ('show me the joins of group {id}' -> paths=joins; 'did my last change go live?' -> status/configHash) plus a 'Don't use when' routing to scrapewise_get_matcher_job. It also states when to reach for include=fields (read once before an edit) and version (to restore), which is genuine usage steering.

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

All Scrapewise tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.