Provides tools for interacting with Azure DevOps wikis, including searching content, reading and updating wiki pages, navigating hierarchical page structures, and listing and managing wikis within Azure DevOps projects.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Azure DevOps Wiki MCP Server search for deployment documentation in the DevOps project"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that brings Azure DevOps Wiki context to your AI agents, enabling seamless integration with Azure DevOps wikis.
Related MCP server: Azure DevOps MCP Server
The Azure DevOps Wiki MCP Server enables AI applications to interact with Azure DevOps wikis through the Model Context Protocol. It provides comprehensive wiki operations including content search, page management, and hierarchical structure navigation.
Key Features:
🔍 Search across wiki content
📄 Read and update wiki pages
🌲 Navigate hierarchical page structures
📋 List and manage wikis
🔐 Secure authentication via Azure CLI or PAT
Search across wiki content using Azure DevOps Search API.
Parameters:
organization (required): Azure DevOps organization name
project (required): Project name
searchText (required): Search query string
wikiId (optional): Specific wiki identifier
Retrieve hierarchical page structure from wiki.
Parameters:
organization (required): Azure DevOps organization name
project (required): Project name
wikiId (required): Wiki identifier
depth (optional): Maximum depth to retrieve
Get content of a specific wiki page.
Parameters:
organization (required): Azure DevOps organization name
project (required): Project name
wikiId (required): Wiki identifier
path (required): Page path or page ID
Update content of an existing wiki page or create a new page if it does not exist.
Parameters:
organization (required): Azure DevOps organization name
project (required): Project name
wikiId (required): Wiki identifier
path (required): Page path or page ID
content (required): New page content (Markdown)
List all wikis in a project.
Parameters:
organization (optional): Azure DevOps organization name
project (optional): Project name
Note: Both parameters are optional and will use environment defaults if not provided.
Node.js 18 or higher
Azure CLI installed and configured (az login) Required only if you wish to authenticate with Azure, not required if you choose to use PAT token
Appropriate Azure DevOps permissions for target organization
Add to your claude_desktop_config.json:
{
"mcpServers": {
"azure-devops-wiki": {
"command": "npx",
"args": [
"-y",
"azure-devops-wiki-mcp"
],
"env": {
"AZURE_DEVOPS_URL": "https://dev.azure.com/your-organization",
"AZURE_DEVOPS_PROJECT": "your-project",
"AZURE_DEVOPS_PAT": "your-pat-token",
"AZURE_DEVOPS_ORGANIZATION": "your-organization-name"
}
}
}
}Authenticate with Azure:
az loginConfigure with Claude Desktop:
Add to your claude_desktop_config.json:
{
"mcpServers": {
"azure-devops-wiki": {
"command": "npx",
"args": [
"-y",
"azure-devops-wiki-mcp"
],
"env": {
"AZURE_DEVOPS_URL": "https://dev.azure.com/your-organization",
"AZURE_DEVOPS_PROJECT": "your-project",
"AZURE_DEVOPS_ORGANIZATION": "your-organization-name"
}
}
}
}This server supports two authentication methods:
Make sure you're logged in:
az loginThe server will use your Azure CLI credentials to authenticate with Azure DevOps.
You can also use a Personal Access Token for authentication by setting environment variable AZURE_DEVOPS_PAT.
Creating a PAT:
Go to Azure DevOps → User Settings → Personal Access Tokens
Create a new token with the following scopes:
Wiki: Read & Write
Project and Team: Read (for project access)
Copy the token and set it in the AZURE_DEVOPS_PAT environment variable
Environment Variables:
Environment Variables | Description | Required? |
AZURE_DEVOPS_URL | Azure DevOps URL | Yes |
AZURE_DEVOPS_PROJECT | Default project name (optional) | No |
AZURE_DEVOPS_PAT | No | |
AZURE_DEVOPS_ORGANIZATION | Azure DevOps Organization Name | Yes |
When using PAT authentication, the server will prioritize the PAT over Azure CLI credentials.
git clone <repository-url>
cd azure-devops-wiki-mcp
npm install# Build the project
npm run build
# Build in watch mode during development
npm run watch
# Start the MCP server
npm start
# Run tests
npm test
# Run linting
npm run lint
# Clean build artifacts
npm run clean
# Version bump and publishing
npm run version:patch # Bump patch version (1.0.0 → 1.0.1)
npm run version:minor # Bump minor version (1.0.0 → 1.1.0)
npm run version:major # Bump major version (1.0.0 → 2.0.0)
npm run release # Run build, test, and lint checks before publishingAdd to your claude_desktop_config.json:
{
"mcpServers": {
"azure-devops-wiki": {
"command": "node",
"args": [
"--inspect",
"path/to/azure-devops-wiki-mcp/dist/index.js"
],
"dev": {
"watch": "path/to/azure-devops-wiki-mcp/dist/*.js",
"debug": { "type": "node" }
},
"env": {
"AZURE_DEVOPS_URL": "https://dev.azure.com/your-organization",
"AZURE_DEVOPS_PROJECT": "your-project",
"AZURE_DEVOPS_PAT": "your-pat-token",
"AZURE_DEVOPS_ORGANIZATION": "your-organization-name"
}
}
}
}Start up @modelcontextprotocol/inspector with inspection turned on:
mcp-inspector node --inspect dist/index.js
# Alternatively, set the environment variables when you launch it
mcp-inspector -e AZURE_DEVOPS_URL="Your DevOps URL" -e AZURE_DEVOPS_PROJECT="Your DevOps Project" -e AZURE_DEVOPS_PAT="Your PAT" -e AZURE_DEVOPS_ORGANIZATION="Your DevOps Organization" node --inspect dist/index.jsUse IDE (vscode / cursor), select "Attach to MCP Server" and start debug
Enter local test data from MCP Inspector UI
The server follows the Model Context Protocol specification and integrates with Azure DevOps Wiki API through the official azure-devops-node-api client library.
Key Components:
MCP Server: Implements MCP protocol using @modelcontextprotocol/sdk
Azure DevOps Client: Wrapper around azure-devops-node-api for Wiki API operations
Tool Handlers: Five main tools implementing MCP tool interface
Authentication: Azure CLI-based authentication with PAT fallback
The project includes automated version bumping scripts for semantic versioning:
# Bump patch version (1.0.0 → 1.0.1) - for bug fixes
npm run version:patch
# Bump minor version (1.0.0 → 1.1.0) - for new features
npm run version:minor
# Bump major version (1.0.0 → 2.0.0) - for breaking changes
npm run version:majorEach version bump command automatically:
Updates the version in package.json
Creates a git commit with the version number
Creates a git tag (e.g., v1.0.1)
Fork the repository
Create a feature branch
Make your changes
Add tests
Submit a pull request
MIT
List all wikis in a project
| Name | Required | Description | Default |
|---|---|---|---|
| organization | No | Azure DevOps organization name | |
| project | No | Project name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'list', implying read-only, but does not state idempotency, permission requirements, or behavior when project does not exist. This leaves ambiguity for the AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with key information. No unnecessary words, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (list all wikis, two optional params, no output schema), the description is adequate but does not explain the effect of omitting parameters or the structure of the response, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (organization, project) have descriptions in the input schema, providing 100% coverage. The description does not add extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all wikis in a project' clearly states the action (list) and the resource (wikis) with a scope (in a project). It is distinct from siblings which focus on searching or individual page operations, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like search_wiki or wiki_get_page is provided. The context implies it is for retrieving all wikis, but lacks explicit context about when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across wiki content using Azure DevOps Search API
| Name | Required | Description | Default |
|---|---|---|---|
| organization | No | Azure DevOps organization name | |
| project | No | Project name | |
| searchText | Yes | Search query string | |
| wikiId | No | Optional specific wiki identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states that the tool searches wiki content using an external API, but does not mention pagination, rate limits, authentication requirements, or return format. This is minimal transparency for a search operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema. The description does not explain return values, pagination, or result structure. For a search tool, users need to know what the response contains. The description is incomplete for successful invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so all parameters are described in the schema. The tool description adds no additional meaning beyond the schema descriptions. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and resource 'wiki content', and distinguishes from sibling tools like list_wiki and wiki_get_page which focus on listing or retrieving pages rather than content search. The mention of Azure DevOps Search API adds context but is not essential.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings (e.g., when to use search vs list_wiki), nor any conditions or prerequisites. The description only implies usage for searching, with no explicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get content of a specific wiki page
| Name | Required | Description | Default |
|---|---|---|---|
| organization | No | Azure DevOps organization name | |
| project | No | Project name | |
| wikiId | Yes | Wiki identifier | |
| path | Yes | Page path or page ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'get content' but omits read-only nature, authentication needs, error handling (e.g., page not found), or rate limits. This is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. It front-loads the action and resource. However, it could be slightly more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is too minimal. It does not explain the return format, error conditions, or any behavior beyond the basic action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no extra meaning beyond that. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Get content') and resource ('a specific wiki page'). It distinguishes itself from sibling tools like list_wiki, search_wiki, get_page_tree, and update_page by focusing on retrieving a single page's content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like search_wiki or list_wiki. It lacks any prerequisites, context for selection, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve hierarchical page structure from wiki
| Name | Required | Description | Default |
|---|---|---|---|
| organization | No | Azure DevOps organization name | |
| project | No | Project name | |
| wikiId | Yes | Wiki identifier | |
| depth | No | Optional maximum depth to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description must carry behavioral transparency. It only states a read operation but lacks details on auth, errors, or effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, concise sentence with no wasted words, but it is too brief for sufficient context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and four parameters, the description lacks details on return structure, depth behavior, and required parameters beyond wikiId.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters; description adds little beyond confirming it retrieves hierarchical structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves hierarchical page structure, distinguishing it from siblings that list wikis, search, get a single page, or update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like wiki_get_page for single pages; no when-not or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update content of an existing wiki page or create a new page if it does not exist
| Name | Required | Description | Default |
|---|---|---|---|
| organization | No | Azure DevOps organization name | |
| project | No | Project name | |
| wikiId | Yes | Wiki identifier | |
| path | Yes | Page path or page ID | |
| content | Yes | New page content (Markdown) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only says 'update or create,' lacking details on replacement behavior, permissions, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple upsert, but missing details on error handling, output, and permissions. No output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no extra parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing page or creates a new one, distinguishing it from read-only siblings like list, search, and get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied as the only write tool among siblings, but no explicit guidance on when to use vs alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
list_wikisearch_wikiwiki_get_pagewiki_get_page_treewiki_update_pageEach tool has a clearly distinct purpose: listing wikis, searching content, retrieving a page, fetching the page hierarchy, and updating/creating pages. No overlap or ambiguity.
Naming uses snake_case but mixes prefix styles: 'list_wiki' and 'search_wiki' lack the 'wiki_' prefix that appears in 'wiki_get_page', 'wiki_get_page_tree', and 'wiki_update_page'. This inconsistency may confuse an agent.
With 5 tools, the scope is well-balanced for a wiki server—covering enumeration, search, read, hierarchy, and write operations without excess or deficiency.
Core wiki operations are covered: list, search, get page, get hierarchy, and update/create. A minor gap is the lack of an explicit delete page tool, but the update tool handles creation as well.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Shared project wiki for AI agents: read and write pages, next actions, and activity logs over MCP.
A Model Context Protocol server for Wix AI tools
Hosted markdown project wikis your team's AI assistants read, search, and update over MCP.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/uright/azure-devops-wiki-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
