Skip to main content
Glama
Manish-Tamang

dittu

by Manish-Tamang
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Clone website frontend

clone_website

Capture a live website's frontend into a static preview and editable Next.js or Astro projects, then verify visual fidelity against the original using desktop and mobile pixel diffs.

Instructions

Clone a website's frontend (markup, original CSS, fonts, images, scroll animations) into a static preview plus Next.js and Astro projects, then score it against the original with pixel diffs at desktop and mobile widths. Takes ~1 minute per page (several minutes with build=true). Returns output paths and scores (percent identical).

Input Schema

NameRequiredDescriptionDefault
urlYesPage to clone, e.g. https://gole.codes
buildNoAlso npm install + build + score the generated apps (slow, default false)
pagesNoCrawl up to n same-site pages (default 1)
outDirNoOutput directory (default ./dittu-out/<host>)
removeNoCSS selectors to drop (cookie banners, chat widgets)
verifyNoScore the clone against the original (default true)
waitMsNoExtra wait after load in ms
stylingNocss keeps the original stylesheet (default); tailwind converts class rules to Tailwind utilities wherever that renders identically and keeps the rest as CSS
frameworksNoProjects to generate (default next + astro)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • changedInput schema / properties / url / description
      Previous value: -"Page to clone, e.g. https://example.com"New value: +"Page to clone, e.g. https://gole.codes"
  2. Changed1 schema field changedv0.2.0
    • addedInput schema / properties / styling
      Added value: +{
+  "description": "css keeps the original stylesheet (default); tailwind converts class rules to Tailwind utilities wherever that renders identically and keeps the rest as CSS",
+  "enum": [
+    "css",
+    "tailwind"
+  ],
+  "type": "string"
+}
  3. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Beyond readOnlyHint=false and openWorldHint=true, the description discloses the main cost driver (per-page duration, slower with build=true) and the side effect of writing artifacts to an output location with returned paths and similarity scores. It does not say whether existing output directories are overwritten or what happens on partial failure, so it stops short of full transparency.

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?

Two tightly packed sentences, front-loaded with what is cloned and generated, followed by timing and return values. Nearly every clause earns its place; the desktop/mobile width detail is the only bit that leans toward implementation trivia.

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?

With nine parameters and no output schema, the description carries the return-value burden and does so ('Returns output paths and scores (percent identical)'). Combined with the full schema coverage and cost disclosure, an agent has enough to invoke it correctly; failure modes and overwrite behavior are the remaining gaps.

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%, so every parameter is already documented, which sets the baseline at 3. The description adds modest context by tying throughput to page count and clarifying the desktop/mobile scoring widths, but contributes no new semantics for parameters like remove, waitMs, styling, or frameworks.

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?

States a concrete verb and resource ('Clone a website's frontend') and enumerates exactly what is captured (markup, CSS, fonts, images, scroll animations) and what is produced (static preview plus Next.js and Astro projects). It does not differentiate from siblings like verify_clone, and in fact overlaps with them by also scoring the clone, which slightly muddies which tool to pick.

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

Usage Guidelines3/5

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

No explicit when-to-use or when-not-to-use guidance, and no mention of when to prefer verify_clone or read_report. The time estimate ('~1 minute per page (several minutes with build=true)') implies when the expensive path is worth it, but the agent must infer routing between siblings.

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

Deploy Server

Other Tools