/**
 * Hand-authored MCP tool descriptions for Harper operations.
 *
 * Authoring process: each entry was authored by reading the corresponding
 * handler implementation in `OPERATION_FUNCTION_MAP` — its leading JSDoc,
 * its actual behavior (mutations, side effects, RBAC, hazards), and its
 * relationship to sibling operations — and writing a short, verb-led
 * sentence grounded in that code. The path:line citation above each entry
 * points to the handler's declaration so reviewers can verify in one click.
 *
 * Authoring rubric:
 *   1. Verb-led sentence: "Creates …", "Returns …", "Restarts …", "Lists …".
 *   2. Disambiguate from siblings when useful (e.g. search_by_id vs
 *      search_jobs_by_start_date). The LLM uses these to choose tools.
 *   3. One cost/hazard sentence for heavy or destructive calls.
 *   4. ≤ 400 chars per entry. Long descriptions waste context and get
 *      truncated by some MCP clients.
 *   5. No PR/issue references in descriptions — they're shown to LLMs at
 *      tool-selection time, not consumed by human reviewers.
 *
 * Coverage target: every operation matching the v1 DEFAULT_ALLOW glob
 * expansion, plus every destructive operation an operator might opt into
 * via `mcp.operations.allow`. Out-of-core operations (e.g. harper-pro's
 * `cluster_status`) cannot have entries here — their authoritative
 * description belongs alongside their implementation.
 *
 * Transitional status: this catalog is the in-core fill until #878
 * (introspectable operations registry) ships, at which point each
 * operation's description lives with its schema and its handler in one
 * place and this file is retired.
 */
export declare const OPERATION_DESCRIPTIONS: Record<string, string>;
