Google Sites MCP

Overview Schema Source Related Servers Discussions Admin

Add a link button

gsites_add_button

Insert a labeled button linking to a URL into the selected Google Sites section; content appends by default and can be reordered afterward.

Instructions

Insert a button with a label that links to a URL. New content goes after the currently selected section; by default the last section is selected first so content is appended at the end. Use gsites_move_section to reorder afterwards.

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": {
      "label": "<label>",
      "url": "<url>"
    },
    "name": "gsites_add_button"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes	Link, e.g. https://example.com
`label`	Yes	Button text, e.g. 'Ver proyectos'

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Nov 5, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare the write, open-world, and non-idempotent profile, so the bar is lower. The description adds behavior annotations cannot express: the insertion point depends on the current selection, and the default selection causes append-at-end semantics. It does not warn that repeated calls create duplicate buttons, which is the main remaining gap.

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?

Three short sentences, each earning its place: what it does, where the content lands, and which tool to use for reordering. The most important scoping detail, the insertion point, is front-loaded after the purpose statement.

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?

For a two-parameter insert tool with full schema coverage, annotations, and no output schema, the description supplies the one thing an agent could not infer: where the new block appears relative to the current selection. Only the duplicate-on-repeat behavior is left unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both `label` and `url` documented including examples and length bounds, so the schema carries the parameter burden. The description restates the two parameters at a high level ('a label that links to a URL') without adding format or validation meaning. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Insert a button with a label that links to a URL,' which clearly separates it from sibling insert tools like gsites_add_text, gsites_add_image, or gsites_add_embed. It stops short of naming those siblings explicitly, so the differentiation is inferred from the resource noun rather than stated.

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?

It gives concrete placement guidance: new content goes after the currently selected section, and the last section is selected by default so content appends at the end. It also routes the agent to gsites_move_section when reordering is needed, which is genuine alternative-tool guidance. It does not cover when to choose a button over other block types, but the insertion context is well handled.

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