Skip to main content
Glama
thevibepreneur

Gapbase MCP

gapbase-mcp

从 Claude Desktop、Cursor 和 Windsurf 中查询 474 个经过验证的创业缺口。

GapBase 是一个从 Reddit、LinkedIn 和 X 上抓取的真实痛点数据库——每一个都是 vibe-coded 微型 SaaS 的验证机会。此 MCP 服务器允许你直接从 AI 编码环境中搜索整个数据库。

  • 🗂️ 474 个经过验证的缺口,涵盖 7 个行业(电子商务、医疗保健、法律、会计、房地产、牙科、兽医)

  • 🧠 每个缺口都包含 问题陈述 + vibe-code 解决方案

  • 🔥 5 个每周热门缺口,来自实时社交信号(TikTok、HBO、病毒式挑战)

  • 🚀 免费、无需注册、零网络调用 — 全部在本地运行

  • 🔗 每个缺口都链接到 thevibepreneur.com 上的完整蓝图(技术栈、GTM、外联模板)

安装

npm install -g gapbase-mcp

然后添加到你的 MCP 客户端配置中:

Claude Desktop

编辑 ~/Library/Application Support/Claude/claude_desktop_config.json(macOS)或你操作系统上的等效文件,并添加:

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

重启 Claude Desktop。你应该会看到一个 🔌 图标,表示服务器已连接。

Cursor

编辑 ~/.cursor/mcp.json:

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

Windsurf

编辑 ~/.codeium/windsurf/mcp_config.json:

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

Related MCP server: PainSpotter MCP Server

使用方法

安装完成后,只需用自然语言向你的 AI 助手提问:

“帮我找 5 个关于计费或时间跟踪的法律行业缺口。”

“有什么针对想要离开 Klaviyo 的 Shopify 商家的电子商务缺口吗?”

“向我展示本周构建周期短的热门缺口。”

“目前物业管理领域的主要痛点是什么?”

“给我一个我可以在这个周末用 vibe code 构建的牙科行业缺口。”

Claude / Cursor 将自动调用相应的工具,并返回带有 vibe-code 解决方案方向的问题陈述。每个结果都包含一个 full_blueprint URL,指向 thevibepreneur.com 上的完整分析。

工具

工具

功能

list_industries

涵盖 7 个行业,并显示每个行业的缺口数量

search_gaps

在 474 个经过验证的 B2B 缺口中进行关键词和/或行业过滤搜索(主要工具)

get_gap

通过 id 或 slug 获取单个缺口

get_viral_social_gaps

5 个每周病毒式消费趋势(TikTok、HBO、短周期构建)——专业内容,请明确询问

get_stats

数据库统计信息和元数据

理念

免费的 MCP 用户获得诊断结果。治疗方案在网站上。

MCP 包中的每个缺口都包括:

  • 问题陈述(哪里出了问题)

  • Vibe-code 解决方案(构建方向)

  • 行业 + 角色

  • full_blueprint URL,包含技术栈、难度、GTM 手册和外联模板

如果你发现一个值得构建的缺口,请点击跳转到 thevibepreneur.com 上的蓝图以获取完整工具包。创始会员权限 可永久解锁全部 474 个蓝图。

隐私

此 MCP 服务器 100% 在本地运行。它不会向外发送数据、不会跟踪使用情况、不会收集关于你、你的查询或你的 Claude 对话的任何数据。整个缺口数据库都打包在 npm 包中——没有网络调用,没有 API 密钥,没有身份验证。

关于

由 The Vibepreneur 构建。每周添加新缺口。在 thevibepreneur.com/gaps 关注开发进度和发布说明。

许可证

MIT

Available Tools

5 tools
get_gapA

Fetch a single gap by its id or slug. Returns problem + solution direction + blueprint URL. Use after search_gaps to get a specific gap's full details.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesGap id (e.g. 'pd-la001') or slug.

