Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@page-image-mcp generate site images for https://example.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server que lê um site página por página e gera uma imagem coesa com o tema de cada página — sem nenhum texto e sem rostos humanos reconhecíveis.
cd /Users/pastorello/Desktop/MCP
npm install
npm run buildA geração de imagem usa uma instância local do
Draw Things rodando o modelo Flux Schnell
quantizado. Não precisa de API key nem de internet para gerar — mas o app
Draw Things precisa estar aberto com o servidor de API habilitado em
http://127.0.0.1:7860 antes de rodar qualquer tool deste MCP.
Os detectores locais de rosto/texto (scripts/detect_face.py,
scripts/detect_text.py) rodam via OpenCV num virtualenv próprio, não
versionado:
python3 -m venv venv-facedetect
venv-facedetect/bin/pip install opencv-python numpyEles também esperam dois arquivos de modelo em models/ (não versionados
por serem binários grandes — o EAST detector tem ~92MB):
models/face_detection_yunet.onnx — OpenCV Zoo, face_detection_yunet
models/frozen_east_text_detection.pb — modelo EAST de detecção de texto
Related MCP server: Imagen
claude mcp add page-image-mcp -- node /Users/pastorello/Desktop/MCP/dist/index.jslist_pages { url, maxPages } — descobre as páginas do site via
sitemap.xml (com fallback para crawl same-origin por links).
generate_page_image { url, outDir?, styleHint?, size? } — lê uma página
e gera 1 imagem coesa com o conteúdo dela.
generate_site_images { url, maxPages?, outDir?, styleHint?, size? } —
roda o fluxo completo: descobre páginas + gera 1 imagem por página.
Imagens são salvas em ~/Desktop/MCP/output por padrão.
O prompt enviado ao modelo de geração de imagem (via Draw Things) inclui instruções rígidas, sempre anexadas ao tema da página:
proibição explícita de letras, números, palavras, logos, legendas, marcas d'água;
proibição de rostos humanos reconhecíveis — pessoas só podem aparecer como silhuetas distantes ou de costas;
proibição de UI/screenshots.
Ver src/prompt.ts para o texto exato.
Reads a single web page, extracts its theme/content, and generates two cohesive images representing it (16:9 landscape and 9:16 portrait) via a local Draw Things instance (Flux Schnell, must be running with its API server enabled on http://127.0.0.1:7860 — no cloud dependency, no API key), saved into a folder named after the page title. The prompt forbids text and human faces, and two local offline detectors (OpenCV YuNet for faces, EAST for text) verify each result, retrying with a new seed up to 3 times if either is detected.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the page to read | |
| outDir | No | Base directory under which the page's folder will be created (defaults to ~/Desktop/MCP/output) | |
| styleHint | No | Optional visual style guidance, e.g. 'minimalist flat illustration' or 'moody photography' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description extensively discloses behavior: local execution, model (Flux Schnell), API endpoint, folder naming, prompt restrictions (no text/faces), offline detectors (OpenCV YuNet, EAST), and retry logic (up to 3 times). This fully compensates for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single informative paragraph that front-loads the main action and key details. It is concise but could be slightly more structured (e.g., bullet points for prerequisites or retry logic) without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers many behavioral aspects, it lacks explicit mention of return values (e.g., file paths) and error handling (e.g., what happens if all retries fail). Given no output schema, these gaps reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds some context (e.g., folder named after page title) but does not significantly enhance parameter meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'generates' and the resource 'images for one page' with specific output (two images, 16:9 and 9:16 ratios), distinguishing it from sibling 'generate_site_images' by focusing on a single page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear prerequisites (local Draw Things instance running with API at http://127.0.0.1:7860) and implies use case (offline image generation from a page), but does not explicitly state when not to use or mention alternatives like generate_site_images for multiple pages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discovers pages for a site and generates a folder per page (named after the page title), each containing a 16:9 and a 9:16 cohesive image, via a local Draw Things instance (Flux Schnell, must be running with its API server enabled on http://127.0.0.1:7860 — no cloud dependency, no API key), verified against local face and text detectors with automatic retry. Use with a reasonable maxPages to control run time.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Starting URL of the site | |
| outDir | No | Base directory under which each page's folder will be created (defaults to ~/Desktop/MCP/output) | |
| maxPages | No | Maximum number of pages to process | |
| styleHint | No | Optional shared visual style guidance across all pages |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the local Draw Things dependency, local face/text detectors, and automatic retry, but does not detail error handling (e.g., if Draw Things is not running) or the outcome of verification failures beyond retry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, structured with the main functionality and a usage note. It is not overly verbose, but the first sentence is lengthy. It is well-organized but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations. The description explains the process and constraints, but lacks details on output (e.g., folder and image naming conventions) and does not address potential side effects or prerequisites beyond the local server.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage of parameter descriptions. The description adds minimal extra semantic value beyond what is already in the schema (e.g., defaults, constraints). The usage tip about maxPages is mentioned but not as part of parameter docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers pages for a site and generates folders with 16:9 and 9:16 cohesive images per page. It distinguishes itself from sibling tools like generate_page_image by focusing on an entire site.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions using a reasonable maxPages to control run time, but does not explicitly explain when to use this tool versus alternatives (e.g., generate_page_image for a single page). The context is implied but not clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discovers pages for a website starting from a URL, preferring sitemap.xml and falling back to a same-origin crawl. Returns a list of page URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Starting URL of the site | |
| maxPages | No | Maximum number of pages to discover |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description bears full burden. It discloses the two discovery methods (sitemap-first, then crawl) and the output type, but omits details like auth requirements or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that are front-loaded and contain no filler. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description adequately explains the return value (list of page URLs) and covers the core behavior. No missing information relative to complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds little beyond implying 'starting from a URL' for the url parameter and 'maximum' for maxPages, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers pages from a URL, specifying the method (sitemap preference with fallback crawl) and output (list of page URLs). It is distinct from siblings which generate images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or when not to use it. With sibling tools present, such guidance would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0generate_page_imagegenerate_site_imageslist_pagesScored across 3 tools
Each tool has a clearly distinct purpose: generating images for a single page, generating images for multiple pages, and discovering page URLs. No overlap exists.
All tool names follow a consistent verb_noun pattern (generate_page_image, generate_site_images, list_pages) using snake_case.
Three tools is well-scoped for a focused image-generation server—neither too few nor too many.
The tool set covers the full workflow: discover pages, generate images for a single page, and generate images for an entire site. No obvious gaps for its purpose.
Analyze images from multiple angles to extract detailed insights or quick summaries. Describe visu…
Desktop and mobile website screenshots plus page context for AI agents and automation workflows.
Turn any idea, URL, doc, or PDF into on-brand visuals: 100+ formats, native in 150+ languages
Web Content Extract Mcp connects AI agents to real public APIs via MCP. Tools include
