Skip to main content
Glama
thevibepreneur

Gapbase MCP

gapbase-mcp

Claude Desktop、Cursor、Windsurfから474件の検証済みスタートアップのギャップ(機会)をクエリします。

GapBaseは、Reddit、LinkedIn、Xから収集した実際のペインポイント(悩み)のデータベースです。それぞれが、バイブコード(vibe-coded)によるマイクロSaaSの検証済み機会となっています。このMCPサーバーを使用すると、AIコーディング環境から直接データベース全体を検索できます。

  • 🗂️ 7つの業界(Eコマース、ヘルスケア、法律、会計、不動産、歯科、獣医)にわたる 474件の検証済みギャップ

  • 🧠 すべてのギャップに対する 問題提起 + バイブコードによる解決策

  • 🔥 ライブのソーシャルシグナル(TikTok、HBO、バイラルチャレンジ)から抽出した 毎週5件のトレンドギャップ

  • 🚀 無料、登録不要、ネットワーク通信ゼロ — すべてローカルで動作します

  • 🔗 各ギャップには、thevibepreneur.com上の完全なブループリント(技術スタック、GTM、アウトリーチテンプレート)へのリンクが含まれています

インストール

npm install -g gapbase-mcp

次に、MCPクライアントの設定に追加します:

Claude Desktop

~/Library/Application Support/Claude/claude_desktop_config.json(macOS)またはお使いのOSの同等のファイルを編集し、以下を追加します:

{
  "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マーチャントをターゲットにしたEコマースのギャップは何?」

「今週のトレンドギャップで、構築期間が短いものを教えて。」

「現在、不動産管理における最大のペインポイントは何?」

「今週末にバイブコードで構築できそうな歯科関連のギャップを教えて。」

Claude / Cursorは自動的に適切なツールを呼び出し、問題提起とバイブコードによる解決の方向性を返します。すべての結果には、thevibepreneur.com上の完全な内訳を示す full_blueprint URLが含まれています。

ツール

ツール

機能

list_industries

業界ごとのギャップ数を含む、カバーされている7つの業界

search_gaps

474件の検証済みB2Bギャップを対象とした、キーワードや業界でフィルタリング可能な検索(メインツール)

get_gap

IDまたはスラッグで単一のギャップを取得

get_viral_social_gaps

毎週5件のバイラルな消費者トレンド(TikTok、HBO、短期構築向け) — 特化型のため、明示的に尋ねてください

get_stats

データベースの統計とメタデータ

哲学

無料のMCPユーザーは診断結果を得られます。治療法はウェブサイトにあります。

MCPバンドル内の各ギャップには以下が含まれます:

  • 問題提起(何が問題か)

  • バイブコードによる解決策(構築の方向性)

  • 業界 + 役割

  • 技術スタック、難易度、GTMプレイブック、アウトリーチテンプレートを含む full_blueprint URL

構築する価値のあるギャップを見つけたら、thevibepreneur.comのブループリントをクリックして完全なキットを確認してください。Founding Memberアクセスにより、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