Skip to main content
Glama

scrapewise_get_enrichment

Read-onlyIdempotent
        Returns the lineage of a group's enriched dataset: which runs were combined, on which
        columns they were matched, and when it was last built. Run ordinals match the `(run N)`
        column tags in the enriched data. `configured` is false when there is no saved recipe
        (e.g. a legacy title-merge) even if enriched data still exists.

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

        Returns:
          `EnrichmentLineageDTO` — `{configured, runs:[{ordinal,scraperId,scraperName,primary,
          latestRunFinished,latestRunItems}], matches:[{fromOrdinal,fromColumn,toOrdinal,toColumn,
          matchMode}], lastEnrichedAt, items}`.

        Examples:
          - Use when: "what was group {id}'s enriched data combined from"
          - Use when: "which runs and join columns produced this enriched dataset" → same op
          - Don't use when: you want the raw enriched rows → read the enriched group's data instead

        Error Handling:
          - 400 (CustomerError envelope) if no group with the given 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_get_enrichment"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Beyond the read-only and idempotent annotations, the description explains semantic edge cases such as `configured` being false for legacy title-merges even when enriched data exists, plus 400/401 error behavior. It does not mention the runtime caveat that the response is JSON-as-text with a dynamic shape and should be parsed defensively, which is a meaningful behavioral gap.

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 purpose is front-loaded, and the Args/Returns/Examples/Error Handling structure is easy to scan. The second 'Use when' example is slightly redundant, but the remaining detail is generally useful for a lineage tool without an output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Because there is no output schema, the description appropriately supplies the DTO shape, error handling, and key lineage semantics. It is nearly complete but omits the runtime hint that the response should be treated as a string-or-object blob and parsed defensively.

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 schema only defines `id` as an undescribed string, so the description carries the burden and adds useful meaning: it is a required path parameter and must be the original group's MongoDB ObjectId. That is sufficient for a single-parameter tool, though it stops short of adding example formatting.

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 description states a specific verb and resource: returning the lineage of a group's enriched dataset, including runs combined, match columns, and last build time. It also clearly distinguishes this from reading raw enriched rows, so an agent can identify the operation 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?

It provides explicit 'Use when' examples and a 'Don't use when' alternative for raw enriched rows. The routing guidance is clear enough that an agent can choose this tool versus the data-reading alternative without inference.

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.