Skip to main content
Glama

Server Details

The most accurate web access API. Stop getting blocked.

Status
Healthy
Last Tested
Transport
Streamable HTTP
URL

Glama MCP Gateway

Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.

MCP client
Glama
MCP server

Full call logging

Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.

Tool access control

Enable or disable individual tools per connector, so you decide what your agents can and cannot do.

Managed credentials

Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.

Usage analytics

See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.

100% free. Your data is private.
Tool DescriptionsA

Average 4.9/5 across 3 of 3 tools scored.

Server CoherenceA
Disambiguation5/5

Each tool has a clear, distinct purpose: fetching a specific URL, performing a web search, or crawling a site's structure. Descriptions and usage guidance effectively prevent confusion.

Naming Consistency5/5

All tools follow a consistent 'web_access_<action>' pattern with underscores, making it easy to remember and predict tool names.

Tool Count4/5

With only 3 tools, the set is minimal but still covers the essential web access operations (fetch, search, sitemap). It feels slightly under-scoped but not problematic.

Completeness4/5

The tools cover the primary workflows: searching to find URLs, fetching to get content, and crawling to map sites. Minor gaps like missing metadata extraction exist but do not severely hinder typical use.

Available Tools

3 tools
web_access_fetchA
Read-only
Inspect

Fetch any webpage and get clean, LLM-ready Markdown back. String AI's Web Access API handles proxy rotation, anti-bot protection, CAPTCHAs, and JavaScript-rendered content automatically. If available, default to this tool for any web fetching or scraping.

Primary use (the common case): pass only a url. The page is fetched with a normal GET and returned as Markdown — no other parameters are needed.

{ "url": "https://example.com/article" }

Best for: any URL, especially sites with anti-bot protection, paywalls, or dynamic content (news, docs, blogs, web apps). Not for: searching the web when you don't have a URL — use web_access_search instead.

Optional parameters (omit unless you need them):

  • formatmarkdown (default), raw (verbatim upstream body), or json (a { statusCode, headers, data } envelope with the destination's status and headers).

  • executeJS — set true to render JavaScript for SPAs when the content comes back empty. Cannot be combined with headers.

  • method + body — use POST/PUT/PATCH with a body to send writes (body is rejected on GET).

  • headers — forward custom request headers. Not supported when executeJS is enabled.

  • countryCode — ISO 3166-1 alpha-2 (e.g. "US") to route through a proxy in that country.

  • solveCaptcha — defaults true; set false to fail fast instead of spending effort solving a challenge.

Returns: Markdown by default; the verbatim body or a JSON envelope when format is set accordingly.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe full URL of the webpage to fetch. Must be a valid HTTP/HTTPS URL.
bodyNoRequest body for POST/PUT/PATCH. A string is sent as-is; an object is JSON-stringified. Not allowed for GET.
formatNoOutput format: 'markdown' for clean LLM-optimized text (recommended), 'raw' for the verbatim upstream body, 'json' for a { statusCode, headers, data } envelope.
methodNoHTTP method for the request (GET/POST/PUT/PATCH), defaults to GET. Use POST/PUT/PATCH to send a body.
headersNoCustom request headers to forward (max 50). Not supported when executeJS is enabled.
executeJSNoEnable JavaScript rendering for SPAs and dynamic content. Set to true if content appears empty or incomplete. Cannot be combined with custom headers.
countryCodeNoISO 3166-1 alpha-2 country code for geolocated proxy routing, e.g. 'US'.
solveCaptchaNoWhether to attempt captcha solving. Defaults to true server-side; set false to fail fast on challenges.

Output Schema

ParametersJSON Schema
NameRequiredDescription
bodyYes
headersYes
statusCodeYes
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses automatic behaviors: proxy rotation, anti-bot protection, CAPTCHA solving, JavaScript rendering. It explains the solveCaptcha default and interaction between parameters. No contradictions.

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 description is well-structured with an overview, primary use example, best/not for, and parameter explanations. It is concise (about 15 lines) and front-loaded with the most important information.

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?

The description covers all necessary context: what the tool does, when to use it, how to use parameters, and output format. Given the output schema exists, the description does not need to detail return values, and it provides complete guidance for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 8 parameters are described in the schema (100% coverage), but the description adds significant value: e.g., 'Cannot be combined with headers when executeJS is true', 'body is rejected on GET', and usage notes for each optional parameter.

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 clearly states the verb ('Fetch'), resource ('any webpage'), and output ('clean, LLM-ready Markdown'). It distinguishes from sibling tools by specifying that this tool is for fetching when you have a URL, while web_access_search is for searching without a URL.

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?

The description provides explicit 'Best for' and 'Not for' sections, and directly mentions the alternative tool (web_access_search). It also gives a primary use case and detailed guidance on when to use optional parameters.

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

web_access_sitemapAInspect

Crawl an entire website and map its URLs using String AI's Web Access API sitemap crawler. Starting from one URL it follows same-domain links breadth-first (optionally seeded from the site's /sitemap.xml) and records every URL it reaches with fetch status, depth, and parent. The crawl runs asynchronously server-side, so it handles whole sites that a single web_access_fetch call cannot.

Best for: discovering all pages/URLs of a site (site audits, building scraping worklists, coverage checks) before fetching individual pages with web_access_fetch. Not for: reading one page's content (use web_access_fetch) or open-ended web queries (use web_access_search).

