Skip to main content
Glama
deenesjakoruzh
sfeeney1897

wasp-mcp

by sfeeney1897
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

wasp-mcp

Web Agent Semantic Protocol — MCPサーバー

wasp-mcpは、Claude（または任意のMCPクライアント）が任意のウェブページをトークン効率的かつ構造を認識した検索でクエリできるようにするModel Context Protocolサーバーです。WASPは、生のHTMLをコンテキストウィンドウにすべて流し込むのではなく、ページの見出しから軽量な構造インデックス（マニフェスト）を構築し、クエリに関連するセクションのコンテンツのみを取得します。

その結果、単純なスクレイピングよりもはるかに少ないトークンコストで、実際のページコンテンツに基づいた回答を得ることができます。

プロトコルの完全な仕様については、WASPホワイトペーパーを参照してください。

仕組み

すべてのウェブページには、有用な2つの層があります。

  1. 構造 — 目次を形成する見出しとセクションアンカー。サイズが小さく、インデックス作成コストが低い。

  2. コンテンツ — 各見出しの下にあるテキスト。すべてを送信するとコストが高く、ほとんどのクエリにとって無関係な内容です。

WASPは、この分割を2段階のパイプラインで活用します。

Tier 1 — get_manifest(url)
  ↓ Try GET /.well-known/wasp.json (site-native manifest, 3 s timeout)
  ↓ Fall back: fetch HTML → parse headings → generate manifest client-side
  → Returns: structured index (headings, anchors, depth, token estimates)

Tier 2 — fetch_chunk(url, anchor)
  ↓ Resolve anchor → DOM element (getElementById → querySelector → fuzzy match)
  ↓ Extract section text via Range API / heading-sibling walk
  → Returns: plain-text body of that section only

query_page(url, query)
  ↓ get_manifest → score chunks by keyword match → fetch_chunk for top results
  ↓ Build numbered [1. Heading] context → call Claude API → inline [N] citations
  → Returns: { answer, sources[] }

一般的な教員のプロフィールを単純にフルページスクレイピングすると約16,700トークンかかります。WASP経由で同じクエリを実行すると約2,700トークンとなり、6倍の削減になります。

Related MCP server: MCP Web Research Server

インストール

要件: Node.js ≥ 18、Anthropic APIキー。

git clone https://github.com/seanfeeney/wasp-mcp
cd wasp-mcp
npm install
npm run build

APIキーを設定します:

export ANTHROPIC_API_KEY=sk-ant-...

サーバーを実行します（stdioトランスポート、Claude Desktop / Claude Code用）:

node dist/index.js

Claude Codeへの追加

Claude Codeプロジェクトの設定に、ローカルMCPサーバーとしてwasp-mcpを追加します:

claude mcp add wasp -- node /absolute/path/to/wasp-mcp/dist/index.js

または、.claude/settings.jsonを直接編集します:

{
  "mcpServers": {
    "wasp": {
      "command": "node",
      "args": ["/absolute/path/to/wasp-mcp/dist/index.js"],
      "env": {
        "ANTHROPIC_API_KEY": "sk-ant-..."
      }
    }
  }
}

保存後にClaude Codeを再起動します。サーバーが稼働していることを確認します:

/mcp

MCPツール

get_manifest

URLの構造インデックスを取得します。まずサイト独自の /.well-known/wasp.json を試行し、失敗した場合は取得したHTMLからクライアントサイドでDOMを生成します。

パラメータ

名前

型

必須

説明

url

string

はい

ページの完全修飾URL

例

