Skip to main content
Glama

Razi Web Tools

fetch_page_metadata

Read a web page's metadata without downloading any images. Returns JSON { url, finalUrl, title, description, siteName, canonical, lang, themeColor, author, generator, feeds, openGraph, twitter, icons, cached }, where feeds is an array of RSS/Atom URLs, openGraph and twitter are the complete tag sets as string maps, and any tag the page does not declare is simply omitted. icons is always an empty array here because icon resolution is switched off — call fetch_site_logo when the caller wants a logo, favicon or icon. finalUrl is the address after redirects (up to 3 hops are followed), which is how you resolve where a domain actually points. This is the fast, cheap counterpart to fetch_site_logo: one page fetch and no image work. It reads the served HTML only — it runs no JavaScript, so a client-rendered page may expose little, and it does not capture how the page looks (use screenshot_url for that). The crawler identifies itself as RaziMetadataBot, and HTTP status is not checked, so a 404 or bot-challenge page that serves HTML is parsed as though it were the page you asked for. Errors: 400 for a URL that is refused as unsafe, redirects too many times, does not return HTML, or exceeds the 5MB page cap; 504 if the page does not answer within 10 seconds; 502 otherwise. Results are cached for 24 hours and replayed with cached: true; 20 calls per minute per IP, then 429.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe page to read, e.g. https://stripe.com/pricing. A bare domain is accepted and assumed to be https. It is the cache key verbatim, so two spellings of the same page are fetched twice.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedInput schema / properties / url / description
      Previous value: -"The page to read, e.g. https://stripe.com/pricing. A bare domain is accepted and assumed to be https."New value: +"The page to read, e.g. https://stripe.com/pricing. A bare domain is accepted and assumed to be https. It is the cache key verbatim, so two spellings of the same page are fetched twice."
  2. First observed

TDQS

A5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of disclosing behavior, and it does so thoroughly: no image downloads, redirect handling up to 3 hops, no JS execution, no HTTP status verification, user-agent identification, error codes, caching behavior, and rate limits. This is comprehensive beyond what structured fields would reveal.

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 dense but every sentence adds essential operational detail. It front-loads the return shape and main scope, then layers in limitations, errors, and caching. No filler or repetition; the length is justified by the tool's behavioral complexity.

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?

There is no output schema, so the description must explain the return format, and it does so in detail with field names, types, and conditional presence. It also covers failure modes, edge cases, caching, rate limits, and alternatives, making it fully sufficient for an agent to invoke correctly.

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?

Although the schema already describes the url parameter at 100%, the description adds valuable semantics: bare domains are accepted and assumed https, and the URL is the verbatim cache key, meaning different spellings cause duplicate fetches. This extra context helps the agent avoid misuse.

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 tool's verb and resource: read a web page's metadata without downloading images. It also distinguishes itself from siblings by explicitly naming fetch_site_logo and screenshot_url as alternatives for icon resolution and visual capture.

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 guidance: it is the fast, cheap counterpart to fetch_site_logo, and it tells the agent to call fetch_site_logo when a logo/favicon/icon is wanted and screenshot_url when the page's appearance is needed. It also notes limitations such as no JavaScript execution.

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.

Resources