Most of your software lives in its own world. You log in, do the work, log out. Change tabs, context switch, lose your place, get distracted and eventually remember where you left off.
If you want information from another tool, you copy and paste it across. If you want two platforms to talk to each other, you wait for them to build an integration, pay for a Zapier connection, or do it by hand.
That model is rapidly changing thanks to AI.
And the new Ignition MCP is one of the clearest examples yet of what comes next.
What Is an MCP?
MCP stands for Model Context Protocol. It is an open standard, introduced by Anthropic, that lets AI assistants connect directly to software platforms.
Think of it this way. Claude, or any AI assistant built on MCP, can read from and write to a platform in real time using natural language. No copy-paste. No switching tabs. No exporting data so the AI can see it.
When a platform builds an MCP server, it is essentially giving Claude a direct line into its data and functionality. Claude can ask Ignition what proposals exist, what services are in the library, what a client's status is, and then act on that information — all without the user touching the Ignition interface.
The MCP standard is open, which means any software company can build one. Ignition has. And the implications for proposal workflows are significant.
Why Proposal Work Is a Good Test Case
Proposals are time-intensive because they are context-intensive. A good proposal requires knowing what was discussed in the discovery call, what the client's situation is, how similar engagements have been scoped and priced, and how to write an intro that actually converts.
That knowledge typically lives across three or four places: a meeting recording, a CRM, a previous proposal, and someone's memory. Pulling it together manually is exactly the kind of work that slows firms down and creates inconsistency in how proposals get written and sent.
This is the problem the Ignition MCP, paired with an AI meeting tool like Vinyl, is designed to dissolve.
What It Looks Like in Practice
The session that demonstrated this started with a discovery call transcript and ended with two completed, personalised draft proposals in Ignition. The time taken was under four minutes.
Here is what Claude actually did across that workflow.
Read the practice data. Claude pulled the practice information directly from Ignition, listed all 20 recent proposals and their statuses, and catalogued the full service library — more than 50 services — without any manual navigation.
Analysed the discovery call. Using Vinyl, Claude read the full transcript from the discovery call. It identified the scope, the client's situation, pricing signals, and campaign angles, then mapped that conversation to a concrete proposal structure.
Handled the client and contact work. Claude looked up the relevant client, confirmed the email address was already in the system, and resolved a duplicate record to identify the correct active client to use.
Built the proposals. Two drafts were created directly in Ignition. The primary proposal, was structured as a GTM Pilot Campaign with a three-month minimum, auto-expiry turned off, the correct email template and terms attached, and a fully personalised intro message written and loaded in.
Applied pricing intelligence. Claude cross-referenced a lost proposal and an accepted proposal to inform its recommendation. It revised the scope from $28,800 down to $22,000 to better fit the pilot framing and EOFY context, and flagged a missing service — a Marketing List — that the original scope had overlooked.
All of that happened through a conversation with Claude. No manual data entry. No tab switching. No reformatting.
How to Think About This for Your Firm
The Ignition MCP is in beta. Most firms will need to wait for the broader release before connecting it to their stack. But the workflow it enables is worth understanding now, because it changes how you should think about the tools you already use upstream.
The quality of the output depends on the quality of the input. Claude can only work with what it can read. If the discovery call was captured clearly by a tool like Vinyl, the proposal will reflect that. If the discovery call was vague, or never recorded, the AI has nothing to work from. Structured discovery conversations become more valuable, not less, as this kind of tooling matures.
The MCP layer is broader than Ignition. As more platforms build MCP servers — practice management systems, CRMs, document tools — the manual handoffs between them become optional. Proposal software, billing, and client management can start operating as a connected environment rather than a collection of separate logins. Ignition is one piece of that picture.
The human role shifts, not disappears. What Claude produced in this session were drafts. A practitioner still reviewed the pricing rationale, confirmed the scope, and would send the proposal. The difference is that the groundwork, the reading, the cross-referencing, the writing, was done in minutes rather than the better part of an hour.
What Comes Next
The Ignition MCP is one of the first purpose-built integrations of this kind for accounting and bookkeeping software. It will not be the last.
Firms that understand how MCPs work, and start building workflows around them, will have a structural advantage as more platforms open up this layer. The concept is straightforward: the AI reads your tools, reasons across them, and acts on your behalf. The hard part is knowing which problems are worth pointing it at.
Proposal creation, as this session showed, is a strong place to start.
So here is the question worth sitting with: if the research, the cross-referencing, the writing, and the data entry can all happen in under four minutes, what is the real cost of doing it manually?
The Ignition MCP is currently in private beta. If you want early access, reach out to your Ignition account manager to get on the waitlist.
