How do I use saaspo-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@saaspo-mcp find dark mode hero sections for SaaS" 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.

saaspo-mcp

by doziben

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Remote

saaspo-mcp

An MCP server that gives AI coding agents access to saaspo.com — the SaaS web design inspiration library — plus a companion skill that makes the agent design landing pages like a senior designer: pull real references, deconstruct why they work, then mix and match.

3,000+ real SaaS pages · 700+ individual sections · tagged by style, industry, page type, section type and stack · with screenshots the agent can actually see.

Why

Coding agents produce visually average pages when they design from training data alone. Great designers steal like artists: they study world-class work, break down what makes it work, and recombine it. This server gives your agent that reference library, and the skill gives it the workflow — give the agent your copy, tell it the vibe, and it grounds every visual decision in real shipped designs instead of hallucinating.

Related MCP server: hidrix-tools

Tools

Tool	What it does
`get_design_vocabulary`	All searchable styles (Dark Mode, Bento, Neobrutalism…), industries, page types, section types, stacks — with example counts. Translates a "vibe" into filters.
`search_pages`	Search full pages by style/industry/page type/stack/free text.
`search_sections`	Search individual sections (Hero, Pricing, Testimonials, Footer…) for mix-and-match stealing.
`get_page_details`	Full record: live URL, tags, screenshot variants, the company's other pages and captured sections.
`get_screenshot`	Returns the actual screenshot as an image the agent can look at. Tall full-page captures are served in readable vertical segments.
`get_random_pages`	Random references for divergent exploration.

Install

claude mcp add saaspo -- npx -y saaspo-mcp

Or in any MCP client config:

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

To hack on it from source instead:

git clone https://github.com/doziben/Saaspo-MCP.git && cd Saaspo-MCP
npm install && npm run build
claude mcp add saaspo -- node /path/to/Saaspo-MCP/dist/index.js

The skill

skills/saaspo-designer/SKILL.md encodes the senior-designer workflow (brief → vocabulary → references → deconstruction → section plan → design tokens → implementation → self-critique). Install it for Claude Code:

mkdir -p ~/.claude/skills/saaspo-designer
curl -fsSL -o ~/.claude/skills/saaspo-designer/SKILL.md \
  https://raw.githubusercontent.com/doziben/Saaspo-MCP/main/skills/saaspo-designer/SKILL.md

Then just give the agent your copy: "Design a landing page for my product with this copy — dark, technical, premium vibe." The skill triggers, pulls references through the MCP, and designs from them.

Dataset

The server ships with a pre-scraped index (data/). Saaspo adds new pages continuously; refresh whenever you like:

npm run scrape

Screenshots are never bundled — they're fetched on demand from saaspo's public CDN at view time.

How it works

Saaspo is a Webflow site. The scraper walks the public sitemap and parses each page's metadata (page type, styles, industries, stack, section tags, screenshot URLs) into a compact JSON index. At runtime the server searches the index in memory and fetches screenshots from the Webflow CDN, resizing and segmenting them (via sharp) so even 13,000px-tall full-page captures arrive as readable images.

Please be a good citizen: the scrape is a few thousand light HTML requests with modest concurrency. All content belongs to saaspo and the respective site owners — this tool is for design study, in the spirit of saaspo itself.

This project is not affiliated with or endorsed by saaspo. If you find the library useful, submit your sites and support them.

Available Tools

6 tools

get_design_vocabularyGet design vocabularyA

Lists every filter value the library understands — page types, visual styles (e.g. Dark Mode, Bento, Neobrutalism, Gradients, Big Type), industries, asset styles, tech stacks, section types and section tags — with how many examples exist for each. Call this FIRST to translate a design brief or 'vibe' into concrete search filters.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

The description accurately describes the tool's outputs (filter values and counts) and implies it is a read-only discovery operation. No annotations are provided, but the description is honest and covers the key behavior without contradiction.

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?

The description is a single sentence that efficiently conveys the tool's purpose and usage, with no fluff. It is front-loaded and every word contributes value.

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 has no parameters, no output schema, and is a simple listing, the description is complete. It provides sufficient detail about the content (types of filters and counts) and its role in the workflow, making it self-contained.

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?

The input schema has zero parameters, so no parameter documentation is needed. The baseline for 0 parameters is 4, and the description does not add parameter info because 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 lists filter values with counts (verb 'lists', resource 'filter value') and explicitly distinguishes from sibling tools by indicating it should be called first to translate a design brief into search filters.

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 guidance on when to use ('Call this FIRST') and the context (translate a design brief into concrete search filters). It does not explicitly mention when not to use, but the sibling tools are sufficiently differentiated.

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

get_page_detailsGet page detailsA

Full record for one page: live website URL, all tags, screenshot variants, the company's other pages in the library, and any individually-captured sections from the same company.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Page slug from search_pages, e.g. 'adaline-landing-page'

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits such as rate limits, authentication requirements, or side effects. It only describes the data returned.

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, well-structured sentence that front-loads the tool's purpose and lists all key features without unnecessary 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?

Given one parameter and no output schema, the description adequately explains what the tool returns. Could be improved by mentioning error handling (e.g., invalid slug).

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%, and the parameter 'slug' is described in the schema. The description adds no additional meaning beyond 'Page slug from search_pages'.

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 'Full record for one page' and lists specific data elements (live URL, tags, screenshots, other pages, sections), distinguishing it from siblings like search_pages (list) and get_screenshot (single image).

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 this tool vs. alternatives like get_random_pages or search_pages. The description implies usage for obtaining complete page details but lacks exclusions or context.

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

get_random_pagesGet random pagesB

Random pages from the library — useful for divergent exploration when the brief is open-ended, or to escape a local maximum of taste.

ParametersJSON Schema

Name	Required	Description	Default
`count`	No
`pageType`	No	Optionally constrain, e.g. 'Landing'

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, description should disclose behavior (read-only, rate limits, result variability) but only says 'random pages'. Missing critical transparency for a potentially non-deterministic tool.

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?

Efficient single sentence, no redundancy. Could be more structured (front-load key info), but compact.

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?

Adequate for a simple tool with no output schema, but gaps in behavioral transparency and parameter semantics reduce completeness.

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

Parameters2/5

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

Schema description coverage is 50% (only pageType has description). Description adds no parameter context; fails to compensate for undocumented count parameter.

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?

Clearly states it returns random pages and gives use cases (divergent exploration, escaping local maximum), but doesn't explicitly distinguish from siblings like search_pages.

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?

Provides explicit scenarios for use (open-ended brief, escaping taste local maxima), but lacks when-not-to-use or alternative tools.

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

get_screenshotGet screenshotA

Returns the actual screenshot image of a page or section so you can SEE the design. For pages choose a variant: 'desktop' (above-the-fold, default), 'full' (entire page top to bottom — tall, delivered in segments; iterate the segment parameter to walk down the page), or 'og' (social image). Section slugs return the section capture. Always view references before designing from them.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	A page slug or a section slug
`index`	No	Sections only: which capture (some have desktop + mobile)
`segment`	No	For tall captures: which vertical segment (0 = top)
`variant`	No	Pages only; ignored for sections	desktop

TDQS

A4.3/5.0

Behavior4/5

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

No annotations, so description carries full burden. Explains that variant is ignored for sections, how full variant delivers in segments with iteration, and that section slugs capture the section. Does not cover error cases or rate limits, but sufficiently covers key behavior.

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 sentences, front-loaded with main purpose, then details. No wasted words. Could be slightly more structured (e.g., bullet points for variants) but overall efficient and readable.

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 the tool's complexity and lack of output schema, the description covers the main use cases and parameter behavior. It warns about tall captures and iterating segments. Adequate for an agent to use 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?

Schema coverage is 100%, so schema already documents parameters. Description adds meaning: explains what each variant does, clarifies that variant is only for pages, and that segment is used for tall captures. Adds context beyond schema.

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 returns a screenshot image of a page or section. Distinguishes between pages (with variants) and sections. The verb 'returns' and resource 'screenshot image' are specific. No sibling overlap mentioned but the purpose is distinct from other 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?

Tells when to use: to see the design. Explains pages vs sections and variant choices. But does not explicitly say when not to use or mention alternatives from sibling list. The advice to view references before designing is helpful context.

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

search_pagesSearch pagesA

Search full SaaS pages (landing, pricing, about, …) by style, industry, page type, stack and free text. styles/assets must ALL match (use them to narrow, e.g. ['Dark Mode','Bento']); industries match ANY. Returns compact summaries — follow up with get_page_details and get_screenshot on the promising ones.

ParametersJSON Schema

Name	Required	Description
`limit`	No
`query`	No	Free text matched against company name, title and product description
`stack`	No	Tech stack, e.g. 'Next.js', 'Webflow', 'Framer'
`assets`	No	Illustration/asset styles, ALL must match, e.g. ['3D']
`offset`	No
`styles`	No	Visual styles, ALL must match, e.g. ['Dark Mode','Gradients']
`pageType`	No	e.g. 'Landing', 'Pricing', 'About' — see get_design_vocabulary
`industries`	No	Industries, ANY may match, e.g. ['AI','Devtools']

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses matching logic (ALL vs ANY) and output nature (compact summaries), adding value beyond structured data. No mention of rate limits or auth but acceptable for a read-like tool.

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 well-structured sentences, front-loaded with key criteria, no wasted words. Every sentence adds value: search scope, filter logic, return type, and follow-up actions.

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?

Adequately covers purpose, filter behavior, output, and next steps for an 8-parameter tool with no output schema. Lacks pagination details but offset/limit are schema-defined. Missing prerequisites but acceptable.

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?

