<!-- Connecting your own MCP servers -->
<!-- canonical: https://plainwater.ai/en/wiki/bronnen/eigen-mcp-servers -->
# Connecting your own MCP servers

Many organisations have MCP servers of their own, and there are public MCP servers with documentation that is useful to
everyone. Plainwater AI can connect such servers. The agent does not talk to the external server directly: the platform
is the intermediary, and every call goes through the same gate as the platform's own tools.

## Why through the platform

If an agent talked to an external server directly, it would need a token or password for it, and nobody would keep track
of what goes back and forth. Through the platform:

- the agent never receives a credential;
- names in arguments and results are treated the same as with the platform's own tools;
- every call is in the audit;
- the data access rules of customer and source apply.

## Three scopes

| Scope | Example | Who switches it on |
| --- | --- | --- |
| **Platform** | A public documentation server | Switched on per customer |
| **Customer** | The customer's internal MCP server | For that one customer |
| **Source** | An MCP server belonging to one source | Follows the work item's sources |

## The server declaration

Before an external server becomes active, a person records a **declaration**:

- what kind of data the tools return (metrics only, or values too);
- the classification (customer data, for example);
- a reason;
- a responsible person.

The effective setting is the strictest of three: the customer's ground rules, the source's setting and the declaration. A
server that returns customer data can only run with active pseudonymisation.

:::warning What the platform cannot know
Pseudonymisation works on names the platform knows. An external server can return something the platform has never seen
before. That residual risk is exactly why the declaration is a decision by a person, with a name attached.
:::

## Approval per tool

Each tool of an external server is approved separately. On approval the platform records a fingerprint of the tool's
description and schema. If the server later changes that description, the tool becomes invisible and refused until
someone approves it again. An external server therefore cannot quietly change what a tool means.

## Write tools

A tool that changes something is not executed by the agent itself. The call becomes a **proposal**. A person sees what
would happen and approves or rejects it. Only after approval does the platform execute the call.

## How to connect a server

1. Enter the MCP server's address and choose the scope.
2. Set up authentication. The secret is stored encrypted and the agent never sees it.
3. The platform fetches the list of tools.
4. Record the declaration.
5. Approve the tools agents may use.
6. Switch the server on.

## Example

A bank has an internal MCP server that exposes its data dictionary: definitions of terms and owners per table. The
administrator connects it as a customer server with the declaration "metadata only, no customer data", approves the read
tools and leaves out the tool that changes definitions. Agents working for this bank can now look up the official
definition of "active customer" in every analysis, and those calls are in the audit.

:::tip Read on
- [Sources and connectors](https://plainwater.ai/en/wiki/bronnen/overzicht)
- [Security guarantees](https://plainwater.ai/en/wiki/veiligheid/garanties)
:::