This single tool drives the whole job lifecycle through action:

1. submit — quote a crawl (nothing is crawled or billed yet). Requires url. Optional: maxPages (1–10000, default 10), maxDepth (1–100, default 2), pathPrefix (only crawl URLs whose path starts with this, e.g. "/docs"), budgetUsd (spend ceiling; the crawl stops with status token_cap_exceeded if it would exceed it), useSitemap (also seed the site's root /sitemap.xml — one extra billed page, but finds pages links miss). Returns jobId, estimatedPages, and estimatedCostUsd with status awaiting_approval.

{ "action": "submit", "url": "https://example.com", "maxPages": 200, "maxDepth": 3 }

2. approve — start the quoted crawl (requires jobId). This is the billing-consent step: pages are billed as they are fetched, capped by the quote/budget. Before approving a non-trivial estimatedCostUsd, confirm the spend with your user. Fails with status 402 if the account balance cannot cover the quote; a 409 partial_state error means an earlier approve was interrupted — just call approve again.

3. status — poll progress (requires jobId). Statuses: awaiting_approvalrunning → terminal completed | failed | canceled | token_cap_exceeded (budget hit before maxPages; collected results are still readable). While running it returns pending and processed counts; a partial_state status means an interrupted approve — call approve again to repair it. Status never includes the URL list — page that with results. Poll every few seconds for small crawls; give hundreds-of-pages crawls tens of seconds between polls.

4. results — page through discovered URLs (requires jobId). Optional limit (default 1000, max 5000) and offset; total tells you when to stop paging. Each entry has url, statusCode (0 = discovered but not fetched), depth, parentUrl, isSitemap, sourceType, and an error when that page failed. discoveredUrls (links found on the page) is only present for ~1h after completion; afterwards results come from durable storage which omits it — everything else stays available.

5. cancel — stop a running or pending job (requires jobId). Already-terminal jobs return a 409 error. Pages already fetched stay billed and readable via results.

6. list — recent crawl jobs for the account. Optional limit (default 20, max 100) and offset. Use it to find a jobId you lost or check for an equivalent recent crawl before paying for a new one.

Typical workflow: submit → check estimatedCostUsd → approve → poll status until terminal → results (paged). A 404 on any jobId action means the job doesn't exist or belongs to another account; a 403 on submit means the target domain is blocked for this account (contact support@usestring.ai).

Returns: the JSON envelope for the chosen action (quote, status, URL page, job list) alongside a one-line summary.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNosubmit only (required there): the full http(s) URL to start crawling from. The crawl stays on this URL's domain.
jobIdNoThe job id returned by submit. Required for approve, status, results, and cancel.
limitNoresults/list only: page size. results default 1000 (max 5000); list default 20 (max 100).
actionYesLifecycle action to perform: 'submit' (quote a new crawl), 'approve' (start a quoted crawl — billing consent), 'status' (poll progress), 'results' (page through discovered URLs), 'cancel' (stop a job), or 'list' (recent jobs).
offsetNoresults/list only: number of rows to skip for pagination.
maxDepthNosubmit only: maximum link depth from the start URL, 1-100 (server default 2).
maxPagesNosubmit only: maximum pages to fetch, 1-10000 (server default 10). Each fetched page is billed.
budgetUsdNosubmit only: spend ceiling in USD (min 0.0001). The crawl finalizes as token_cap_exceeded when it would exceed this; omit to let the approved quote be the cap.
pathPrefixNosubmit only: restrict the crawl to URLs whose path starts with this prefix, e.g. '/docs'.
useSitemapNosubmit only: also seed the crawl from the site's root /sitemap.xml (one extra billed page; finds pages that internal links miss).

Output Schema

ParametersJSON Schema
NameRequiredDescription
jobsNo
urlsNo
jobIdNo
totalNo
statusNo
pendingNo
processedNo
finishedAtNo
errorMessageNo
estimatedPagesNo
pagesProcessedNo
estimatedCostUsdNo
Behavior5/5

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

With no annotations, the description carries full burden. It details the asynchronous server-side lifecycle, billing mechanics, error conditions (402, 409, 403, 404), data availability windows, and precise behavior for each action. No contradictions.

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?

Well-structured with sections, but lengthy; some redundancy (e.g., 409 error mentioned multiple times). Every sentence adds value, but could be trimmed slightly for better conciseness.

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?

Covers lifecycle, error handling, constraints, and returns. Although an output schema exists, the description still summarizes result fields and mentions the 'one-line summary' in returns. Complete for a complex sitemap-crawling tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant meaning: explains defaults (maxPages 10, maxDepth 2), conditional requirements (jobId needed for approve/status/results/cancel, url for submit), budgetUsd as spend ceiling, and useSitemap behavior. Goes well beyond the schema.

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 clearly states that the tool crawls an entire website to map its URLs using a sitemap crawler, following same-domain links breadth-first. It distinguishes itself from siblings web_access_fetch and web_access_search with explicit 'Best for' and 'Not for' sections.

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?

Provides explicit when-to-use and when-not-to-use guidance, naming alternatives. Includes a typical workflow and specific use cases (site audits, building scraping worklists), plus error handling and billing consent steps.

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

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Servers

View all MCP Servers

Try in Browser

Your Connectors

Sign in to create a connector for this server.

Resources