Locus

Locus Web Extract

web_extract

Read the full content of one to twenty exact public URLs you already have and return each page's text, or structured JSON via json. Use after a search produced URLs or when the user supplies links; it never searches or substitutes other pages, so use router/web-search or router/web-research to find sources first. Billed per URL; maxCredits caps the total. In text mode a second extractor retries only the URLs the first one fails; json mode uses a single extractor with no retry. Usually costs ~1.01 credits per call. The result reports credits charged.

Input Schema

Name	Required	Description
`json`	No	Return structured JSON for each URL in one step instead of page text. Pass a prompt, a JSON Schema, or both. Cannot be combined with objective.
`urls`	Yes	Exact public HTTP(S) resources to read. The router never substitutes another URL.
`_locus`	No	Optional Locus execution controls; provider arguments remain top-level.
`objective`	No	Optional focus within each supplied resource; it does not authorize discovery.
`maxCredits`	No	Aggregate hard charge ceiling in workspace credits. Decimal strings support up to six fractional digits; numeric values are rounded down to six digits.
`attribution`	No	Optional JSON ledger metadata such as a task or customer identifier.
`maxAgeSeconds`	No	Maximum accepted cache age. Omit to use each extractor default.
`externalUserId`	No	Optional end-user billing attribution for a tenant secret key.
`maxCharactersPerUrl`	No

Output Schema

Name	Required	Description
`data`	Yes	Raw provider response.
`usd_charged`	No	USD charged (secret-key auth only).
`credits_balance`	No
`credits_charged`	No
`idempotent_replay`	No	Stored replay; no new charge.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 7, 2026

addedInput schema / properties / json

Added value: +{
+  "additionalProperties": false,
+  "description": "Return structured JSON for each URL in one step instead of page text. Pass a prompt, a JSON Schema, or both. Cannot be combined with objective.",
+  "minProperties": 1,
+  "properties": {
+    "prompt": {
+      "maxLength": 400,
+      "minLength": 1,
+      "type": "string"
+    },
+    "schema": {
+      "additionalProperties": true,
+      "type": "object"
+    }
+  },
+  "type": "object"
+}

removedOutput schema / properties / credits_balance / description
```
Removed value: -"Remaining credit balance."
```
removedOutput schema / properties / credits_charged / description
```
Removed value: -"Credits debited for this call."
```

changedOutput schema / properties / data / description

Previous value: -"Raw upstream provider response body."New value: +"Raw provider response."

changedOutput schema / properties / idempotent_replay / description

Previous value: -"True when a stored identical call was replayed; no new charge was made."New value: +"Stored replay; no new charge."

AddedOct 3, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses per-URL billing, that maxCredits is a hard aggregate ceiling, the retry asymmetry (text mode retries only failed URLs with a second extractor, json mode uses a single extractor with no retry), the typical ~1.01 credit cost, and that the result reports credits charged. This is exactly the cost/retry information an agent needs before spending credits, and nothing contradicts readOnlyHint=false / idempotentHint=false.

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-loaded with the core action, then usage routing, then billing and retry semantics in descending importance. Dense but every sentence carries operational information; the cost figure and retry clause could be tightened 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?

An output schema exists, so return shape needs no explanation, and the description still covers the non-obvious pieces: spend limits, retry behavior by mode, and cost per call. Only edge details such as failure/error outcomes for individual URLs are left unstated.

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 89%, so the schema already explains json, urls, maxCredits, maxAgeSeconds and the Locus controls. The description adds only the 1–20 URL bound and that maxCredits caps the total, which is largely redundant with the schema's minItems/maxItems and its own description.

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 ('Read the full content of one to twenty exact public URLs') and names the two output shapes (page text or structured JSON via json). The 'never searches or substitutes other pages' clause separates it cleanly from the router search/research siblings.

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 trigger ('Use after a search produced URLs or when the user supplies links') and an explicit alternative for the other case ('use router/web-search or router/web-research to find sources first'). The boundary between extracting and discovering is stated rather than implied.

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

All Locus 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.