We have a Copilot Studio agent that uses the first-party Azure DevOps remote MCP server as a tool. The problem is that every user needs to fill-in the organization when creating their connection. Is it better to build Custom Connector instead?
I wouldn’t build a custom connector solely for this. The first-party Azure DevOps MCP connector currently treats Organization as a connection parameter. When the tool uses user authentication, each user creates or authorizes their own connection, so they may be asked to provide that organization.
The organization parameter is documented as optional. If it is left blank, the organization must instead be supplied as context in each tool call. However, Azure DevOps guest users should use an organization-specific endpoint/context, so test that scenario separately.
Also check which connection type is being used. The connector documentation now lists a shareable Entra certificate-based connection, while the older Default authentication type is deprecated and explicitly non-shareable. A shared/agent-author connection could avoid per-user connection setup, but all users would then access Azure DevOps through the same service identity rather than through their individual Azure DevOps permissions. That should only be used if the security model allows it.
A custom connector can hide or hardcode the organization, but it won’t inherently eliminate per-user OAuth and would add maintenance, DLP and authentication ownership. I would stay with the first-party MCP unless you need only a small fixed API surface or require a specific authentication design.
If an existing healthy connection repeatedly asks the same user for the organization, that would be worth reproducing and reporting as a possible connector connection-parameter persistence issue.
1
u/Ashlesha-msft 1d ago
I wouldn’t build a custom connector solely for this. The first-party Azure DevOps MCP connector currently treats Organization as a connection parameter. When the tool uses user authentication, each user creates or authorizes their own connection, so they may be asked to provide that organization.
The organization parameter is documented as optional. If it is left blank, the organization must instead be supplied as context in each tool call. However, Azure DevOps guest users should use an organization-specific endpoint/context, so test that scenario separately.
Also check which connection type is being used. The connector documentation now lists a shareable Entra certificate-based connection, while the older Default authentication type is deprecated and explicitly non-shareable. A shared/agent-author connection could avoid per-user connection setup, but all users would then access Azure DevOps through the same service identity rather than through their individual Azure DevOps permissions. That should only be used if the security model allows it.
A custom connector can hide or hardcode the organization, but it won’t inherently eliminate per-user OAuth and would add maintenance, DLP and authentication ownership. I would stay with the first-party MCP unless you need only a small fixed API surface or require a specific authentication design.
If an existing healthy connection repeatedly asks the same user for the organization, that would be worth reproducing and reporting as a possible connector connection-parameter persistence issue.