Configure Avanoo MCP Proxy (On-premise)

Avanoo MCP Proxy lets you expose approved SaaS services through a single MCP endpoint.

With the on-premise deployment, you run Avanoo MCP Proxy in your own environment using the Avanoo Docker image.

Once deployed, the setup is simple:

1. Select the SaaS services to allow

2. Add scoped instructions for each service

3. Share the MCP Proxy URL with your users

Your users then add that URL to their MCP client, authenticate, and start using the services you exposed.

How it works

An on-premise Avanoo MCP Proxy gives you the same MCP endpoint model while letting you control where the proxy runs.

As an admin, you:

• deploy the Docker image in your environment

• configure which SaaS services are exposed

• define the access scope for each service

• share the MCP Proxy URL with users

As an end user, the experience stays the same: add the MCP Proxy URL to an MCP client, authenticate, and use the exposed services.

Before you begin

Make sure you have:

• permission to deploy containers in your environment

• access to the Avanoo MCP Proxy Docker image

• a public or internal URL that users can reach

• the list of SaaS services you want to expose

Deploy Avanoo MCP Proxy

Deploy the Avanoo MCP Proxy Docker image in your environment using your standard container platform.

For example, you might run it with Docker, Kubernetes, or another container orchestration system supported by your infrastructure.

Your deployment should expose a single MCP endpoint URL that end users can access from their MCP client.

Configure the on-premise MCP Proxy

Step 1: Select the SaaS services to allow

Choose the SaaS services you want to expose through Avanoo MCP Proxy.

For example:

• Google Drive

• Slack

• Notion

• Jira

• GitHub

Only the services you enable here will be exposed through this MCP Proxy.

Step 2: Add scoped instructions

For each service, you can add instructions to help define the permission scope.

These instructions are used to narrow access. They are not broad behavioral instructions for the assistant.

Use them to specify things such as:

• which workspace, repository, project, or folder should be accessible

• whether access should be read-only or include write actions

• which resources should be excluded

Examples:

Google Drive: only the Product and Support shared drives. Read-only access.

GitHub: only repositories in the avanoo organization. Read-only access to issues, pull requests, and repository content.

Jira: only the ENG and OPS projects. Allow reading tickets and updating ticket status if due date is not in the past.

Keep these instructions short and precise. Their purpose is to define access boundaries for each service.

Step 3: Save the configuration

Once you have selected the services and added the scoped instructions, save the configuration.

Your on-premise Avanoo MCP Proxy is now ready to use.

Step 4: Share the MCP Proxy URL

Expose the deployed proxy through a URL that your users can reach.

Example:

https://mcp.example.com

Share this URL with the users who should access the proxy.

Connect from an MCP client

End users only need the MCP Proxy URL.

To connect:

1. Open the MCP client

2. Add a new MCP server

3. Paste the Avanoo MCP Proxy URL

4. Authenticate when prompted

After authentication, the client can discover and use the SaaS services exposed by that proxy.

Deployment considerations

For on-premise deployments, make sure:

• the MCP Proxy URL is reachable by the intended users

• TLS is configured according to your environment requirements

• your authentication setup is working correctly

• the deployed version matches the version you intend to operate

Update an existing on-premise proxy

You can update an on-premise MCP Proxy at any time.

Typical updates include:

• deploying a newer Docker image

• adding a new SaaS service

• removing a service

• changing the scoped instructions

• refining access boundaries

Users continue to connect through the same MCP Proxy URL unless you change the endpoint.

Troubleshooting

A service does not appear

Check that:

• the service is enabled in the proxy configuration

• the configuration was saved successfully

• the user authenticated successfully

Access is too broad or too limited

Review the scoped instructions configured for that service.

In most cases, permission issues come from instructions that are too vague or too restrictive.

The user cannot connect

Check that:

• the MCP Proxy URL is correct

• the deployed service is reachable

• TLS and networking are configured correctly

• the user is signing in with the correct account

The proxy is running but authentication fails

Check your authentication configuration and confirm that the deployed endpoint is using the intended identity setup.

Next steps

After your on-premise MCP Proxy is deployed and configured:

• verify that the endpoint is reachable

• test authentication from your MCP client

• review the scoped instructions for each enabled service

• share the MCP Proxy URL with users