What MCP Connections Are Useful For
MCP (Model Context Protocol) connections let Biddy reach into the other tools your team already uses - CRMs, project trackers, and similar systems - during a BidBot session, so it can pull in live information or take actions there without you leaving BidScript or copy-pasting between tabs.
To be clear on the shape of this: BidScript is the client - it's Biddy that reaches out to connect. The third-party app is the server - it's the one exposing its data and actions over MCP. BidScript doesn't build or host a separate integration for each vendor; instead, it connects to whichever MCP servers your other applications already provide.
MCP Server vs. MCP Client - What's the Difference?
These two terms come up a lot, so here's the plain-language version:
MCP Server - this is the third-party application (for example, Planhat or Atlassian). It's the one making its data and actions available over MCP, at a specific address (a URL).
MCP Client - this is BidScript. Biddy is the client that "dials out" to connect to a server, using the URL you provide.
In short: the other app is the server, BidScript is the client that connects to it.
How to Check If an App You Want to Connect Has an MCP Server
Not every application supports MCP yet, and there's no single master list - it comes down to whether that vendor has built one. To check:
Look in that vendor's own help centre or developer documentation for terms like "MCP," "Model Context Protocol," "remote MCP server," or "MCP endpoint."
Check their admin or developer settings for an integrations, API, or "connect an AI assistant" section - this is often where an MCP server URL is published.
If you already use that app with another AI assistant that supports "custom connectors" (for example, Claude), the same server URL will typically work with BidScript too - it's the same underlying standard.
If a vendor doesn't have an MCP server yet, there's currently no way to connect it in BidScript - we only connect to applications that genuinely speak MCP themselves, rather than building one-off workarounds. If enough customers ask for a specific vendor, let us know and we can flag the demand
What to Look for in the MCP Server URL
Once you've confirmed a vendor supports MCP, you're looking for a single web address (URL) - this is the server's connection endpoint. It's usually labelled something like:
"MCP server URL"
"Remote MCP endpoint"
"Connector URL"
This is usually found in that vendor's own settings, documentation, or developer portal — not inside BidScript. Copy this URL exactly as shown.
A note on extra credentials: most vendors only require the URL, and the rest of the connection is handled automatically. A small number of vendors (Planhat is one example) don't support that automatic step, so you'll also need a Client ID and Client Secret from their admin settings. If this applies, BidScript will show you an Advanced settings option asking for these alongside the URL - you'll only see this if the vendor actually requires it.
How to Connect an MCP Server URL in BidScript
Connecting has two parts - a one-time setup by an admin, and then each person connecting their own account:
Step 1: An Admin Registers the Server (once per team)
Go to Settings → Integrations → MCP Connections.
Click Add MCP Server.
Paste in the server URL you found from the vendor.
If the vendor requires it, expand Advanced settings and enter the Client ID and Client Secret as well.
Save. The server is now available for anyone on your team to connect to.
This step only needs to happen once per application - an admin registers the server, they don't connect on behalf of the whole team.
Step 2: Each User Connects Their Own Account
Go to Settings → Integrations → MCP Connections.
Find the server your admin registered and click Connect.
You'll be redirected to sign in and approve access with your own account on that application.
Once approved, you'll see the connection marked as Connected under your own account.
Note: Every person connects individually, with their own login and their own permissions on that application. Nobody shares a single team-wide login. This also means what Biddy can see or do through that connection reflects your own personal access on that app — not more, not less.
How to Test That the Connection Is Working
Once you're connected, the best way to check everything is working is to try it in a real BidBot session:
Start a BidBot session as you normally would.
Ask Biddy something that would need that application's data or actions — for example, "Check [Application] for the latest update on this account."
When Biddy needs to use the connected application, you'll see an approval card asking you to confirm the action before it runs.
Approve it, and Biddy will complete the request and bring the result back into your session.
If it works, you'll see a normal result come back in the conversation. If something's wrong, you'll typically see an error or Biddy will tell you it couldn't reach the application — in that case, double-check the URL was entered correctly and that your own individual connection still shows as Connected in Settings → Integrations.
Note: If a connected application changes what it allows Biddy to do, you may see a badge on the approval card letting you know its permissions have changed since you last approved it — worth a quick look before continuing.
Quick FAQ
Do I need to be an admin to connect an application?
No - an admin only needs to register the server once. After that, any team member can connect their own account to it.
Does BidScript control what Biddy can see or do in the connected app?
No - that's controlled by the application itself, based on your own permissions there. BidScript doesn't add or remove access on top of what you already have.
Is there a list of supported applications I can pick from?
No - there's no fixed catalogue. Any application with its own MCP server can be connected by pasting its URL.
What if the app I want isn't MCP-enabled yet?
It can't be connected until that vendor builds MCP support themselves. This isn't something BidScript can work around on our side.