Skip to main content
Glama

Get site content

get_site_content
Read-onlyIdempotent

Fetch a site's current entry document by id so you can edit it and push the result back with update_site: the read half of the round-trip get_site and list_sites omit (they return only metadata, never the body). Returns the live document inline as UTF-8 (encoding: "utf-8") for HTML/Markdown/text/SVG/JSON, or base64 (encoding: "base64") for binary content like PDFs and images, alongside content_type, content_kind, and content_hash. A site whose content_kind is not html was rendered from a file (Markdown, a notebook, a Word, PowerPoint or Excel file, a CSV, a PDF, an image, a video, an audio, a Mermaid diagram, a text file or a React component): what comes back is its rendered page, not the file, and the result says so in note. To change such a site, send the source again to update_site: a text source (Markdown, CSV, Mermaid, notebook, code, component) as files, a binary one as an upload_id (which needs a shell that makes the SnapHost tool calls itself; without a shell, update_site says where the person drops it); sending edited HTML turns it into an HTML site. Pass original true to fetch the uploaded file itself when the page offers it for download (get_site reports original_included); refused when it does not.

Input Schema

NameRequiredDescriptionDefault
site_idYesThe id of the site whose content to fetch
originalNoFetch the uploaded file the page carries for download (a .pptx, an image, a CSV) instead of the rendered page
workspace_idNoOptional: the workspace to act in, from list_workspaces (the connection reaches the person's personal space and every workspace they are a member of). Required on a write when the connection reaches more than one workspace. Omit to act in the personal space (for an older single-workspace connection, the one workspace it was authorized for).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / original
      Added value: +{
      +  "description": "Fetch the uploaded file the page carries for download (a .pptx, an image, a CSV) instead of the rendered page",
      +  "type": "boolean"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / workspace_id / description
      Previous value: -"Optional: the workspace (the personal space or a Pro workspace) to act in, from list_workspaces. Omit to act in the token owner's own account."New value: +"Optional: the workspace to act in, from list_workspaces (the connection reaches the person's personal space and every workspace they are a member of). Required on a write when the connection reaches more than one workspace. Omit to act in the personal space (for an older single-workspace connection, the one workspace it was authorized for)."
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive, but the description adds substantial context beyond them: the inline vs base64 encoding split by content type, the presence of `content_type`, `content_kind`, and `content_hash`, and the important caveat that a non-html `content_kind` returns a rendered page rather than the source file, surfaced in `note`. It also discloses the refusal behavior for `original`.

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?

The purpose and the sibling distinction are front-loaded in the first clause. The remainder is dense with long parenthetical lists (Markdown, notebook, Word, PowerPoint, Excel...) that border on exhaustive but each conveys a distinct behavioral fact. Slightly heavy, but nearly every sentence earns its place.

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 explaining return values, and it does: encoding, content_type, content_kind, content_hash, note, and the rendered-vs-source distinction. An agent has everything needed to call it and interpret the response, including the follow-up path via update_site.

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 baseline is 3, but the description meaningfully enriches `original` by explaining what it returns (the uploaded .pptx/image/CSV rather than the rendered page), its precondition, and its failure mode. The `site_id` and `workspace_id` parameters are left to their schema descriptions, which is reasonable given full coverage.

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 and resource ('Fetch a site's current entry document by id') and immediately distinguishes itself from get_site and list_sites, which 'return only metadata, never the body'. An agent can select this tool without ambiguity among the three read siblings.

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?

Explicitly frames the tool as 'the read half of the round-trip' and directs the agent to update_site to push changes back, with guidance on how to send text vs binary sources. It also gates the `original` parameter on a condition (the page offering the file for download, signalled by get_site's `original_included`) and states it is refused otherwise. Lacks only explicit when-not-to-call guidance for the plain-page case, which is implicitly covered.

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.