TDQS

A4/5.0
Behavior3/5

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

No annotations; description reveals return fields but no behavioral traits like idempotency, side effects, or rate limits. Adequate for a simple read operation.

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-loaded with purpose, no fluff. Efficient and easy to scan.

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 a simple 1-param tool with no output schema, description covers purpose, usage, and return info. Lacks mention of possible error cases but overall complete.

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 parameter description already specifies id or slug. Description adds no new semantic meaning beyond what schema provides, so baseline 3.

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 fetches a single gap by id or slug, returns specific details (problem, solution direction, blueprint URL), and is distinguished from siblings like search_gaps.

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?

Explicitly says 'Use after search_gaps' to get full details, providing clear context. Lacks explicit when-not-to-use or alternatives, but context is sufficient.

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

get_statsA

Get GapBase database statistics: total gaps, industry breakdown, trending gap count.

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 are provided, so the description carries full burden. It does not disclose behavioral traits like auth requirements, rate limits, or read-only nature. The listed statistics give some idea of output but no side effects or safety info.

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 sentence, front-loaded with key information. Every word contributes: verb (Get), resource (GapBase database statistics), specific outputs (total gaps, industry breakdown, trending gap count). No wasted text.

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 a zero-parameter, no-output-schema tool, the description is nearly complete. It covers the tool's purpose and data categories. However, missing details on output format, caching, or how results relate to sibling tools keep it from being fully comprehensive.

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, so the description cannot add parameter meaning. Baseline 4 is appropriate given 100% schema coverage and zero params; description correctly omits param 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 retrieves database statistics, specifying three distinct types (total gaps, industry breakdown, trending gap count). This verb-resource pairing is specific and distinguishes it from siblings like get_gap (single gap) or list_industries (industry list).

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?

The description implies usage for overview statistics but provides no explicit guidance on when to use this tool vs alternatives. No exclusions or prerequisites are mentioned, leaving the agent to infer context from sibling names.

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

get_viral_social_gapsA

SPECIALIZED TOOL — only use when the user explicitly asks for VIRAL, SOCIAL, TIKTOK, CONSUMER, TREND-BASED, or SHORT-WINDOW build opportunities. Returns 5 time-sensitive consumer/viral trend gaps (TikTok challenges, HBO premieres, viral formats) with peak windows measured in days or weeks. DO NOT call this tool for general 'find me ideas' or 'what should I build' queries — those should use search_gaps which returns serious validated business opportunities across 7 industries. Only call this when the user specifically mentions viral, social, trend, TikTok, Instagram, or consumer-facing short-window builds.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

No annotations provided, so description bears full responsibility. It discloses output structure (5 gaps, peak windows in days/weeks) and implies read-only behavior. Lacks explicit statement of non-destructive nature or permissions but is sufficient for safe use.

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?

Front-loaded with 'SPECIALIZED TOOL' and bold usage restrictions. While somewhat lengthy, every sentence adds value. Minor redundancy in listing trigger words could be trimmed, but overall efficient.

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 no parameters and no output schema, description adequately covers what the tool does, when to use it, and what it returns (5 gaps). Missing explicit output structure for agent processing, but sufficient for invocation decision.

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?

Input schema has zero parameters, so baseline is 4 per rubric. No parameter explanation needed; description doesn't cover parameters because there are none.

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 explicitly states the tool returns 'time-sensitive consumer/viral trend gaps' and specifies exact trigger conditions (TikTok challenges, HBO premieres, viral formats). It clearly distinguishes from sibling tool `search_gaps` by contrasting the scope (viral/social vs serious business opportunities).

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

Usage Guidelines5/5

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

Provides explicit guidance on when to use ('only use when user asks for VIRAL...') and when not to ('DO NOT call for general queries'), and names the alternative tool (`search_gaps`) with its purpose.

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

list_industriesA

List the 7 industries covered by GapBase and the number of validated gaps in each. Use this first to understand the database coverage before searching.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
Behavior4/5

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

No annotations provided, but description accurately describes the read-only listing of industries and counts. Does not mention any potential side effects, but given the nature, none are expected.

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 concise sentences, front-loaded with the action and followed by usage advice. No wasted words.

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 zero parameters and no output schema, the description fully explains the tool's purpose and provides usage context, leaving no gaps for a simple listing tool.

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 exist; schema coverage is 100%. Description adds value by specifying the exact output content (industries and gap counts).

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 it lists the 7 industries and their gap counts, distinguishing it from sibling tools that handle individual gaps or searches.

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

Usage Guidelines5/5

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

Explicitly instructs to use this first to understand database coverage before searching, providing clear when-to-use guidance.

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

search_gapsA

PRIMARY TOOL for finding startup ideas, validated business opportunities, SaaS ideas, micro-SaaS opportunities, B2B pain points, or anything a user could build to get paying customers. Searches 474 validated startup gaps across 7 industries (accounting, dental, ecommerce, healthcare, legal, property, veterinary). Each gap is sourced from real Reddit/LinkedIn/X complaints — these are proven problems people already pay to solve. Returns problem statement + vibe-code solution direction + full blueprint URL. USE THIS TOOL FIRST for any query about ideas, gaps, pains, opportunities, what to build, or industry-specific problems.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryNoFree-text keyword to search across pain points and solutions (e.g. 'billing', 'no-show', 'reconciliation', 'tenant tracking'). Leave empty to browse by industry only.
industryNoFilter to one industry. Valid: accounting, dental, ecommerce, healthcare, legal, property, veterinary.
limitNoMax results to return (1-25, default 10).

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the source of gaps (Reddit/LinkedIn/X) and the return format (problem statement, solution direction, blueprint URL). However, it does not mention any behavioral traits such as rate limits or pagination, so transparency is adequate but not exceptional.

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?

The description is well-structured, front-loading the primary purpose and then providing details on sources, industries, and return format. It is slightly verbose but stays focused and informative, with each sentence serving a 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 the lack of output schema, the description compensates by clearly stating return values: problem statement, solution direction, and blueprint URL. It covers all three parameters and lists sibling tools, making the context complete for the 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?

Although the input schema already provides 100% coverage with descriptions, the description adds value by explaining the context of the query parameter (free-text search across pain points) and the industry filter. It also reinforces that leaving query empty allows browsing by industry, which is not explicitly in 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 explicitly states it is the 'PRIMARY TOOL for finding startup ideas' and clearly specifies the verb 'search' and resource 'gaps'. It also distinguishes itself from siblings by describing its comprehensive database and direct relevance to user queries about ideas or opportunities.

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: 'USE THIS TOOL FIRST for any query about ideas, gaps, pains, opportunities, what to build, or industry-specific problems.' It does not explicitly state when not to use, but the instruction suggests it is the first choice, effectively guiding usage.

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. 5 tool updatesv0.1.1
    • Addedget_gap
    • Addedget_stats
    • Addedget_viral_social_gaps
    • Addedlist_industries
    • Addedsearch_gaps

TDQS

A4.3/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: search_gaps for general queries, get_gap for details, list_industries for overview, get_stats for statistics, and get_viral_social_gaps for specific viral trends. Descriptions explicitly warn against misuse, removing ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (get_, list_, search_). No mixing of styles or vague names. The pattern is predictable and readable.

Tool Count5/5

With 5 tools, the server is well-scoped for its purpose of discovering and retrieving startup ideas. Each tool fills a necessary role without redundancy or omission, appropriate for a focused database API.

Completeness5/5

The tool surface covers the full user workflow: browse industries (list_industries), search (search_gaps), get details (get_gap), view stats (get_stats), and access specialized trending gaps (get_viral_social_gaps). No obvious gaps for read-only access to validated gaps.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers