What can you do with this server?

The Ares DevOps MCP Server enables seamless interaction with Azure DevOps Git repositories and pipelines. * Repository Management: Create new repositories and list existing repositories * Branch Operations: List branches within a repository * Pull Request Management: Create pull requests between branches and add comments to pull requests * Commit History: Get commit history for a repository branch * Pipeline Operations: List available pipelines and trigger pipelines with specified parameters

Which integrations are available for this server?

Enables interaction with Azure DevOps Git repositories, including repository creation, branch management, and commit history retrieval. Required runtime environment for the MCP server, facilitating Azure DevOps API connectivity. Provides type-safe operations for Azure DevOps interactions implemented using TypeScript.

How do I use Ares DevOps MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Ares DevOps MCP Server create a pull request from feature-login to main in the auth-service repo" 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.

Ares DevOps MCP Server

by Cognitive-Stack

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Ares DevOps MCP Server 🚀

🔌 Compatible with Cline, Cursor, Claude Desktop, and any other MCP Clients!
Ares DevOps MCP is also compatible with any MCP client

The Model Context Protocol (MCP) is an open standard that enables AI systems to interact seamlessly with various data sources and tools, facilitating secure, two-way connections.

The Ares DevOps MCP server provides:

Seamless interaction with Azure DevOps Git repositories
Secure repository and branch management
Efficient pull request creation and management
Type-safe operations with TypeScript
Pipeline automation and monitoring

Prerequisites 🔧

Before you begin, ensure you have:

Azure DevOps account with appropriate permissions
Personal Access Token (PAT) with required scopes
Claude Desktop or Cursor
Node.js (v14 or higher)
Git installed (only needed if using Git installation method)

Related MCP server: Ares DevOps MCP Server

Ares DevOps MCP server installation ⚡

Running with NPX

npx -y ares-devops-mcp@latest

Installing via Smithery

To install Ares DevOps MCP Server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @ares-devops/mcp --client claude

Configuring MCP Clients ⚙️

Configuring Cline 🤖

The easiest way to set up the Ares DevOps MCP server in Cline is through the marketplace with a single click:

Open Cline in VS Code
Click on the Cline icon in the sidebar
Navigate to the "MCP Servers" tab (4 squares)
Search "Ares DevOps" and click "install"
When prompted, enter your Azure DevOps credentials

Alternatively, you can manually set up the Ares DevOps MCP server in Cline:

Open the Cline MCP settings file:

# For macOS:
code ~/Library/Application\ Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json

# For Windows:
code %APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json

Add the Ares DevOps server configuration to the file:

