Skip to main content
Glama

scrapewise_get_matcher_config_status

Read-onlyIdempotent
        Tells whether a matching save may be made for the group now: whether a setup exists, the status of
        the group's newest matcher job (QUEUED / INITIAL / RUNNING = a run is going; COMPLETED, FAILED,
        PENDING = a stored draft), when it last matched, whether there is new scraped data since, and
        whether the group is on the newer matching engine (where the owner saves drafts of the text settings and a
        Scrapewise admin key may change everything).
        Read-only; costs nothing. Check it before scrapewise_update_matcher_job, for every group whose
        order matters (save the second group only after the first one has finished).

        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:
          ConfigStatus: hasMatcherJob, status, lastMatchedAt, hasNewData, canConfigure, engineManaged (true / false,
          null when it could not be checked), engineManagedCanEdit (on such a group: may THIS key save; false for
          a read-only key), engineVersion (legacy | v2: the matcher rules version the group runs on; absent
          when it could not be read),
          scheduleDueAt (a scheduled run waiting to start), waitingReason (feeds-running | settling |
          other-group | forced | none) and queueAhead (matcher jobs queued before this one). priceRefresh = what
          the daily price refresh did on its LAST VISIT of this group: lastAt (when it visited), feedsRefreshed
          (feeds with changed rows), rowsChecked, rowsWritten (rows whose prices changed), wideStaleSince (the
          wide view / export shows older prices than match/data since then; null = in step) and skippedReason
          (set = skipped or cut short, and why; rowsWritten still says what changed). priceRefresh is null when
          price refresh is off or never visited the group. Not the delivery status of a run.
          indexBuild = the group's search-data rebuild: state (NONE | QUEUED | BUILDING | DONE | FAILED |
          CAP_REACHED), position (builds ahead), capKind (GROUP_CAP | CUSTOMER_CAP | null), capPerGroupPerDay,
          capPerCustomerPerDay, usedGroupToday / usedCustomerToday (null = not known), usedAsOf, resetsAt and
          lastEnd {result (DONE | FAILED | ABORTED | SUPERSEDED | CAP_GROUP | CAP_CUSTOMER), counted}.
          runFeatures (absent = all off) = which run controls this group offers: keepsDelivered, runChoices
          (autoMatches / manualMatches are used), runLedger, engineOpenEdits, engineReplaceRunning, restoreRun.

        Examples:
          - Use when: "is group {id} still matching?" before a save.
          - Use when: "may this key change the matching of group {id}?" -> engineManagedCanEdit.
          - Don't use when: you want the setup itself -> 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_config_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
customerRefNoAdmin 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.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotent and non-destructive, and the description adds substantial context beyond them: it decodes status values into 'a run is going' vs 'a stored draft', warns that priceRefresh is 'Not the delivery status of a run', and specifies engineManaged/engineManagedCanEdit permission implications for the key. Error handling (400, 409 TAKE_OVER_ACTIVE, 401, 500) and the 'costs nothing' cost profile are also disclosed.

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?

Purpose, preconditions, Args, Returns, Examples and Errors are cleanly front-loaded and sectioned, so it scans well. It is nonetheless long and dense in the Returns block (indexBuild, priceRefresh, runFeatures field dumps), which is defensible given there is no output schema but could be tightened.

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 and a wide, conditional return surface, the description carries the burden by enumerating every field group, null semantics and enum meanings (engineVersion legacy|v2, indexBuild states, waitingReason). Combined with the sibling routing, error cases and the ordering precondition, an agent has everything needed to call and interpret it.

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% (id is undocumented in the schema), and the Args block compensates by explaining both: id as the group's id and customerRef's exact Take Over condition plus the 409 that results from omitting it. The only shortfall is that id's semantics remain trivial and no format guidance is added.

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 question the tool answers ('whether a matching save may be made for the group now') and enumerates exactly what it reports: setup existence, newest job status, last match time, new data, engine version. The 'Don't use when' line explicitly routes the agent to scrapewise_get_matcher_job for the setup itself, so it is distinguishable from the nearest sibling.

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?

Gives an explicit precondition ('Check it before scrapewise_update_matcher_job, for every group whose order matters') including the ordering constraint that the second group is saved only after the first finishes. The Examples block supplies two concrete use-when triggers and one don't-use-with-alternative, leaving nothing to inference.

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.