/**
 * Workspace-scoped GTM resources that share an identical CRUD(+revert) shape:
 *   - clients         (server containers)
 *   - transformations (server containers)
 *   - zones           (web containers — zone delegation)
 *   - templates       (custom templates / gallery-installed templates)
 *   - gtag_config     (Google tag / gtag configuration; no revert)
 *
 * These resources have rich, deeply-nested bodies (parameters, consent
 * settings, template data, etc.). Rather than model every field in Zod, the
 * create/update tools accept the full resource as a JSON string (`bodyJson`),
 * mirroring the existing workspace_resolve_conflict pattern. List/get/delete
 * use the same guardrails and pagination as the rest of the server.
 */
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import type { GtmClient } from '../utils/gtmClient.js';
/**
 * The tag `type` string for a custom template, which is what `tags_create` needs and what no
 * field on the template resource contains.
 *
 * There are two shapes, and the difference matters because guessing wrong is not a validation
 * error — GTM accepts the tag and the UI renders it as an unrecognised type:
 *
 *   gallery-installed   cvt_<galleryTemplateId>              e.g. cvt_MRQN8
 *   locally authored    cvt_<containerId>_<templateId>       e.g. cvt_1234567_12
 *
 * Note that a gallery template's type uses the GALLERY's id, NOT the workspace `templateId` it
 * was given on import. Those are different numbers, and the workspace one looks like the
 * plausible answer, which is exactly why it gets used by mistake.
 */
export declare function customTemplateType(template: Record<string, unknown>, fallbackContainerId: string): string;
export declare function registerServerSideTools(server: McpServer, getClient: () => GtmClient): void;
//# sourceMappingURL=serverSide.d.ts.map