Skip to main content
Glama

URLpipe

Extract page metadata

extract_metadata
Idempotent

Exposes POST /meta. Reconciles Open Graph, Twitter card and standard page metadata into one clean object: title, description, language, main image, favicon, author, publication date and feed. Values injected by JavaScript are included, because the page is rendered first. 5 credits.

This is the page's metadata, not a dump of its meta tags. If you only need the title, it is also in the Markdown — and that costs 1 credit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe page to fetch. Must be a public http(s) URL.
syncNoWait for the result and return it (default false). When false the call returns a token immediately and you collect the result with get_result.
labelsNoYour own keys to find this request by later, e.g. {"client": "acme"}: they come back with the result, in the webhook and in list_requests, which can filter by them. Up to 16 keys of up to 40 letters, digits, _ - or .; string values up to 256 characters.
max_ageNoHow fresh a stored result must be to be reused, e.g. "2 hours" or "3 days". Default 7 days, maximum 30. A reused result is free. Pass "0" to force a fresh fetch.
report_toNoAsync only: a webhook URL to deliver the result to. Defaults to the project's configured endpoint, if it has one.
project_idYesWhich project this request belongs to. From list_projects.
residentialNoFetch the page from a residential (home ISP) exit instead of a datacentre one. Costs a surcharge per page visit — see get_usage. Use it for sites that block datacentre traffic.
page_optionsNoWhat to do to the page before anything is read off it. Applies to the result itself: removed ads and banners are gone from html, markdown and summaries too.
idempotency_keyNoMakes the call safe to retry: sending it again with the same key within 24 hours returns the first call's token and result instead of starting (and charging for) new work, even with max_age "0". Up to 255 printable ASCII characters; a UUID is ideal.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "https://json-schema.org/draft/2020-12/schema",
      +  "anyOf": [
      +    {
      +      "properties": {
      +        "additional_author_information": {
      +          "type": [
      +            "object",
      +            "null"
      +          ]
      +        },
      +        "author_name": {
      +          "type": [
      +            "string",
      +            "null"
      +          ]
      +        },
      +        "description": {
      +          "type": [
      +            "string",
      +            "null"
      +          ]
      +        },
      +        "favicon_url": {
      +          "type": [
      +            "string",
      +            "null"
      +          ]
      +        },
      +        "feed_url": {
      +          "type": [
      +            "string",
      +            "null"
      +          ]
      +        },
      +        "language": {
      +          "type": [
      +            "string",
      +            "null"
      +          ]
      +        },
      +        "main_image_url": {
      +          "type": [
      +            "string",
      +            "null"
      +          ]
      +        },
      +        "publication_date": {
      +          "type": [
      +            "string",
      +            "null"
      +          ]
      +        },
      +        "title": {
      +          "type": [
      +            "string",
      +            "null"
      +          ]
      +        }
      +      },
      +      "type": "object"
      +    },
      +    {
      +      "properties": {
      +        "labels": {
      +          "type": "object"
      +        },
      +        "status": {
      +          "const": "accepted",
      +          "type": "string"
      +        },
      +        "token": {
      +          "type": "string"
      +        }
      +      },
      +      "type": "object"
      +    }
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false (so mutation is possible, but the description clarifies it's a read operation) and idempotentHint=true. The description adds valuable behavioral context beyond annotations: it states the page is rendered first, so JavaScript-injected values are included, and it discloses the 5-credit cost. It also clarifies that this is not a raw meta-tag dump, which manages expectations. While it doesn't cover error handling or rate limits, the added context is meaningful given the annotation coverage.

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 concise and well-structured. It opens with a direct statement of what the tool does, then elaborates on the outcome, followed by a clarifying note about scope and a cost-effective alternative. Every sentence earns its place: no filler, and the critical clarification about not being a meta-tag dump is placed in the second paragraph but remains prominent. The length is appropriate for the tool's complexity.

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?

Given the tool has 9 parameters, a nested object, and an output schema, the description covers the essential behavioral context: the purpose, the inclusion of JS-injected values, and the cost. It does not explain the async flow (sync parameter, get_result), but the input schema fully documents that, and the output schema exists. The description is complete enough for an agent to understand when to use it and what to expect, though more explicit mention of the async pattern could improve it slightly.

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 100%, so all nine parameters are already well-documented in the input schema. The description does not add any parameter-specific semantics beyond what the schema provides; it focuses on the tool's purpose and output. The baseline of 3 is appropriate since the schema handles parameter documentation, and the description does not need to repeat it.

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 what the tool does: it exposes POST /meta and reconciles Open Graph, Twitter card, and standard metadata into a clean object with a specific list of fields. It distinguishes itself from a raw meta-tag dump and points to the alternative of using Markdown for a title, making the purpose unambiguous and distinct from 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?

The description explicitly contrasts this tool with a cheaper alternative: 'If you only need the title, it is also in the Markdown — and that costs 1 credit.' This directly instructs the agent on when to use this tool versus fetch_markdown, and implicitly signals that this tool is for comprehensive metadata needs. The cost difference and the condition (only need title) are concrete, actionable 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.

Resources