Skip to main content
Glama
Sign In

Urlbox

by io.github.urlbox
OverviewDiscussionsAdmin

Look up Urlbox render options

describe_options
Read-only

The complete, authoritative reference for Urlbox's 201 render options (GPU, engine version, proxies, cookies, headers, waits, PDF and video settings, and more). Call it whenever the user asks for something a render tool doesn't list as a parameter, then pass what it finds in that tool's options object. It is faster and more accurate than searching the web for Urlbox docs.

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>",
      "query": "<query>"
    },
    "name": "describe_options"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
queryYesAn option name (e.g. 'wait_for') or a few keywords (e.g. 'cookie', 'pdf margin', 'gpu'). Search one feature at a time for the best results.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"An option name (e.g. 'wait_for') or a keyword (e.g. 'cookie', 'pdf margin')."New value: +"An option name (e.g. 'wait_for') or a few keywords (e.g. 'cookie', 'pdf margin', 'gpu'). Search one feature at a time for the best results."
  2. First observed

TDQS

A4/5.0
Behavior3/5

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

The annotations already establish that this is a safe, read-only, closed-world lookup, so the bar for extra disclosure is lower. The description adds that the content is authoritative and how the results should be reused (the `options` object), but says nothing about paging, result shape, or how many options a call returns by default. That is acceptable but thin for a search-style tool.

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 what the tool is, then when to call it, then the payoff versus web search. No filler or repetition of the title or the schema.

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 three-parameter lookup with no output schema, the description covers purpose, trigger, and downstream use of results well. The gaps are minor: no hint about result volume or how paging works, and no mention of the mandatory `intent` parameter the agent must supply.

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 67%, and the schema itself explains both `query` (an option name or keywords, one feature at a time) and `intent` (a short goal recorded for audit). The description adds nothing about any parameter, not even the required `intent`, and never mentions `limit` or the default page size. The baseline of 3 fits because the schema does the heavy lifting without description compensation.

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 names the resource precisely (Urlbox's 201 render options) and enumerates the covered categories (GPU, engine version, proxies, cookies, headers, waits, PDF and video settings). It implicitly frames the tool as a lookup that feeds the render tools' `options` object, which separates it from the render siblings. It stops short of a crisp action verb like 'search' or 'look up', leaving the agent to infer the retrieval behavior from 'reference'.

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?

It gives an explicit trigger: 'Call it whenever the user asks for something a render tool doesn't list as a parameter'. It also names the alternative it supersedes, web searching Urlbox docs, and explains why this tool wins on speed and accuracy. Follow-up action is spelled out: pass the results into the render tool's `options` object.

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

All Urlbox 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