Skip to main content
Glama
Sign In

Ginta

by app.ginta
OverviewDiscussionsAdmin

Read a site: files and versions

get_site
Read-onlyIdempotent

Use before editing an existing site, or when the owner wants their code: returns its files (text contents; images and fonts as a list with their addresses), and with history: true its saved versions for restore_version. Pass paths to read only some files. (In Ginta's editor, owners on every plan can also see and edit the files in the Code tab and download everything as a .zip.)

Input Schema

NameRequiredDescriptionDefault
pathsNoOnly these files (default: all text files, if the site isn't too large).
historyNoAlso list the last 20 saved versions.
site_idYesThe site id: the first part of the site URL, e.g. "bella-roma" for https://bella-roma.ginta.page (see list_sites).

Output Schema

NameRequiredDescriptionDefault
urlYesThe site's address.
textYesThe answer in words, the same as the text content: read it (for get_guide the whole guide, for get_site the files' contents).
filesYesText files returned (their contents are in text).
assetsYesImages, fonts and other binary files.
site_idYesThe site id.
versionYesThe live version.
completeYesfalse = the site is too large; ask for specific paths.
versionsNoSaved versions (with history: true).
total_bytesYesSize of all files.
notify_emailYesForm messages go to another address than the account email, shown masked (null = the account email).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedOutput schema / properties / files / description
      Previous value: -"Text files returned (their contents are in the text content)."New value: +"Text files returned (their contents are in text)."
    • addedOutput schema / properties / text
      Added value: +{
+  "description": "The answer in words, the same as the text content: read it (for get_guide the whole guide, for get_site the files' contents).",
+  "type": "string"
+}
    • changedOutput schema / required
      Previous value: -[
-  "site_id",
-  "url",
-  "version",
-  "total_bytes",
-  "notify_email",
-  "files",
-  "assets",
-  "complete"
-]New value: +[
+  "site_id",
+  "url",
+  "version",
+  "total_bytes",
+  "notify_email",
+  "files",
+  "assets",
+  "complete",
+  "text"
+]
  2. Changed1 schema field changed
    • changedOutput schema / properties / notify_email / description
      Previous value: -"Form messages go here (null = the account email)."New value: +"Form messages go to another address than the account email, shown masked (null = the account email)."
  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 readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds real context beyond them: images and fonts are returned as references rather than bytes, history yields 'saved versions for restore_version', and there is a size caveat on default file retrieval. The trailing note about the editor's Code tab is mildly promotional rather than behavioral.

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 usage trigger is front-loaded, and the return-shape clause follows immediately. It is appropriately sized for a three-parameter read tool. The parenthetical about seeing files in the Code tab and downloading a .zip is tangential to invoking this tool and costs a little tightness.

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 enumerated, yet the description already characterizes them. Usage, narrowing via paths, the history option, and the restore_version relationship are all present. Nothing an agent needs in order to call this correctly is missing.

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 even without description help. The description nonetheless adds meaning the schema does not: it frames the history flag as the input that pairs with restore_version, and reinforces paths as a partial-read mechanism. It does not explain the default size threshold that governs behavior when paths is omitted.

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: reads a site and returns its files plus, optionally, saved versions. It goes further than the title by specifying that text files come back with contents while images and fonts come back as a list of addresses, which lets an agent distinguish this from list_sites, get_stats, or preview_site.

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 trigger ('Use before editing an existing site, or when the owner wants their code') and a narrowing instruction ('Pass paths to read only some files'). It also links the history flag forward to restore_version. It lacks an explicit when-not or a direct pointer to sibling reads like list_sites, so it falls short of a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Ginta toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources