The ShineCRM MCP server is in development. The capabilities on this page will become available after release. These instructions do not mean that a connection or tool is available today.
Choose the connection’s permissions
An owner will need to accept the connected-agent acknowledgement and enable external access before granting a connection. You will choose a preset or individual permissions. The assistant will see only tools covered by that connection’s grants, and every call will be checked again. Existing connections will keep their existing permissions. They will not gain editing or recurring authority automatically. New permissions in Full operations will apply to future grants. An owner will need to grant any additional authority explicitly.
The identifiers beginning with
service_plans will be tool and permission names for Recurring services. Ordinary document creation permission, documents.write, will not grant invoice or job editing. Reading an estimate before editing it will require estimates.read. Packaged and agreement-linked draft edits will also require service_plans.proposals.write.
Find the existing record first
Your assistant will be able to search across your organization before returning a page of results. It will need to keep following the returned continuation information with the same filters. A missing record on one page will not establish that it does not exist. The planned tools will cover these tasks:- Contact details:
contacts.getwill return the contact, every saved address, the primary address and a revision.contacts.updatewill edit names, company, phone, email and explicit address operations. - Address books: contact updates will add, edit or remove addresses and change the primary address. An address referenced by an existing document will not be removable, including when that document is historical.
- Property searches:
addresses.searchwill search saved addresses and address snapshots on contacts, jobs, estimates and invoices. Each document type will need its own read permission. The result will identify which types were searched. - Requests:
requests.get,requests.searchandrequests.createwill work with contact-based leads. A request ID will be the contact ID. New and unanswered filters will share the existing open lane; handled results will include evidence of handling. Raw message bodies will need their separate message-read permission. - Invoices:
invoices.get,invoices.searchandinvoices.updatewill find, read and edit eligible unpaid invoices. - Jobs:
jobs.get,jobs.searchandjobs.updatewill cover job records, services, prices and permitted scheduling or lifecycle changes. - Booked visits:
visits.get,visits.searchandvisits.updatewill cover job visits and estimate appointments. A booked recurring occurrence will appear once as a job. An unbooked recurring due date will remain part of Recurring services. - Estimates:
estimates.searchwill find estimates by customer, address, number, status, date and stored total.estimates.getwill provide the draft and revision needed before an edit.
Read before every edit
1
Find and read the exact record
Your assistant will use the appropriate search and get tools before proposing a change. It will take the revision from that read, rather than guessing one.
2
Review the intended change and its effects
You will be able to distinguish a notes edit from a price change, appointment change or recurring proposal. Scheduling and lifecycle actions can run the existing automation described below.
3
Save against the revision you read
The assistant will send the exact record ID and revision. A stale revision will produce a conflict instead of silently overwriting another edit.
4
Read and reconcile before retrying
After a conflict or an uncertain response, the assistant will read the record again. It will not automatically repeat an old overwrite. A notification failure after a successful save will not mean the record needs saving again.
contacts.get. Invoice, job and appointment edits will use the returned updated_at. Recurring booking and change proposals will use the revision from service_plans.get.
Omitted invoice and job fields, lines and discounts will be preserved. When supplied, a line list or discount list will replace that complete list. Existing line IDs will need to be retained. A metadata-only invoice edit will not recalculate its prices or taxes.
Creation tools that request an idempotency key will use it for one exact intent. An unchanged retry will reuse that key. A different request will need a different key. After contacts are merged, an original manual-request receipt will retain its history and identify the current contact separately.
Invoice editing and customer checkout
Invoice edits will cover unpaid Draft, Sent, Viewed and Overdue invoices. Paid and cancelled invoices will remain locked. Due dates, notes and other permitted metadata will be editable without repricing unchanged work. A price edit will use the same calculation authority as the app. Existing partial payments, deposits and refunds will remain recorded. An edit will not create a payment, refund, credit or write-off. Before a financial edit replaces an invoice’s checkout terms, ShineCRM will retire older open checkouts at those terms. A payment already submitted or still processing will need a definite outcome before a conflicting edit can finish. An idle checkout tab alone will not reserve the old price indefinitely. Your customer will keep the same invoice portal link. If the price or payment coverage changes while they are reviewing it, they will need to review the current payment details before proceeding. A due-date or notes edit will not unnecessarily retire checkout.Jobs, appointments and automation
Job price edits will require an eligible unpaid job with no live invoice or payment/deposit allocation. They will preserve source links, recurring relationships and recorded work timing. Scheduling or lifecycle changes will need to be made separately from price or address edits. The appointment tools will allow permitted schedule and notes changes, completion, cancellation and reopening of cancelled work. They will not move a job directly into En route or In progress, undo completed or paid work, or edit payroll and timekeeping records. Financial or source-document conflicts will prevent an unsafe transition. Changing one booked recurring visit will not change the standing recurrence. Reopening cancelled work will not silently restore cancelled reminders. A repeated completion using an old revision will be refused.Recurring services and proposals
service_plans.get and service_plans.search will read accepted recurring terms, item identities and booked-job context. service_plans.create_job will book work from active accepted terms at an explicit time.
The first job will use the full accepted source estimate, including its other accepted lines and linked recurring services. Later bookings will be able to select the applicable recurring items. A later one-off visit will not advance the normal cadence. Booking will not accept a proposal or charge a payment.
Initial recurring and packaged proposals will be prepared as estimate drafts. service_plans.propose_change will prepare a draft linked to the selected existing recurring service. The assistant will need to keep the selected service and line identities clear when similar services exist more than once.
Creating or editing these drafts will not activate terms. The existing customer acceptance flow will remain responsible for that. Previously booked work, visit history and payment records will remain intact. Review any returned discount warnings and the full proposal before using a separate send or acceptance flow.
Reports and money permissions
The read-only financial report tool will use ShineCRM’s existing report calculations. It will support recorded revenue, refunds and tips, tax, estimate conversion, period comparisons and supported breakdowns by service or customer. Historical invoice aging and recurring-revenue classification will be reported as unavailable where the records cannot support them. The owner-onlypayments.write permission will allow invoices.record_payment to record money already received outside ShineCRM, such as cash or an e-transfer. It will not charge a card. Settling an invoice this way may send the standard customer receipt through the existing flow. A payment recorded automatically by a card provider must not be entered again.
Assigning a crew and vehicle
The planned job-assignment tools will let a connected assistant find your active team members and vehicles, read a job’s current assignments, and change them together. You will grant Assign job crew and vehicles separately. Existing connections will not gain this permission automatically. The assistant will be able to assign a crew and vehicle after creating a job or converting an accepted estimate. If someone changes the assignments while the assistant is working, it will need to read them again before saving. Newly assigned teammates with a login may receive their usual notifications according to their preferences. A notification problem will leave the assignment saved. Prices, invoices, payments and recorded work will stay unchanged.Customer communications
Record editing and recurring proposals will not add a custom email or document-send operation. A request to edit, prepare or follow up will not constitute approval to send an email. Before asking an assistant to send an email on your behalf, approve the exact subject and body and every To, Cc and Bcc recipient. Customer SMS will retain separatecommunications.sms_batch.prepare and communications.sms_batch.approve_and_queue permissions. Neither will be included in a preset. An owner will need to grant them explicitly through the connection’s authorization flow.
Preparing a batch will create an immutable proposal for no more than 10 exact recipients and message bodies. The assistant will need to show every recipient and complete body in chat. Nothing will be queued until a separate owner-authorized approve-and-queue call approves that unchanged proposal.
Approval will need to happen within 10 minutes of preparation. An approved batch may then wait through quiet hours and safety pacing. Before each send, ShineCRM will recheck authorization, recipient eligibility, consent, opt-outs and its existing messaging safeguards. Messages will count toward your organization’s usage.