Skip to main content
Glama

Read a cited page

read_source_url
Read-onlyIdempotent

Read one cited page in depth, after read_visibility_sources or an answer names it: how often it was retrieved and cited, when first and last seen, the engines and models that cite it, the prompts it is cited for (up to 50), the brands it names (up to 12, including whether yours is there), and what CiteLadder read on the page itself. Omit audit_id to cover every run in the market, not just the latest. The URL must match the cited URL exactly; unavailable url_not_cited_in_selection means it was not cited in that selection.

Input Schema

NameRequiredDescriptionDefault
urlYesA cited URL exactly as read_visibility_sources or an answer listed it.
cohortNocore is the scored prompts (the default); comparison is the prompts that also name a competitor, reported separately; all is both.core
engineNoRead one engine only; omit for every engine.
audit_idNoA run id (audit_id); omit for every run.
market_idNoA market id from get_project_business_context; omit for the default market. Markets are never pooled.
project_idYesA project id that list_projects returned.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / audit_id / description
      Added value: +"A run id (audit_id); omit for every run."
    • addedInput schema / properties / cohort / description
      Added value: +"core is the scored prompts (the default); comparison is the prompts that also name a competitor, reported separately; all is both."
    • addedInput schema / properties / engine / description
      Added value: +"Read one engine only; omit for every engine."
    • addedInput schema / properties / market_id / description
      Added value: +"A market id from get_project_business_context; omit for the default market. Markets are never pooled."
    • addedInput schema / properties / project_id / description
      Added value: +"A project id that list_projects returned."
    • addedInput schema / properties / url / description
      Added value: +"A cited URL exactly as read_visibility_sources or an answer listed it."
  2. Changed1 schema field changed
    • changedInput schema / properties / cohort / enum
      Previous value: -[
      -  "core",
      -  "comparison"
      -]New value: +[
      +  "core",
      +  "comparison",
      +  "all"
      +]
  3. 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 read-only, idempotent, non-destructive, closed-world behavior, so safety is covered. The description adds real context beyond that: result caps (50 prompts, 12 brands), the aggregation semantics of omitting audit_id, and the url_not_cited_in_selection outcome. It stops short of explaining truncation/sorting behavior for the capped lists.

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 verb and purpose, then two short sentences for scoping and error handling. The first sentence is dense with a long enumeration of return fields, but every clause carries information an agent needs.

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 carries the full burden of describing the return payload, and it does so concretely, including the caps on the prompts and brands lists. Combined with the schema's parameter docs and the annotations' safety profile, an agent has what it needs to call this correctly.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning: omitting audit_id pools every run rather than defaulting to the latest, and the URL must match the cited URL exactly with a named failure mode. The cohort, engine and market_id semantics are largely left to the schema.

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+resource ("Read one cited page in depth") and enumerates the exact payload: retrieval/citation frequency, first/last seen, citing engines and models, prompts (up to 50), brands (up to 12), and on-page content. It is clearly distinguishable from the discovery sibling read_visibility_sources, which it names as the upstream step.

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 an explicit prerequisite and trigger ("after read_visibility_sources or an answer names it") and clarifies the audit_id omission case (every run in the market vs latest). It does not state when a different read tool (e.g. read_ai_traffic_url, read_query_evidence) would be the better choice, so it stops short of full alternative routing.

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