/**
 * Typed, one-call builders: the tools the desktop chat has and the website chat did not.
 *
 * Every other write tool in this server is a thin wrapper over one GTM API call, which makes the
 * CALLER responsible for the resource shape. For a model that means re-deriving GTM's conventions
 * on every turn, and the conventions are not guessable: a GA4 event tag needs a `measurementId`
 * tagReference AND a `measurementIdOverride`, event parameters live in an `eventSettingsTable` list
 * of maps keyed parameter/parameterValue, a click trigger's conditions are keyed arg0/arg1, and a
 * built-in variable referenced before it is enabled silently resolves to nothing.
 *
 * Measured consequences of leaving that to the model, from one real "create a GA4 email_click tag"
 * turn on the hosted chat: four list calls, a gallery-template import that 404ed, two rejected
 * trigger writes, and a Data Layer Variable created for a value nothing pushes to the dataLayer, so
 * the finished tag reports an empty email address. Eight model round trips at roughly 6,000 tokens
 * each, against an account limited to 30,000 tokens per minute.
 *
 * These tools take the fields a person would state and let OUR code build the resource, using the
 * same builders the desktop assistant uses (src/shared/gtm-builders.ts). One call enables the
 * built-in variables the tag and trigger reference, reuses or creates the named trigger, and
 * creates the tag pointing at it.
 *
 * Guardrails are unchanged: writes still require GTM_MCP_ENABLE_WRITES and confirm=true, and this
 * file creates nothing a caller could not already create by hand with tags_create + triggers_create
 * + built_in_variables_enable. It removes the guesswork, not the gate.
 */
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import type { GtmClient } from '../utils/gtmClient.js';
export declare function registerTypedBuilderTools(server: McpServer, getClient: () => GtmClient): void;
//# sourceMappingURL=typedBuilders.d.ts.map