Skip to main content
Glama
deenesjakoruzh
sfeeney1897

wasp-mcp

by sfeeney1897
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

wasp-mcp

Web Agent Semantic Protocol — Servidor MCP

wasp-mcp es un servidor del Protocolo de Contexto de Modelo que permite a Claude (o a cualquier cliente MCP) consultar páginas web arbitrarias con una recuperación eficiente en tokens y consciente de la estructura. En lugar de volcar HTML sin procesar en la ventana de contexto, WASP construye un índice estructural ligero (el manifiesto) a partir de los encabezados de una página, y luego obtiene el contenido solo para las secciones relevantes para una consulta.

El resultado: respuestas fundamentadas en el contenido real de la página a una fracción del coste en tokens del scraping convencional.

Consulta el Libro Blanco de WASP para ver la especificación completa del protocolo.

Cómo funciona

Cada página web tiene dos capas útiles:

  1. Estructura — encabezados y anclas de sección que forman una tabla de contenidos. Pequeño, barato de indexar.

  2. Contenido — el texto bajo cada encabezado. Caro de enviar completo; la mayor parte es irrelevante para cualquier consulta dada.

WASP explota esta división con una tubería de dos niveles:

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[] }

Un scraping completo de una página típica de perfil de facultad cuesta ~16,700 tokens. La misma consulta a través de WASP cuesta ~2,700 — una reducción de 6×.

Related MCP server: MCP Web Research Server

Instalación

Requisitos: Node.js ≥ 18, una clave API de Anthropic.

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

Establece tu clave API:

export ANTHROPIC_API_KEY=sk-ant-...

Ejecuta el servidor (transporte stdio, para Claude Desktop / Claude Code):

node dist/index.js

Añadir a Claude Code

Añade wasp-mcp como un servidor MCP local en la configuración de tu proyecto de Claude Code:

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

O edita .claude/settings.json manualmente:

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

Reinicia Claude Code después de guardar. Confirma que el servidor está activo:

/mcp

Herramientas MCP

get_manifest

Obtiene el índice estructural de una URL. Primero intenta con el archivo /.well-known/wasp.json del propio sitio; si falla, recurre a la generación de DOM del lado del cliente a partir del HTML obtenido.

Parámetros

Nombre

Tipo

Requerido

Descripción

url

string

sí

URL completa de la página

Ejemplo

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

Recupera el cuerpo de texto plano de una sola sección identificada por su ancla. La resolución de anclas utiliza un respaldo de tres etapas: getElementById → querySelector → coincidencia difusa de encabezados.

Parámetros

Nombre

Tipo

Requerido

Descripción

url

string

sí

URL de la página (usada para búsqueda en caché; vuelve a obtener si no está en caché)

anchor

string

sí

Cadena de ancla CSS del manifiesto (ej. "#research-interests")

Ejemplo

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

query_page

Recuperación completa de extremo a extremo: construye el manifiesto, puntúa los fragmentos frente a la consulta, obtiene los cuerpos de las secciones relevantes, llama a Claude y devuelve una respuesta citada.

Parámetros

Nombre

Tipo

Requerido

Descripción

url

string

sí

Página a consultar

query

string

sí

Pregunta en lenguaje natural

provider

string

no

"claude" (predeterminado)

"openai"

"ollama"

Ejemplo

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" }
  ]
}

Eficiencia de tokens

Enfoque

Tokens enviados al LLM

Página de ejemplo

Scraping HTML sin procesar

~16,700

Perfil de facultad TAMU

WASP query_page

~2,700

misma página, misma consulta

Reducción

6.1×

El ahorro de tokens aumenta con la longitud de la página. Una página de documentación de 50,000 tokens puede ver una reducción de 20–40× cuando solo 2–3 secciones son relevantes.

Estructura del proyecto

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

Licencia

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