Scrapewise

scrapewise_get_matcher_job

Read-onlyIdempotent

        Returns the group's current product-matching setup exactly as scrapewise_update_matcher_job takes
        it: the main list, the ID column, the match lines (flat and per source), the runs in scope and the
        job's status. Read-only; costs nothing.

        Each source is also named by its stable scraper id (masterData.scraperId for the main list,
        scopeScraperIdByJobId for every scope run), so a setup read here can be saved again with the newest
        run of each scraper: replace each scope run id with that scraper's newest finished run.

        Args:
          - id (string, path, required): the group's id.
          - customerRef (string, query, optional): only for a Scrapewise admin key while the admin works in
            another customer's account (Take Over): the customerUniqueRef of that customer. Required then
            (409 TAKE_OVER_ACTIVE without it); leave it out otherwise.

        schedule says when the matcher runs again by itself (null = run once; AFTER_SCRAPES, DAILY,
        EVERY_N_DAYS or WEEKLY at time/zone), with nextRunAt; PUT never clears a schedule — use
        scrapewise_update_matcher_schedule with null. masterData.reviewMaxByScope / reviewFloorByScope =
        per-feed review band (score > max -> MATCH, < floor -> NO), keyed by scope job id, both or neither.
        A run held by the size guard is not shown here: see scrapewise_get_matcher_history (guardHold).

        Returns:
          MatcherJobDTO: id, status, masterData (jobId, scraperId, targetField, matchers, matchersByScope,
          targetFieldByScope, imageMatchingEnabled, ...), scope (run ids), scopeScraperIdByJobId, created,
          schedule, lastScheduledRun, scheduleDueAt, nextRunAt, version (send it unchanged, as a string, with
          the next scrapewise_update_matcher_job; "" when the job has none).

        Examples:
          - Use when: "show me how group {id} is matched" or before changing one line of the setup.
          - Use when: copying a setup to the newest runs (read, swap the run ids, save).
          - Don't use when: you need the history of earlier setups -> scrapewise_get_matcher_history.

        Error Handling:
          - 404: the group has no matching setup yet.
          - 400 (CustomerError): no group with this id for this customer (another customer's group gives
            the same answer).
          - 409 TAKE_OVER_ACTIVE: this key's admin works in another customer's account — end Take Over or
            send customerRef=<that customer's ref>.
          - 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_job"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes
`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.5/5.0

Behavior4/5

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

Annotations already carry readOnlyHint/idempotentHint/destructiveHint=false, but the description adds substantial context: "Read-only; costs nothing", the stable scraper-id mapping (masterData.scraperId, scopeScraperIdByJobId) that enables re-saving a read, and the note that runs held by the size guard are excluded here. It also discloses that PUT never clears a schedule, which is behavior of the sibling tool rather than this one — useful but slightly off-target.

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 front-loaded and sectioned (Args / Returns / Examples / Error Handling), with the key distinction in the first sentence. It is long, and the schedule and review-band paragraph explains update-side semantics ("PUT never clears a schedule") that arguably belong on the writer tool, costing some focus.

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?

Covers arguments, returned DTO fields, the version-roundtrip requirement, and a full error table (404, 400, 409, 401, 500) — far more than most read tools. Minor tension: it enumerates specific return fields while the runtime hint warns the payload is a dynamic blob and no field should be assumed present.

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?

Schema coverage is only 50%, and the description fills the gap: id is defined as "the group's id" and customerRef is explained in depth (admin key during Take Over, required then, 409 TAKE_OVER_ACTIVE without it). The customerRef text largely restates the schema description, but the error coupling and the id clarification add real meaning.

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 ("Returns the group's current product-matching setup") and defines the return shape by reference to the writer tool's input contract, which immediately tells an agent what this is. It is clearly distinct from scrapewise_update_matcher_job and scrapewise_get_matcher_history, both of which are named.

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 two explicit "Use when" scenarios (inspecting a setup, copying a setup to newest runs) and an explicit "Don't use when" routing the agent to scrapewise_get_matcher_history. The ordering advice ("before changing one line of the setup") gives a concrete workflow position.

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.