Skip to main content
Glama
Sign In

Tulina

by ai.tulina.mcp
OverviewDiscussionsAdmin

web_read

Read-only

Read a PUBLIC web page, escalating until it yields — and always saying which path was used.

Escalation: ① plain HTTP fetch (free) → on 403/timeout/empty shell ② hosted scraper (serper, ~2 credits — basic anti-bot, but NO guaranteed JS rendering: a client-rendered page comes back 200 with a near-empty body, and ② will report it as read) → ③ ONLY IF browser=true: a disposable hosted Chrome session (real fingerprint, patience — costs a browser session). Without browser=true the answer stops at ② and tells you what to do.

Returns {content, title, final_url, hote, chemin, tentatives, cout, truncated} — chemin = which path actually produced the content (http | serper | browser), tentatives = every path tried and why it moved on, cout = what the read cost (serper credits, browser session). A skipped path (no serper key, Browserbase not configured) is REPORTED, never silent.

⚠️ final_url is the OBSERVED landing URL, or null when the path used cannot report one (the hosted scraper follows redirects silently). hote = {demande, servi, conforme} says whether the page actually served belongs to the domain you asked for: conforme is true (same site), false (a redirect took you elsewhere — the content is that OTHER site's) or null (unknowable on this path). Anything but true also sets avertissement. Never assume the body came from the host you requested — read hote.

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": "web_read"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesabsolute public URL (http/https). Internal/private addresses are refused by design, and so is a page under the project's `excluded_url_prefixes` (requested or landed on by redirect).
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
as_htmlNoTrue = raw HTML/DOM instead of readable text (①/③ only — ② returns markdown).
browserNoopt-in for the costly last resort (real Chrome session).
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
max_charsNocap on returned content (truncation is flagged).

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond readOnlyHint=true: it quantifies cost (~2 serper credits, a browser session), warns that path ② can return a 200 with a near-empty client-rendered body and still report success, documents that skipped paths are reported rather than silent, and explains the redirect-leak risk via `hote`. That is exactly the kind of operational context annotations cannot carry.

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?

Front-loads the escalation ladder, then the return shape, then the host-verification warning — a sensible order. It is dense rather than bloated, but the final sentence ('Never assume the body came from the host you requested — read `hote`') restates the `hote` explanation already given, and the circled-number/emoji formatting adds mild noise.

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?

For a 9-parameter tool with no output schema, the description supplies the full return contract (content, title, final_url, hote, chemin, tentatives, cout, truncated), explains the critical `final_url=null` and `conforme=null` cases, and flags truncation. An agent can call it and interpret the result without further documentation.

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?

With 100% schema coverage the baseline is 3, and the description adds cross-parameter meaning the schema lacks: `browser=true` is what unlocks path ③ (otherwise the answer stops at ②), and `as_html` only applies to paths ①/③ while ② always returns markdown. The internal routing params (_org, _group, _run_id, _project, _instance) are left to the schema, which is acceptable.

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?

States a specific verb and resource ('Read a PUBLIC web page') plus the distinctive mechanism (an escalation ladder ending in an opt-in Chrome session) and what it always reports (which path was used). This is far more informative than a generic fetch, though it never names an alternative tool (http_get, serper_scrape, apify_website_crawl) to differentiate against.

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?

Gives explicit conditions for each escalation step (403/timeout/empty shell → hosted scraper; 'ONLY IF browser=true' → Chrome) and clearly states the consequence of omitting browser=true. What's missing is guidance on when to prefer this tool over the sibling scrapers (serper_scrape, apify_website_crawl) rather than only how its internal paths trigger.

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

All Tulina 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