/**
 * GTM's type vocabulary, so the chat can ANSWER questions about it instead of guessing.
 *
 * Why this is a tool and not prose in a description: the catalogue is long, and a tool description
 * is paid for on every single request whether or not anybody asks about tag types. As a tool it
 * costs nothing until the question is actually asked.
 *
 * PROVENANCE, because the three lists have very different standing:
 *
 *   Trigger types        OFFICIAL. Google publishes this as an enum on the Trigger resource, and
 *                        the list below is that enum in full.
 *   Built-in variables   OFFICIAL. Also a published enum; the server already carries it in
 *                        builtInVariables.ts, which stays the single source of truth.
 *   Tag + variable types NOT PUBLISHED. `Tag.type` and `Variable.type` are free strings in the API,
 *                        and Google documents the human names ("Lookup Table") without ever naming
 *                        the code that goes over the wire ("smm"). Blog posts that fill the gap
 *                        contradict each other, so every code below was decoded from the parameter
 *                        keys real containers carry, which identify a type unambiguously: a Lookup
 *                        Table has `input` + `map`, a RegEx Table has `fullMatch` + `ignoreCase`,
 *                        a Bing UET tag has `uetqName`. Where a code is uncertain it says so rather
 *                        than guessing.
 *
 * Keep entries free of em dashes: this text is written to be relayed to users verbatim.
 */
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
/**
 * Finds gallery templates by name.
 *
 * Ranked rather than filtered, because the useful answer to "hotjar" is the template actually called
 * Hotjar, not the first of nine alphabetically. Exact name beats prefix beats substring, and an
 * owner match is kept last so searching a vendor name still finds their templates.
 */
export declare function searchGallery(query: string, limit?: number): {
    name: string;
    owner: string;
}[];
export interface TypeEntry {
    /** The exact string the API expects. */
    code: string;
    /** What it is called in the GTM interface. */
    name: string;
    /** Where it applies, and anything that trips people up. */
    note?: string;
}
/**
 * Tag types.
 *
 * `web` runs in a browser container, `server` in a server container, `legacy` still resolves but
 * is no longer the way to build anything new.
 */
export declare const TAG_TYPES: Record<'web' | 'server' | 'legacy', TypeEntry[]>;
/**
 * Trigger types, the complete published enum from the Trigger resource.
 *
 * CASING MATTERS AND CHANGES BY CONTEXT: the live API uses these camelCase strings, while an
 * exported container JSON writes the same values as UPPER_SNAKE (customEvent becomes CUSTOM_EVENT).
 * Reading a type off an export and posting it to the API is a real and easy mistake.
 */
export declare const TRIGGER_TYPES: Record<'web' | 'server' | 'amp' | 'mobile', TypeEntry[]>;
/** User-defined variable types. Codes decoded from the parameter keys real containers carry. */
export declare const VARIABLE_TYPES: TypeEntry[];
/**
 * The Community Template Gallery, by category.
 *
 * Not an exhaustive index: the gallery has well over a thousand templates and changes constantly,
 * so freezing a full copy here would be wrong within a week. What this gives is the SHAPE, which is
 * what a question like "can you add Hotjar" actually needs: the category exists, it is reachable by
 * templates_import_from_gallery, and here is the owner/repository where it is known.
 *
 * The honest rule for anything not listed: the answer is still yes, but the exact owner/repository
 * has to be read off the template's page in the gallery, because guessing it returns a bare 404.
 */
export declare const GALLERY_CATEGORIES: {
    category: string;
    examples: string[];
    known?: Record<string, string>;
}[];
/**
 * Vendors GTM ships a NATIVE tag template for, from Google's published "Supported tags" list.
 *
 * Names only, deliberately. Google documents that these vendors are built in but never publishes
 * the type code that goes over the wire for each, and no reliable third-party list exists either:
 * a search for them returns pages that contradict each other. Recording a guessed code would be
 * worse than recording nothing, because a wrong code is accepted by the API and then renders in GTM
 * as an unrecognised tag, so the failure is silent.
 *
 * The useful thing to say is therefore "GTM has this built in, read the exact code off the
 * container", which is what identifyTagType does.
 */
export declare const NATIVE_TEMPLATES: {
    name: string;
    code?: string;
}[];
/** Kept for callers that only want the names. */
export declare const NATIVE_VENDORS: string[];
/**
 * Looks a native template up by the name GTM shows in its tag picker.
 *
 * Returns the code when one is confirmed and `null` for it otherwise, which is the point: the
 * caller learns that GTM does have this template AND that its code has to come from the container
 * rather than from here.
 */
export declare function findNativeTemplate(name: string): {
    name: string;
    code: string | null;
} | null;
/**
 * Reports the SHAPE of a custom-template code, which is all a code alone can honestly tell you.
 *
 *   cvt_MRQN8        gallery:          the gallery's own id, short and alphanumeric
 *   cvt_1234567_12   container-scoped: containerId + templateId, both numeric
 *
 * The numeric pair used to be reported as 'local', meaning authored in this container. That was
 * wrong: GTM assigns a container-scoped id to gallery IMPORTS too, and in the export corpus the
 * overwhelming majority of numeric-pair codes belong to templates that carry a galleryReference.
 * Calling one of those home-grown told auditors a vendor template had no publisher and no upstream
 * version, which is exactly the misleading verdict this file exists to avoid. The shape is still
 * worth reporting, but only as a shape: origin has to come from the template's galleryReference.
 *
 * Anything that is not clearly the numeric pair still falls back to gallery, because a gallery id
 * could in principle contain an underscore and sending someone hunting for source code that does
 * not exist is the more expensive mistake.
 */
export declare function customTemplateOrigin(code: string): 'gallery' | 'container-scoped';
/**
 * Names a tag type seen in a container.
 *
 * Three outcomes, and keeping them distinct is the whole point: a known built-in code is named
 * outright; a cvt_ code is reported as a custom or gallery template with the lookup that resolves
 * it; and anything else is reported as UNKNOWN rather than guessed at. An audit that invents a
 * vendor name is worse than one that admits it does not recognise a code.
 */
export declare function identifyTagType(type: string): {
    code: string;
    name: string;
    known: boolean;
    scope?: 'web' | 'server' | 'legacy';
    origin?: 'gallery' | 'container-scoped';
    howToResolve?: string;
};
/** Resolves a custom-template NAME against the gallery index, to name its publisher. */
export declare function identifyGalleryTemplate(templateName: string): {
    name: string;
    owner: string;
} | null;
export declare function registerReferenceTools(server: McpServer): void;
//# sourceMappingURL=reference.d.ts.map