Skip to main content
Glama
Sign In

Urlbox

by io.github.urlbox
OverviewDiscussionsAdmin

Report a problem with a render

report_render
Destructive

Report a render that came out wrong (blocked by a bot check, a login wall, missing content, a cookie banner or popup left in, or a failed render) to the Urlbox support team, who reply in the dashboard. Use it after you have tried the obvious render options (see describe_options) and the result is still wrong. Reporting the same render again updates the open report.

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>",
      "renderId": "<renderId>",
      "category": "<category>",
      "comment": "<comment>"
    },
    "name": "report_render"
  }
}

Input Schema

NameRequiredDescriptionDefault
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.
commentYesWhat is wrong with the render and what you expected, in plain words.
categoryYes
renderIdYesThe render id, from a render tool's result or list_renders.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Beyond the annotations it discloses the recipient of the report, the reply channel (dashboard), and the upsert behaviour ('Reporting the same render again updates the open report'), which is real context an agent cannot get from structured fields. The gap is that destructiveHint=true is never explained: nothing says whether a report can overwrite or amend an existing ticket in a way that loses prior detail, and the idempotentHint=false framing sits in mild tension with the 'updates the open report' wording.

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, all load-bearing: symptom list first, then the precondition, then the dedupe rule. Nothing repeats the schema and nothing is padding.

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 four-required-parameter reporting tool with no output schema, the description covers what to send, when to send it, who handles it and what happens on repeat submission. It stops short of the follow-up expectation (whether the render is retried, or what a resolved report looks like) and leaves the destructive annotation unexplained.

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 75%, so the schema already documents intent, comment and renderId; the description's added value is mapping plain symptoms ('a bot check, a login wall, missing content, a cookie banner') onto the category enum values. That mapping meaningfully reduces mis-categorisation, though it does not clarify the open-ended 'other' category.

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 names a specific verb and resource (report a wrong render to the Urlbox support team) and enumerates the concrete failure modes it covers (bot check, login wall, missing content, cookie banner/popup, failed render). That is enough to separate it from the render-producing siblings such as screenshot, pdf, or render 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?

It gives an explicit precondition ('after you have tried the obvious render options') and points at the alternative to consult first (describe_options) before falling back to this tool. Exclusions and alternatives are both stated rather than inferred.

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