get_manifest("https://engineering.tamu.edu/cse/profiles/aklappenecker.html")
{
  "wasp": "1.0",
  "url": "https://engineering.tamu.edu/cse/profiles/aklappenecker.html",
  "title": "Andreas Klappenecker — Texas A&M CSE",
  "summary": "Faculty profile for Andreas Klappenecker.",
  "keywords": ["quantum computing", "cryptography", "image processing"],
  "chunks": [
    { "id": "chunk_001", "heading": "Andreas Klappenecker", "anchor": "#wasp-001", "depth": 1, "tokens": 5, "order": 1 },
    { "id": "chunk_002", "heading": "Research Interests",   "anchor": "#wasp-002", "depth": 2, "tokens": 4, "order": 2 },
    { "id": "chunk_003", "heading": "Selected Publications","anchor": "#wasp-003", "depth": 2, "tokens": 5, "order": 3 }
  ],
  "generated": "client"
}

fetch_chunk

アンカーで識別された単一セクションのプレーンテキスト本文を取得します。アンカーの解決には、getElementById → querySelector → あいまいな見出しマッチングという3段階のフォールバックを使用します。

パラメータ

名前

型

必須

説明

url

string

はい

ページURL（キャッシュ検索に使用。キャッシュがない場合は再取得）

anchor

string

はい

マニフェストからのCSSアンカー文字列（例: "#research-interests"）

例

fetch_chunk(
  "https://engineering.tamu.edu/cse/profiles/aklappenecker.html",
  "#wasp-002"
)
Quantum computing, image processing, cryptography.

query_page

完全なエンドツーエンドの検索：マニフェストの構築、クエリに対するチャンクのスコアリング、関連するセクション本文の取得、Claudeの呼び出し、そして引用付きの回答を返します。

パラメータ

名前

型

必須

説明

url

string

はい

クエリ対象のページ

query

string

はい

自然言語の質問

provider

string

いいえ

"claude" (デフォルト)

"openai"

"ollama"

例

query_page(
  "https://engineering.tamu.edu/cse/profiles/aklappenecker.html",
  "What are this professor's research interests?"
)
{
  "answer": "Professor Klappenecker's research interests are quantum computing [1], image processing [1], and cryptography [1].",
  "sources": [
    { "heading": "Research Interests", "anchor": "#wasp-002" }
  ]
}

トークン効率

アプローチ

LLMへの送信トークン数

ページの例

生のHTMLスクレイピング

約16,700

TAMU教員プロフィール

WASP query_page

約2,700

同ページ、同クエリ

削減率

6.1倍

トークンの節約効果はページが長いほど大きくなります。50,000トークンのドキュメントページでは、2〜3セクションのみが関連する場合、20〜40倍の削減が見込めます。

プロジェクト構造

wasp-mcp/
  index.ts        MCP server entry — registers tools
  manifest.ts     get_manifest() — discovery + DOM generation
  chunks.ts       fetch_chunk() — anchor resolution + text extraction
  retrieval.ts    query_page() — scoring, enrichment, LLM call
  providers.ts    claude / openai / ollama provider adapters
  cache.ts        In-memory URL → { manifest, html } cache with TTL
  types.ts        Shared TypeScript types

ライセンス

MIT © Sean Feeney, 2026

Available Tools

3 tools
fetch_chunkA

Fetch the plain-text content of a specific section of a webpage by its CSS anchor. Call get_manifest first to discover available anchors. Uses a three-stage anchor resolution: getElementById → querySelector → fuzzy heading match.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesFully-qualified URL of the webpage
anchorYesCSS anchor of the target section (e.g. "#introduction" or "#wasp-003")

TDQS

A4/5.0
Behavior3/5

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

Reveals the three-stage anchor resolution (getElementById → querySelector → fuzzy heading match), which adds transparency beyond basic description. However, no annotations are provided, and the description omits error handling, permission needs, or rate limits.

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?

Three concise sentences with no redundancy. Purpose is front-loaded, and every sentence adds value (purpose, prerequisite, resolution algorithm).

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?

Covers the key usage pattern (prerequisite, resolution logic) for a 2-parameter read operation. Lacks details on return format (only says 'plain-text content') and potential edge cases, but overall sufficient for typical use.

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?

The input schema already describes both parameters (url and anchor) with 100% coverage. The description adds context about anchor being a CSS anchor and the resolution stages, but no significant extra meaning beyond 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?

