#1187 - Best practices for exposing integrations as tools

Introduction 

If you've been reading my blogs, even on an irregular basis, you will have seen how easy it is to expose existing integrations as agent tools.

One click exposure. One more click and you have exposed the project as an MCP server, thus giving 3rd parties access to the tools.

But is this the best approach? Will your integration developers be the ones exposing integrations as tools? Or could this be another group of users? 

Where different teams own integration development and agent tooling, separating these responsibilities provides clearer control.

In this post I give tool managers a controlled way to reuse integrations while integration owners retain control over what they share.

Controlled Exposure as Tools

I work on the basis that in many organizations, the person creating the integrations may not be the one exposing such as agentic tools. With that in mind, I create a new group in IDCS - OIC-Tools-Mgrs. I assign one user to this group; he is our tools manager.

As you can see, user Niall Mac Cumascaigh is assigned to the group. He also has the OIC ServiceDeveloper role, although he is not an integration developer. This role is required for him to be able to create tools in OIC.

Another user, niall.commiskey@oracle.com, has been involved in enterprise integration since his halcyon days of youth. It was he who created the project with these 3 integrations - 

This project is currently private, from an RBAC perspective - 

User Niall Mac Cumascaigh can see the project listed in OIC - 

but he cannot open it - 

The project owner can decide which integrations should be shareable; in our case, which integrations should be available as tool candidates.

Our veteran integration developer shares the get Invoice integration - 

Meanwhile, our tools manager creates a new tools project in OIC - 

This is where he will add tools - 

Now, our Invoices project owner applies RBAC - the view permission is required to use a shared asset. 

The OIC Tools Mgr can now create a tool based on the shared integration - 

He enters the first characters of the invoices project name in the Project field. 

Note, only the shared integration, get Invoice, is available for selection as a tool. 

The tools mgr user can change the description etc. -

The tools manager now enables the dedicated tools project as an MCP server.

Govern Access via MCP Gateway

The OIC MCP Gateway policies govern access to the published tools.

This gateway can front multiple MCP servers, including the project MCP server we just enabled. 

Please see my posts on the Gateway for details on how to configure etc.

Summa Summarum

Exposing an integration as an agent tool takes just a few clicks. Deciding what to expose, who should publish it, and how agents should access it deserves a deliberate approach.

The pattern demonstrated here gives integration owners and tools managers clear responsibilities. Integration owners select which assets to share and grant the required project access. Tools managers build a dedicated tools project from those shared assets, refine the tool descriptions, and expose the project as an MCP server. The MCP Gateway then provides the policies governing access to those tools.

The value is straightforward: reuse existing integration logic while retaining control over which capabilities become available to agents. Integration developers can focus on delivering business functionality, while tools managers shape how that functionality is presented for agent use.

Try it with one shared integration and a dedicated tools project. Validate the permissions from the tools manager’s account, then configure and test gateway access. You now have a repeatable approach for expanding your agent toolkit with clear ownership and governance.