What can you do with this server?

Nightmarquee is an MCP stdio server that lets AI coding assistants browse and fetch cinematic website build prompts, with free and paid tiers. * nightmarquee_search_prompts: search the prompt catalog by free-text query, category (hero, landing, saas, portfolio, ecommerce, 3d), and tier (free/unlimited), with result limits. * nightmarquee_get_prompt: fetch a full build prompt by slug, optionally customizing the fictional brand and targeting a tool dialect (lovable, bolt, cursor, claude). * nightmarquee_sign_in: start and complete a browser-based sign-in flow to unlock Unlimited prompts. * nightmarquee_whoami: check signed-in status, connected email, and how many free/unlimited prompts are accessible. * Prompts are also exposed as native MCP prompts, so the whole catalog appears in clients like Claude Code as slash commands or in the Claude Desktop attachment menu. * Free prompts (e.g. glasshouse-nine, aetheris-voyage, nordlys-fintech, solstice-festival, lumen-observatory) work without an account; locked prompts return a teaser and pricing link. * Supports headless/CI use via NIGHTMARQUEE_TOKEN and configurable API/home/timeout/telemetry environment variables.

nightmarquee

by ant-dev-lab

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

nightmarquee

Cinematic website prompts with live previews, inside your editor.

Art-directed prompts for hero sections, landing pages, SaaS, portfolio, e-commerce and 3D/WebGL scenes. Each is tuned for Lovable, Bolt, Cursor and Claude, and each has a live demo you can scroll.

An MCP (Model Context Protocol) stdio server. Node 20 or newer.

Install

Claude Code

claude mcp add nightmarquee -- npx -y nightmarquee

Claude Desktop / Cursor: add to your MCP config:

{
  "mcpServers": {
    "nightmarquee": {
      "command": "npx",
      "args": ["-y", "nightmarquee"]
    }
  }
}

Claude Desktop reads ~/Library/Application Support/Claude/claude_desktop_config.json on macOS and %APPDATA%\Claude\claude_desktop_config.json on Windows. Cursor reads ~/.cursor/mcp.json, or .cursor/mcp.json inside a project.

No account needed. Free prompts work immediately.

Related MCP server: sitemd

Use

nightmarquee_search_prompts: browse by query, category or tier
nightmarquee_get_prompt: fetch one by slug, optionally with your own brand name and a tool dialect (lovable, bolt, cursor, claude)
nightmarquee_sign_in: connect an account to unlock Unlimited prompts
nightmarquee_whoami: check what's connected

Categories are hero, landing, saas, portfolio, ecommerce, 3d and mobile.

Ask for a design in plain language and the model will usually reach for nightmarquee_search_prompts on its own. Or drive it directly:

nightmarquee_get_prompt(slug: "glasshouse-nine", tool: "cursor", brand: "Northwind")

Every prompt in the catalog is also registered as an MCP prompt, so the whole library shows up in your client's command palette. In Claude Code that means a slash command per design:

/mcp__nightmarquee__glasshouse-nine

Other clients surface MCP prompts their own way. Claude Desktop lists them in the attachment (+) menu. The list is built from the catalog fetched at startup, so if the server can't reach nightmarquee.com when your editor launches, the tools still work but the per-prompt commands won't appear until you restart.

Unlimited

Some prompts are free, currently glasshouse-nine, aetheris-voyage, nordlys-fintech, solstice-festival and lumen-observatory. The rest need Unlimited. Run nightmarquee_search_prompts with tier: "free" for the live list.

Run nightmarquee_sign_in and approve the code in your browser. It waits about a minute; if you took longer, run it again and it picks up the same request rather than issuing a new code. Either way the rest unlock in the same session, no restart. Fetching a locked prompt without an entitlement returns a teaser and a pricing link, never the body.

For headless environments where no browser is reachable, carry a token across instead: sign in once on a machine that has a browser, copy the token value (nm_live_…) out of ~/.nightmarquee/credentials.json, and set it there.

{ "env": { "NIGHTMARQUEE_TOKEN": "nm_live_..." } }

Connections are listed on your account page and can be revoked from there; the next call falls back to free-only.

Configuration

