Connecting Expedify as MCP

Lesson 32 of 40 · 5 min

Everything in this course so far has happened in a browser tab. This module is the same org, the same objects and the same rules, reached from wherever you already work — and it takes one config block to open.

MCP is a standard way for a tool you use to call a system you have. Expedify runs a server that speaks it. Point Claude, or your editor, or a script at that server with a key, and the org's capabilities become things your tool can do — not a chat window bolted onto the product, but your tool holding their business.

What it actually is

Read from a session captured against anvaya-finserv-demo on 2026-08-19.


An address	`https://api.expedify.ai/v1/mcp`
A key	An API key from the org, sent as a bearer token
What you get	The org's capabilities as callable tools — the same ones the product uses

An address

: https://api.expedify.ai/v1/mcp

A key

: An API key from the org, sent as a bearer token

What you get

: The org's capabilities as callable tools — the same ones the product uses

There is no separate AI to configure and no data to copy anywhere. The server is the same API the product runs on, wearing a different collar. When you ask a question through it, the answer is a live read of the org — not an export, not an index, not a summary somebody generated last night.

Connecting it

In Claude — desktop or the CLI — this is the whole of it. Other tools differ in where the file lives, not in what goes in it:

{
  "mcpServers": {
    "expedify": {
      "type": "http",
      "url": "https://api.expedify.ai/v1/mcp",
      "headers": {
        "Authorization": "Bearer <your org's API key>"
      }
    }
  }
}

One server entry. Name it after the client, not after the product — you will end up with several.

Name each connection after the client. A partner running four accounts ends up with four of these, and the day you have both a demo org and a live one connected is the day the name matters. Nothing warns you that you are in the wrong org — the tools look identical, because they are.

The key decides what it can do

An API key carries scopes, and they are the whole of the safety story. A key with read scopes can answer any question and change nothing. A key that can write can write.

Start read-only. Everything in Asking your business a question works with a read key, and it is most of the value.
Add write when you need it, per client. Not per partner, per client — so a mistake in one account cannot reach another.
It is revocable at their end. Same answer as API keys and OAuth: who has to click: the client can turn you off without asking you, and that is what makes handing over a key reasonable.

Ask it one thing

The test that it is connected is not a status light. Ask it something only that org could answer:

You: How is the pipeline looking — how much is sitting in each stage?

If what comes back is your client's pipeline rather than an apology, you are connected — and everything in the rest of this module is now available to you.

Change one thing — connect your own

Create an API key in your demo org with read scopes only.
Add the config block above to whatever tool you use, named after the org.
Ask it the question above. Check the numbers against the board you read in The deals board and the seven stages.
Do not add write scopes yet. Changing things by asking is the lesson that earns them.

Try it

Work out what you would do if a client asked to see exactly what your tooling can reach in their org. There is a precise answer and it is the key's scopes.
Decide whether you would ever connect a client's org to a tool that is not on your own machine. Think about where the key ends up.

Next: Asking your business a question — the questions a business asks on a Monday, and how many of them have no screen in any CRM.