Google Sites MCP

Overview Schema Source Related Servers Discussions Admin

List page sections

gsites_list_sections

Read-onlyIdempotent

List the content sections of the open Google Sites page top to bottom with 1-based indexes and previews, so you can move, duplicate, or delete specific sections.

Instructions

List the content sections of the open page, top to bottom, with a 1-based index and a preview (text, [image], [divider], [block]). Use these indexes in gsites_move_section / duplicate / delete.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "gsites_list_sections"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Nov 5, 2026

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/non-destructive, so the safety profile is covered. The description still adds real behavioral value by disclosing the return shape (1-based index plus preview tokens text/[image]/[divider]/[block]), which the agent cannot infer from annotations. It stops short of describing empty-page behavior or index stability after mutations.

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?

Two sentences, front-loaded with the action and return format, then the actionable follow-up. No filler and nothing redundant with the schema.

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?

With no output schema, the description carries the burden of explaining return values and does so adequately via the index and preview format. Minor gap: no statement of behavior when the page is empty or when no page is open, which matters for an openWorld browser tool.

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?

The tool takes zero parameters and the schema is empty, so there is no parameter semantics to document; baseline applies. The description correctly does not invent parameter detail and instead spends its words on output semantics.

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 specific verb+resource (list sections of the open page) and adds scope detail — top-to-bottom ordering, 1-based index, and preview tokens. It is clearly distinguishable from the gsites_add_* and gsites_*_section siblings, which it explicitly names as consumers of the indexes.

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?

'Use these indexes in gsites_move_section / duplicate / delete' gives explicit downstream usage and thereby routes the agent to the right follow-up tools. The implicit prerequisite ('the open page') is conveyed, but there is no explicit when-not guidance or note about what to do if no page is open.

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