Variable	Effect
`NIGHTMARQUEE_TOKEN`	Use this token instead of the stored one. Wins over `credentials.json`.
`NIGHTMARQUEE_API`	Point at a different backend. Defaults to `https://nightmarquee.com`.
`NIGHTMARQUEE_HOME`	Directory for `credentials.json`. Defaults to `~/.nightmarquee`.
`NIGHTMARQUEE_TIMEOUT_MS`	Ceiling on every API request, in milliseconds. Defaults to `10000`; unparseable or non-positive values fall back to the default, and anything above `2147483647` is clamped to it.
`NIGHTMARQUEE_NO_TELEMETRY`	Set to `1` (any non-empty value works) to stop sending the install ID and your client's name. See below for exactly what this does and doesn't cover.

Privacy Policy

Full policy: https://nightmarquee.com/privacy

What is collected

Credentials are stored locally at ~/.nightmarquee/credentials.json, mode 0600.

Fetching a prompt is an HTTP request to nightmarquee.com, so the server necessarily sees which prompt slug and tool dialect you asked for, and logs that. That is true in every configuration.

On top of that, each request carries three headers by default:

x-nm-install: a random UUID generated on your machine on first run and kept in credentials.json. Not derived from anything, tied to nothing else.
x-nm-client: the name and version your MCP client reports, e.g. claude-code/2.1.240.
x-nm-version: the version of this package.

If you are signed in, the request also carries a bearer token identifying your NightMarquee account.

Never sent, in any configuration: the prompts or code you write, file paths, file contents, or anything else from your project.

How it is used and stored

Request records are used to operate the service and to understand which prompts people use, nothing else. They are held in our Supabase database.

Opting out

NIGHTMARQUEE_NO_TELEMETRY=1 drops x-nm-install and x-nm-client. x-nm-version is still sent, and requests are still made and still logged server-side, and the log rows just carry no install ID and no client name. If you are signed in, the bearer token identifies your account regardless of this setting.

Your data is not sold, rented, or shared with third parties for their own purposes. It is processed only by the infrastructure providers running the service on our behalf: Vercel (hosting), Supabase (database), and Lemon Squeezy (payments, for subscribers only). No advertising or analytics networks receive any of it.

Retention

Account data is kept while your account exists. Email support@nightmarquee.com to delete your account and we remove your data within 30 days, except records we must keep for tax and accounting (held by the merchant of record).

Request records are not currently expired on a fixed schedule; they are deleted on request along with your account.

Tokens and local credentials are under your control at any time: revoke a connected editor from your account page, which deletes the token outright, or delete ~/.nightmarquee/credentials.json to remove the local copy.

Contact

Privacy questions, data access, and deletion requests: support@nightmarquee.com

License

The server code in this package is MIT.

The prompt text it fetches is licensed separately: free prompts cover personal and non-commercial projects, Unlimited adds commercial use, and the prompt text itself may not be republished or resold. Full terms: https://nightmarquee.com/license.

MIT © NightMarquee

Available Tools

4 tools

nightmarquee_get_promptGet a NightMarquee promptA

Read-onlyIdempotent

Fetch the full build prompt for one NightMarquee design, tuned for the target tool. Free prompts need no account; Unlimited prompts need one (run nightmarquee_sign_in).

ParametersJSON Schema

Name	Required	Description
`slug`	Yes	Prompt slug, e.g. "glasshouse-nine" — from nightmarquee_search_prompts
`tool`	No	Target tool dialect, defaults to claude
`brand`	No	Swap the fictional brand for this name

Output Schema

ParametersJSON Schema

Name	Required	Description
`slug`	Yes
`text`	No	The full build prompt, present only when entitled
`tier`	No
`tool`	No	Dialect the text was written for
`error`	No	Set when the prompt could not be fetched
`title`	No
`demoUrl`	No
`entitled`	Yes	Whether the full build text is included; false means locked or missing
`pricingUrl`	No	Set when the prompt is locked

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds meaningful context beyond that by explaining that Free prompts need no account while Unlimited prompts require one, and it points to the sign-in sibling for the needed prerequisite.

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 carry the essential information with no filler. The main action and the account requirement are front-loaded, and the mention of nightmarquee_sign_in is directly actionable.

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?

For a low-complexity tool with one required parameter, full schema coverage, an output schema, and safety annotations, the description is complete. An agent can determine what the tool does, whether authentication is needed, and how to proceed if it is.

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 the schema already documents all three parameters fully. The description does not add parameter-specific detail beyond the schema, but it does reinforce the purpose of the tool and the auth context for retrieving prompts.

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 and resource: it fetches the full build prompt for one NightMarquee design, tuned for a target tool. This clearly distinguishes it from the sibling search tool, which finds prompts rather than retrieving their full content.

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?

