Skip to main content
Glama

Exepal

read_batch

Read-only

Page reader for up to 10 URLs. Price: $0.03 USDC per call on Base, paid with x402; not charged if the call fails.

Input Schema

NameRequiredDescriptionDefault
urlsYesPages to read
linksNo
formatNo
imagesNo
maxCharsNoCap per page, default 20000

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.4/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 safety, yet the description adds meaningful non-obvious behavior: a per-call price of $0.03 USDC on Base via x402 and the fact that failed calls are not charged. That is real cost/risk context an agent cannot get from annotations. It still omits what happens on per-URL failures within a batch or how results are returned.

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?

Two sentences, both earning their place: the first defines the operation and batch bound, the second front-loads cost and the no-charge-on-failure guarantee. No filler or hedging.

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

Completeness2/5

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

With 5 parameters, 40% schema coverage, and no output schema, the definition should explain the undescribed options and the shape of results (one blob vs. per-URL results, ordering, partial failures). Instead it is silent on all of these, leaving the agent guessing how to call it correctly.

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

Parameters2/5

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

Schema description coverage is only 40%: only urls and maxChars carry descriptions. The description reinforces the 10-URL cap but says nothing about links, format (the one enum), or images, so three of five parameters remain undocumented in both schema and description.

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?

"Page reader for up to 10 URLs" gives a specific verb (read pages) and resource (URLs) plus the batch bound. It does not distinguish itself from the sibling tool "read", which is presumably the single-URL variant, so the agent must guess which to pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The "up to 10 URLs" phrasing implies batch usage, so the use case is inferable, but there is no explicit statement of when to choose this over the sibling "read" tool, and no exclusions, prerequisites, or failure-mode guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.