DeepScout

Create a matching job

scout_match_websites

Create a matching job: find the same products on the reference website and the competitor websites. A paid job matches every pair of its websites, so the matches also connect the competitors with each other. All the websites must be scraped first. The job waits for approval with its price estimate; sample=True runs the free sample of the project instead. Approve it with scout_approve_job(job_kind="matching").

DeepScout matching does not need EAN codes. It finds the same product under different names, even in another language. Each uncertain pair gets a strict check with the product photos and data. A match must have the same brand, specifications, and pack size. It must also be the same variant, for example the same color, size, capacity, edition, or model number. Products with almost the same name often fail this check, so DeepScout matching is more accurate than homemade matching scripts.

The matches export has one row for each product and its match on another website. Join it with the product exports of the websites (website_id + product_id) to get:

assortment gaps: products that competitors sell and the reference website does not. These are competitor products with matches, but with no match on the reference.
price comparison of the market: the prices of one product on all the websites, also between two competitors.
assortment overlap: the products that each pair of websites shares. The completed job gives the counts in overlap.

The free sample matches a part of the reference website, once for each project. It does not match the competitors with each other. It shows the quality of the matches before the user pays. Run the sample before you create the paid job: a matching job that waits for approval blocks the sample.

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": {
      "project_id": "<project_id>",
      "reference_website_id": "<reference_website_id>",
      "competitor_website_ids": "<competitor_website_ids>"
    },
    "name": "scout_match_websites"
  }
}

Input Schema

Name	Required	Description	Default
`sample`	No
`project_id`	Yes
`reference_website_id`	Yes
`competitor_website_ids`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only supply openWorldHint=false and destructiveHint=false, so the description carries the real burden and does: the job is paid, produces a price estimate, and then blocks awaiting approval rather than starting work immediately. It also discloses that the free sample is limited (part of the reference website, once per project, no competitor-to-competitor matching) — exactly the cost/blocking behavior an agent needs before invoking.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose, precondition, and sample guidance are front-loaded, which is good, but roughly half the text is a tutorial on joining the matches export to derive assortment gaps, price comparison, and assortment overlap. Since an output schema exists and this is a create-job tool, that material is downstream guidance rather than invocation help and dilutes the signal.

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 four-parameter job-creation tool with an output schema, the description covers what an agent could get wrong: scraping prerequisite, cost/approval blocking, sample-before-paid ordering, and the approval call. Only the id-to-role mapping for project_id is thin, and the rest leaves nothing essential missing.

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

Parameters3/5

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

Schema coverage is 0%, so the description must compensate. It does well on the two riskiest parameters — it explains that sample=True runs the free sample of the project instead of the paid job, and it clearly separates 'the reference website' from 'the competitor websites', which is the main misuse risk here. But project_id is only mentioned obliquely ('of the project', 'once for each project'), and nothing states that competitor_website_ids is a list or that the three ids are required.

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?

Opens with a specific verb and resource — 'Create a matching job: find the same products on the reference website and the competitor websites' — and defines the matching semantics (cross-competitor matching, no EAN needed, strict variant checks). No sibling tool in the list does anything similar, and the description makes that distinction obvious.

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?

Explicit preconditions ('All the websites must be scraped first'), an explicit ordering rule ('Run the sample before you create the paid job'), and the reason for it ('a matching job that waits for approval blocks the sample'). It also names the follow-up action and its argument: scout_approve_job(job_kind="matching").

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

All DeepScout 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.