• Powered by Cuvama MCP

Can I just connect it to Claude?

Name: Cuvama
Brand: Cuvama
Availability: InStock

Yes. Also ChatGPT, Copilot, Gemini, Agentforce, and any agent your value team is already building. It’s not a choice between building it in Claude and buying Cuvama. You buy Cuvama so you can build it in Claude, and your agents work on a living value plan instead of a blank page.

Your value model, governed in one place. One living value plan, from value discovery through to value realisation.

Your value plan lives in one place. Your team works everywhere else.

Your sellers work in an assistant. Your CSMs work in another. Your champion works in email and a spreadsheet you never see. The value plan, the one thing that should carry a deal from the first call through to the renewal, sits in a tool most of them only open when somebody asks them to. Anything drafted outside it inherits none of your value model, lands in no shared record, and leaves no trace of who agreed to what.

What it costs you

When the Work Happens Outside the Plan	What It Costs You
Your value model stays behind. Drivers, formulas, and guardrails live in the platform, not in the tool the work is happening in.	Numbers your value team has to unpack, and a champion circulating something they cannot defend.
Nothing writes back. The output is a file, and it leaves the system the moment it is emailed.	The thread snaps at every hand-off: value discovery to value case, close to value realisation.
No record of who decided what. No audit trail, no adoption data, no quality signal.	You cannot tell whether the number that reached the decision maker was ever validated, or by whom.

AI makes two of these easy. Only the third is defensible.

Every value team is about to have an agent. The question is what they build on.

01 . AGENT

The brain

Researches and drafts. Pulls the account together and produces a first version in minutes.

02 . ARTIFACT

A snapshot

The document it emits. Accurate the day it is made, and frozen the moment the deal moves forward.

03. PLATFORM

The living system

Brain, interface, and governed value data in one connected system the whole team and their agents work in.

Not a file that goes stale.

What only a platform gives you

These are the four things a value plan has to do to survive a whole deal cycle. We wrote the longer version here.

Bring your own agents. Cuvama is the value infrastructure.

Cuvama MCP is an access layer over the Cuvama application. It is not a separate product, a separate data store, or a separate data processor. It exposes what your users can already do in Cuvama through a different door, so their agents work against live value plans instead of scraping context from somewhere else. Three layers, top to bottom.

Two things to set up. The rest happens on its own.

You set up	1. Your admin adds the connector	One entry at the organisation level: a name and a URL. For most platforms there is no OAuth client ID or secret to enter. Where a platform requires one, such as Gemini Enterprise, it is org-scoped and provisioned by Cuvama, never a per-user credential.
You set up	2. Your value team builds the shared agent	A project, an agent, a custom GPT, whatever your stack uses. The value team writes the instructions once, and every seller inherits them.
Then it runs	3. Each user signs in once	The first time someone calls Cuvama, they are prompted to authenticate with their normal credentials. One-time, per person, no admin involvement.
Then it runs	4. They work against the live plan	Everything the assistant reads and updates is exactly what that person can already see and change in Cuvama. Their permissions, nothing more.

A single admin task plus one agent build. No data migration, no separate deployment, no new contract.

Two interfaces. One for the people selling, one for the people governing.

Cuvama MCP splits into two surfaces, so a seller and an admin have their own set of tools. The User MCP is for the people working a deal. The Admin MCP is for the people who decide how value gets done. Both work on the same living value plan, under the same permissions your team already has.

Here are a handful of examples, not a catalogue, because Teams keep finding new use cases all the time.

User MCP · for sellers and CSMs

For working a live deal. Some of the things your agents can do:

Pick up where discovery left it	Read the value plan, its sections, and the discovery notes, transcripts, CRM notes, emails and calls behind it, then draft the next version from what is actually known about the account.
Turn a conversation into value	A call surfaces two new facts; the agent turns them into a value driver, quantifies it inside your value model guardrails, and puts it in the plan.
Build and stress the numbers	Drivers, metrics, ROI and TCO. Show it after tax. Give the buyer a floor as well as a headline. Show where a number came from.
Work with your champion	Share the plan, capture what they validate, and keep the change history that proves they were part of building it.
Carry it past the close	Record what actually happened, put the actuals next to what was promised, and build the expansion case off the original plan.

Admin MCP · for value leaders and admins

For running the value function. Some of the things your agents can do:

Shape the value model	Configure the default drivers, metrics and formulas every plan inherits.
Set the template	Define the value plan sections and the org settings your team works inside.
Run access	Manage users, roles and teams without opening a ticket.
See what is actually happening	Read the org-wide activity log and report on usage, adoption, and results, including which plans your champions validated and which they did not.

