redreplier

Analyze Website

analyze_website

Scrape any URL to get an AI-written business description, enabling preview of website text before you create or update the site.

Instructions

Scrape a URL and return an AI-written business description as { description }, without creating or changing any website. Use it to draft or preview the text before create_website or update_website, then pass the result as their description. Consumes one AI generation from the monthly quota unless a precomputed description already exists for that domain, and refunds it if generation fails. Returns 400 when the quota is exhausted or url is not a valid URL, and an error when the page has too little readable text.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes	Full website URL to scrape (e.g. "https://example.com")

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	No	{ description }: the AI-written business description, ready to pass to create_website or update_website.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.1Sep 7, 2026

changedInput schema / properties / url / description

Previous value: -"Website URL to analyze"New value: +"Full website URL to scrape (e.g. \"https://example.com\")"

changedOutput schema / properties / result / description

Previous value: -"The AI-generated business description for the analyzed URL."New value: +"{ description }: the AI-written business description, ready to pass to create_website or update_website."

First observedv0.1.0Sep 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint false, destructiveHint false), the description discloses quota consumption, refund behavior on failure, precomputed-domain shortcut, and specific HTTP error codes for quota exhaustion and invalid URL. This is rich behavioral context that annotations alone do not provide, and it aligns with the readOnlyHint false because quota consumption is a side effect.

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

Conciseness5/5

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

Four sentences with no redundancy. The main action is front-loaded, followed by usage guidance, quota behavior, and error handling. Every sentence earns its place and there is no fluff or repetition.

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?

The tool has one parameter, an output schema (not shown but present), and clear error conditions. The description covers usage flow, side effects, and failure modes. Nothing an agent needs to call it correctly is missing; the output schema handles return structure.

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?

The input schema already documents the only parameter 'url' with a clear example, so schema coverage is 100%. The description adds no new meaning about the parameter itself; it mentions 'url' in error conditions but that is not additional semantic detail. Baseline 3 is appropriate because the schema does the heavy lifting.

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 (scrape) and resource (URL) with a clear deliverable (AI-written business description). It also distinguishes itself from siblings by explicitly positioning it as a drafting/preview step before create_website or update_website, making its purpose unambiguous.

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 explicitly tells the agent when to use this tool ('Use it to draft or preview the text before create_website or update_website') and how to chain the result ('pass the result as their description'). It also clarifies the non-destructive nature and error scenarios, leaving no guesswork about invocation context.

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