Ujeebu

ujeebu_scrape_json

Destructive

General web scraping that always returns JSON response with metadata. Use this when you need structured response data including headers, status, timing info, and content. Can return HTML, screenshot, or PDF in JSON format.

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": {
      "url": "<url>"
    },
    "name": "ujeebu_scrape_json"
  }
}

Input Schema

Name	Required	Description
`js`	No	Execute JavaScript. Default: true
`url`	Yes	URL to scrape
`device`	No	Device: 'desktop' or 'mobile'. Default: 'desktop'
`cookies`	No	Custom cookies
`timeout`	No	Timeout in seconds. Default: 60
`wait_for`	No	Wait condition
`block_ads`	No	Block ads. Default: false
`custom_js`	No	Custom JavaScript code
`post_data`	No	POST/PUT data
`useragent`	No	Custom user agent
`auto_proxy`	No	Auto-escalate proxy. Default: false
`js_timeout`	No	JS timeout in seconds
`proxy_type`	No	Proxy type. Default: 'rotating'
`session_id`	No	Session ID
`strip_tags`	No	Tags/selectors to remove
`http_method`	No	HTTP method. Default: 'GET'
`scroll_down`	No	Scroll page. Default: false
`custom_proxy`	No	Custom proxy URI
`window_width`	No	Viewport width
`proxy_country`	No	Proxy country. Default: 'US'
`response_type`	No	Content type: 'html', 'raw', 'pdf', or 'screenshot'. Default: 'html'
`window_height`	No	Viewport height
`block_resources`	No	Block resources. Default: false for screenshot/pdf
`wait_for_timeout`	No	Wait timeout in milliseconds
`progressive_scroll`	No	Progressive scroll. Default: false
`screenshot_partial`	No	Partial screenshot selector/coords (if response_type=screenshot)
`screenshot_fullpage`	No	Full page screenshot (if response_type=screenshot)
`custom_proxy_password`	No	Custom proxy password
`custom_proxy_username`	No	Custom proxy username

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 10, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is partly covered. The description adds the useful behavioral fact that responses are always JSON-wrapped with metadata, but it never mentions that this tool can issue POST/PUT requests, run custom JavaScript, or escalate proxies — the behaviors that justify the destructive/non-idempotent hints.

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?

Three short sentences, front-loaded with the core behavior and the when-to-use trigger, with no filler. The first and second sentences overlap slightly ('always returns JSON response with metadata' vs. 'structured response data including headers, status, timing info'), a minor redundancy.

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?

There is no output schema, and the description partially compensates by naming the metadata fields (headers, status, timing, content). However, for a 29-parameter tool with no annotations on return behavior and proxy/session/POST capabilities, the description leaves notable operational gaps an agent would want covered.

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 description coverage is 100% across all 29 parameters, so the schema does the heavy lifting and a 3 is the baseline. The description adds only a loose mapping to response_type ('Can return HTML, screenshot, or PDF in JSON format') and no syntax or interaction guidance for proxies, sessions, or wait conditions.

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 states a specific verb and resource (general web scraping) and pins down the output contract: always a JSON envelope with metadata, carrying HTML, screenshot, or PDF payloads. That output-envelope detail is what separates it from scrape_html/scrape_pdf/scrape_screenshot, though those siblings are never named explicitly.

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?

It gives a clear selection criterion: use this when you need structured response data including headers, status, and timing info. It stops short of stating when NOT to use it (e.g. 'use scrape_html if you only want raw content'), so the agent must infer the boundary with the format-specific siblings.

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

All Ujeebu tools Inspect

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

Need Help?