Website Change Detector & Diff API

industrial_platform/web-change-intelligence

industrial_platform--web-change-intelligence

Destructive

This tool calls the Actor "industrial_platform/web-change-intelligence" and retrieves its output results. Actor description: Detect page changes and deterministic diffs. Price: $0.01 per successful comparison.

This tool requires an x402 payment. Include a valid x402 payment signature in the request metadata (_meta["x402/payment"]). Your MCP client must support the x402 payment protocol.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	REQUIRED Public http:// or https:// URL to inspect. Example values: "https://example.com/"
`selector`	No	Optional CSS selector that restricts monitoring to a specific part of an HTML page, such as main, #pricing, or .inventory.
`waitSecs`	No	Max seconds (0–45, default 30) to cap the wait for the Actor run to reach terminal state. For long-running Actors the response returns at the cap with the current run status; follow `nextStep` to poll via get-actor-run. Set to 0 to fire-and-forget.
`previous_hash`	No	Optional current_hash from a previous run. Use this for compact changed/unchanged checks when a detailed diff is not required.
`previous_text`	No	Optional current_text returned by a previous run. When provided, the Actor returns deterministic added/removed excerpts and change metrics.
`max_diff_chars`	No	Maximum length returned for each added/removed excerpt. Example values: 12000
`max_text_chars`	No	Maximum characters retained before hashing and comparison. Keep this value consistent across repeated checks. Example values: 100000
`timeout_seconds`	No	Maximum time allowed for the target request. Example values: 30
`ignore_selectors`	No	Optional HTML selectors to remove before comparison, useful for clocks, rotating banners, ads, or other volatile regions.
`include_current_text`	No	Return current_text so a later run can perform a detailed text comparison. Example values: true

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 30, 2026

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=true, openWorldHint=true). The description adds genuinely useful non-annotation context: the $0.01 pricing model and the x402 payment-signature requirement in _meta. It does not, however, explain the destructive hint or the async run/poll lifecycle.

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?

The actual purpose is buried after a redundant first sentence that restates the title, and the payment paragraph is appended rather than integrated. Roughly one of the three sentences is boilerplate, so structure is adequate but not front-loaded.

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

Completeness3/5

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

An output schema exists, so return values need not be explained, and the payment prerequisite is disclosed. Still missing for a wrapper tool: the asynchronous run semantics implied by waitSecs and how to poll via the sibling get-actor-run when the cap is hit.

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 description coverage is 100% across all 10 parameters, so the schema already documents url, selector, previous_hash/text, and the char caps in detail. The description adds no parameter-level meaning beyond that, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The second sentence ('Detect page changes and deterministic diffs') states a specific verb+resource that an agent can act on. However, the primary framing is tautological wrapper boilerplate ('calls the Actor X and retrieves its output results'), and it offers no differentiation from the generic run-management siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus alternatives, no exclusions, and no mention of the sibling tools (get-actor-run, get-dataset-items) that the run/poll workflow would route to. Only the payment prerequisite is noted, which is a requirement rather than usage guidance.

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

All Website Change Detector & Diff API 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.