Clearly states it fetches plain-text content of a webpage section by CSS anchor. Distinguishes from siblings by mentioning the prerequisite get_manifest and the specific anchor resolution method.

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 instructs to call get_manifest first to discover anchors, and describes the three-stage resolution process. However, does not specify when not to use the tool or alternatives.

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

get_manifestA

Fetch the WASP structural index for a webpage. Returns a manifest with the page title, summary, keywords, language, and a list of heading sections (chunks) with their anchors and token estimates. Checks /.well-known/wasp.json first (native manifest); falls back to DOM-generated manifest if not found.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesFully-qualified URL of the webpage to index

TDQS

A4.3/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 the fallback mechanism (native vs DOM-generated manifest) and return fields. However, it omits error conditions, permissions, or rate limits, leaving some behavioral gaps.

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 efficiently convey purpose, returns, and fallback. No redundant information. Every sentence adds value, making it highly concise and well-structured.

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?

Despite lacking an output schema, the description fully explains what is returned (title, summary, keywords, etc.) and how the tool behaves (fallback check). For a simple one-param tool with no output schema, this is complete and informative.

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 schema already describes 'url' as 'Fully-qualified URL of the webpage to index'. The description adds no new parameter semantics beyond the schema, meeting the baseline for full coverage.

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 'Fetch the WASP structural index for a webpage' using a specific verb and resource, and enumerates return fields (title, summary, keywords, etc.). It distinguishes from sibling tools (fetch_chunk, query_page) by focusing on structural indexing.

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 implies usage context (when you need the structural index) and explains fallback behavior, but does not explicitly contrast with siblings or state when not to use. Agents can infer usage, but direct guidance is missing.

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

query_pageA

Ask a natural-language question about a webpage. Internally runs the full WASP two-tier retrieval pipeline: fetch manifest → score relevant chunks → fetch chunk content → call Claude API → return answer with inline citations. Requires ANTHROPIC_API_KEY environment variable (or OPENAI_API_KEY for provider=openai).

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesFully-qualified URL of the webpage to query
queryYesNatural-language question to answer about the page
providerNoLLM provider to use (default: "claude"). Requires corresponding API key env var.

TDQS

A4/5.0
Behavior4/5

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

No annotations are provided, so the description adequately discloses the internal pipeline steps (fetch manifest, score chunks, etc.) and the need for API keys. However, it does not explicitly state side effects (none expected for a query) or rate limits.

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 concise: two sentences. The first sentence front-loads the primary purpose, and the second adds necessary context about the pipeline and requirements. No redundant information.

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 output schema, the description mentions the return type ('answer with inline citations'). It covers the essential aspects for a query tool, though it could mention potential error cases or timeout behavior.

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?

The input schema has 100% description coverage, and the tool description does not add additional meaning beyond what the schema already provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Ask a natural-language question about a webpage.' This is a specific verb+resource combination that distinguishes it from sibling tools like fetch_chunk and get_manifest.

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 mentions required API keys ('Requires ANTHROPIC_API_KEY environment variable (or OPENAI_API_KEY for provider=openai)') but does not provide guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites beyond keys.

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. 3 tool updatesv1.0.0
    • First observedfetch_chunk
    • First observedget_manifest
    • First observedquery_page
Deploy Server
Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

TDQS

A4.4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: get_manifest retrieves the page index, fetch_chunk gets content of a specific section, and query_page performs a full Q&A pipeline. No functional overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (get_manifest, fetch_chunk, query_page), making the API predictable and easy to navigate.

Tool Count5/5

Three tools is appropriate for the server's purpose of indexing and querying webpages. Each tool earns its place and there are no superfluous or missing functions.

Completeness5/5

The set covers the full pipeline: manifest retrieval (get_manifest), targeted content access (fetch_chunk), and high-level question answering (query_page). No obvious gaps for the intended functionality.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers