Which integrations are available for this server?

Provides tools for Git repository operations including creating new repos, importing repos, creating branches, archiving repos, and syncing backups. Integrates with GitHub to create repositories, import them with backup remotes, and manage branches and archives via the GitHub CLI.

How do I use agent-services-mcp?

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., "@agent-services-mcp Create a new repo called my-app" 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.

agent-services-mcp

by ludoplex

Overview Schema Related Servers Score Discussions

TypeScript

Local

agent-services-mcp

MCP Server for Git operations, agent templates, and project utilities.

Features

Git Operations (Token Savings: 85-95%)

Tool	Description	Token Savings
`git_new_repo`	Create new GitHub repo with backup	~950 tokens
`git_import_repo`	Clone and configure backup remote	~470 tokens
`git_new_branch`	Create and push branch to all remotes	~280 tokens
`git_archive_repo`	Archive with final backup push	~375 tokens
`git_sync_backup`	Sync to backup remotes	~280 tokens

Templates

Tool	Description
`templates_list`	List available agent instruction templates
`templates_get`	Get template content by name

Utilities

Tool	Description
`project_structure`	Get project directory structure
`search_files`	Search for files by pattern

Related MCP server: forgejo-mcp

Installation

cd agent-services-mcp
bun install

Usage

As MCP Server

bun run start

Configuration

Add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "agent-services-mcp": {
      "command": "bun",
      "args": ["run", "start"],
      "cwd": "C:\\Users\\rache\\DevProject\\agent-services-mcp",
      "env": {
        "DEVPROJECT_ROOT": "C:\\Users\\rache\\DevProject"
      }
    }
  }
}

Environment Variables

Variable	Description	Default
`DEVPROJECT_ROOT`	Project root directory	`~/DevProject`
`AGENT_TEMPLATES_DIR`	Custom templates directory	Auto-detected

Prerequisites

Bun 1.0+
Git
GitHub CLI (gh) - authenticated

License

BSD-2-Clause

Available Tools

9 tools

git_archive_repoC

Archive a repository with final backup push. Saves ~375 tokens.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Repository path
`archiveOnGitHub`	No	Mark as archived on GitHub (default: false)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so the description must carry the burden. It mentions 'final backup push' and 'saves ~375 tokens' but does not disclose whether the operation is destructive, reversible, or requires specific permissions. The behavioral impact beyond the stated action is unclear.

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?

Single sentence, front-loaded with key action and resource. The token saving hint adds value without extra verbosity. Could be slightly more structured, but efficient.

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?

With no annotations or output schema, the description is adequate for a simple tool with two well-documented parameters. However, lacks detail on return values, side effects, or error conditions, leaving some gaps.

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%, so the description adds no additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate as the schema documents both 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 clearly states the verb 'archive' and resource 'repository', and adds 'with final backup push' which distinguishes it from a simple archive. However, it does not explicitly differentiate from sibling tools like git_sync_backup, which may also involve backup.

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. The description does not mention prerequisites, context, or when not to use it. Siblings like git_sync_backup are present but not contrasted.

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

git_import_repoB

Clone an existing GitHub repository and configure backup remote. Saves ~470 tokens.

ParametersJSON Schema

Name	Required	Description
`path`	No	Local path to clone to (optional)
`repo`	Yes	Repository in format 'owner/repo'
`withBackup`	No	Create/configure backup remote (default: true)

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It only mentions cloning and configuring backup, but does not disclose authentication needs, potential overwrites, or error conditions.

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 two sentences, front-loaded with the main action, and contains no fluff. Every word is justified.

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 tool that modifies the local filesystem, the description lacks information about output, error handling, and whether existing directories are replaced. The token savings note is a minor addition.

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%, so the schema already documents all parameters. The description adds 'configure backup remote' which aligns with the withBackup parameter. No new parameter detail is added beyond the schema.

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 'Clone an existing GitHub repository and configure backup remote', which is a specific verb-resource-action pair. This distinguishes it from siblings like git_archive_repo (archive) and git_new_branch (branch).

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 when-not-to-use guidance is provided. The description implies cloning an existing repo, but does not indicate alternatives or prerequisites.

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

git_new_branchB

Create a new branch and push to all configured remotes. Saves ~280 tokens.

ParametersJSON Schema

Name	Required	Description
`base`	No	Base branch (default: current branch)
`name`	Yes	Branch name
`path`	No	Repository path (default: current directory)
`push`	No	Push to all remotes (default: true)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description must disclose full behavioral traits. It mentions the write operations (create, push) but lacks details on preconditions (e.g., branch existence), failure modes, or side effects (e.g., checkout). The token savings mention is a benefit, not a behavioral trait.

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 concise with two sentences, no unnecessary words. However, it could be slightly more structured (e.g., separating the main action from the benefit). It earns its length.

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?

Given the tool's complexity (4 parameters, write operations, no output schema) and lack of annotations, the description is too minimal. It omits critical information such as return values, error handling, and specific behaviors like whether the branch is checked out.

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%, so the baseline is 3. The description adds no new parameter semantics beyond what the schema already provides (e.g., the 'push' parameter is described in both). The token savings remark does not relate to parameters.

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 a new branch') and the additional behavior ('push to all configured remotes'), with the unique benefit of saving tokens. This distinguishes it from sibling tools like git_archive_repo or git_import_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?

The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it state prerequisites or conditions that might preclude its use. It only implies usage for branch creation with automatic push.

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

git_new_repoB

Create a new GitHub repository with optional backup remote. Saves ~950 tokens vs agent-generated commands.

ParametersJSON Schema

Name	Required	Description
`name`	No	Repository name (optional, defaults to directory name)
`path`	Yes	Local path for the repository
`private`	No	Make repository private (default: false)
`withBackup`	No	Create companion backup repository (default: true)
`description`	No	Repository description

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only states basic creation action and optional backup; does not disclose authentication needs, rate limits, or behavior for existing paths (e.g., overwrite vs error).

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?

Two concise sentences, front-loaded with main purpose. Second sentence adds a tangential benefit but is still efficient. No wasted words.

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?

With 5 parameters, no output schema, and no annotations, description is too minimal. Does not explain return values, what constitutes a backup remote, or path usage details. Incomplete for a tool of this complexity.

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%, so baseline is 3. Description adds no extra meaning beyond what schema already provides (e.g., 'optional backup remote' maps to withBackup param, already described).

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?

Description clearly states 'Create a new GitHub repository with optional backup remote', providing a specific verb and resource. The mention of backup remote distinguishes this from siblings like git_import_repo or git_archive_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. The token savings claim is irrelevant to decision-making. Lacks explicit when-not or references to sibling tools.

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

git_sync_backupC

Sync local repositories to their backup remotes. Saves ~280 tokens.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Repository or directory path
`dryRun`	No	Show what would be done without doing it
`recursive`	No	Process all repos in directory (default: false)

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It says 'sync' and mentions token savings, but does not disclose whether this is a read-only or destructive operation, what happens on conflict, or any side effects.

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 short at two sentences, but the second sentence about token savings is tangential and may confuse agents. It earns its place minimally.

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?

Given no output schema and only three parameters, the description should elaborate on return values, error handling, or prerequisites. It lacks completeness for safe agent 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?

Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning to the parameters beyond what the schema already provides.

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 tool syncs local repositories to backup remotes, which is specific and distinguishes it from siblings like git_archive_repo or git_new_repo. However, it doesn't clarify whether sync includes push, pull, or both.

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. The description provides no context for appropriate usage or exclusions, leaving the agent to infer.

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

project_structureB

Get the directory structure of a project

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Project path
`depth`	No	Maximum depth (default: 3)
`includeHidden`	No	Include hidden files (default: false)

TDQS

B3.2/5.0

Behavior2/5

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

No annotations, so the description must disclose behaviors. It only states basic purpose but omits details like output format, handling of hidden files, depth behavior, or error scenarios.

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 redundancy. Efficient and front-loaded.

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?

With 3 parameters and no output schema, the description is too brief. It doesn't clarify the return structure, which is critical for tool 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?

Schema description coverage is 100%, so baseline is 3. The description adds no further parameter meaning beyond the schema.

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 tool retrieves the directory structure of a project, with specific verb and resource. It distinguishes from sibling tools like git operations and search_files.

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 search_files or git tools. The description does not mention exclusions or context.

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

search_filesC

Search for files by name pattern

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Search root path
`pattern`	Yes	File name pattern (glob)
`maxResults`	No	Maximum results (default: 50)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations exist, so the description must fully disclose behavior. It only states the action without revealing search scope (recursive?), file type handling, or performance implications. This is insufficient for an agent to predict tool side effects.

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, concise sentence that communicates the core purpose without any extraneous text. It is efficiently front-loaded.

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?

Given the absence of annotations and output schema, the description fails to cover important aspects like return format, recursion behavior, or error handling. It is too minimal for a tool with 3 parameters and no output schema.

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% with descriptions in the input schema. The description adds no extra meaning beyond the schema, so it meets the baseline expectation but does not compensate for schema limitations.

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 'Search for files by name pattern' clearly states the action (search) and resource (files) with a specific criterion. It is direct and unambiguous, but lacks distinction from potential siblings, though none directly compete.

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 or alternatives. The description does not mention any prerequisites, limitations, or context, leaving the agent without clues for decision-making.

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