The description gives clear context about account requirements and tells the agent to run nightmarquee_sign_in for Unlimited prompts. It does not explicitly state when to prefer this over search_prompts, but the purpose and the schema's slug source make the intended flow reasonably clear.

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

nightmarquee_search_promptsSearch NightMarquee promptsA

Read-onlyIdempotent

Search the NightMarquee catalog of website and mobile app build prompts by keyword, category (hero, landing, saas, portfolio, ecommerce, 3d, mobile) or tier. Returns matching slugs, taglines and demo links to pass to nightmarquee_get_prompt.

ParametersJSON Schema

Name	Required	Description
`tier`	No	"free" needs no account; "unlimited" needs a signed-in Unlimited plan
`limit`	No	How many matches to return, 1 to 50, default 10
`query`	No	Free text, matched against titles, taglines and style keywords
`category`	No	Restrict to one section of the catalog

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Set only when the catalog could not be reached
`total`	Yes	Matches before `limit` was applied
`results`	Yes	Matches, capped at `limit`

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds little behavioral context beyond what annotations and the output schema already provide, but it does not contradict them.

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?

A single dense sentence with an action, resource, and downstream integration. The inline list of categories is somewhat redundant with the schema enum, but it supports quick at-a-glance understanding without wasting words.

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?

For an optional-parameter, read-only search tool with a fully documented schema and an output schema present, the description provides enough context to select and invoke it correctly. It could clarify what happens on an empty search, but the schema and output schema mitigate that gap.

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%, with descriptions for query, category, tier, and limit including enums, defaults, and auth implications. The description merely echoes the parameter vocabulary without adding new semantic detail, so the schema carries the load.

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 opens with a specific verb-resource pair ('Search the NightMarquee catalog of website and mobile app build prompts') and names the search dimensions (keyword, category, tier). It also differentiates itself from the sibling retrieval tool by stating that results are slugs, taglines, and demo links to feed into nightmarquee_get_prompt.

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?

The workflow is clear: search first, then pass a matching slug to nightmarquee_get_prompt. This implicitly tells the agent when to select this tool versus the retrieval sibling, though it does not explicitly mention when not to use it or spell out exclusions.

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

nightmarquee_sign_inSign in to NightMarqueeA

Connect a NightMarquee account so Unlimited prompts work here. Shows a short code to approve in the browser. Run it again after approving to finish.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`email`	No	Set once approved
`status`	Yes	Run the tool again while this is "waiting"
`message`	Yes	The same text shown to the human
`userCode`	No	The code to approve in the browser
`verificationUri`	No	Where to approve it

TDQS

A4.6/5.0

Behavior5/5

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

The description discloses important behavioral details beyond annotations: it requires an external browser approval, shows a short code, and must be run twice. This is valuable interactive context that annotations (readOnlyHint=false, openWorldHint=true) only hint at. No contradiction with annotations.

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 with no filler. The purpose is front-loaded, and the step-by-step flow is conveyed efficiently. Every sentence earns its place.

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?

The description covers the interactive nature, the need for a second run, and the purpose. With an output schema present and no parameters, the agent has enough to invoke it correctly. It could optionally mention prerequisites (e.g., already having a NightMarquee account) but that is minor.

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?

There are no parameters (schema coverage 100% trivially). Per the rubric, 0 params earns a baseline of 4. The description adds context about the sign-in flow but not parameter-level semantics since none exist.

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 clearly states the tool's purpose: 'Connect a NightMarquee account' and explains the benefit ('so Unlimited prompts work here'). It also distinguishes itself from siblings (search, get, whoami) by describing a sign-in flow, which is unique among the listed tools.

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?

The description provides clear usage context: it is needed for Unlimited prompts and involves a two-step process ('Run it again after approving'). It implicitly tells the agent when to use it (when sign-in is needed), though it doesn't explicitly exclude alternatives. Since no sibling does sign-in, this is sufficient.

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

nightmarquee_whoamiNightMarquee account statusA

Read-onlyIdempotent

Show which NightMarquee account is connected and what it can reach.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`free`	No	Prompts readable without an account
`email`	No
`error`	No
`message`	Yes
`signedIn`	Yes
`unlimited`	No	Prompts that need Unlimited

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds 'what it can reach,' providing context about the output scope without contradicting annotations. This adds value beyond the structured hints.

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?

A single, succinct sentence that front-loads the core function. No wasted words; it gets straight to the point.

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 the tool's simplicity (no params, output schema provided, annotations cover side effects), the description is fully sufficient. An agent has all necessary information to invoke it correctly.

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?

