"Using a CRM System for Work" matching MCP tools:

• create_custody_event

  connect

  Record a consignment or loan: a work moves physically to a gallery, dealer, museum, or other holder without ownership changing. Use kind=consignment when the work is placed with a gallery or dealer for potential sale (typically with commission and asking price). Use kind=loan for exhibition loans, museum loans, or private loans without sale intent. TRIGGER: "I just consigned this to Pace," "on loan to the Whitney," "sent to Gagosian for the summer," "loaned to a private collector." Present a summary (work, holder, kind, dates, plus commission and price for consignments) and confirm before saving. Consignments support exclusivity. Only one active exclusive consignment per work is allowed; concurrent attempts return HTTP 409 with the blocking event in details.blocking_event. Does NOT trigger pending_resignature. Custody lives on a separate timeline from the signed record, so recording a consignment or loan does not invalidate the existing VC. Resolve work_id via search_works. Never ask the user for the UUID.

  Connector

• list_custody_events

  connect

  List the custody timeline for a work: consignments and loans where the work is physically held by someone other than the owner. Separate from provenance (ownership history) and exhibitions (public display history). TRIGGER: "is this on consignment," "where is the work physically," "who has it now," "show consignment history," "show loan history." Returns events in reverse chronological order (newest start_date first) with kind, status, holder, dates, prices, commission, exclusivity. Resolve work_id via search_works. Never ask the user for the UUID.

  Connector

• get_work

  connect

  Get full details for a work including images, provenance, exhibitions, and bibliography. TRIGGER: "show me," "tell me about," "pull up," "can I see," "let me see," "how does it look," or any reference to a specific work by title. Resolve work_id via search_works — never ask the user. When presenting: describe the image first, then summarize data naturally — do not dump raw fields.

  Connector

• em_apply_to_task

  Execution Market

  Apply to work on a published task. Workers can browse available tasks and apply to work on them. The agent who published the task will review applications and assign the task to a chosen worker. Requirements: - Worker must be registered in the system - Task must be in 'published' status - Worker must meet minimum reputation requirements - Worker cannot have already applied to this task Args: params (ApplyToTaskInput): Validated input parameters containing: - task_id (str): UUID of the task to apply for - executor_id (str): Your executor ID - message (str): Optional message to the agent explaining qualifications Returns: str: Confirmation of application or error message. Status Flow: Task remains 'published' until agent assigns it. Worker's application goes into 'pending' status.

  Connector

• escalate_with_context

  VaultCrux Memory Core

  Contextual escalation — packages your full reasoning state (evidence gathered, options considered, recommended action) and routes to a human for review. Preserves work so the human responds with full context, not from scratch. Use when you hit genuine uncertainty that the system cannot evaluate.

  Connector

• link_work_to_bibliography

  connect

  Associate a work with a bibliography entry — recording that a specific publication references or illustrates this work. Include page reference, plate number, or illustration details if available. Never ask the user for UUIDs — resolve work_id via search_works, and bibliography_id from the create_bibliography response. Side effect: if the work is signed, this puts it in `pending_resignature` — the authenticator must re-confirm in Raisonnai before a new VC issues. Tell the user. After success, ask if they'd like to see the updated work. Then call get_work to show the visual card.

  Connector

• em_apply_to_task

  execution-market-mcp

  Apply to work on a published task. Workers can browse available tasks and apply to work on them. The agent who published the task will review applications and assign the task to a chosen worker. Requirements: - Worker must be registered in the system - Task must be in 'published' status - Worker must meet minimum reputation requirements - Worker cannot have already applied to this task Args: params (ApplyToTaskInput): Validated input parameters containing: - task_id (str): UUID of the task to apply for - executor_id (str): Your executor ID - message (str): Optional message to the agent explaining qualifications Returns: str: Confirmation of application or error message. Status Flow: Task remains 'published' until agent assigns it. Worker's application goes into 'pending' status.

  Connector

• condition_reports

  connect

  A work's condition reports (physical state — surface, structure, frame). action "list": all condition reports for a work — read-only. TRIGGER: "what's the condition of," "any damage on," "condition history for." action "create": document a work's physical state — write. TRIGGER: "this piece has damage," "the surface is," "frame is cracked," "condition report." Gather details conversationally; present a summary and confirm before saving. Side effect: if the work is signed, this puts it in pending re-authentication — the authenticator must re-confirm in Raisonnai before a new VC issues; tell the user. After success, offer to show the updated work via get_work. Resolve work_id via search_works — never ask the user.

  Connector

• request_revision

  Human Pages

  Request changes on submitted work (job must be SUBMITTED). Moves job back to ACCEPTED so the human can resubmit. Include a clear reason explaining what needs fixing. The human receives a notification. Use approve_completion instead if the work is satisfactory.

  Connector

