Each person signs in to an MCP connector
For the person who creates an MCP connector for a server that must know who is calling, and for everyone who then uses it: each person connects their own account or licence, and an agent's calls run as the person whose chat or run it is.
Before you start: the connector basics (MCP connector). Sign-in with OAuth or Microsoft needs this Studio's sign-in address set up; an administrator gets it by updating the Studio through Organisations, and until then Connect answers "Sign-in is not set up on this Studio yet. Ask your administrator to update the Studio."
Choose how each person signs in
In Authentication Configuration, set Sign-in method to one of these, or tick Each person adds their own key under Custom headers or Query parameters.
| Choice | Use it when | What each person does |
|---|---|---|
| Sign in with OAuth (each person) | The server accepts OAuth sign-in as its own users, for example a data provider with a personal subscription | Presses Connect and signs in at the provider |
| Sign in with Microsoft (each person) | The server is behind Microsoft Entra ID and must see the caller, for example an Amazon Bedrock AgentCore Gateway (Connect an Amazon Bedrock AgentCore Gateway) | Presses Connect Microsoft account and approves access once |
| Custom headers or Query parameters with Each person adds their own key | Each person has their own licence key or token for the server | Presses Add your key and enters their own values |
The connector's definition (address, sign-in method, tools, approval settings) is shared by everyone who can see it. The credentials are not: each person's connection is theirs alone.
Sign in with OAuth
- Create an MCP Server connector and enter the MCP Server URL. It must be
https. - Set Sign-in method to Sign in with OAuth (each person).
- Choose Client registration:
- Register automatically: Studio registers itself with the provider's sign-in service the first time someone connects, and reuses that registration. Use it when the provider supports it.
- Use a client registered with the provider: you enter the Client ID the provider gave you, and for a confidential client choose Client authentication (Send in the request body or Send as HTTP Basic) and enter the Client secret. Choose None (public client) when the provider issued no secret.
- Optionally enter Scope (optional); blank uses the scopes the server advertises. Enter Authorisation server (optional) when the server does not say where its sign-in service is.
- Click Check sign-in. Studio finds the sign-in service and shows its address, whether automatic registration is available, and the Redirect URI for this Studio. If it fails you see why, for example "The server did not say where to sign in. Enter the authorisation server address, or check the server address." or "The sign-in service does not let Studio register itself. Choose "Use a client registered with the provider" and enter its client ID."
- Save the connector. Test Connection finds the sign-in details and does not need a connection: "Sign-in details found. Save the connector, then connect your account to list its tools." Connect your own account (below), then Refresh tools to list and choose the tools.
Studio signs in with OAuth 2.1 and PKCE, and refuses a sign-in service that does not support PKCE with S256.
A provider that needs a pre-registered sign-in app
Some providers do not let a product register itself. They issue your organisation a client ID and secret for a sign-in app, and ask you to list the addresses the app may return people to. Some also publish no discovery document for the server.
- Ask the provider for a sign-in app and give it the Redirect URI the form shows (it is the same for every connector in this Studio, and Check sign-in also shows it). Register it with the provider for every Studio that will use the connector.
- Choose Use a client registered with the provider, enter the Client ID, choose the Client authentication the provider expects and enter the Client secret. It is stored in AWS Secrets Manager for this Studio and never shown again.
- If the server does not advertise its sign-in service, enter it as Authorisation server (optional).
- Add any Scope (optional) the provider documents, then Check sign-in and save.
Everything else is as above: each person still signs in with their own account at the provider, and the app's secret is only the Studio's proof that the request comes from your registered app.
Sign in with Microsoft on behalf of each person
Studio's own sign-in does not give it a Microsoft token for you, so each person grants the connector's Microsoft app access once. Studio keeps their refresh token and, for each call, redeems it for an access token for the server's API, so the server sees that person. The full set-up for an Amazon Bedrock AgentCore Gateway is in Connect an Amazon Bedrock AgentCore Gateway.
- Set Sign-in method to Sign in with Microsoft (each person).
- Enter Directory (tenant) ID, Application (client) ID and Client secret of the Microsoft Entra app, and Scope, the API's delegated scope (for example
api://<application-id-uri>/access_as_user). - Add the Redirect URI shown in the form to the app registration in Microsoft Entra ID, and grant consent for the scope: "Add this redirect URI to the app registration in Microsoft Entra ID, and grant it consent for the scope."
- Save. Each person then presses Connect Microsoft account and must sign in with the Microsoft account they use for Studio, or Studio refuses it: "Sign in with the Microsoft account you use for Studio (email)."
Personal keys
With Each person adds their own key ticked, the header or query parameter rows you define are the names, and each person supplies the values. Nobody enters a value when creating the connector. Each person presses Add your key on the connector's page, fills every row and saves; Studio sends their values, and only theirs, with their calls.
Connect and Disconnect
A connector that signs in as each person shows the badge Each person signs in in Data Connectors, and for you Not connected or Connect again until your connection works. Its page has a Your account panel:
| Part | What it does |
|---|---|
| Status | Connected, Not connected or Connect again (your sign-in expired or the connector's settings changed), with "Signed in as account" when known |
| Connect or Connect Microsoft account | Opens a sign-in window. When it closes the page reads "Your account is connected." |
| Add your key | A form with one field per header or parameter name |
| Test with my account | Runs Test Connection with your own connection |
| Disconnect | Asks "Disconnect your account from connector?", then removes your tokens or keys at once and, where the provider supports it, revokes them |
Press Connect again if a sign-in window reports a problem: "This sign-in took too long or was already used. Press Connect again." (a sign-in must be finished within 10 minutes), "This sign-in was started by someone else. Press Connect again." or "Sign-in was cancelled."
In chat and workflows
An agent's call runs with the account of the person whose chat, workflow run or schedule it is.
- When you have not connected, the call waits and the card reads Waiting for you to connect, with "Connect your account to use connector", Connect and Not now. The tool call line reads "tool: waiting for you to connect your account". Connect opens the sign-in; the agent carries on by itself once you are connected, and a tool that asks before running then asks as usual (MCP connector). Not now tells the agent it could not use the tool. A call nobody completes within 30 minutes is not run.
- A workflow you start runs as you. A scheduled run runs as the person who created the schedule, and the schedule editor says "Scheduled runs use your own connected accounts." with a Connect line for each connector that person has not connected. A scheduled run that meets an unconnected connector waits on the connect card in its owner's Inbox (Inbox).
- A run started with an API key has no person to act as, so it cannot use these connectors: "This connector signs in as each person, so runs started with an API key cannot use it."
- Your account is raised as a banner too when your connection needs attention (Banners you may see).
What is never shared
- Your tokens and keys are held in this Studio's AWS Secrets Manager, one secret for you and one connector, and no one else, including administrators, can read your connection or see whether you are connected.
- A Library shares the connector's definition only. Someone who downloads the connector arrives Not connected and connects their own account (Libraries and sharing). Organisations never reads or relays a personal credential.
- Your connection is tied to where it was made. If someone edits the connector so that a sign-in would go somewhere else (another address, scope, client or tenant), your connection becomes Connect again and nothing is sent until you reconnect.
- In a governed deployment the connector is shared by everyone on the deployment and every person connects their own account. In a standard deployment each person who can see the connector connects theirs.
- Deleting the connector deletes everyone's connection to it.
Notes
- The client secret of a pre-registered app, or of the Microsoft app, can be managed centrally by your organisation without sharing anyone's own sign-in (Connector policy, credentials and activity). It is the connector's credential; each person's connection stays personal.
- A policy set in Organisations can limit which MCP servers and sign-in methods are allowed. A blocked connector shows "Blocked by your organisation's policy." and its message (Connector policy, credentials and activity).
- Other refusals you may see: "Your organisation has not yet allowed this app to act for you. Ask your Microsoft Entra administrator to grant consent." and "The connector's owner has not chosen its tools yet."