# MCP Example Workflows These prompts are starting points. Replace names, dates, entities and workspaces with the client context you are reviewing. {% hint style="info" %} **Tip:** Default to read-only. When a workflow writes data, ask for a preview first and confirm before applying. The prompts in this article are phrased that way; keep that pattern when adapting them. {% endhint %}
Find the right client context > List the Kick workspaces I can access. Help me identify the workspace for Acme LLC, then confirm the workspace id before using any other tools. Use this when you are switching between clients or checking whether the assistant is using the right workspace.
Plan your day across clients > List the workspaces I can access, then summarize what needs attention in each: uncategorized counts, unmatched transfers, unreconciled opening balances, and items with no recent activity. Order by close-blocking impact for the period ending \[date]. Use this as a morning standup or a Sunday-night look-ahead across your full client roster. For a focused triage view: > Across all my workspaces, which clients are at risk of missing close this month? Show the workspace, the uncategorized count, the unmatched-transfer count, and the date of the most recent meaningful change.
Review transactions that need attention > In the active workspace, find January transactions that need bookkeeping review. Limit the first result to 25 rows. Group your summary by likely follow-up: missing category, unclear counterparty, possible transfer, or needs client context. Ask for source data before acting: > For each item, include the transaction id, date, amount, counterparty, and bank description.
Pull reports for review > Pull the January P\&L for entity 123 on a cash basis. Summarize the largest expense categories and list three questions I should ask the client. For a deeper review: > Compare the January P\&L, balance sheet, and trial balance for entity 123. Point out accounts that changed materially from the previous month and include the report source for each observation.
Inspect activity before changing anything > Show recent activity related to transaction category changes. Summarize who made the changes, when they happened, and whether any batch looks worth reviewing before close. Use this before approving a close, reviewing a catch-up file, or investigating unexpected report changes.
Unwind a change after review When activity inspection turns up a batch you want to roll back, ask for a preview before reverting: > Pull the activity log for the bulk update on \[date] that touched \[count] transactions. Show what changed for each — the before and after state. Then prepare to revert that batch and stop before applying. I will confirm. For a single transaction: > Show the full edit history for transaction \[id]. List every change with the user, timestamp, and the previous and new values for each field.
Run a period-end sweep A sweep stitches together close-prep checks into a single read-only pass: > For \[workspace] and the period \[start] through \[end], list: every uncategorized transaction, every unmatched transfer, every transaction over \[threshold] without a memo, and any vendor that first appeared this period. Group the results and include source ids. To reconcile against an external source: > Compare the opening balances in \[workspace] against the attached trial balance. List every account where the balances diverge, with both values shown side by side. Do not change any data.
Audit and tune the Chart of Accounts Start with usage before making changes: > In the active workspace, list each account and category with the number of transactions posted to it in the last ninety days. Flag entries with zero recent usage and note whether each looks safe to disable. For a structural change, request a preview before any write: > Prepare to create a new Long-Term Liability account named \[account name] and reclassify the historical loan transactions for \[counterparty] into it. Show the count of affected transactions, the date range, and the proposed account hierarchy. Stop before writing.
Clean up counterparties and classes Identify duplicates and underused entries before merging or retiring: > List counterparties in the active workspace that look like duplicates of \[name]. Show the variants, the transaction count for each, and the merge target you would pick. Do not merge yet. > Which classes have fewer than five transactions this year? List each with its transaction count and propose which ones to retire. Once you have reviewed the proposal, authorize the merge: > Prepare to merge the counterparty variants you listed above into a single counterparty named \[target]. Show the final transaction count and stop before confirming.
Build and tune rules Preview what a new rule would match before creating it: > I want a rule that categorizes \[vendor] payouts as \[category] and assigns class = \[class]. Show me which existing transactions would have matched if this rule had been in place. Stop before creating the rule. Audit existing rules for staleness: > List my existing rules with the date each one last fired. Flag any that have not fired in the last six months and check whether the underlying patterns still appear in recent transactions.
Draft journal entries from source documents A high-leverage MCP workflow is handing the assistant a document — payroll register, closing statement, amortization schedule, or complex bill — and asking it to draft the journal entry. Always have it draft, never post directly from a document. > Read the attached payroll register and draft the journal entries for the period: split gross wages, employer taxes, employer benefits, and net pay across the appropriate accounts. Show the full proposed entry with debits, credits, and the underlying line items. Stop before posting. > Here is a closing statement for a property purchase. Identify each line item, propose how it should be allocated across asset, expense, and liability accounts, and present the proposed journal entry for review. Do not post until I confirm. > Take the attached loan amortization schedule and propose the next twelve monthly journal entries splitting principal and interest. List them in order with running balances. Stop before posting. For a known one-line entry, you can authorize a direct post: > Post a journal entry dated \[date]: debit \[Account] \[amount],credit\[Account]\[amount], memo \[text]. Confirm the post in your reply. To audit posted entries: > List every manual journal entry posted to \[Account] this year. Show date, amount, memo, and the user who posted each.
Stage a new client setup Onboarding involves writes — entities, addresses, ledgers, Chart of Accounts copy, and opening balances. Stage each step as a preview before confirming. > Prepare to set up a new entity called \[entity name] in \[state]. List the steps you will run — entity creation, address, tax locations, ledger setup, Chart of Accounts copy from \[source workspace], and opening-balance staging from the attached trial balance — and stop before executing. I will confirm each step before you run it. For comparing existing client structures (read-only): > Compare the Charts of Accounts across the workspaces I can access. List accounts that exist in only one workspace and accounts that exist in all of them. Do not modify anything.
Prepare client follow-up > Review the open transaction questions and draft a client-friendly message. Do not change any Kick data. Include transaction dates, amounts, and short context for each question. This is a strong read-only workflow: the assistant gathers context while the accountant stays in control of the client message.
Preview supported write actions Some write tools return a confirmation preview before they change data. Ask the assistant to stop at the preview: > Prepare a preview for the supported correction, then stop. Do not confirm the action until I approve the exact change. Only confirm after you review the workspace, resource ids, dates, amounts, and intended change.
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.kick.co/ai/kick-mcp/mcp-use-case-library/mcp-example-workflows.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.