Scrapewise

scrapewise_get_scraper_config_parameters

Read-onlyIdempotent

        Returns the catalogue of enum values the scraper-builder UI uses to populate
        dropdowns: scraper types (SINGLE_PRODUCT, MULTIPLE_PRODUCTS, API,
        APPLICATION_LD_JSON), pagination strategies, parameter types (TEXT, NUMBER,
        IMAGE, BOOLEAN, JSON, etc.), the pre-defined "common parameters" each
        scraper type wires by default, and post-processing rule kinds (CURRENCY_CONVERT,
        ENUM_MAP, REGEX_CLEAN, QUANTITY_NORMALIZE, NUMBER_EXTRACT) with the NUMBER_EXTRACT unit
        presets (postProcessUnitPresets). Static catalogue — same response for
        every customer; cache aggressively at the agent side. Refresh once per
        backend deploy (the catalogue ships with the backend binary). Also reports the
        current file-upload size limits (maxUploadFileSizeMb, maxExcelFileSizeMb;
        1 MB = 1,000,000 bytes), which an admin can change.

        Args:
          (none — endpoint is parameter-free.)

        Returns:
          ScraperConfigParametersDTO containing five enum lists: scraperType,
          paginationType, parameterType, commonParameters (list of pre-wired field
          defs per scraper type), postProcessKind. Use these values when building a
          ScraperDTO body for scrapewise_create_scraper — sending an enum string
          outside the catalogue surfaces as a 400 validation error. Plus
          maxUploadFileSizeMb / maxExcelFileSizeMb: the largest file the upload
          accepts (CSV / JSON Lines, and Excel).

        Examples:
          - Use when: "what scraper types can I create?" → call this once per session
          - Use when: building a wizard UI that needs dropdowns
          - Don't use when: you already have a valid ScraperDTO body → skip this

        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_get_scraper_config_parameters"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, but the description adds materially more: the response is a static per-customer-invariant catalogue, so it should be cached aggressively and refreshed only on a backend deploy. It also flags that maxUploadFileSizeMb / maxExcelFileSizeMb are admin-mutable and names the unit convention (1 MB = 1,000,000 bytes), and it lists 401/500 error modes. No contradiction with annotations, though it stops short of describing pagination/response size or auth requirements.

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 lead paragraph is front-loaded with the highest-value information (what the catalogue contains) and the caching advice, which is good. Structure is clean with Args/Returns/Examples/Error Handling sections, but there is redundancy: the Returns section restates the enum lists already named in the opening paragraph, and the Args line merely says 'none', so a small amount of text does not earn its place.

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, but the description compensates by naming the wrapper type (ScraperConfigParametersDTO), listing the five enum lists returned, and explicitly noting the two size-limit scalars. It also addresses the runtime caveat that responses are JSON-as-text blobs, so an agent has enough to call the tool, parse it, and use the values downstream.

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?

The tool takes zero parameters, so the baseline is 4, and the description correctly states the endpoint is parameter-free, which prevents an agent from inventing arguments. It adds no further parameter detail because none is needed.

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 first sentence names a specific verb ('Returns the catalogue of enum values') and enumerates the exact contents: scraper types, pagination strategies, parameter types, common parameters, and post-process rule kinds. This is unmistakably the config/catalogue tool rather than any of the sibling getters that fetch scraper, site, or data-group records.

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 gives explicit use-when cases ('what scraper types can I create?', building a wizard UI needing dropdowns) plus a genuine don't-use case ('you already have a valid ScraperDTO body → skip this'). It also routes the agent to the consuming tool, scrapewise_create_scraper, and explains the consequence of ignoring the catalogue (400 validation error).

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.