Skip to main content
Glama
zackscriven

ghl-mcp-server-v2

by zackscriven

ghl_social_delete_watermark

DestructiveIdempotent

Soft-deletes a social media watermark template by template ID, stopping it from applying at post-publish, preserving the record, and releasing bound accounts for other templates.

Instructions

Delete a watermark template by ID Soft-delete a watermark template. The template is marked as deleted and no longer applies at post-publish time, but the record is preserved in the database. Any accounts previously bound via accountIds are released and become eligible for other templates. Endpoint: DELETE /social-media-posting/{locationId}/watermarks/{templateId} (Version header: v3; source: v3/social-planner-v3.json) Requires a Sub-Account (location) token. OAuth scopes: socialplanner/watermarks.write

Input Schema

NameRequiredDescriptionDefault
locationIdYesLocation ID
templateIdYesWatermark template ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, and the description adds substantial context beyond them: the delete is soft, the row survives, previously bound accountIds are released and become eligible for other templates. It also discloses the auth requirement (Sub-Account token) and the OAuth scope, which an agent needs before calling.

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 behavior-changing information (soft delete, account release) is front-loaded in the first two sentences, and the rest is reference metadata. The endpoint/version/source line is somewhat extraneous but compact.

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?

For a two-parameter delete with no output schema, the description covers effect, persistence, side effects on account bindings, auth token type, and required scope. Nothing an agent needs to invoke it correctly is missing.

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%, so both locationId and templateId are already documented in the schema. The description mentions accountIds only as a side-effect concept, not as a parameter, so it adds no syntax or format guidance beyond the schema. Baseline 3 applies.

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?

The description states a specific verb and resource ('Delete a watermark template by ID') and immediately clarifies it is a soft-delete rather than a hard purge. That distinction makes it clearly distinguishable from sibling operations such as ghl_social_update_watermark or ghl_social_get_watermark.

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?

The description gives clear context for when this applies: the template stops applying at post-publish time but the record persists, and bound accounts are released. It does not explicitly name an alternative (e.g., update vs. delete) or state exclusions, which keeps it shy of a 5.

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

Deploy Server

Other Tools