• authenticate

  marketplace

  Authenticate this MCP session with your BopMarket API key. Call this once before using cart, checkout, price watch, order, or listing tools. Read-only tools (search, get_product, batch_compare, get_categories) work without auth. Buyer keys: sk_buy_*. Seller keys: sk_sell_*.

  Connector

• create_works_batch

  connect

  Create multiple artworks at once (up to 50) — batch create / catalogue / add / import several works into the catalogue or inventory in one call. TRIGGER: user pastes a list or describes multiple works — "I have a bunch of works," "here's my inventory," "add these," "catalogue all of these." For a SINGLE work use create_work. Extract all you can per work — title, date, medium, extent, edition, authentication marker, series. Present a summary and wait for confirmation. If the user has a CSV or spreadsheet file, direct them to raisonn.ai/import instead. artist_id from get_profile — never ask the user. Per-work typed Identity Eight is identical to create_work: populate medium_category, extent_type/extent_value, edition_status, authentication_marker_type/value per work (each field's description carries its variants + per-category label; ask with the medium-appropriate label, never a generic "signature"). Image uploads separately via get_upload_url. `unsigned`/`none` are valid positive marker values. After success, ask if they'd like to see any of the works. Then call get_work to show the visual card.

  Connector

• save_provenance

  connect

  Save confirmed provenance entries to a work. WRITE operation — NEVER call without user confirmation. Call parse_provenance first to parse text, present results for review, then use this tool to save. Set source to "ai_parsed" for parsed entries, "manual" for user-provided. Side effect: if the work is signed, this puts it in `pending_resignature` — the authenticator must re-confirm in Raisonnai before a new VC issues. Tell the user. After success, ask if they'd like to see the provenance timeline. Then call get_provenance_visual. Also offer to show the updated work card via get_work.

  Connector

• tables_list

  runik-ai

  List all available tables in the business system

  Connector

• approve_completion

  Human Pages

  Approve submitted work for a SUBMITTED job. IMPORTANT: Confirm with the user before approving — this finalizes the job. Call this after reviewing the human's deliverables (check via get_job_messages). Moves the job to COMPLETED. After approval, use leave_review to rate the human. If the work needs changes, use request_revision instead.

  Connector

• prompts_update

  dialogbrain

  Update a prompt template's name, system instructions, or auto-reply rules. Changes affect every agent using this template, unless the agent has its own override (set via agents.update → prompt_text). All parameters except prompt_id are optional — only provided fields are updated.

  Connector

• calculate_inverter_size

  VoltPlan Wiring Diagrams

  Calculate the recommended inverter size for running AC loads from a DC battery system. Accounts for continuous power, startup surge power (motors typically surge 2-3x), and includes a 25% headroom for the continuous rating. Returns the recommended inverter wattage and the DC current draw at system voltage.

  Connector

• update_account_rights_defaults

  connect

  Patch the artist's account-level declared-rights defaults — applied to every future signing event when the work doesn't carry a per-work override. Four V1.1 claim families per Architectural Invariant 7: AIPREF (AI usage), IPTC PLUS (reproduction rights), attribution (Berne Art. 6bis framing), and the ARR collecting-society pointer. IMPORTANT: this does NOT mutate already-signed RAIs. Existing signed credentials remain valid; the new defaults apply on the next signing event for each work. Per-work overrides (set via update_work) win over account defaults. TRIGGER: "set my AI defaults," "default to no AI training," "set my credit line," "I'm a member of [collecting society]."

  Connector

• bulk_export

  Boolsai Directory

  Paginated bulk export of indexed sites matching a filter. Returns up to 1000 rows per page in CSV or JSONL format with a cursor for continued pages. Use this when an agency needs an outbound prospect list (e.g. all sites using Klaviyo in the US) for CRM import. The full row count is also returned so you can size the export.

  Connector

• book_appointment

  Dashform MCP Server

  Submit a lead's information to request an appointment. Provide answers keyed by question keys from get_form_questions. Creates a reply record visible in the dashboard and triggers connected integrations (CRM, email, webhooks). Also accepts legacy lead object for backwards compatibility.

  Connector

• consignment_requests

  connect

  The Requestor→Authenticator consignment pull-protocol. Consignment is a CUSTODY transfer, not ownership — approval creates a custody_event, never a provenance entry. action "create": submit a request for a specific work (Requestor side) — write. TRIGGER: "ask [artist] to consign [work]," "request a consignment of [work]." The target work must already exist (resolve via search_works). action "list": the Authenticator's incoming requests (pending/approved/declined/expired/cancelled) — read-only. TRIGGER: "show consignment requests," "consignment inbox." `count_only` returns just the pending count. action "respond": approve (mints an active custody_event using proposed terms unless overridden) or decline (closes it) — write; confirm with the user first. Find request_id via action "list" — never ask the user.

  Connector