Adds meaning beyond schema by explaining matching semantics (styles/assets must ALL match, industries ANY) and output nature (compact summaries). Schema covers most parameters, but limit lacks description; however, description compensates with context.

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 it searches full SaaS pages by multiple criteria (style, industry, page type, stack, free text), distinguishes from siblings like search_sections and get_page_details by specifying the return type and follow-up actions.

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?

Provides clear guidance on when to use (searching for pages) and how to narrow results (styles/assets ALL match, industries ANY), and suggests follow-up tools (get_page_details, get_screenshot). Lacks explicit when-not-to-use but context is strong.

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

search_sectionsSearch sectionsA

Search individual page sections (Hero, Pricing, Testimonials, Footer, FAQs, CTA, Features, How It Works, …) — perfect for mixing and matching: take the hero pattern from one product and the pricing table from another. tags must ALL match.

ParametersJSON Schema

Name	Required	Description
`tags`	No	Section tags, ALL must match, e.g. ['Logos'] — see sectionTags
`limit`	No
`query`	No	Free text matched against company/title
`offset`	No
`sectionType`	No	e.g. 'Hero', 'Pricing', 'Testimonials' — see get_design_vocabulary sectionTypes

TDQS

A4.1/5.0

Behavior3/5

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 search behavior: matches tags (all must match) and free text against company/title. It implies a read-only operation but does not disclose any side effects or return details.

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?

The description consists of two concise sentences. The first sentence defines the tool's purpose with examples, and the second adds a critical constraint. Every word serves a purpose, with no unnecessary information.

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?

Given the tool has 5 parameters, no output schema, and no annotations, the description covers the core functionality and a key constraint. However, it lacks details on pagination, return format, and idempotency, which would be beneficial for an agent.

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?

The schema coverage is 60%. The description adds value by explaining the 'tags' parameter (all must match) and providing examples. It also clarifies that 'sectionType' values come from get_design_vocabulary, which helps the agent. Other parameters like 'query' and 'limit' are sufficiently covered by the schema.

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 that the tool searches individual page sections and lists examples (Hero, Pricing, Testimonials, etc.). It distinguishes itself from sibling tools like search_pages by focusing on sections rather than whole pages.

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 explains the tool is 'perfect for mixing and matching' sections, implying a reuse scenario. It also states 'tags must ALL match', providing a key usage constraint. However, it does not explicitly mention when not to use or compare to alternatives.

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.

6 tool updatesv0.1.0Jul 10, 2026
- First observedget_design_vocabulary
- First observedget_page_details
- First observedget_random_pages
- First observedget_screenshot
- First observedsearch_pages
- First observedsearch_sections

Install Server

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

TDQS

A4.1/5.0

Scored 2026-07-10 15:30 across 6 tools

Disambiguation5/5

Each tool has a distinct purpose: vocabulary listing, page details, random pages, screenshots, page search, and section search. No overlap or ambiguity among them.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., get_design_vocabulary, search_pages), making the set predictable and easy to navigate.

Tool Count5/5

With 6 tools covering search, detail retrieval, exploration, and visualization, the count is well-proportioned for a design library without being excessive or insufficient.

Completeness5/5

The tool set covers the full range of expected operations for a read-only design reference: discover filters, search pages/sections, retrieve details, view screenshots, and explore randomly. No obvious gaps.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
RampifyOAuth
dev.rampify
SEO MCP server: crawl your site, find AI-visibility gaps, and ship the fix from your coding agent.
Marketing Web Scraping Developer Tools
23
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24
ZapierOAuth
com.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
App Automation Workplace & Productivity
2297

Related MCP Servers

@designjs/mcp-server
Developer Tools Design Tools
rubychilds
A
license
Not graded
quality
C
maintenance
MCP server that enables AI coding agents to read and write to a local-first HTML/CSS design canvas, bridging visual design and code generation.
Updated 2 months ago (2026-07-20 09:24 UTC)
MIT
hidrix-tools
Search Web Scraping Social Media
sonpiaz
A
license
Not graded
quality
F
maintenance
MCP tool server that gives any AI agent the ability to search, scrape, and analyze content across the internet.
Updated 5 months ago (2026-04-23 20:41 UTC)
42
MIT
Design-MCP
Design Tools Coding Agents RAG Systems
mdhossain-2437
F
license
Not graded
quality
B
maintenance
An MCP server that enables AI agents to semantically retrieve premium UI components from Awwwards and adapt them into clean React + Tailwind code.
Updated 2 months ago (2026-07-14 19:17 UTC)
1
-
Figma Context MCP AIR
Design Tools Developer Tools
compassalessandrolorenz
A
license
Not graded
quality
C
maintenance
An MCP server that gives AI coding agents access to Figma design data, enabling pixel-perfect implementation of designs through structured data extraction, image downloads, and design token retrieval.
Updated 5 months ago (2026-04-02 17:39 UTC)
54
1
MIT