Skip to main content
Glama
Sign In

Scrapewise

by ai.scrapewise
OverviewDiscussionsAdmin

scrapewise_get_scraper_group_ai_control_status

Read-onlyIdempotent
        Reads where "AI control" of one group stands: whether it is on, when the next check is
        planned and what the last check found. Read-only; it changes nothing.

        Args:
          - id (string, path param, required): the group's MongoDB ObjectId.

        Returns:
          GroupAiControlStatusDTO:
          - enabled, cadence: the group's choice (cadence DAILY, TWICE_WEEKLY or WEEKLY).
          - phase, in plain words:
            OFF: AI control is switched off for this group.
            PAUSED: checks are paused on our side at the moment. The choice is kept, and
            checks go on by themselves when the pause ends.
            RUNNING: a check of this group is running now.
            QUEUED: a first check is queued; it usually starts within minutes.
            DUE: the next check is due and starts soon.
            SCHEDULED: the next check is planned at nextCheckAt.
          - nextCheckAt: the next planned check (null when OFF or PAUSED, or not planned yet).
          - lastCheckAt: when the last check ended (also a check that found no new runs).
          - lastResultAt: when the last check that had a result ended.
          - nothingNewSinceResult: true when the last check found no new runs after the last result.
          - checkedCount: how many scrapers the last result judged.
          - scrapersPerCheck: the most scrapers one check looks at (the ones checked longest ago first).
          - results: the last result as lines of kind, count and reasons.
            `reasons` are internal codes; read `kind`. The kinds:
            CHECK_FAILED: the check could not be finished; it is tried again next time.
            IN_PROGRESS: a repair is being made.
            REPAIR_APPLIED: a repair was made; the next real run confirms it.
            REPAIRED: a repair was made and confirmed by the next real run.
            REPAIR_UNDONE: a repair was undone because the next real run was worse.
            REPAIR_KEPT_WORSE: a repair was kept, but the next real run looked worse.
            FIX_NOT_SAFE: a problem was found; the fix did not pass the safety test, nothing changed.
            REPAIR_PAUSED: a problem keeps coming back; repairs are paused for that scraper.
            PROBLEM_NOT_FIXABLE: a problem was found that AI cannot fix for this kind of scraper yet.
            PROBLEM_RECORDED: a problem was found and recorded; during the test phase it is not repaired.
            BLOCKED: the scraper could not be checked this time; it is tried again at the next check.
            ACCEPTED_CHANGE: a column stayed empty; this is now treated as normal.
            NOTHING_TO_REPAIR: checked, nothing to repair.
            What a BLOCKED line means (help text for its reasons):
            SKIPPED_BUDGET, SKIPPED_CAP, SKIPPED_PERMIT_BUSY, SKIPPED_NO_KEY: our own daily limit
            for AI checks was reached or the AI service was busy. This is not your wallet.
            SKIPPED_RUNNING, SKIPPED_SCHEMA_BUSY, SKIPPED_LIVE_ACTION: the scraper was busy.
            INFRA_ISSUE: the website or the network failed.
            REPAIR_INCONCLUSIVE: the test did not give a clear answer.
            SKIPPED_DISABLED: that kind of repair is switched off.
            CONFLICT: the scraper was changed at the same time.

        Examples:
          - Use when: "is AI control on for group {id}, and when is the next check?"
          - Use when: "what did the last AI check of group {id} find?"
          - Use when: right after scrapewise_update_scraper_group_ai_control, to see the first check.
          - Don't use when: checking again and again — the next check time is in the result.
          - Don't use when: you want to switch AI control on or off → use
            scrapewise_update_scraper_group_ai_control.

        Error Handling:
          - 400 (CustomerError envelope) if the id is not valid or no group with the given id
            exists for this customer (another customer's group gives the same 400).
          - 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_scraper_group_ai_control_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered; the 'Read-only; it changes nothing' sentence largely restates them. However, the description adds genuinely non-structured behavior: a 400 is returned both for an invalid id and for another customer's group, so absence/existence is not leaked — a meaningful disclosure beyond the annotations. It stops short of stating rate limits or caching, keeping it at 4.

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 structured with front-loaded purpose, then Args, Returns, Examples, Error Handling, so an agent can stop reading early. It is long — enumerating roughly twenty result kinds and their reason codes — but since no output schema exists that enumeration is load-bearing rather than filler. Slightly heavy in the Returns block for a status-read tool.

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?

There is no output schema, so the description carries the return contract and does so exhaustively: every phase, timestamp field, counter and result kind is defined, including what BLOCKED reason codes mean. Combined with the 400/401/500 error breakdown and the runtime hint about a dynamic JSON-as-text payload, an agent has everything needed to call and interpret this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the parameter, and it does: the single 'id' is identified as a required path param holding the group's MongoDB ObjectId, and the error section clarifies that the id is scoped per customer. This is meaning the bare {"id": string} schema does not convey.

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?

States a specific verb and resource with scope: reads where the 'AI control' status of one group stands, covering on/off state, next planned check and last check findings. It is immediately distinguishable from the sibling mutation tool scrapewise_update_scraper_group_ai_control, which is named explicitly.

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 explicit 'Use when' triggers (on/off state, last result, immediately after an update call) and explicit 'Don't use when' exclusions, including the anti-polling guidance that the next check time is already in the result. It routes the agent to the correct sibling for switching AI control on or off.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Scrapewise toolsInspect
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.

Resources