Scrapewise

scrapewise_get_matcher_setup_view

Read-onlyIdempotent

        Returns the group's matching setup as the matching engine sees it now — what the portal canvas
        draws: which sources are matched on which columns, with which roles, and whether the drawing is up
        to date with the saved job. Read-only; costs nothing. Use it to check a save landed the way it was
        meant, or to see the engine-side setup (codes, joins, picture sources) of a group on the newer
        matching engine.

        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.

        Returns:
          204 when the matcher has not reported yet. Otherwise 200 {view, managed, flags}: view=false when
          there is no setup to draw (managed=false: the group is not on the newer matching); view=true adds
          jobId, builtAt, upToDate and engineSetup (column names and roles only) for the job
          scrapewise_get_matcher_job returns. flags=null when the matcher's last report is older than 5
          minutes.

        Examples:
          - Use when: "did my last matching save reach the engine?" -> upToDate.
          - Use when: "which columns does group {id} match on, per source?".
          - Don't use when: you need the saved job body to edit -> scrapewise_get_matcher_job.

        Error Handling:
          - 400 (CustomerError): no group with this id for this customer.
          - 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_setup_view"
  }
}

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.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description still adds substantial context: the cost profile ('costs nothing'), the 204 not-reported-yet state, the 5-minute staleness rule for flags=null, the view/managed/flags branching, and the Take Over auth requirement with its 409 code. These are behavioral facts the annotations cannot express.

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?

Front-loaded with a one-sentence summary before the structured Args/Returns/Examples/Error blocks, so an agent can stop early. It is longer than most descriptions, but the Returns branching and error codes genuinely need the room; the appended runtime hint is not part of the authored text.

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 Returns block carries the full burden and does so: it enumerates both status codes, the view/managed/flags combinations, and which fields appear when view=true. Error handling covers 400, 401, 409, and 500, so nothing an agent needs to call this correctly is missing.

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 50% because id carries no description; the Args section fixes that ('the group's id'). customerRef already has schema text, but the description adds real meaning beyond it: the concrete failure mode (409 TAKE_OVER_ACTIVE without it) and the confirmation that it should be omitted otherwise.

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 ('Returns the group's matching setup as the matching engine sees it now') and immediately grounds it in the portal canvas concept, so an agent knows exactly what it gets back. It also names the sibling it is not ('you need the saved job body to edit -> scrapewise_get_matcher_job'), which separates it from the closest-looking alternative.

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?

Explicit 'Use when' examples ('did my last matching save reach the engine?' -> upToDate; 'which columns does group {id} match on, per source?') and an explicit 'Don't use when' routing to scrapewise_get_matcher_job. The one ambiguous boundary, the overlap with scrapewise_get_matcher_engine_setup, is not addressed, which is the only gap.

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.