Skip to main content
Glama

scrapewise_get_reapply_rules

Read-onlyIdempotent
        The latest re-apply job of one run, so an agent can follow a re-apply it started with
        scrapewise_run_reapply_rules until it ends. Read-only and free (no credits). A job moves PENDING →
        RUNNING → COMPLETED, or ends CANCELLED (stopped, run deleted, switched off) or FAILED (with an error
        text). Poll every few seconds while state is PENDING or RUNNING; stop polling once it is final.

        Args:
          - jobId (string, path, required): the run's id (scraperJobStatusId) — the same id the re-apply was
            started for.

        Returns:
          The job: reapplyId, state, active, percent (0-100), rowsTotal, rowsRead, rowsChanged, writes, raced
          (rows another writer changed meanwhile; left as they were), failureRowsSkipped, per column
          {added, updated, keptStale}, waiting (FILE_UPLOAD while a file upload runs on the scraper; the job
          resumes by itself), rulesHash, createdAt, startedAt, finishedAt and error. 204 No Content when this
          run never had a re-apply.

        Examples:
          - Use when: "is the re-apply of run {jobId} finished?" → read state and percent.
          - Use when: "how many rows got new values?" → rowsChanged and the per-column counts.
          - Don't use when: you want every waiting or running job of the account →
            scrapewise_list_reapply_rules.

        Error Handling:
          - 400 (CustomerError) when the run does not exist for this customer.
          - 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": {
      "jobId": "<jobId>"
    },
    "name": "scrapewise_get_reapply_rules"
  }
}

Input Schema

NameRequiredDescriptionDefault
jobIdYes

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 cover read-only/idempotent/no-destructive, but the description adds substantial context beyond them: it is free (no credits), the PENDING → RUNNING → COMPLETED/CANCELLED/FAILED state machine with meanings for each terminal state, the FILE_UPLOAD 'waiting' condition that resumes automatically, the 'raced' rows another writer changed, and 204 No Content when no re-apply exists. That is exactly the behavioral detail 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 the one-sentence purpose, then cleanly sectioned into Args/Returns/Examples/Error Handling. The long Returns enumeration is justified because there is no output schema, though a few items (e.g. rulesHash, createdAt) could arguably be trimmed.

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 single parameter, the description carries the whole burden and does: it enumerates return fields (state, percent, row counts, per-column counts, error), documents the 204 empty case, and lists 400/401/500 error meanings. The runtime hint about defensive parsing is the only caveat, and the description already frames the result as a job object.

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 description coverage is 0%, so the description must compensate, and it does: jobId is explained as the run's id (scraperJobStatusId) and specifically 'the same id the re-apply was started for,' which tells the agent where to obtain the value. It stops short of format examples (string shape/UUID form), which is the only small gap.

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 precise verb+resource+scope: 'The latest re-apply job of one run,' and explicitly names the sibling it is not (scrapewise_list_reapply_rules for all jobs of an account). An agent can distinguish polling one job from listing jobs 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?

States the workflow (follow a re-apply started with scrapewise_run_reapply_rules until it ends), gives explicit polling cadence ('poll every few seconds while PENDING or RUNNING; stop once final'), and an explicit 'Don't use when' routing to scrapewise_list_reapply_rules. Both when and when-not are covered.

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.