Skip to main content
Glama

Extract text or structured data from a website

render_text
Destructive

Render a page and return its text (as markdown) plus its metadata (title, description, OpenGraph). Pass llm_prompt, optionally with llm_output and llm_schema, to also extract structured data with the LLM configured on your project (Ultra plan). Pick this when you need the metadata or LLM extraction; pick render_markdown instead when you just want the whole page as markdown. Any other Urlbox option (proxies, cookies, headers, user agent and many more) goes in options: look it up with describe_options.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "intent": "<intent>"
    },
    "name": "render_text"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNoThe URL or domain of the website you want to screenshot. We will automatically prepend http:// if it is missing.
htmlNoHTML to render instead of a URL (HTML to PDF, HTML to image).
intentYesRequired. In one or two sentences, what you are trying to achieve for the user with this call and why (for example: 'Screenshot the pricing page so the user can compare plans'). Recorded for analytics and audit; do not include secrets.
optionsNoAny other Urlbox render option by name, e.g. { "gpu": true }. For an option this tool doesn't list, look it up with describe_options first (it covers every option); don't search the web. Validated by the Urlbox API.
projectNoProject id (proj_…) or exact name to render with. Defaults to your default project.
selectorNoTake a screenshot of the element that matches this selector. By default, if the selector is not found, Urlbox will take a normal viewport screenshot. If you prefer Urlbox to fail the request when the selector is not found, pass fail_if_selector_missing=true.
wait_forNoWaits for the element specified by this selector to be present in the DOM before taking a screenshot or PDF. By default, Urlbox will take a screenshot or PDF if the wait_for element is not found after waiting for the time specified by the wait_timeout option. If you prefer Urlbox to fail the request when the wait_for element is not found, pass fail_if_selector_missing=true
llm_outputNoYou can provide a structured output type and schema to Urlbox, and we will prompt your LLM to give back that response structure. By passing an llm_schema without this option, it will default to responding with an object specified by your JSON Schema. If you choose Array, the response will be an array of your provided JSON Schema. If you choose enum, you can provide an array of strings as your schema, and your LLM will respond only with a value from that enum. One of: object, array, enum. Requires the ultra plan or above.
llm_promptNoThe prompt to give the LLM EG "Analyse this image and its associated HTML, giving me back a summary of what the website contents are and a list of all of the links it has " Requires the ultra plan or above.
llm_schemaNoThis is the JSON schema or string[] provided which we will pass over to your LLM. Your LLM provider will respond with a structured output (if supported by your provider) according to that schema. Please take a look at the various resources on the JSON Schema website for more information on designing and validating a JSON schema. Requires the ultra plan or above.
wait_secondsNoHow long to wait for the render before returning. 0 queues it and returns a render id at once. If the wait runs out the render keeps going; fetch it with get_render.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare openWorld and non-read-only behaviour, and the description adds real context beyond them: the LLM extraction path is gated on the Ultra plan, the intent string is recorded for analytics/audit (with a don't-pass-secrets warning), and free-form options are validated by the Urlbox API. It does not explain the credit/cost implications that presumably underlie destructiveHint=true, but nothing in the text contradicts the annotations.

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 sentences, front-loaded with the primary behaviour and return payload, then the sibling routing rule, then the escape hatch for exotic options. Every clause carries decision-relevant information; no restatement of the title or name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter, nested-object tool with no output schema, the description covers the LLM extraction path, plan gating, and the options escape hatch well. It omits the asynchronous behaviour implied by wait_seconds and get_render, so an agent has no top-level cue about how to recover a timed-out render, which is a meaningful gap for this 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%, so baseline is 3, but the description adds compositional meaning the schema does not: llm_prompt is the entry point with llm_output and llm_schema as optional modifiers, and every non-enumerated Urlbox option is funnelled into `options` with describe_options as the lookup path. That is genuine added meaning over eleven individually documented properties.

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 plus the exact return payload: page text as markdown, metadata (title, description, OpenGraph), and optional LLM-extracted structured data. It also names the sibling it is not (render_markdown) together with the distinguishing condition, so an agent can select it without opening any schema.

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

Usage Guidelines5/5

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

Explicit routing guidance in both directions: 'Pick this when you need the metadata or LLM extraction; pick render_markdown instead when you just want the whole page as markdown.' It also routes the agent to describe_options for the long tail of options rather than guessing, and states the Ultra plan prerequisite for LLM extraction.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.