A lot of companies are getting described as AI platforms right now, including plenty that do entirely different jobs, so we've started hearing a version of the same question: is Cotiss an MCP?

It's a fair question and the answer is no. It's also worth being precise about why, because getting the category wrong means getting the value wrong.

First, what people usually mean by MCP

The Model Context Protocol is an open standard for connecting AI systems to the tools and data outside them. A server describes what a system can do and what it holds, a client asks, and the model gets to reach past the chat window into the places where work actually happens. It's good infrastructure, we're glad it exists, and it's on its way to becoming the default way models talk to software.

What a protocol does is carry. It holds no view about what's true, it arrives with no memory of the last time it was called, and it hands the model whatever sits on the other end, faithfully, including all the parts that are wrong. Point one at an ERP holding a single supplier under thirty spellings and you get thirty spellings, delivered fast and reliably.

So a protocol won't resolve fragmented supplier records, work out that three business units are buying the same service under three different labels, or tell a CFO where costs are drifting and where the leverage went. That work has to have happened before there's anything worth carrying, and it's the work we do.

Cotiss solves a different problem

Cotiss exists because large organizations don't have a clean, reliable view of their vendor landscape. It looks like a data problem and it behaves like a commercial one.

Contracts sit in old inboxes, spend data sits in systems that don't talk to each other, and two teams negotiate with the same supplier without either knowing the other exists. Renewal windows pass without the right people seeing them, and the context leaves the building when the person holding it does. What that produces is financial leakage, because costs get locked in before anyone has what they'd need to challenge them.

It's why we moved away from being a source-to-contract tool. The original product worked and it created real value for procurement teams, but the same structural limit kept showing up: savings couldn't scale past the walls of procurement while the underlying vendor data stayed fragmented across the business. So we moved upstream.

Today we connect and structure fragmented vendor data across email, ERP systems, finance tools, SharePoint, contract repositories and wherever else it's sitting, then surface the commercial signals that matter most, which is where spend sits, where risk sits, and where savings can still be captured before the window closes.

The difference between connection and understanding

An MCP server can give an AI system access to a tool. That's a different job from helping an organization understand a vendor relationship.

If the question is whether a vendor is operating outside contracted terms, whether a rebate clause is being missed, whether duplicate suppliers exist across business units, or whether a renewal risk is approaching, access on its own won't answer it. The answer sits in messy, inconsistent, incomplete records spread across communications, agreements, spend patterns, supplier history, and knowledge nobody ever wrote down anywhere useful. Somebody has to read all of it, decide which vendor is really which, and work out what it means under this company's own terms.

The volume is part of why this can't be a connection. A tool call is a request, answered in the moment, from whatever state the system happens to be in. Reading a company's commercial history is a different shape of work: tens of millions of documents, each routed to whichever engine can handle that particular job affordably, run and re-run as new material lands. No model does that inside a single call, and putting every document through a frontier model stays uneconomic at that volume however cheap the models get.

It's why we describe Cotiss as a CRM for vendors instead of customers. A CRM is valuable because it builds shared context around a relationship, and we apply that logic to the cost side of the business, holding a connected commercial record for the vendor network rather than a pile of disconnected documents and transactions.

Why this matters for finance and operations leaders

Fragmented vendor data is frustrating if you're a procurement practitioner. If you're a CFO, a VP of Finance or an operational leader, it shows up in EBITDA.

Large organizations spend hundreds of millions and sometimes billions across their vendor base, so small gaps in visibility carry large financial consequences. From a single data source, usually email, we can surface about 95% of an organization's total vendor spend, and on average we identify at least 1% in savings across non-headcount opex and capex. At that scale, it usually means millions of dollars.

We go after the use cases with direct financial impact from the first week:

off-contract spend
CPI increases
missing rebate terms
service credits
renewal exposure
duplicate supplier arrangements

Every one of those is a decision somebody can make this quarter with money attached to it.

What makes Cotiss different

Most large organizations have more systems than anyone can name. What they don't have is a way to connect the information across them and make sense of what it means.

Four things get us there, and not one of them is a connection.

We read the material that never reached a form, which is the email where a price got negotiated down, the call where a delivery date slipped, the meeting note where somebody agreed to a scope change nobody logged anywhere. We reason over it against rules you write in plain English, the way you'd brief a new hire, so the hundreds of pages of policy and the handful of unwritten rules everyone already knows become the rules the system runs on. We hold it, which means a decision made in 2022 is still queryable in 2030, after the person who made it has moved on. And we run the work off it at whatever level of autonomy you set, from telling you what we found through to acting inside limits you've defined, with a named person accountable for anything it does and every action leaving its evidence behind.

Underneath all of it sits an ontology per customer. Cotiss arrives already treating vendors, categories, clauses, commitments and exceptions as first-class things, then learns your naming conventions, your category language and the exceptions everyone knows about, and keeps refitting as teams reorganize and vendors get renamed. That's what lets it absorb messy inputs without anyone being asked to tidy up first. Your team spends around fifteen hours on it, and you go from connection to grounded answers in about three weeks. The familiar alternative runs to months of integration work, heavy change management, and a dashboard at the end that still depends on incomplete data.

The part that bears on protocols is where the comprehension sits. A generic automation waits for a field to change in a database, which means a person has already read the email and typed the fact in. Cotiss starts while the fact is still prose. Then every answer arrives with its source attached, the clause on the page, the sentence in the email, the second in the call, because a confidence score isn't an answer and a cited document is.

A useful way to think about it

If MCP is part of the plumbing, Cotiss is the commercial nervous system. Plumbing matters, and nothing connects without it. A nervous system does something else: it senses what's happening, connects signals from across the organization, and makes them visible while there's still time for someone to act.

Which gets me to the honest version of the answer. MCP is how you reach us, not what we are. We already expose your commercial memory as a native MCP endpoint, so whatever you're running, your own build, Zip, Oro or Copilot, can call it and act on the reasoning behind the record instead of the record alone. Shipping that endpoint took a small fraction of the work that went into having something worth calling, and that ratio is the whole argument. As the protocols make access cheap and standard, the scarce thing becomes whatever sits on the other end of the connection, and a system that has already read your company, resolved it and worked out what it means is a much harder thing to stand up than a way of asking.

The version of Cotiss that exists today gives an organization a connected view of its vendor network. The version we're building understands the relationships inside that data well enough to say what they mean and what should happen next, which is the move from retrospective reporting to continuous commercial awareness.

So what is Cotiss?

Cotiss is a Commercial Intelligence company. We help large organizations build a clear, connected view of their vendor network so they can see what they're spending, where risk sits, and where savings exist before costs are locked in.

There's AI in it, there are integrations in it, and some of the systems we read are the same ones other companies reach through protocols and tooling. Connecting to the data is the cheap part, and it gets cheaper every year. The expensive part, and the part worth paying for, is turning what comes back into commercial context an organization can act on, which you build over months rather than call in a request.

If you're trying to work out where money is leaking across your vendor base, that difference is most of the answer. I'd rather show you on a real vendor network than argue the taxonomy.

Why Cotiss isn't an MCP