Skip to main content
Glama

Read site

read_site
Read-onlyIdempotent

Open a site published before, in this chat or another: its live versionId, files, and the text of its HTML, CSS and JS, in pages. list_sites lists the account's sites; a temporary site needs its claimToken. Call this before edit_site.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slug": "<slug>"
    },
    "name": "read_site"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathNoRead one file, such as index.html.
slugYesSlug or link.
offsetNoWhere to go on in path, from a previous read.
searchNoFind this text instead of reading; returns each match with its offset.
maxCharsNo
claimTokenNo

Output Schema

NameRequiredDescriptionDefault
slugYes
filesYes
searchNo
contentNo
siteUrlYes
remainingNo
versionIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed14 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / claimToken / minLength
      Removed value: -8
    • removedInput schema / properties / maxChars / default
      Removed value: -50000
    • changedInput schema / properties / offset / description
      Previous value: -"Character offset in path to start from, from a previous read_site."New value: +"Where to go on in path, from a previous read."
    • removedInput schema / properties / path / minLength
      Removed value: -1
    • changedInput schema / properties / search / description
      Previous value: -"Find this text (case-insensitive) instead of reading; returns each match with its offset and surrounding text."New value: +"Find this text instead of reading; returns each match with its offset."
    • removedInput schema / properties / search / minLength
      Removed value: -1
    • changedInput schema / properties / slug / description
      Previous value: -"The site slug, or its link such as https://<slug>.attim.link/."New value: +"Slug or link."
    • removedInput schema / properties / slug / minLength
      Removed value: -1
    • removedOutput schema / properties / anonymous
      Removed value: -{
      -  "type": "boolean"
      -}
    • removedOutput schema / properties / files / items / properties / contentType
      Removed value: -{
      -  "type": "string"
      -}
    • removedOutput schema / properties / files / items / properties / kind
      Removed value: -{
      -  "type": "string"
      -}
    • removedOutput schema / properties / title
      Removed value: -{
      -  "type": "string"
      -}
    • removedOutput schema / properties / variables
      Removed value: -{
      -  "type": "array"
      -}
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real context on top: it reads the live version, returns content in pages, and requires a claimToken for temporary sites. It stops short of stating default page size or whether draft/unpublished content is excluded.

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 what the tool returns, then constraints, then ordering. The opening sentence is dense and colon-chained, but nothing is wasted and no sentence is filler.

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?

An output schema exists, so return values need not be re-explained. Given six parameters, a required slug, and pagination, the description covers source of the identifier, the auth edge case, and sequencing with edit_site — everything needed to invoke it 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?

At 67% schema coverage, the description compensates for the biggest gap by explaining claimToken (which has no schema description) and how slug may come from list_sites. The 'in pages' framing also gives meaning to offset/maxChars that the schema only names.

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?

Uses a concrete verb on a concrete resource and enumerates what comes back: live versionId, files, and the text of HTML/CSS/JS, in pages. That is enough to distinguish it from edit_site and list_sites without opening either schema.

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?

Explicitly states the precondition for temporary sites (needs its claimToken), points to list_sites as the way to discover slugs, and gives an ordering constraint: 'Call this before edit_site.' That is concrete routing guidance rather than implied usage.

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