Skip to main content
Glama

scrapewise_list_customer_schema

Read-onlyIdempotent
        Return every JSON-Schema document owned by the authenticated customer (filtered
        by `customerRef = <auth-principal>`). Excludes global schemas — those are
        returned by a separate global-list endpoint that lives outside the MCP surface.
        Each entry is a lightweight `SchemaListDTO` (id, name, type, version) — enough
        to build a picker UI or to feed an agent's "which schema should I use?" decision.
        For the full schema content (the JSON-Schema document itself) call the
        schema-by-id endpoint with the `id` from this list.

        **Not paginated** — returns the full flat set in one call. This is fine for the
        legacy per-(type, version) schemas this endpoint was built for, but be aware of
        the CUSTOM-type caveat below before using it as a CUSTOM schema picker.

        **CUSTOM-type caveat:** this endpoint lists one row PER VERSION document, not one
        row per schema group. A CUSTOM group with 5 saved versions shows up here as 5
        separate rows, all sharing the same `groupId` but different `id`/`version`. To
        discover "what custom schema groups does this customer have" (one row per group,
        with the group's current `latestPublishedVersion`), call
        scrapewise_list_custom_schema_groups instead — that is the cursor-paginated,
        one-row-per-group summary and the intended picker source for CUSTOM. Use this
        endpoint's `groupId` field only to know which group a given version row belongs to
        (e.g. after finding a version's `id` you want to add a sibling version to).

        Args:
          - none — the authenticated customer scope is implicit.

        Returns:
          `List<SchemaListDTO>` — zero or more schemas. Each row carries:
            - id (string): MongoDB ObjectId; use to fetch full content or to attach
              this schema to a new AI_CONF scraper
            - name / type / version: enough context for picker UIs and agent
              decision-making
            - groupId (string, CUSTOM-only, null otherwise): the schema group this
              version belongs to. Pass it as `body.groupId` on
              scrapewise_create_customer_schema to add a new version to this same group.

        Examples:
          - Use when: "what schemas do I have?" (non-CUSTOM, or you need per-version
            detail) — single read, returns the full inventory
          - Use when: discovering whether a customer schema for a given domain
            already exists before creating a new one via scrapewise_create_customer_schema
          - Don't use when: you want a one-row-per-CUSTOM-group summary (with
            `latestPublishedVersion`, `versionCount`, `scraperRefCount`) → use
            scrapewise_list_custom_schema_groups instead
          - Don't use when: you want global schemas too → use the global-schema-list
            endpoint (currently outside the MCP surface; see scraper-api OpenAPI for
            administrative tooling)
          - Don't use when: you need the full JSON-Schema content — this is a
            summary list; fetch by id for the full document

        Error Handling:
          - 200 with empty list if the customer has no custom schemas (not an error).
          - 401 Unauthorized if no Firebase JWT or API key.
          - 500 INTERNAL with `correlationId` if Mongo lookup fails.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses that the call is not paginated and returns the full flat set, that CUSTOM schemas appear as one row per version rather than per group, and that groupId is null for non-CUSTOM rows. It also enumerates error behavior (200 empty list is not an error, 401 on missing JWT/API key, 500 with correlationId).

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 core behavior and well-sectioned (Returns, Examples, Error Handling), but it is long and the CUSTOM per-version caveat is stated twice — once in the prose block and again in the 'Don't use when' bullet. Some redundancy could be trimmed without losing meaning.

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?

For a zero-argument list tool with no output schema, the description covers the return row shape, the id/groupId handoff to sibling create/fetch tools, pagination status, and error cases. Nothing an agent needs in order to call it and interpret the result is missing, though the runtime hint's warning about dynamic response shape sits in mild tension with the declared `List<SchemaListDTO>`.

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?

Zero parameters, so the baseline is 4; the description earns the extra point by explicitly stating 'Args: none — the authenticated customer scope is implicit,' which prevents an agent from hunting for a customer identifier argument.

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 ('Return every JSON-Schema document owned by the authenticated customer') plus the exact filter applied (`customerRef = <auth-principal>`). It explicitly separates itself from the global-schema list and from `scrapewise_list_custom_schema_groups`, so an agent can distinguish it from siblings without opening any 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 (full inventory, pre-create duplicate check) and three 'Don't use when' exclusions, each naming the correct alternative (custom-group list, global list, schema-by-id for content). This is the full when/when-not/alternative triad.

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.