Skip to main content
Glama
gamercc-apps

Mock Screenshots MCP Server

by gamercc-apps
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

Mock Screenshots MCP server

An MCP server that lets an AI agent compose a fake chat and get a deep link to the matching Mock Screenshots generator — pre-filled and ready to preview and download.

Output is watermarked and clearly fictional, intended for parody, education, design mockups and fiction. It is not for deception — see the ethics policy.

Tools

Tool

What it does

generate_fake_chat

Compose a conversation (platform, messages, contact, status, device, dark) → returns a rendered, watermarked PNG (inline preview + hosted URL for download/share) plus a deep link to the generator. Supports format: "image" (default, returns preview+URL) or "link" (text-only URLs).

list_platforms

Lists supported chat apps and their generator URLs.

list_devices

Lists the iPhone/Android device frames.

generate_fake_chat input

{
  "platform": "whatsapp",            // imessage | whatsapp | whatsapp-group | instagram | telegram | messenger | snapchat
  "contact": "Mom",                  // header name / username / group name
  "status": "typing…",               // header status line (optional)
  "device": "galaxy-s24",            // see list_devices (default iphone-16-pro)
  "dark": true,                      // dark mode (optional)
  "format": "image",                 // "image" (default) | "link" — see Screenshots section
  "messages": [
    {
      "text": "you home?",
      "sender": "them",
      "time": "19:01",
      "image": {
        "data": "<base64 PNG, JPEG, or WebP bytes>",
        "mimeType": "image/png",
        "alt": "A synthetic design mockup"
      }
    },
    { "text": "5 mins!", "sender": "me", "time": "19:02", "ticks": "read" }
  ]
}

messages[].image is optional and supported only for whatsapp and whatsapp-group, so existing text-only requests remain unchanged. Image-only messages are also supported. Attachments must be self-contained PNG, JPEG, or WebP bytes with a matching file signature; SVG, remote URLs, malformed base64, and files over 2 MB are rejected. Alternative text is limited to 160 characters, trimmed, and defaults to Attached image. The server also rejects more than 100 messages, message text over 4,000 characters, header metadata over 256 characters, and aggregate text/image source data over 6,000 bytes before it decodes attachments or builds duplicate JSON/base64url state. The merged site endpoint limits the complete base64url state to 8,000 characters, so the final encoded-state check remains authoritative and a smaller attachment may still be required after conversation metadata is included.

Attachment privacy and URL handling

Use only non-sensitive synthetic or already-public attachments. Attachment bytes are stored as a data URL inside the base64url-encoded JSON state in both the hosted GET /api/render?...&s=<state> URL and the generator edit ?s=<state> URL. Base64url is encoding, not encryption: anyone or any system with either URL can recover the attachment.

Treat every attachment-bearing render or edit URL as sensitive. It may be retained in MCP transcripts, client logs, browser history, proxy/CDN request logs, analytics/referrers, and cache keys. Do not use credentials, private user data, confidential screenshots, or private uploads as fixtures. The MCP's own preview request uses cache: "no-store" and referrerPolicy: "no-referrer" as defense in depth, but those client-side request settings cannot guarantee that the deployed endpoint, intermediaries, or a user-opened URL will not log or cache the full GET URL. No attachment or URL logging is added by this MCP server.

This residual exposure is inherent in the currently deployed URL-state contract. Roll back attachment support by reverting the attachment commit, or avoid messages[].image; existing text-only requests remain compatible and unchanged. A future opaque, expiring server-side state token would require a separate site/API contract and is intentionally not invented here.

Screenshots

Returns a rendered, watermarked screenshot server-side via the site's GET /api/render endpoint (Cloudflare Browser Rendering). Default output (format: "image") includes:

  • Inline preview image (scaled, watermarked — displays immediately)

  • Hosted full-res PNG URL (download / share in DMs, always watermarked and clearly fictional)

  • Deep edit link to the generator, pre-filled with your conversation

Alternately, use format: "link" for text-only output (just the URLs, no image preview).

Always watermarked: Screenshots include a prominent "FAKE" watermark and cannot be disabled. This ensures they remain clearly fictional and non-deceptive for parody, education, design mockups and fiction — see the ethics policy.

Also returns a URL like https://mockscreenshots.com/fake-whatsapp-chat-generator?s=<state> that opens the generator with the conversation loaded (for preview/tweaking before final export).

Related MCP server: ComfyUI MCP Server

Run

npm install
npm start           # stdio server

Use with Claude Desktop / Claude Code

// claude_desktop_config.json  (or: claude mcp add)
{
  "mcpServers": {
    "mockscreenshots": {
      "command": "node",
      "args": ["/absolute/path/to/mcp/server.mjs"]
    }
  }
}

Once published to npm you can instead use npx -y mockscreenshots-mcp.

Publishing / distribution

  1. npm publish the mockscreenshots-mcp package.

  2. Register on registry.modelcontextprotocol.io using server.json.

  3. Submit to mcp.so, Smithery, PulseMCP, Glama, and open a PR to awesome-mcp-servers.

