Skip to main content
Glama
1596941391qq

proxy302-mcp

by 1596941391qq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Fetch a web page through a Proxy302 proxy

fetch_url
Read-only

Fetches any URL through your Proxy302 residential proxy, optionally exiting in a chosen country, and returns the page as Markdown, plain text, or raw HTML. Use it for geo-specific or proxy-routed content without JavaScript rendering.

Instructions

Request a URL from your machine through one of your Proxy302 proxies (optionally exiting in a given country) and return the page as Markdown, plain text or raw. No JavaScript rendering: for JS-heavy sites use a browser with the proxy URL from get_dynamic_proxy. Uses your proxy traffic.

Input Schema

NameRequiredDescriptionDefault
urlYes
formatNomarkdown
countryNoExit country; picks one of your dynamic proxies for it
token_idNoUse a specific proxy from list_my_proxies
max_charsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover read-only and open-world natures, yet the description adds real context: requests are made from the user's machine, traffic is consumed from the proxy quota, and JS content will not render. It doesn't cover error behavior or truncation semantics beyond max_chars, keeping it short of a 5.

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?

Two sentences, front-loaded with the core action, followed by the caveat and alternative. Efficient, though the parenthetical about exiting country interrupts the main clause slightly.

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?

With no output schema, the description does state the return shape (page as Markdown/text/raw), which is the key missing piece. Quota consumption and the no-JS limitation are disclosed; pagination/truncation behavior is only implied by max_chars.

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 40%; the description adds meaning for format (markdown/text/raw) and country exits, but token_id and max_chars are left to the schema, and max_chars has no description at all. Adequate but not compensating for the coverage gap.

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 (request a URL through a Proxy302 proxy) plus the return forms (Markdown, plain text, raw), and distinguishes itself from get_dynamic_proxy for JS-heavy sites. An agent can tell what this tool does without opening the schema.

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?

Explicitly names the exclusion case (no JavaScript rendering) and points to the alternative route via get_dynamic_proxy. It lacks a positive when-to-use statement relative to the other siblings, but the routing guidance is clear.

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

Deploy Server

Other Tools