templates_getC

Get the content of an agent instruction template

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Template name or partial match

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only states the action without revealing any side effects, required permissions, or output characteristics.

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 a single sentence that is concise but overly minimal. It lacks structure and does not front-load important usage details.

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?

Given the simplicity of the tool (one parameter, no output schema), the description should clarify what 'template content' includes and how partial matching works. It fails to provide this context.

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 input schema covers 100% of parameters with a description for 'name'. The tool description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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 (get) and the resource (content of an agent instruction template). It effectively distinguishes from the sibling tool 'templates_list' by focusing on content retrieval rather than listing.

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 like 'templates_list'. There is no mention of prerequisites, limitations, or context where this tool is appropriate.

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

templates_listA

List available agent instruction templates

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

Without annotations, the description should clarify behavioral traits. It only states basic functionality; no mention of side effects, read-only nature, or permissions. For a simple list operation, this is minimally adequate but not transparent.

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 wasted words. It is front-loaded and directly conveys the tool's purpose.

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

Completeness4/5

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

For a parameterless listing tool with no output schema, the description is largely sufficient. However, it could briefly mention that the result is a list of template names or IDs, but given simplicity, completeness is high.

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 the input schema fully covers parameter semantics. The description adds no parameter info, but none is needed. Baseline score of 4 applies for 0 parameters.

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 ('List') and resource ('available agent instruction templates'), distinguishing it from sibling tools like templates_get which likely retrieves a specific template.

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. The description does not mention prerequisites, context, 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.

9 tool updatesv1.0.0Jun 28, 2026
- First observedgit_archive_repo
- First observedgit_import_repo
- First observedgit_new_branch
- First observedgit_new_repo
- First observedgit_sync_backup
- First observedproject_structure
- First observedsearch_files
- First observedtemplates_get
- First observedtemplates_list

Install Server

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

TDQS

B3.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: git operations cover different actions (archive, import, new branch, new repo, sync backup), project tools (structure, search) are separate, and template tools (list, get) are distinct. No overlap between tools.

Naming Consistency4/5

Most tools follow a verb_noun pattern with domain prefixes (git_, templates_), except project_structure and search_files which lack a prefix. While all use snake_case and are readable, the inconsistent prefix usage slightly reduces consistency.

Tool Count5/5

9 tools is well-scoped for a server covering git operations, project exploration, and template management. Each tool serves a clear purpose without being excessive or insufficient for the apparent domain.

Completeness3/5

The tool set covers core git workflows (create, import, branch, archive, sync) and basic project access, but lacks delete operations, file read/write, and template creation/update, leaving notable gaps for full lifecycle management.

Maintenance

ActivityInactive

ResponsivenessSyncing

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

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
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
JFrog Remote MCP Server
io.github.jfrog
MCP Server for JFrog, providing tools for development and artifact management.
Developer Tools CI/CD & DevOps Cloud Platforms
215
Product Management Mcp D
io.github.varvararatta
MCP server for Product Management
Product Management Project Management
2

Related MCP Servers

GitLab MCP Serverofficial
Version Control Project Management Developer Tools
modelcontextprotocol
-
license
A
quality
A
maintenance
MCP Server for the GitLab API, enabling project management, file operations, and more.
Updated 3 days ago (2026-09-03 01:42 UTC)
9
4,944
90,042
MIT
forgejo-mcp
Version Control Developer Tools
raohwork
A
license
Not graded
quality
D
maintenance
An MCP server for managing your repositories on Forgejo/Gitea server.
Updated 10 months ago (2025-10-28 07:59 UTC)
66
Mozilla Public 2.0
gitlab-api
Version Control CI/CD & DevOps
Knuckles-Team
A
license
Not graded
quality
A
maintenance
MCP server for interacting with GitLab API, supporting dynamic tool selection and enterprise-grade security.
Updated 9 days ago (2026-08-28 18:37 UTC)
10
MIT
Repository Manager
Version Control Developer Tools
Knuckles-Team
A
license
Not graded
quality
A
maintenance
A production-grade MCP server for managing git projects, offering dynamic tool selection and enterprise-grade security.
Updated 9 days ago (2026-08-28 18:38 UTC)
2
MIT

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/ludoplex/agent-services-mcp'

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

agent-services-mcp

Features

Git Operations (Token Savings: 85-95%)

Templates

Utilities

Installation

Usage

As MCP Server

Configuration

Environment Variables

Prerequisites

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

GitLab MCP Serverofficial

Latest Blog Posts

MCP directory API