{
  "mcpServers": {
    "ares-devops-mcp": {
      "command": "npx",
      "args": ["-y", "ares-devops-mcp@latest"],
      "env": {
        "AZURE_DEVOPS_ORG": "your-organization",
        "AZURE_DEVOPS_PROJECT": "your-project",
        "AZURE_DEVOPS_PAT": "your-pat-token"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Save the file and restart Cline if it's already running.

Configuring Cursor 🖥️

Note: Requires Cursor version 0.45.6 or higher

To set up the Ares DevOps MCP server in Cursor:

Open Cursor Settings
Navigate to Features > MCP Servers
Click on the "+ Add New MCP Server" button
Fill out the following information:
- Name: Enter a nickname for the server (e.g., "ares-devops-mcp")
- Type: Select "command" as the type
- Command: Enter the command to run the server:
```
env AZURE_DEVOPS_ORG=your-org AZURE_DEVOPS_PROJECT=your-project AZURE_DEVOPS_PAT=your-pat npx -y ares-devops-mcp@latest
```
Important: Replace the environment variables with your Azure DevOps credentials

Configuring the Claude Desktop app 🖥️

For macOS:

# Create the config file if it doesn't exist
touch "$HOME/Library/Application Support/Claude/claude_desktop_config.json"

# Opens the config file in TextEdit
open -e "$HOME/Library/Application Support/Claude/claude_desktop_config.json"

For Windows:

code %APPDATA%\Claude\claude_desktop_config.json

Add the Ares DevOps server configuration:

{
  "mcpServers": {
    "ares-devops-mcp": {
      "command": "npx",
      "args": ["-y", "ares-devops-mcp@latest"],
      "env": {
        "AZURE_DEVOPS_ORG": "your-organization",
        "AZURE_DEVOPS_PROJECT": "your-project",
        "AZURE_DEVOPS_PAT": "your-pat-token"
      }
    }
  }
}

Usage in Claude Desktop App 🎯

Once the installation is complete, and the Claude desktop app is configured, you must completely close and re-open the Claude desktop app to see the ares-devops-mcp server. You should see a hammer icon in the bottom left of the app, indicating available MCP tools.

Ares DevOps Examples

Create Repository:

Create a new repository named "my-project" in Azure DevOps.

Create Pull Request:

Create a pull request from "feature-branch" to "main" in repository "my-project" with title "New Feature" and description "Adding new functionality".

List Pipelines:

List all available pipelines in the project.

Get Commit History:

Get the commit history for the "main" branch in repository "my-project".

Troubleshooting 🛠️

Common Issues

Server Not Found
- Verify the npm installation by running npm --version
- Check Claude Desktop configuration syntax
- Ensure Node.js is properly installed by running node --version
Authentication Issues
- Confirm your Azure DevOps PAT is valid and has required scopes
- Check the PAT is correctly set in the config
- Verify no spaces or quotes around the PAT
Repository Access Issues
- Verify the repository exists in your Azure DevOps project
- Check repository permissions
- Ensure the PAT has appropriate access rights

Acknowledgments ✨

Model Context Protocol for the MCP specification
Anthropic for Claude Desktop
Microsoft Azure DevOps for the API

Available Tools

8 tools

comment-on-prA

Leave a comment on an existing pull request

ParametersJSON Schema

Name	Required	Description	Default
`status`	No	Status of the comment thread	active
`comment`	Yes	Comment to add
`repositoryId`	Yes	ID of the repository
`pullRequestId`	Yes	ID of the pull request

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only says 'Leave a comment' without disclosing side effects (e.g., notifications, thread creation) or authentication requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence that efficiently conveys the action with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with no output schema and clear sibling tools, the description is adequate but could be improved by mentioning the comment thread context or response format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents parameters. The description adds no extra meaning beyond the schema, meeting the baseline but not compensating for missing details like comment formatting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Leave a comment' on the resource 'existing pull request', which is specific and distinguishes it from sibling tools like create-pull-request or create-repo.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for commenting on an existing PR but provides no explicit guidance on when to use vs. alternatives like approving or merging, nor any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create-pull-requestB

Create a pull request from one branch to another

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Title of the pull request
`description`	Yes	Description of the pull request
`repositoryId`	Yes	ID of the repository
`sourceBranch`	Yes	Source branch name
`targetBranch`	Yes	Target branch name

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description only says 'Create a pull request', adding no behavioral details beyond the name. It does not disclose side effects, permissions, or post-creation behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no wasted words. It is front-loaded and gets straight to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with no output schema or nested objects, but the description is minimal. It does not clarify what the response contains (e.g., PR ID), which could be useful for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 5 parameters are fully described in the input schema (100% coverage). The description adds no additional meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Create' and the resource 'pull request' with source and target branches. It distinguishes from sibling tools like comment-on-pr and create-repo.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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, nor any prerequisites or exclusions. The sibling tools provide context but the description itself lacks such information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create-repoB

Create a new repository in Azure DevOps

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Name of the repository to create

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits such as idempotency (e.g., behavior if repo already exists), required permissions, or side effects. The word 'create' implies mutation but lacks detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler words. It is concise and front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple creation tool with one parameter, the description is adequate but minimal. It does not explain return values, error handling, or the expected outcome, which would be helpful for proper invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'name' is fully described in the input schema (100% coverage). The description adds no additional context beyond what the schema already provides, so it meets the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (create) and the resource (repository in Azure DevOps). However, it lacks specificity about the scope (e.g., within a project) which could differentiate it from sibling tools like list-repos.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 list-repos or create-pull-request. No prerequisites or context provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-branchesA

List all branches of a repository

ParametersJSON Schema

Name	Required	Description	Default
`repositoryId`	Yes	ID of the repository

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It only states the action, missing details like authorization needs, error handling, or behavior when repositoryId is invalid. However, for a simple read operation, this is minimally acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. Every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity of a single-parameter list tool, the description covers the core function but lacks mention of return format or edge cases. With no output schema, some additional context would be beneficial but is not strictly required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already describes the repositoryId parameter adequately. The description adds no additional 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'all branches of a repository', which distinguishes it from siblings like get-commits or list-repos. It is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is given on when to use this tool versus alternatives. Usage is implied by the description, but no exclusions or context are provided. This is adequate for a straightforward tool but lacks depth.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-commitsC

Get commit history for a repository

ParametersJSON Schema

Name	Required	Description	Default
`branch`	Yes	Branch name
`repositoryId`	Yes	ID of the repository

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden for behavioral disclosure. It does not mention whether the operation is read-only, requires authentication, or has pagination, ordering, or limits. The single sentence is insufficient for behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core function, though it could be slightly expanded without hurting conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with 2 required parameters and no output schema, the description is incomplete. It omits details like commit ordering, pagination, and result format. An agent may need additional context to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema covers 100% of parameters with descriptions. The description adds no extra meaning beyond the schema. Baseline 3 is appropriate since schema already documents parameters adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get commit history for a repository' clearly indicates the action (Get) and resource (commit history). It is specific enough to distinguish from sibling tools like list-repos or get-branches.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, such as when to use list-pipelines for pipeline history or get-branches for branch details. The description lacks context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-pipelinesA

List all pipelines in the project

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It only states 'List all pipelines', without disclosing behavioral traits such as pagination, permissions, or whether it returns metadata. Minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no waste. It is front-loaded with the key action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and no output schema, the description is minimally adequate. However, it does not specify the project context (e.g., 'in the current project') or any scope, leaving some ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so schema coverage is trivially 100%. The description adds no parameter information, which is acceptable as there are none to describe.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List all pipelines in the project' uses a specific verb ('List') and resource ('pipelines'), clearly distinguishing it from siblings like 'comment-on-pr' or 'create-repo'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing pipelines, but no explicit guidance on when to use this vs alternatives or when not to use it. The sibling names provide context, but the description itself lacks direct guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-reposA

List all repositories in the organization

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, so description carries full burden. States it lists repos but doesn't mention pagination, returned fields, or any mutation behavior. Adequate for a simple list.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no wasted words. Efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, could describe return format or pagination. Missing detail but adequate for a simple list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters, so description doesn't need to add param info. Schema coverage is 100% with empty properties, baseline score 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb 'list' and resource 'repositories' with scope 'all in the organization'. No confusion with siblings as they are different actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or alternatives. Implied by lack of sibling with similar purpose, but no guidance on when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

trigger-pipelineC

Trigger a CI pipeline with parameters

ParametersJSON Schema

Name	Required	Description	Default
`parameters`	Yes	Pipeline parameters
`pipelineId`	Yes	ID of the pipeline

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, and the description does not disclose behavioral traits such as side effects (e.g., whether a build is started), idempotency, or rate limits. The phrase 'trigger' implies a mutable action but no further details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short (5 words), which is concise but not necessarily effective. It sacrifices clarity and completeness for brevity. Could be more informative without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, so description should hint at return values (e.g., pipeline run ID). It does not. For a tool with a complex nested parameter (additionalProperties), no guidance on valid keys is given. Incomplete for a state-changing operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (both parameters described), so baseline is 3. The description adds little beyond the schema: it mentions 'with parameters' but does not explain valid keys for the parameters object, which has additionalProperties allowing arbitrary fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (trigger) and resource (CI pipeline). It is specific enough to distinguish from sibling tools like list-pipelines, but lacks detail about which CI system or what triggering entails.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidelines are provided. There is no mention of when to use this tool vs alternatives, prerequisites (e.g., pipeline must exist), or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv1.0.0Apr 19, 2025
- First observedcomment-on-pr
- First observedcreate-pull-request
- First observedcreate-repo
- First observedget-branches
- First observedget-commits
- First observedlist-pipelines
- First observedlist-repos
- First observedtrigger-pipeline

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool targets a distinct operation: commenting on PRs, creating PRs, creating repos, listing branches, getting commits, listing pipelines, listing repos, and triggering pipelines. No two tools have overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent hyphenated lowercase verb-noun pattern (e.g., comment-on-pr, create-pull-request, get-branches). No mixing of conventions.

Tool Count5/5

8 tools is well-scoped for a DevOps server covering repository, branch, commit, pull request, and pipeline operations. Each tool serves a clear purpose without being excessive.

Completeness3/5

Core workflows are covered (create/list repos, branches, commits, PRs, pipelines), but missing important operations like get pull request details, update/delete repos or PRs, and pipeline status checks. Gaps could hinder full automation.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Azure DevOps (ADO)OAuth
io.github.PremierInc
The MCP server for Azure DevOps, bringing the power of Azure DevOps directly to your agents.
CI/CD & DevOps Version Control Project Management
21,997
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
ArletOAuth
dev.arlet
Create, deploy, and operate MCP servers directly from your GitHub repositories.
Developer Tools CI/CD & DevOps
2
serverOAuth
com.devopness.mcp
Devopness MCP server for DevOps happiness! Empower AI Agents to deploy apps and infra, to any cloud.
Cloud Platforms CI/CD & DevOps Developer Tools
3

Related MCP Servers

Git PR MCP Server
Version Control Developer Tools
peterj
F
license
Not graded
quality
D
maintenance
An MCP server that enables Git repository operations and GitHub PR workflows, allowing users to manage repositories, create branches, commit changes, and create pull requests through natural language.
Updated a year ago (2025-06-07 22:15 UTC)
2
-
Ares DevOps MCP Server
Version Control CI/CD & DevOps Developer Tools
MCP-Mirror
F
license
Not graded
quality
Not graded
maintenance
Enables seamless interaction with Azure DevOps for managing Git repositories, branches, and pull requests through natural language. It also supports automating and monitoring pipelines while providing secure, type-safe operations within MCP-compatible clients.
Updated a year ago (2025-06-25 18:09 UTC)
14
-
Azure DevOps MCP Server
CI/CD & DevOps Version Control Developer Tools
iimsaurav
A
license
A
quality
C
maintenance
An MCP server that exposes 41 Azure DevOps tools to AI assistants, enabling management of pipelines, repositories, pull requests, releases, work items, test management, and wikis through natural language.
Updated 5 months ago (2026-04-04 05:56 UTC)
41
MIT
Azure DevOps MCP Server
Cloud Platforms CI/CD & DevOps Version Control
varnierg
A
license
Not graded
quality
B
maintenance
MCP server that enables AI assistants to manage Azure DevOps resources including Work Items, Git repositories, pipelines, and user identities.
Updated 2 months ago (2026-07-04 23:53 UTC)
34
MIT

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Cognitive-Stack/ares-devops-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server