What the tools accept

Every input is an identifier, a filter value, a date, or a document name. No tool accepts free-form code, database queries, file paths, or URLs. The full tool inventory sits in the documentation your administrators receive, and new or changed tools are announced in the Cuvama release notes.

DESIGN PRINCIPLE

Keep it simple for sales.

A clean interface for the AE, the CSM, and the champion. Power users get depth through the agent layer without pushing that complexity onto everyone else.

Two agents we built on our own interface, and one pattern it supports

We use Cuvama MCP the way we expect you to. These are not mockups.

01 · Built and running

The marketing value agent

Marketing works against the same governed value drivers and realised outcomes the sales team uses, so campaign messaging and the value case inside the deal say the same thing in the same language.

02 · Built and running

The value selling agent

A seller asks their assistant what the team knows about the account. It pulls the value plan, the discovery notes, and the knowledge base, and returns an Upfront Value PoV they can walk into the first call with. Day-One Expert, without the forty percent of the week that usually goes to research.

03 · Pattern the interface supports

The post-sale agent

There is no hand-off document. The CSM opens the same living value plan the AE built, updated automatically as the deal closed, so the targets that were sold are already the commitments being tracked. Actuals go back into that same plan, which is what makes the renewal case write itself off the original promise.

This is what moves value coverage from ten percent of pipeline to a hundred. Not more headcount on the value team; the same team’s methodology running everywhere at once.

Answered before they ask it

Question	Answer
Authentication	Each user authenticates with their own Cuvama credentials. There is no shared API key and no service account. Where a platform requires an org-level connector credential to register the connection, such as Gemini Enterprise, Cuvama provisions it and it is held by your administrators; it registers the connector and never stands in for a user. Every request still runs on the individual’s own Cuvama sign-in.
Permissions	Every request runs under that user’s Cuvama permissions and is scoped to their organisation. The assistant can access only what the user can already access in the application.
Data processing	The MCP introduces no new data processing. Cuvama is an AI application, and processing of customer data by language models is already covered by your existing agreement and data processing terms.
Encryption	Encrypted in transit and at rest, to the same standard as the rest of the Cuvama application.
Build	One hundred percent built and hosted by Cuvama. No third-party MCP code.
Change management	New and changed tools are announced in the Cuvama release notes your administrators already receive.

Buy Cuvama so you can build it in Claude.

Yes, and we would rather you did. Your value team knows your motion better than any vendor does, and the tools to build with are already in your stack. What an agent cannot invent for itself is the thing underneath it: a governed value model, a living value plan the whole cycle writes to, an interface your champion can work in, and a record of every deal that sharpens the next one. Buy that, then build whatever you want on top of it.

You Build	Cuvama Brings
The agent, and the experience your team works in	The value model, the drivers, the math your admins lock
The prompts and the guidance that match your motion	The living value plan the whole cycle writes to
The workflow, in whatever assistant your org has standardised on	A shared interface your AE and your champion both work in, which no agent can give you on its own
The judgment about which deals get the treatment	The record of who changed what, and the store of past cases that sharpens the next one

Which is why the question stopped being build or buy. It is build and buy, and the MCP is the bridge between the two. Your agents, our living value plan.

The longer version of this argument.

FAQS

The rest of what value leaders and RevOps ask

How do we get it?

The MCP is available now, and it is an access layer over the Cuvama application rather than a separate system to stand up. Talk to us about your stack and we will walk you through it.

What can an agent actually change in Cuvama?

Whatever the person driving it could change in the app. Your agents create and progress value plans, build the numbers inside your value model guardrails, share plans with your buyer, and configure the value model itself through the Admin MCP, all under that user’s own permissions with a full change history behind it.

Do we need an MCP gateway?

No. It works directly with any MCP-compatible assistant, and through a gateway such as Runlayer if your organisation routes everything that way.

What if our team uses three different assistants?

That is the point of an open interface. Claude, ChatGPT, Copilot, Gemini, and your own agents all connect to the same value system of record.

Does this replace the Cuvama UI?

No. Sellers and champions who want our interface can keep it. Power users get depth through the agent layer. Some organisations run headless entirely, and that is supported.

We already have a value platform. Why does this matter?

Because your team does not work in it. The value plan sits in one tool while the seller drafts in an assistant, the CSM works in another, and nothing carries between them. An open interface puts the living value plan wherever the work is already happening, which is the difference between a platform your team owns and one they visit.

NEXT STEPS

Your agents are only as good as the value model behind them.

Your value team can build the agent. What they cannot build in a sprint is the governed value model, the living value plan, and the record of who validated what. Connect the agents to the system that runs all three.