With zero parameters, the baseline is 4. The description doesn't need to explain any parameter semantics since there are none, and the output schema handles return details.

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 clearly states the tool's function: showing the connected NightMarquee account and its accessible resources. It distinguishes itself from sibling tools like sign_in (connection) and search/get_prompt (prompt operations), so an agent can easily identify when this is the right tool.

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?

The context is clear: use this when you need to verify which account is connected or what it can access. It doesn't explicitly mention alternatives, but the purpose is self-evident and distinct from siblings, so no exclusions are needed.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updatev0.1.5Sep 16, 2026

Changednightmarquee_search_prompts1 field changed

changedInput schema / properties / category / enum

Previous value: -[
-  "hero",
-  "landing",
-  "saas",
-  "portfolio",
-  "ecommerce",
-  "3d"
-]New value: +[
+  "hero",
+  "landing",
+  "saas",
+  "portfolio",
+  "ecommerce",
+  "3d",
+  "mobile"
+]

4 tool updatesv0.1.4Sep 8, 2026
- First observednightmarquee_get_prompt
- First observednightmarquee_search_prompts
- First observednightmarquee_sign_in
- First observednightmarquee_whoami

Deploy Server

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

TDQS

A4.2/5.0

Scored 2026-09-16 16:25 across 4 tools

Disambiguation5/5

Each tool has a distinct job: searching the catalog, retrieving a prompt, checking account status, and signing in. There is no meaningful overlap in purposes.

Naming Consistency4/5

All tools share the 'nightmarquee_' prefix and mostly use verb_noun naming like get_prompt and search_prompts. 'whoami' and 'sign_in' are minor stylistic deviations but still predictable.

Tool Count5/5

Four tools is well-scoped for a narrow catalog-and-account server. Each tool covers a necessary part of the workflow without unnecessary bulk.

Completeness4/5

The core loop of searching, fetching, and authenticating is fully covered. A sign-out or account detail tool would be a nice addition, but its absence does not break the main use case.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

LandingConnectOAuth
com.landingconnect
Build, clone & publish websites by chatting with Claude. Live in seconds, custom domains + SSL.
Web Scraping Content Management Systems Cloud Platforms
1
Shiped AOAuth
io.github.kandahk
Deploy AI-generated HTML/CSS/JS to instant public HTTPS URLs from any MCP-compatible agent.
Cloud Platforms CI/CD & DevOps Developer Tools
31
2ools B
app.2ools
Build, version, review, and export websites, web apps, and games from a conversation.
Developer Tools CI/CD & DevOps Content Management Systems
812
UnshiftOAuth
io.github.unshift-ai
Turn Claude or ChatGPT into a website builder that ships a real site to a live URL you own.
Content Management Systems Developer Tools Cloud Platforms
2

Related MCP Servers

seite
Developer Tools Content Management Systems Autonomous Agents
seite-sh
A
license
Not graded
quality
A
maintenance
AI-native static site generator with built-in MCP server and Claude Code integration
Updated 11 days ago (2026-09-12 06:13 UTC)
20
MIT
sitemd
Developer Tools Content Management Systems
sitemd-cc
A
license
Not graded
quality
F
maintenance
Static site generator / website building toolkit for AI coding agents like Claude, Codex, Cursor, Gemini, OpenClaw, etc. No subscription, no lock-in — host your site anywhere.
Updated a day ago (2026-09-21 14:40 UTC)
1 npm
9
Elastic 2.0
BrandKit MCP
Design Tools Marketing Developer Tools
ejwhite7
A
license
A
quality
C
maintenance
MCP for deploying BrandKit guardrails to LLMs across your organization.
Updated 24 days ago (2026-08-29 15:05 UTC)
12
42 npm
5
MIT
figwright
Design Tools Developer Tools
awdr74100
A
license
A
quality
A
maintenance
Open-source, bidirectional Figma agent for MCP clients — a free alternative to Figma's Dev Mode MCP. Reads designs with high-fidelity grounding and writes back to the canvas: frames, text, auto-layout, styles, variables, and components. 92 tools, no API token, no paid Figma seat.
Updated 3 days ago (2026-09-20 05:50 UTC)
100
825
MIT

nightmarquee

Install

Use

Unlimited

Configuration

Privacy Policy

What is collected

How it is used and stored

Opting out

Third-party sharing

Retention

Contact

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers