web-access

Send a web request

web_access_request

Destructive

Send a POST, PUT or PATCH request to any URL, through String's Web Access API. It works like web_access_fetch, but for calls that submit data rather than read a page — a JSON API that only accepts POST, a GraphQL endpoint, a search backend that takes a body.

Use web_access_fetch instead whenever you only need to read a page. This tool sends a body to the destination rather than reading it, so use it only for a request the user actually asked for.

Usage Example:

{
  "url": "https://api.example.com/search",
  "method": "POST",
  "body": { "q": "widgets" }
}

Returns: The destination's response, in the requested format.

Input Schema

Name	Required	Description
`url`	Yes	The full URL to send the request to. Must be a valid HTTP/HTTPS URL.
`body`	No	Request body. A string is sent as-is; an object is JSON-stringified.
`format`	No	Output format: 'markdown' for clean LLM-optimized text, 'raw' for the destination's verbatim body, 'json' for a { statusCode, headers, data } envelope (default).
`method`	Yes	HTTP method: POST, PUT or PATCH. GET is not accepted here — use web_access_fetch to read a page.
`headers`	No	Custom request headers to forward (max 50).
`countryCode`	No	ISO 3166-1 alpha-2 country code for geolocated proxy routing, e.g. 'US'.
`solveCaptcha`	No	Whether to attempt captcha solving. Defaults to true server-side; set false to fail fast on challenges.

Output Schema

Name	Required	Description
`body`	Yes
`error`	No	Set when a browser action step failed. The call still succeeds, and body holds the page as it stood when the step failed.
`headers`	Yes
`finalUrl`	No
`screenshot`	No
`statusCode`	Yes
`failedActionIndex`	No	0-based index into the request's actions array identifying the step that failed.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 8, 2026

TDQS

A4.7/5.0

Behavior4/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 covered. The description adds the reason it is a write ('sends a body to the destination rather than reading it') and a caution about only acting on user-requested calls, which gives useful context beyond the flags. It does not discuss auth requirements or rate limits, so it stops 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose and the alternative-tool routing are front-loaded in the first two sentences, with example and return note following. Every block earns its place and nothing is redundant.

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

Completeness5/5

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

An output schema exists, so return-value detail is not required, and the description still sketches the response shape. Combined with full param coverage and annotations, an agent has everything needed to call it correctly.

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 description coverage is 100%, so the baseline is 3, and the parameters are fully self-documenting. The description adds a concrete usage example showing how url, method and a JSON body combine, which is modestly useful gloss on top of the schema rather than a restatement.

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 ('Send a POST, PUT or PATCH request to any URL'), names the API it routes through, and explicitly contrasts itself with the sibling web_access_fetch. An agent can distinguish it from web_access_search and web_access_sitemap immediately.

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?

Gives an explicit when-not rule ('Use web_access_fetch instead whenever you only need to read a page') and a gating condition ('use it only for a request the user actually asked for'). The alternative and the condition that selects it are both stated.

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

All web-access tools Inspect

Try in Browser

Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

Glama MCP Gateway

Add one secure layer between your agents and this server.