Scrapewise

scrapewise_list_reapply_rules

Read-onlyIdempotent

        Every re-apply job of this customer that is waiting or running, oldest first (at most 200). Read-only
        and free (no credits). Use it to see what is in progress across all runs before starting more: the
        account can run only a few re-apply jobs at once, the others wait their turn and start by
        themselves. Finished jobs are not listed — read one with scrapewise_get_reapply_rules.

        Args:
          - none. The customer comes from the API key.

        Returns:
          A list of jobs, each with reapplyId, runId, scraperId, groupId, state (PENDING or RUNNING), waiting
          (FILE_UPLOAD while a file upload runs on that scraper), percent, rowsTotal, rowsRead, rowsChanged
          and per-column counts. An empty list when nothing is in progress.

        Examples:
          - Use when: "which re-applies are still running?"
          - Use when: before starting many re-applies, to see how many already wait.
          - Don't use when: you need one run's finished result → scrapewise_get_reapply_rules.

        Error Handling:
          - 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

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "scrapewise_list_reapply_rules"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

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 readOnlyHint/idempotentHint/destructiveHint=false, but the description adds genuinely new behavioral facts: the call is free (no credits), the account runs only a few re-apply jobs at once with excess jobs queued and self-starting, the list is capped at 200 and ordered oldest first, and it is empty when nothing is in progress. It also lists the 401/500 error modes, which annotations do not cover.

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?

The core scoping sentence is front-loaded and the Args/Returns/Examples/Error sections are easy to scan. There is minor redundancy — 'Read-only' restates readOnlyHint=true, and the queue-then-self-start explanation is slightly wordy — but nothing is wasted at the level of a tool an agent must invoke correctly.

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?

Since no output schema exists, the Returns section carries the full burden and does so, enumerating reapplyId, runId, scraperId, groupId, state (PENDING/RUNNING), waiting, percent, rowsTotal/rowsRead/rowsChanged, and per-column counts, plus the empty-list case. Combined with the cap, ordering, error codes, and the runtime hint about defensive parsing, 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?

With zero parameters the baseline is 4, and the description handles it correctly by stating 'Args: none. The customer comes from the API key' — clarifying that identity is implicit via authentication rather than a missing argument. No further parameter meaning is possible.

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 description opens with a specific verb and resource ('Every re-apply job of this customer that is waiting or running'), plus ordering ('oldest first') and a hard cap (at most 200). It explicitly excludes finished jobs and names the sibling that serves those, so the tool is distinguishable from scrapewise_get_reapply_rules without opening either 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?

It states the positive use case ('see what is in progress across all runs before starting more') with the motivation (concurrency limits), and gives an explicit exclusion: 'Don't use when: you need one run's finished result → scrapewise_get_reapply_rules.' The Examples block reinforces both the when and when-not.

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.