Skip to main content
Glama
KnockOutEZ

wigolo

by KnockOutEZ
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

extract

Read-onlyIdempotent

Pull specific data from a URL or raw HTML with CSS selectors, tables, metadata, JSON Schema, or brand details.

Instructions

Extract structured data from a URL or raw HTML. Use for specific data points (tables, prices, schema fields) rather than whole-page markdown.

Key parameters:

  • mode: "selector" (CSS → text) | "tables" | "metadata" (title/author/date/og_* + JSON-LD) | "schema" (pass a JSON Schema) | "structured" (one-shot: tables + definitions + JSON-LD + chart hints + key-value pairs) | "brand" (name/tagline/description/logo_url/favicon_url/og_image_url/social_links/fonts + CSS-var colors, each with explainable provenance).

  • css_selector: required for mode="selector".

  • schema: required for mode="schema".

  • multiple: return all matches (mode="selector" only).

Prefer mode="structured" over chaining multiple extract calls — one response carries { tables, definitions, jsonld, chart_hints, key_value_pairs }. chart_hints surfaces SVG titles, aria-labels, figcaptions for charts whose data is JS-rendered. Metadata parity with fetch (same og_/canonical_url shape). mode: "brand" walks JSON-LD Organization/Brand/WebSite → OG/Twitter Card meta → <link rel=icon> → CSS custom properties → heuristic header/footer DOM; provenance records the winning source. Provenance enums: logo ∈ {json-ld, og:logo, link[rel=icon], heuristic, unknown}; colors ∈ {css-vars, palette-extraction, unknown}; fonts ∈ {css-vars, css-rule, inline-style, google-fonts-link, unknown}. Honesty: name and logo_url are unset when no explicit source emits them — favicons never promote to logo_url. mode: "schema" is evidence-only: LLM-sourced fields not present in source text are returned as null with a warning.

Input Schema

NameRequiredDescriptionDefault
urlNoURL to fetch and extract from
htmlNoRaw HTML to extract from (url takes priority if both provided)
modeNoselector | tables | metadata | schema (LLM-sourced fields verified against source; hallucinated values returned as null) | structured | brand (logo/favicon/colors/fonts/social_links with provenance; favicons never promote to logo_url)
schemaNoJSON Schema defining fields to extract. Field names are matched against page content via CSS classes, ARIA labels, microdata, and JSON-LD. Required when mode="schema".
multipleNoReturn array of all matches instead of first (default: false, only for mode="selector")
css_selectorNoCSS selector to match (required when mode="selector")
named_schemaNoExtract page data into a strict named schema (heuristic only; no LLM required). Mutually exclusive with `schema`.
max_tokens_outNoToken-budget cap on extracted output (cl100k-base BPE). Trims structured/table/schema results to fit; trailing rows or heavy keys are dropped first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0
  2. Removedv0.2.0
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial behavior beyond them: the brand-mode resolution chain, provenance enums with their allowed values, the honesty guarantee that favicons never promote to logo_url, schema-mode's null-plus-warning for unverifiable fields, and what chart_hints surfaces for JS-rendered charts. These are exactly the non-obvious traits an agent could not infer from structured fields.

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 purpose and the key routing sentence before parameter detail, and for a six-mode tool with no output schema nearly every clause carries information. It is still a dense wall of prose, and the inline provenance enum listing arguably belongs in the schema rather than the description.

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?

With 8 parameters, nested objects, and no output schema, the description carries the return-value burden and does so — it names the structured response keys, the brand fields, and the trimming behavior under max_tokens_out. An agent has enough to pick a mode and predict the shape of the result.

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?

Schema coverage is 100%, so the baseline is 3; the description earns above that by expanding mode semantics well past the enum strings (what 'structured' returns, the order 'brand' walks sources, evidence-only behavior for 'schema'). Some lines are pure restatement of the schema, e.g. "css_selector: required for mode='selector'", which keeps it from a 5.

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?

States a specific verb and resource ("Extract structured data from a URL or raw HTML") and immediately scopes it against the whole-page path with "Use for specific data points (tables, prices, schema fields) rather than whole-page markdown," which routes an agent away from the fetch/crawl siblings. The six enumerated modes make the tool's surface unambiguous.

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?

Gives clear selection context both across tools (specific data points vs. whole-page markdown) and within the tool ("Prefer mode='structured' over chaining multiple extract calls"), plus a rule for choosing mode='schema' vs named_schema flags. What's missing is an explicit named exclusion such as "use fetch instead when you need the full page text" — the routing is implied rather than stated.

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

Deploy Server

Other Tools