Each listing is a genuine dofollow dev-domain link + agent discovery — the uncontested distribution channel

How it works

The MCP server itself stays tiny and stateless: it builds URLs and encodes the conversation into a compact, URL-safe ?s= parameter (also read by the generator on load, src/lib/share.ts), then fetches a preview from the site's /api/render endpoint, which does the actual (always-watermarked) server-side rendering via Cloudflare Browser Rendering. This keeps the server dependency-light and keeps the human in the loop to preview, tweak and export.

The server never fetches a caller-supplied attachment URL. Preview responses are accepted only when they are PNG data from the fixed Mock Screenshots endpoint. The response body is consumed with a 10 MB streaming cap and the reader is cancelled immediately when that cap is crossed, even when Content-Length is absent or inaccurate. Endpoint errors, invalid responses, and timeouts safely fall back to the hosted image/edit links while retaining the watermark, ethics warning, and (when an attachment is present) attachment privacy warning.

Available Tools

3 tools
generate_fake_chatA

Compose a fake chat screenshot (iMessage, WhatsApp, Instagram DM, Telegram, Messenger, Snapchat) and get a deep link to the Mock Screenshots generator, pre-filled and ready to preview and download. Output is watermarked and clearly fictional; intended for parody, education, design mockups and fiction — not deception.

ParametersJSON Schema
NameRequiredDescriptionDefault
darkNoDark mode. Defaults to false.
deviceNoDevice frame. Defaults to iphone-16-pro.
formatNoReturn an inline preview image (default) or just links.
statusNoHeader status line, e.g. "online", "Active now", "typing…".
contactNoContact name, username or group name shown in the header.
messagesYesThe conversation, in order.
platformYesWhich chat app to mimic.

TDQS

A4/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. It discloses that output is watermarked and clearly fictional, but does not detail other behavioral aspects like authentication, rate limits, or side effects. The parameter schema is rich, but description adds only the watermarking point.

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?

Two sentences front-load the core purpose and add necessary usage warnings without redundancy. Every part contributes value.

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?

Given 7 parameters and no output schema, the description explains that output is a deep link and watermarked. It covers the essential context for using the tool, though it could elaborate on the return structure for different formats.

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 100% with descriptive property descriptions. The description does not significantly add meaning beyond the schema, except for reinforcing the platform list. Baseline of 3 is appropriate.

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?

Description clearly states the tool composes a fake chat screenshot for various platforms and provides a pre-filled deep link. It mentions specific use cases (parody, education, design mockups, fiction) and distinguishes from siblings by focusing on generation rather than listing devices or platforms.

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

Usage Guidelines4/5

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

Description explicitly states the output is watermarked and intended for legitimate purposes, not deception. While it gives usage context, it does not directly contrast with sibling tools (list_devices, list_platforms) that could be used to explore available options.

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

list_devicesA

List the device frames (iPhone and Android) the generators support.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior2/5

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

No annotations provided, so description must carry full burden. It only states the basic action with no disclosure of side effects, authentication needs, or output behavior (e.g., format, pagination).

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?

Single, front-loaded sentence with no wasted words. Efficiently conveys the tool's purpose.

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?

With no parameters and no output schema, the description covers the basic purpose but omits details about return format or data structure, which would help an agent interpret results.

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

Parameters5/5

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

Zero parameters (baseline 4), but description adds meaning beyond the empty schema by specifying the content (iPhone/Android device frames) and context (the generators support). This fully compensates for lack of schema detail.

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?

Description clearly states the verb 'List' and the resource 'device frames (iPhone and Android) the generators support'. It distinguishes from sibling tools: generate_fake_chat (generation) and list_platforms (platforms).

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 guidance on when to use or when not. Context implies use when device frame information is needed, but no comparisons to siblings or prerequisites are mentioned.

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

list_platformsA

List the chat platforms this server can generate, with their generator URLs.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. Discloses that it returns generator URLs, indicating a safe read operation. Lacks details on pagination or limits but sufficient for a simple list.

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?

Single concise sentence, no waste, front-loaded with purpose.

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?

Given no parameters, no output schema, and a simple tool, the description is complete. Tells what it lists and what it returns.

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

Parameters4/5

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

No parameters, baseline 4. Description adds no parameter info, but none needed.

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?

Clearly states it lists chat platforms and their generator URLs. Distinct from sibling tools generate_fake_chat and list_devices.

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 guidance on when to use vs alternatives, but the purpose is straightforward and implies usage to view available platforms.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a distinct purpose: generating a fake chat screenshot, listing device frames, and listing chat platforms. No two tools overlap in functionality.

Naming Consistency5/5

All tools use a consistent verb_noun pattern in snake_case (generate_fake_chat, list_devices, list_platforms), making the naming predictable and easy to understand.

Tool Count5/5

With three tools, the server is appropriately scoped for generating fake chat screenshots, covering the main action and necessary discovery. It is neither too sparse nor overloaded.

Completeness4/5

The tool set covers the core generation workflow and listing of options. A minor gap is the lack of additional customization tools, but the current surface is functional for the stated purpose.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gamercc-apps/mockscreenshots-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server