{"versionId":"6e8585ff-49ee-45b0-72b2-08df3875e214","articleId":"3ac3a6e3-ce26-4042-af81-08df392c5d0a","title":"Azure DevOps MCP server | Admin guide","tags":["MCP","System admin","Integrations","All articles"],"content":"

Connect Theta Assist to Azure DevOps so users can work with project information, work items and wiki pages from an assistant. This guide helps system administrators set up authentication, choose available features, control access and test the connection.

\n
\n

Quick links

\n\n
\n

Before you start

\n

You will need:

\n\n

Check that Enable MCP Servers is turned on under Admin > Tools > Settings.

\n

1. Add Azure DevOps permissions

\n
    \n
  1. Open the Microsoft Entra admin centre and go to App registrations.
    2. \n
  2. Open the app registration you will use for Azure DevOps. If you reuse an existing registration, check its current integrations before changing it.
    3. \n
  3. Open API permissions and select Add a permission.
    4. \n
  4. Select the Azure DevOps API, then choose Delegated permissions. These are Azure DevOps permissions, not Microsoft Graph permissions.
    5. \n
  5. Add the permissions needed for your enabled features from the table below. 
    6. \n
  6. Complete the consent process required by your organisation. Have an authorised administrator grant tenant-wide consent if that is your rollout approach.
    7. \n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
PermissionTypePurpose
vso.profileDelegatedRead the user profile.
vso.projectDelegatedRead project and team information.
vso.work_writeDelegatedRead and write work items.
vso.codeDelegatedRead code information.
vso.buildDelegatedRead build information.
vso.wikiDelegatedRead and search wiki pages. Use for read-only wiki access.
vso.wiki_writeDelegatedRead and write wiki pages. Use instead of vso.wiki when editing is needed.
\n

Grant only the permissions needed for the tools you plan to make available. Users also need the corresponding access within Azure DevOps. Adding delegated permissions does not grant them extra organisation, project or wiki access.

\n

2. Configure authentication

\n
    \n
  1. Go to Admin > Tools > Auth Configurations.
    2. \n
  2. Select + Add Auth, or open an existing configuration intended for Azure DevOps.
    3. \n
  3. Enter a clear name, such as “Azure DevOps production”, and select the appropriate Microsoft OAuth provider.
    4. \n
  4. Enter the tenant ID, client ID, client secret and OAuth details required by the form. Check that the redirect URI registered in Entra matches the callback used by your Theta Assist deployment.
    5. \n
  5. Set Scopes to the following value:
    6. \n
\n
https://app.vssps.visualstudio.com/.default offline_access
\n
    \n
  1. Select Save.
    2. \n
\n

The Azure DevOps resource uses the .default scope to request permissions configured for that resource on the app registration. Adding a permission in Entra and entering the OAuth scopes are separate setup steps.

\n

Do not assume an existing Microsoft Graph authentication configuration has the correct scopes for Azure DevOps. Use an Azure DevOps-specific configuration where changing a shared configuration would affect another integration.

\n

For the shared authentication fields, see Authentication configurations | Admin guide. Ask users to reconnect Azure DevOps after permissions or consent change.

\n

3. Add the MCP server

\n
    \n
  1. Go to Admin > Tools > MCP Servers.
    2. \n
  2. Select + Theta Assist MCP Server.
    3. \n
  3. Select Azure DevOps. The built-in server details are pre-populated.
    4. \n
  4. Choose the Azure DevOps Auth Configuration you prepared.
    5. \n
  5. Review the server name and any additional instructions.
    6. \n
  6. Set the access controls and approval policy described below, then save the server.
    7. \n
\n

\"Azure

\n

4. Set organisation, project and feature options

\n

The Azure DevOps Connection section of this page (shown below) allows you to set its defaults and additional features.

\n
\n

 

\n

Choose default values

\n
    \n
  1. Enter your Azure DevOps organisation name in Default Organisation, for example “ThetaDigital”. Use your own organisation name.
    2. \n
  2. Optionally enter a project name in Default Project.
    3. \n
\n

Defaults let the assistant omit the organisation or project from individual calls. They can still be overridden per call. They are not access restrictions or an allowlist. Use Azure DevOps permissions to control access to organisations and projects.

\n

Enable attachment features

\n
    \n
  1. Turn on Turn work item attachments into secure download links.
    2. \n
  2. Turn on Allow the AI to attach files to work items if users should be able to upload attachments.
    3. \n
  3. Set Maximum file size (MB). The supplied configuration uses 60 MB. Choose a lower limit if large uploads time out.
    4. \n
  4. Set Allowed file extensions, or leave the field blank to use the default document, image and data types.
    5. \n
  5. Turn on Allow public web addresses as a file source if your organisation allows attachments to be fetched from public HTTPS addresses.
    6. \n
  6. Continue to the wiki settings below, then select Save changes after choosing the features you need.
    7. \n
\n

Secure download links download files using the clicking user's Azure DevOps credentials. With this option, attachment file contents are not sent to the model.

\n

The upload option can attach an AI-generated file, a user-uploaded file, a document link from another tool or, when enabled, a public web address. Uploads use the signed-in user's Azure DevOps permissions.

\n\n

Enable wiki features

\n

Choose whether users need read-only access or editing.

\n
    \n
  1. Confirm the app registration has vso.wiki for reading and searching, or vso.wiki_write for editing as well.
    2. \n
  2. Turn on Allow the AI to search and read wiki pages.
    3. \n
  3. If users need editing, also turn on Allow the AI to create, edit and delete wiki pages. This is the current grouped setting label. Leave this option off for a read-only setup.
    4. \n
  4. Select Save changes.
    5. \n
  5. If permissions or consent changed, ask users to reconnect Azure DevOps before testing.
    6. \n
\n

Wiki reads and edits use the signed-in user's own wiki permissions. Review the tools exposed by the grouped write setting and use Allowed Tools to limit available actions where needed. This guide's confirmed release scope and test steps cover reading, searching and editing.

\n

5. Set access controls and approvals

\n

Control who can configure and use the server

\n
    \n
  1. Go to Admin > Management > Access Profiles and create or select a profile for authorised assistant authors.
    2. \n
  2. Add the relevant users or groups.
    3. \n
  3. Assign that Access Profile to the Azure DevOps MCP server.
    4. \n
  4. Review who can access assistants that have the server enabled.
    5. \n
  5. Check each pilot user's organisation, project, work item and wiki permissions in Azure DevOps.
    6. \n
\n

Important: For MCP servers, access profiles control who can add or configure the server on an assistant. They do not necessarily prevent other people from using it through an assistant they can access. Do not use an access profile as the only control for a pilot or restricted rollout.

\n

Delegated permissions are not app-only access. Consent to the app does not give a user extra project access in Azure DevOps. Defaults, assistant instructions and approval prompts do not replace service-side permissions.

\n

For more detail, see Access profiles | Admin guide.

\n

Choose an approval policy

\n
    \n
  1. Set the server's Approval policy to Always require approval for initial testing.
    2. \n
  2. Review Allowed Tools if you want to limit the exposed tools, including wiki write actions.
    3. \n
  3. Save your changes.
    4. \n
\n

Never require approval lets tools run without approval prompts. Use it only after reviewing the available actions and your organisation's requirements.

\n

Users can save approval preferences for a tool or the whole server. For a test that needs a fresh approval prompt, open the wrench icon > Approvals and remove any saved preference for that tool or server. Ask pilot users not to save blanket approval while you are testing.

\n

6. Set up an assistant

\n
    \n
  1. Open an assistant you own or can edit.
    2. \n
  2. Open its Tools tab and enable the Azure DevOps MCP server.
    3. \n
  3. Add instructions describing the intended organisation, project and allowed tasks, including whether wiki editing is intended. Treat these as guidance, not enforceable access restrictions.
    4. \n
  4. Save the assistant and limit its audience to the pilot group.
    5. \n
  5. Open a conversation and select the wrench icon in the message box.
    6. \n
  6. Select Authenticate for Azure DevOps, sign in with the intended account and complete any consent prompts. Allow browser pop-ups if needed.
    7. \n
\n

A red dot next to the wrench icon indicates authentication is needed. Each user should sign in with their own account.

\n

See Adding tools and connectors to your assistant and Connectors & MCP | End user guide.

\n

7. Run a test task

\n

Use a test project and an account with permission to create work items. Replace the example names before sending these prompts.

\n
    \n
  1. Confirm read access with: “In organisation [organisation] and project [project], list a few work items I can access. Do not change anything.”
    2. \n
  2. Check that the results are from the intended organisation and project.
    3. \n
  3. Test the configured defaults by asking: “Using the configured default organisation and project, list a few work items. Do not change anything.” If no default project is configured, name the project.
    4. \n
  4. Request a test task: “Create a Task in organisation [organisation], project [project], titled ‘Theta Assist MCP connection test’. Set the description to ‘Test item created to verify the Azure DevOps connection’. Do not assign it or change any other work items.”
    5. \n
  5. Review and approve the tool call if prompted.
    6. \n
  6. Open the returned work item in Azure DevOps and check its project, type, title and description.
    7. \n
  7. If attachments are enabled, upload a small non-sensitive PDF to the conversation and ask the assistant to attach it to that test work item.
    8. \n
  8. Ask for the work item's attachment links, then open a returned link and check that the file downloads with your Azure DevOps access.
    9. \n
\n

If the project does not support the Task work item type, choose an available type with the project owner before testing.

\n

After completing the test

\n\n

8. Test wiki reading, searching and editing

\n

Use a non-sensitive test page and an account with the required wiki access. Replace the example names and page path before sending these prompts.

\n
    \n
  1. Test reading: “In organisation [organisation], project [project] and wiki [wiki], read the page [page path] and summarise it. Do not change anything.”
    2. \n
  2. Test searching: “Search wiki [wiki] in organisation [organisation], project [project], for [a phrase on the test page]. Show the matching pages. Do not change anything.”
    3. \n
  3. Check that the page and search results match the intended wiki.
    4. \n
  4. If editing is enabled, request a small change: “In wiki [wiki], update only the test page [page path] by adding the sentence ‘Theta Assist wiki connection test’. Keep all existing content and do not change any other page.”
    5. \n
  5. Review and approve the edit if prompted.
    6. \n
  6. Open the page in Azure DevOps and confirm that only the requested change was made.
    7. \n
  7. Remove the test sentence using your team's normal editing process.
    8. \n
\n

For a read-only setup, leave the grouped wiki write setting off and confirm that editing is unavailable. Also check that users without wiki access cannot read restricted pages or edit them. Record the test results before wider rollout.

\n

Troubleshoot setup

\n

The server is missing from the assistant

\n

Check that the server was saved, MCP servers are enabled globally, the author belongs to the assigned access profile, and the server is enabled on the assistant's Tools tab. After changing access profile membership, allow up to 5 minutes for cached access to refresh.

\n

Authentication fails or the wrench icon has a red dot

\n

Check the selected auth configuration, tenant, client ID, secret, redirect URI and scopes. Confirm that Azure DevOps delegated permissions and consent are in place, allow browser pop-ups, then authenticate again.

\n

A call uses the wrong organisation or project

\n

Review the defaults and the organisation or project explicitly requested in the conversation. A call can override the defaults. Set Azure DevOps permissions separately if access needs to be restricted.

\n

A work item change is refused

\n

Check vso.work_write, user access to the project and work item, available work item types, Allowed Tools and whether approval was rejected. Confirm the operation is exposed by the configured server.

\n

An attachment fails

\n

Check the file size, allowed extensions, upload duration and user's work item permissions. If using a URL, check that public URL sources are enabled and the address is public HTTPS. Try a smaller non-sensitive file.

\n

A wiki tool is missing or fails

\n

Check the wiki feature settings, Allowed Tools, consent and the user's wiki access. Reading and searching need vso.wiki or vso.wiki_write; editing needs vso.wiki_write and the grouped wiki write setting enabled. Reconnect Azure DevOps after permission changes.

\n

If needed, enable MCP Activity logs to investigate tool calls. See MCP servers | Admin guide.

\n

 

","description":"Set up Azure DevOps authentication, permissions, organisation and project defaults, attachments, wiki access, access controls and approvals in Theta Assist. ","isMarkdown":false,"publishedOnUtc":"2026-11-11T22:26:05.3177344","modifiedOnUtc":"2026-11-11T21:24:36.437485"}