## Key Takeaways

- **"Not in the list" almost never means "not connectable."** Between the native catalog, custom MCP servers, and MCP bridges like Zapier and Make, most tools have a working route today.
- **Search the catalog before anything else.** With 3,200+ integrations, the tool you want is often there under the platform's name instead of the product's name, or covered by a neighboring integration.
- **A custom MCP server is a paste-one-URL job.** You paste the server address from the vendor's docs, your AI employee detects how it authenticates, and the tools load. No engineering ticket.
- **Never guess the MCP URL.** The single most common failure is pasting a made-up address. The vendor's own "connect to AI" setup page states the real one verbatim.
- **Zapier, Make, and Pipedream act as bridges.** If a niche tool has no MCP server of its own but lives on one of those platforms, you can expose exactly the actions you choose as tools.
- **Requesting an integration works better with specifics.** Name the tool, the exact workflow you want, and how often it runs. That is what moves a request up the queue.

## The one tool that runs your week is the one that's missing

Connecting the first tools is the easy part. Slack, email, calendar, the CRM: all sitting in the catalog with a Connect button. Then you get to the tool your operation actually runs on, the industry-specific job board, the boutique billing system, the internal dashboard someone built three years ago, and it is not in the list. This is the moment most teams shrug and keep copy-pasting between tabs, and it is almost always the wrong conclusion.

We see this question constantly from new customers, and the honest answer is that "unsupported" is a spectrum, not a wall. There are four routes to a tool that is not in the integrations list, ordered from fastest to slowest. Most requests never make it past the second one.

## Route 1: search the catalog like you mean it

Before building anything, spend two minutes making sure the tool is actually missing. With 3,200+ integrations in the catalog, the most common reason people think a tool is unsupported is that it is listed under a different name.

Three patterns to check:

The tool is listed under its **platform name, not its product name**. The reporting product you know by a brand name might authenticate through its parent suite, so the integration carries the parent's name.

The job is covered by a **neighboring integration**. You do not need a dedicated integration for a tool whose data already flows somewhere connected. If your form tool pushes every response into a Google Sheet, connecting Google Sheets gets your AI employee the same data with zero extra setup.

The tool exposes its work through **email or calendar**. Plenty of legacy systems send everything that matters as notification emails. An AI employee with inbox access can read, parse, and act on those, which for read-heavy workflows is often all you need. Our guide on [choosing your first three integrations](/blog/choosing-your-first-3-integrations) covers this substitution logic in more depth.

If the tool genuinely is not there, move to route 2.

## Route 2: add it yourself with a custom MCP server

MCP is a standard way for a tool to describe its actions to an AI, a common plug that works the same regardless of who built either side. It is not a Viktor-specific feature and it is not something you need engineering for. If the vendor of your missing tool runs an MCP server, and in 2026 a fast-growing number do, you can connect it in about two minutes.

The flow inside Viktor: open Integrations, click **Add custom MCP**, and paste the server URL. That is the whole manual part. Viktor probes the server and figures out how it wants to authenticate:

- If the server is open, the integration saves immediately.
- If the server uses OAuth, you get redirected to the vendor's login page to authorize, the same dance as connecting any mainstream app.
- If the server wants a static key, you land on a page asking for it.

Notice what you did not do: you did not choose an auth type, dig for developer settings, or configure scopes. You pasted one URL. If you have ever wondered what makes this safe, our comparison of [MCP vs OAuth](/blog/mcp-vs-oauth) walks through the security model.

One warning that saves the most support back-and-forth: **get the URL from the vendor's documentation, not from pattern-matching**. Because many servers live at addresses like `mcp.vendorname.com`, people guess, and the guess is wrong often enough that "could not start this connection" errors are usually just a wrong address. Search the vendor's help center for their MCP or "connect to AI" setup guide; the real URL is stated there verbatim.

```prompt
@Viktor I just added our project tool via Add custom MCP. List the tools
that loaded from it and run a quick test: pull the 5 most recently
updated items and post them here.
```

A first-run check like this confirms the connection end to end before you build any real workflow on it.

## Route 3: bridge through Zapier, Make, or Pipedream

Some tools have no MCP server and no native integration anywhere. If the tool lives on one of the big automation platforms, that is your bridge: Zapier, Make, and Pipedream each run MCP servers that expose their catalogs, which collectively cover thousands of long-tail apps.

The pattern is the same as route 2 with one extra step on the platform side. You pick which actions or scenarios to expose, the platform gives you your personal MCP server URL, and you paste that URL into Add custom MCP. Your AI employee then sees exactly the actions you chose, nothing more.

