An engineer walks out of a discovery meeting with a page of notes. Those notes capture what the customer wants. Turning them into a scope still means matching each requirement to the services your business delivers and estimating it the way your team does.
By connecting Claude to ScopeStack via MCP, the assistant handles the heavy lifting of project assembly, like constructing the scope using your company's predefined services, delivery phases, and labor rates, while assisting in the review process. In this webinar, Jon Scott, former solution architect and CEO of ScopeStack, explores why an AI-generated statement of work relies entirely on the quality of the organizational data and operational standards available to the assistant. He also demonstrates how ScopeStack’s MCP integration helps you elevate the quality and consistency of your team’s SOWs.
Discovery notes rarely explain how your business estimates or delivers the work they describe, and that information is what turns a description into a scope. To build something you could send through approval, an assistant also needs:
Without that context, an assistant can still write convincing scope language. A general-purpose model is often right about which services belong in a network project. Discrepancies often arise in estimating level of effort, such as allocating 40 hours for tasks your team finishes in eight.
This can create significant operational hurdles for teams. If every engineer supplies their own context, every engineer gets their own answer. Two solution architects with the same notes and the same prompt will produce different scopes when nothing ties the assistant to company standards.
ScopeStack holds that structure (services, effort logic, rates, and phases) in a form an assistant can query. The engineer still decides whether a standard fits the opportunity, but everyone starts from the same baseline.
Model Context Protocol (MCP) is an open standard that lets compatible AI applications use tools and data exposed by other systems. When Anthropic open-sourced the Model Context Protocol in November 2024, it described the problem MCP addresses: "Every new data source requires its own custom implementation, making truly connected systems difficult to scale."
ScopeStack's MCP server solves that problem for scoping. It offers a set of tools that Claude can discover and call, so the assistant works inside ScopeStack instead of producing a document in a chat window. Claude asks permission before it uses the ScopeStack tools, and a quick identity check confirms it's connected to the right authenticated account.
Learn more: AI Agents for Professional Services: How MCP Is Changing Scoping
As Claude reads your discovery notes, it looks up what a solution architect would normally gather by hand, like rate cards, your standard phase methodology, existing services, level-of-effort assumptions, and past project records. None of it has to be pasted into the prompt. By the time you submit your request, the assistant can already reach the data it needs to build the scope.
This integration also enables Claude to take direct action. After receiving access to project items, it generates the project record and inserts services, allowing you to observe the project build in ScopeStack in real time. You can review the ScopeStack MCP setup guide for instructions on linking Claude alongside other supported tools.
Data updates seamlessly in reverse as well. Modifying the project within ScopeStack ensures the assistant reflects those updates during its next query, as every request fetches live project data via the API.
The assistant relies entirely on the provided input, whether you supply call transcripts or informal post-meeting notes. To get the best results, state your requirements explicitly and prepare to address unresolved questions directly rather than relying on guesswork.
Construct a new ScopeStack project using standard services and established scope language wherever appropriate, clearly identifying any custom elements that require creation. Since standard catalog items rarely cover every project requirement, these custom additions must be highlighted for approval.
Requesting exceptions upfront provides a roadmap. A first draft is only efficient if it clearly distinguishes standard, repeatable tasks from novel commitments requiring careful evaluation.
Claude builds the project in your plan, design, and implement phases, with resources assigned from your rate table. For example, a fictional healthcare facility’s scoping data could shape the result in a few visible ways:
Unlike a narrative draft, the services, quantities, and estimates now live in ScopeStack, where your team can inspect each line and change it.
Expect the first pass to stop short of done. A good assistant says so and returns a short list of decisions only you can make. From there, Claude can draft two pieces of narrative:
Treat both as drafts. Expect to tighten the language, and you decide what belongs in the project and whether the wording reflects the opportunity.
Even when a project appears fully populated, it often remains far from complete. Supporting this view, the Thomson Reuters Institute notes in its 2026 AI in Professional Services Report—based on input from legal, tax, risk, and government experts—that human-validated checkpoints are critical components of any effective agentic AI workflow.
A work breakdown can contain the right services and reasonable effort and still be missing the language that defines each service for the customer. ScopeStack's MCP includes a scope checker that rates a project after it's created, with general checks such as whether the language is complete and whether the project is profitable.
In the webinar’s example project, the checker found the work breakdown in place but most of the service language missing. One request to fix it, and Claude filled in the language before the document was generated.
During a subsequent human review, more nuanced discrepancies can surface. For example, if the catalog text tied to the design session explicitly designated a network assessment as out of scope, despite its active inclusion in the project scope.
Standardized language makes this kind of conflict predictable, because an exclusion written for one engagement gets reused on another where it no longer applies. It's one of the most common questions engineers raise: what happens when something listed as out of scope is actually in scope? Approved language is the starting point, and each project determines which parts of it stay. Catching the conflict before the customer sees it keeps the SOW from contradicting the work you've priced.
For many reviewers, the first check is the bill of materials. If the hardware quote has 10 switches, does the scope account for 10? Gaps between what's being sold and what's being scoped are a steady source of review feedback.
You can ask the assistant to audit the scope against the discovery notes and flag data inconsistencies. A hardware-quantity check only works once the bill of materials is connected, so hand that check off when the data is available, and verify the result yourself.
The engineer resolves open decisions, validates the scope, and sends it through the company's approval process. To sharpen that review, pair the MCP with a prompt or skill that plays devil's advocate before the scope goes for approval, questioning what's weak and asking what you still need to think through.
AI gives the reviewer a better starting point. Your team still owns every commitment in the SOW.
For a services leader, the question changes from how fast one engineer can scope to whether the whole team is selling the same thing.
Picture two reps leaving client meetings, opening a general-purpose AI assistant, entering roughly the same prompt, and pasting whatever comes back into their own templates. Each scope carries its own assumptions, and variability creeps into what the business sells.
When the assistant works from a shared catalog of standard services, effort assumptions, and rates, scopes for similar projects start from the same place. Engineers still adjust for each customer, and every review step above still applies, but the baseline belongs to the business instead of whoever wrote the prompt.
Your delivery team should already know how to deliver your standard services, so a scope built from them is easier to plan and staff. Custom work still needs a closer look. Because custom services stay visibly distinct in the project, reviewers can check whether those items are defined and estimated well enough to hand over.
Other sources, such as CRM history, call transcripts, email threads, or PSA actuals, can add context alongside ScopeStack through their own connections. The workflow above uses ScopeStack data alone.
Learn more: Sales-to-Service Handoff: Best Practices for MSPs, VARs, and IT Service Teams
Building projects isn’t the only use for ScopeStack’s MCP integration. Many customers start by asking an AI assistant to review the content they’ve already created by hand. Before using that material to build new scopes, they want to understand where it’s strong and where it needs work. That review can surface spelling mistakes and inconsistent terminology, but the more valuable questions go deeper: Does a service description explain what the team will actually deliver? Is an exclusion specific enough to set a clear boundary with the customer?
This gives teams a practical way to revisit a service catalog that may have grown over years of individual contributions. A description that made sense to its original author may leave another salesperson guessing. An internal standard may need more detail before it can guide a project consistently. The assistant can help flag those weaknesses for review, while the team decides what the language should say based on how it sells and delivers the work.
Every future scope draws from that same material, including exclusions like the one in the review above. If the underlying language is vague, the assistant can carry that ambiguity into the next project it builds. Cleaning up the catalog improves that starting point. Instead of correcting the same description in one SOW after another, teams can address it at the source and give both their people and their AI assistant clearer content to work with.
See how ScopeStack's MCP connector works
Go back to the engineer leaving the discovery meeting. Instead of opening a blank document and piecing together a scope from past proposals, they can ask an AI assistant connected to ScopeStack to start assembling the project using the services, phases, and rates their business has already defined. The engineer can then focus on the decisions that need their expertise, resolving open questions with the customer and checking whether the proposed work reflects what delivery will actually require.
ScopeStack gives that workflow a foundation in your team’s scoping standards. Service descriptions and effort assumptions provide the context the assistant needs to produce a useful starting point. Your team can review the proposed work, adjust the estimate, and approve the scope before it reaches the customer, with visibility into what’s included and how the project is structured.
The value extends beyond getting one proposal out the door faster. As your team refines its service catalog, those improvements become part of the foundation for future projects. ScopeStack helps you put that accumulated knowledge to work, so AI-assisted scoping reflects how your business delivers services and gives your engineers more time to get the details right.
Request a ScopeStack demo to see how AI can help turn discovery notes into a scope built around your team's standards.