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 백서를 참조하세요.

작동 방식

모든 웹 페이지에는 유용한 두 가지 계층이 있습니다:

  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 프로젝트 구성에 wasp-mcp를 로컬 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토큰 분량의 문서 페이지는 23개 섹션만 관련이 있을 경우 2040배의 절감 효과를 볼 수 있습니다.

프로젝트 구조

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
Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

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