/**
 * Availability filtering utilities.
 *
 * IMPORTANT ARCHITECTURAL NOTE:
 * Availability filtering is a **registry-level** concern, evaluated at boot time
 * against the process's runtime context (OS, runtime, deployment mode, NODE_ENV).
 *
 * This is fundamentally different from:
 * - **Authorization/auth** — request-scoped, evaluated per-session in HTTP flows
 * - **Rule-based filtering** — dynamic, policy-driven, evaluated at request time
 * - **hideFromDiscovery** — a soft hide from listing; the entry is still callable
 *
 * `availableWhen` is a hard constraint: if the runtime context doesn't match,
 * the entry is excluded from both discovery AND execution. It runs once at
 * registry initialization (boot) and the result is effectively frozen for the
 * lifetime of the process — the OS, runtime, and deployment mode don't change.
 */
import { type EntryAvailability } from '@frontmcp/utils';
import type { FrontMcpLogger } from '../interfaces/logger.interface';
/**
 * Log availability filtering results for a set of entries at registry boot time.
 *
 * Called once per registry during `initialize()` → `reindex()` cycle.
 * Produces:
 *   - info:    summary line "X/Y entries available (Z filtered by availableWhen)"
 *   - verbose: per-entry detail for filtered entries
 *   - warn:    entries with empty constraint arrays (always filtered, likely a bug)
 *
 * @param registryKind - e.g. 'ToolRegistry', 'ResourceRegistry'
 * @param entries - all entries (local + adopted) with their metadata
 * @param logger - scoped logger
 */
export declare function logAvailabilityFiltering<T extends {
    name: string;
    metadata: {
        availableWhen?: EntryAvailability;
    };
}>(registryKind: string, entries: readonly T[], logger: FrontMcpLogger): void;
//# sourceMappingURL=availability.utils.d.ts.map