UNPKG

@withpica/mcp-server

Version:

MCP Server for withPICA — enables AI assistants to interact with your withPICA music catalog

108 lines • 4.33 kB
/** * Works Tools — MCP tools for managing musical works. * * ADR-174 Phase 2 item 2 reconciliation: the write surface covers only * real columns on `public.works`. Seven phantom fields previously * accepted via `additionalProperties: true` have been removed: * - `label` (no column; recordings/releases store label via org FK) * - `spotify_url` (lives on recordings/releases) * - `album_name`, `album_release_date`, `album_art_url`, `track_number`, * `upc` (all album/release metadata — handled via `pica_releases_*`) * * Five add-candidates surfaced per the audit at * docs/audits/2026-04-14-mcp-db-reconciliation.md §1: * tempo, key, display_artist, published, tunecode. * * Agents that need to set label metadata call `pica_releases_create` * or `pica_releases_update` with `label_organization_id`, resolving * the name via `pica_labels_query` first. */ import { PicaClient } from "@withpica/mcp-sdk"; import { ToolDefinition, ToolExecutor } from "./index.js"; /** * Canonical write-schema for `works`. Every property below must * correspond to a real column on `public.works` — verified against * `lib/db/database.types.ts`. Keep this list tight: reintroducing a * phantom field is the exact regression ADR-174 Phase 2 exists to * prevent. The HTTP route at `app/api/admin/works/[id]/route.ts` * carries a broader allow-list that includes admin-UI-posted satellite * fields; this list is the narrower MCP-agent contract. */ export declare const WORK_WRITE_PROPERTIES: Record<string, Record<string, unknown>>; export declare class WorksTools { private pica; constructor(pica: PicaClient); /** * Get all works tools */ getTools(): Array<{ definition: ToolDefinition; executor: ToolExecutor; }>; /** * Query works — unified search, list, and health filter */ private queryWorks; /** * Inspect work — unified detail view with selectable sections */ /** * Resolve an ISWC to a work id via the works search (which matches ISWC * server-side — see applyWorksFilters). Takes the first EXACT (dash/dot * stripped, case-insensitive) match. Throws EntityNotFoundError (→ NOT_FOUND) * when nothing matches, so inspect surfaces a hard not-found (ADR-198). */ private resolveWorkIdByIswc; /** * pica_works_inspect in a CLIENT's catalogue (ADR-333 PR 1.3). Only the * song's own record opens through a relationship (GET /api/admin/works/:id, * in the safe shape — lib/auth/catalogue-routes.ts); every other section's * route is refused there. So: no sections asked → the record, saying what * is not available; a section asked that is not available → refused, * naming it. Never the all-sections path, which fails each refused section * soft and would answer "success" about a song it never read (D2 Gate 2, * holdout run 38435148161). */ private inspectWorkInClientCatalogue; private inspectWork; /** * Create work */ private createWork; /** * Update work */ private updateWork; /** * Delete work */ private deleteWork; /** * pica_works_verify — writes nothing, and says so. * * It used to PATCH `is_verified: true` onto the work. `works` has no such * column (no applied migration adds one), so the route's allowed-field check * refused it on every call — its only two calls ever both failed (DonnySavv, * feedback 86e26f75, 2026-09-28). PICA keeps no work-level "metadata * verified" flag, and inventing one would record an agreement nobody made. * What a person CAN confirm lives on specific records, each refused to * agents and each done by the person on /inspect — this names them. */ private verifyWork; /** * Bulk delete works */ private bulkDeleteWorks; /** * Bulk reclassify works as live performances + delete source work rows */ private bulkMoveToPerformances; /** * Stamp a human-creation provenance attestation. Wraps the SDK call; * the route handles authUserId → user_profiles.id resolution and the * signature hashing. */ private attestWork; private verifyRegistrations; } //# sourceMappingURL=works.d.ts.map