Official MCP (Model Context Protocol) server for QuoteWerks Web
C
Calvin Thain
started a topic
about 15 hours ago
What I am asking for
An official QuoteWerks-published MCP server for QuoteWerks Web. MCP is an open standard (Anthropic-authored, now supported by Claude, ChatGPT, Copilot, and Cursor) that lets an AI assistant safely call an application's functions. In practice it is a thin layer on top of the existing QuoteWerks Web REST API that exposes named, task-shaped tools: search_documents, get_document, create_document, add_line_item, update_line_item_pricing, list_products, with OAuth scopes controlling who can call what.
The real world situation
We are a managed service provider. I run account management and vCIO work on QuoteWerks Hybrid (Desktop and Web against the same data) with ConnectWise PSA alongside.
Four things eat my day:
Quoting from an inbound email. A client writes "we need 12 more laptops like the ones you sent in March, plus docks." Today: Open QW, then hunt down the March quote to find out what those laptops actually were, then hand key every line on the Document Items tab. With MCP I could ask my assistant to pull the March document, copy the relevant lines into a new quote with updated quantities, then open that draft in QuoteWerks Web and review it. The AI does the rekeying. I keep the judgment.
Quote status without stopping. Answering "where does the Acme quote stand" means switching to QuoteWerks and running a Document Lookup. With MCP I ask in the window I am already in.
Repricing. When distributor cost moves, I open the document and touch each line on the Document Items tab. A tool that reads line items and writes back approved cost and price changes turns fifteen minutes into a review click.
Reporting. Margin and win rate analysis for QBRs currently means writing a script per question. With MCP, the question is the query.
Why the REST API does not already cover this
I know the QuoteWerks Web REST API exists in beta at qwwapi.quotewerks.com. The problem is shape, not access. It is generic table access (GET /api/v1/qw/tables/{table}) plus OData, which is correct for Power BI and Tableau and wrong for an AI assistant. Hand a model a raw table endpoint and it has to guess your schema, guess which table holds line items, and guess field names. It will guess wrong in ways that quietly produce a bad quote. MCP replaces guessing with named tools that have typed inputs and descriptions.
It is also the right place for guardrails: read-only by default, write
tools requiring explicit user confirmation, and scopes tied to the QuoteWerks Web permissions that already exist, so an assistant can never do what the logged in user could not.
Why this fits QuoteWerks
You already added AI-assisted scripting to QuoteWerks Web, where you describe behavior in plain English and it generates the script. That is AI writing code inside the product. MCP is the other half: AI operating the product from where the salesperson already works. The REST API and QuoteWerks Web webhooks are the pieces already built.
If a full server is too much for one release, read-only tools for document search, document and line item retrieval, and product lookup would deliver most of the daily value on their own, with write tools following.
Calvin Thain
What I am asking for
An official QuoteWerks-published MCP server for QuoteWerks Web. MCP is an open standard (Anthropic-authored, now supported by Claude, ChatGPT, Copilot, and Cursor) that lets an AI assistant safely call an application's functions. In practice it is a thin layer on top of the existing QuoteWerks Web REST API that exposes named, task-shaped tools: search_documents, get_document, create_document, add_line_item, update_line_item_pricing, list_products, with OAuth scopes controlling who can call what.
The real world situation
We are a managed service provider. I run account management and vCIO work on QuoteWerks Hybrid (Desktop and Web against the same data) with ConnectWise PSA alongside.
Four things eat my day:
Quoting from an inbound email. A client writes "we need 12 more laptops like the ones you sent in March, plus docks." Today: Open QW, then hunt down the March quote to find out what those laptops actually were, then hand key every line on the Document Items tab. With MCP I could ask my assistant to pull the March document, copy the relevant lines into a new quote with updated quantities, then open that draft in QuoteWerks Web and review it. The AI does the rekeying. I keep the judgment.
Quote status without stopping. Answering "where does the Acme quote stand" means switching to QuoteWerks and running a Document Lookup. With MCP I ask in the window I am already in. Repricing. When distributor cost moves, I open the document and touch each line on the Document Items tab. A tool that reads line items and writes back approved cost and price changes turns fifteen minutes into a review click. Reporting. Margin and win rate analysis for QBRs currently means writing a script per question. With MCP, the question is the query.
Why the REST API does not already cover this
I know the QuoteWerks Web REST API exists in beta at qwwapi.quotewerks.com. The problem is shape, not access. It is generic table access (GET /api/v1/qw/tables/{table}) plus OData, which is correct for Power BI and Tableau and wrong for an AI assistant. Hand a model a raw table endpoint and it has to guess your schema, guess which table holds line items, and guess field names. It will guess wrong in ways that quietly produce a bad quote. MCP replaces guessing with named tools that have typed inputs and descriptions.
It is also the right place for guardrails: read-only by default, write
tools requiring explicit user confirmation, and scopes tied to the QuoteWerks Web permissions that already exist, so an assistant can never do what the logged in user could not.
Why this fits QuoteWerks
You already added AI-assisted scripting to QuoteWerks Web, where you describe behavior in plain English and it generates the script. That is AI writing code inside the product. MCP is the other half: AI operating the product from where the salesperson already works. The REST API and QuoteWerks Web webhooks are the pieces already built.
If a full server is too much for one release, read-only tools for document search, document and line item retrieval, and product lookup would deliver most of the daily value on their own, with write tools following.