Connecting your own connector
One of your own systems is attached as a connector: a service that offers a manageable number of tools and calls the interface of your system behind them. It is created and granted in the admin panel, without access to the server.
What to settle beforehand
Section titled “What to settle beforehand”- The technical name. The connector runs under this name in your instance. It cannot easily be changed later. So pick something meaningful and durable.
- The address where the connector speaks MCP. The service has to be reachable from your instance.
- The credentials for the target system. They never belong in the configuration in plain text, only ever as a reference to a stored key.
- The account behind the credentials. It is the actual data boundary. In the target system, give it exactly the permissions and exactly the areas the use case needs, see connector patterns.
- A short guide in prose about when this tool should be used and what it cannot do. It is only inserted when the connector is active, and it noticeably improves the hit rate.
Where do I get an MCP server for my system
Section titled “Where do I get an MCP server for my system”Ready-made servers exist for many products. Because MCP is an open standard, vendors and communities publish connectors for common software. Search for the product name together with “MCP server”. For systems with a programming interface of their own, chances are good that someone has already built the bridge.
You can build one yourself. A connector is a small service that offers a handful of tools and calls the interface of your system behind them. For a limited purpose, for example “five read queries against our line of business application”, that is manageable. A deliberately narrow bridge is far cheaper in context than a ready-made server with a hundred tools.
Review a third party server before you connect it. A connector gets access to your data, that is not a formality. Four questions:
- Which tools does it expose? Read the list in full. Writing tools you do not need are pure risk, and they cost context on top.
- Is there a read only mode? A switch that disables write access in the code is worth considerably more than the intention not to use it.
- Is it suitable for multiple users? Connectors that remember state across several calls do not work reliably in multi user operation.
- Where do the credentials live, and what is the license? A connector that holds keys itself belongs on the internal network and nowhere else.
The outcome of such a review can very well be “we build it ourselves”, especially if a ready-made server offers reboots, script runs, or write access alongside reading and that cannot be switched off. How a narrow bridge is cut is described under connector patterns.
Granting access is a step of its own
Section titled “Granting access is a step of its own”A connector that has been created is not yet a connector that has been granted.
Finally, check the grant with two test users who have different permissions. If both see the same thing, your permission boundary is not taking hold.
When something does not work
Section titled “When something does not work”- A tool reports “access denied”. That is not an error, that is the permission rule. Check the grants for the person concerned, see permissions and grants.
- The connector does not answer. First check whether the service is reachable from your instance, then check the stored credentials for the target system.
- The individual checks are described in the guide that ships with your instance. It also covers the connection test, which checks a connection independently of the permissions.