Skip to main content
Glama
Sign In

Hyperbrowser

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Hyperbrowser Extract

hyperbrowser_extract
Read-onlyIdempotent

Extract structured JSON data from one or more web pages using an LLM. Provide a JSON schema and/or a natural-language prompt describing what to pull. Example: hyperbrowser_extract({ urls: ["https://example.com"], prompt: "Get the product name and price", schema: { type: "object", properties: { name: { type: "string" }, price: { type: "string" } } }, _apiKey: "your-key" })

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "urls": [
        "https://example.com/product"
      ],
      "prompt": "Extract the product name, price, and availability status",
      "_apiKey": "your-hyperbrowser-api-key"
    },
    "name": "hyperbrowser_extract"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlsYesOne or more URLs to extract data from.
promptNoNatural-language description of the data to extract (used with or instead of schema).
schemaNoJSON Schema object describing the shape of the data to extract, e.g. { type: "object", properties: { title: { type: "string" } } }.
_apiKeyYesHyperbrowser API key. Sign up at https://app.hyperbrowser.ai (docs: https://docs.hyperbrowser.ai/).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds that it uses an LLM (implying non-determinism) but doesn't disclose potential failure modes, rate limits, or behavior on extraction errors. With annotations present, this is acceptable but not enriched beyond the baseline.

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 two sentences plus an example. The purpose is front-loaded, and the example is directly actionable. No filler or redundant phrasing, though the example is lengthy and could be trimmed without losing value.

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 relatively simple tool with no output schema, the description covers the core usage: what it does, how to specify extraction (prompt and/or schema), and an example. It lacks guidance on when to choose it over siblings and doesn't mention URL limits or rate constraints, but these are minor for the tool's complexity.

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% with all parameters described. The description adds value by clarifying that prompt and schema can be used together or interchangeably ('and/or'), and the inline example demonstrates practical parameter usage with a concrete URL, prompt, and schema. This goes beyond the schema's static definitions.

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

Purpose4/5

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

The description clearly states the tool extracts structured JSON data from web pages using an LLM. The verb 'extract' and resource 'web pages' are specific, and the LLM mechanism distinguishes it from siblings like hyperbrowser_scrape and hyperbrowser_crawl, though it doesn't explicitly name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an example invocation but no explicit guidance on when to use this tool versus hyperbrowser_scrape or hyperbrowser_crawl. There's no mention of alternatives, exclusions, or prerequisite conditions. The example implies usage but doesn't clarify the decision boundary.

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

All Hyperbrowser toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources