Skip to main content
Glama

scrapewise_list_enrichable_scrapers

Read-onlyIdempotent
        Returns one row PER SCRAPER in the group (not per run) for the enrichment builder's
        "choose scrapers" step. Enrichment is scraper-bound and always uses each scraper's latest
        completed run, so the run dimension is collapsed here — `latestRunJobId` is the exact run an
        enrich would consume (use it with scrapewise_get_run_columns to load that scraper's
        columns). `url` (the scraper's configured start URL) disambiguates two scrapers that share
        the same auto-generated name (e.g. a category-level and an item-level scraper on one domain);
        never identify a scraper by `name`. A scraper with no usable run yet has
        `latestRunJobId=null` and cannot be enriched.

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

        Returns:
          `List<EnrichableScraperDTO>` — each `{scraperId, name, url, latestRunJobId,
          latestRunItems, latestRunFinished, latestRunState}`. Empty list if the group has no
          scrapers.

        Examples:
          - Use when: "which scrapers can I enrich in group {id}, and what's each one's latest run"
          - Use when: building the enrichment join UI's scraper-selection step
          - Don't use when: you need every historical run as rows → use
            scrapewise_get_scraper_load_history

        Error Handling:
          - 400 (CustomerError envelope) if the group id is malformed or no group with that id
            exists for this customer.
          - 401 Unauthorized.

[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_list_enrichable_scrapers"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover the read-only, idempotent, closed-world profile, and the description adds real context beyond them: enrichment is scraper-bound, always consumes each scraper's latest completed run, latestRunJobId=null means the scraper cannot be enriched, and 400/401 error conditions are spelled out. It does not discuss pagination or performance, but for a bounded list of group members that is a minor omission.

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 front-loaded: the per-scraper/per-run distinction comes first, followed by field semantics, then Args/Returns/Examples/Error Handling. It is on the long side and repeats some return-field detail that could be trimmed, but no sentence is filler.

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?

Despite no output schema, the description enumerates the full DTO shape (scraperId, name, url, latestRunJobId, latestRunItems, latestRunFinished, latestRunState) and the empty-list case, and it warns never to identify a scraper by name. Combined with the error handling and the runtime hint about JSON-as-text responses, an agent has everything needed to call and parse it correctly.

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 0% and the single property is an untyped-in-schema string, so the description must carry the meaning — and it does, documenting 'id (string, path param, required): the group's MongoDB ObjectId' plus a 400 when the id is malformed or not owned by the customer. That is a genuine addition over the bare schema.

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 explicit scope: 'Returns one row PER SCRAPER in the group (not per run)' for the enrichment builder's choose-scrapers step. It immediately differentiates itself from run-oriented siblings by explaining that the run dimension is collapsed, so an agent knows exactly what this returns without opening the 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?

Provides explicit 'Use when' cases, a 'Don't use when' case routing to scrapewise_get_scraper_load_history for historical runs, and a downstream handoff ('use it with scrapewise_get_run_columns to load that scraper's columns'). When-to-use, when-not-to-use, and the alternative are all present.

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.