This route has two properties worth understanding:

**You control the surface area.** The bridge only exposes what you explicitly select. If you expose "create invoice" and nothing else, your AI employee can create invoices and cannot touch anything else in that account.

**The platform executes the action.** Your AI employee decides what to do and with what data; the bridge platform carries it out using the connection you already trust it with. Existing automations you have built there can be exposed as single tools too, which turns years of accumulated Zaps or scenarios into things you can trigger in plain English from Slack.

```prompt
@Viktor via the Zapier MCP connection, add this week's signed deals from
#sales-closed to our invoicing tool, one draft invoice each, and post
the list back here for my review before anything is finalized.
```

## Route 4: request the integration

If the tool has no MCP server and is not on any bridge platform, request it. This route is slower, but requests are read, and specific ones move faster than vague ones. "Please support AcmeTool" gives nothing to prioritize. A useful request looks like:

- The tool's name and what category it is in
- The exact workflow: "every Monday, pull last week's placements and reconcile against our CRM"
- How often it would run and how many people would use it

While you wait, check whether route 1's substitutions can carry the workflow in the meantime. A surprising share of "we need this integration" requests are solved for good by an email-notification parse or a connected spreadsheet export.

## Which route fits your tool

| Situation | Route | Setup effort | Who maintains it |
| --- | --- | --- | --- |
| Tool is in the catalog under another name | Native integration | One Connect click | Viktor |
| Vendor runs an MCP server | Add custom MCP | Paste one URL, authorize | Vendor |
| Tool lives on Zapier / Make / Pipedream | MCP bridge | Pick actions, paste your bridge URL | You (on the platform) |
| None of the above | Integration request | Write a specific request | Viktor, once shipped |

Work down the table from the top. Each row is faster and less work than the one below it, and in our experience the majority of "missing tool" cases resolve in the first two rows the same day.

## Frequently Asked Questions

### Does Viktor support Zapier and Make?

Yes, through their MCP servers. You expose the actions or scenarios you choose on the platform side, paste your personal MCP URL into Add custom MCP, and those actions become tools your AI employee can use. Existing automations you have already built can be exposed the same way.

### What is MCP in plain terms?

A standard way for a tool to tell an AI "here are the actions I offer and here is how to authenticate." Because it is a shared standard, any tool that speaks it can connect without a purpose-built integration. It is not a Viktor product and not something you install; the vendor runs the server, you paste its address.

### Where do I find a vendor's MCP server URL?

In the vendor's own documentation, usually in a setup guide about connecting AI assistants. Do not guess it from the pattern `mcp.vendorname.com`; wrong guessed addresses are the most common reason a custom connection fails to start.

### Is connecting a custom MCP server secure?

The connection uses whatever auth the vendor's server enforces, most commonly OAuth, where you log in on the vendor's page and can revoke access there at any time. Viktor detects the auth type automatically, so an open server connects directly while a protected one always sends you through the vendor's authorization first. For the deeper security comparison, see [MCP vs OAuth](/blog/mcp-vs-oauth).

### Why didn't it ask me for an API key or token?

Because the server told Viktor it did not need one. When you paste a URL, Viktor probes how the server authenticates and only asks for a key when the server requires a static key. If it saved without asking, the server presented itself as open, and if its tools then fail to load, the URL is the first thing to re-check.

### The connection saved but my AI employee can't use the tool. Now what?

Run a quick test task asking it to list the tools that loaded from that connection. If nothing loads, re-check the URL against the vendor's docs first, then re-authorize. Our guide on [why your AI employee can't access a tool](/blog/why-your-ai-employee-cant-access-a-tool) covers the most common failure modes and their quick fixes.

## The list is a starting point, not a boundary

The integrations catalog is where connecting starts, not where it ends. Search it properly, paste an MCP URL when the vendor offers one, bridge the long tail through the automation platform you already use, and write a specific request for the rest. The tools your team actually runs on, including the obscure ones, are more reachable than the Connect button grid suggests.

[Add Viktor to your workspace and connect the tools you actually use](https://viktor.com/?utm_source=blog&utm_medium=cta&utm_campaign=how-to-connect-tools-your-ai-employee-doesnt-support-yet)

Related reading:

- [How to Connect Any Tool to Your AI Employee (OAuth vs API Key)](/blog/how-to-connect-any-tool-to-your-ai-employee)
- [MCP vs OAuth: What You Actually Need to Know About AI Agent Security](/blog/mcp-vs-oauth)
- [Why Your AI Employee Can't Access a Tool](/blog/why-your-ai-employee-cant-access-a-tool)