Servidor MCP (Model Context Protocol) para obtener habilidades de DevOps desde GitHub (plantillas de documentación de SAP Fiori, estándares de código, mejores prácticas).
Instala el paquete:
npm install -g @devops-vinci/mcpHaz clic en este enlace para configurar automáticamente VS Code (completamente preconfigurado):
📦 Instalar DevOps MCP - Vinci Energies
✅ ¡Eso es todo! No se necesita ninguna configuración adicional.
npm install -g @devops-vinci/mcpLuego, añade esta configuración a .cursor/mcp.json:
{
"mcpServers": {
"devops": {
"command": "npx",
"args": ["@devops-vinci/mcp"],
"env": {
"GITHUB_OWNER": "devops-vesi",
"GITHUB_REPO": "devops-skills"
}
}
}
}Related MCP server: mcp-bitbucket-dc
list_skillsEnumera todas las habilidades de DevOps disponibles en tu repositorio de GitHub.
fetch_skillObtiene el contenido de una habilidad específica desde GitHub.
Simplemente pregúntale a Copilot:
"List available skills"
"Fetch the documentation-templates skill"
"Generate documentation for this Fiori project"
MIT
Fetches a DevOps skill from GitHub (documentation templates, code standards, best practices). Use when the user requests to generate documentation, apply standards, or use a template.
| Name | Required | Description | Default |
|---|---|---|---|
| skillName | Yes | The name of the skill to fetch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Adds valuable context about external source (GitHub) and content structure. However, lacks disclosure of error behavior (missing skill), caching, return format, or safety profile (read-only vs destructive).
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?
Two well-structured sentences with zero waste: first defines operation and content, second specifies usage trigger. Information is front-loaded and appropriately sized for a single-parameter tool.
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?
For a simple fetch tool with 100% schema coverage and no output schema, the description adequately covers purpose, source, and usage context. Minor gap: could explicitly mention relationship to list_skills for skill discovery.
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 has 100% description coverage ('The name of the skill to fetch'), establishing baseline 3. Description does not add syntax details, examples, or constraints (e.g., case sensitivity, naming conventions) beyond what the schema provides.
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?
States specific verb ('Fetches'), resource ('DevOps skill'), source ('GitHub'), and content types ('documentation templates, code standards'). The action clearly contrasts with sibling 'list_skills' (retrieve content vs enumerate available items).
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?
Provides explicit positive guidance ('Use when the user requests to generate documentation, apply standards, or use a template'). Lacks explicit negative constraints or mention of when to use sibling 'list_skills' first to discover available skill names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all available DevOps skills (SAP Fiori documentation templates, code standards, best practices). Use this tool BEFORE generating documentation or reading project content.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional category to filter skills |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full behavioral burden, yet discloses only scope ('Lists all available'). Omits idempotency, side effects, caching behavior, rate limits, or auth requirements. 'Lists' implies read-only but doesn't explicitly confirm safety.
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?
Two sentences with zero waste: first establishes purpose and scope, second provides workflow guidance. Front-loaded with critical information and appropriate length for tool complexity.
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 simple list operation with single optional parameter. However, lacks output schema and description doesn't compensate by describing return structure (array format, skill object fields), leaving response format ambiguous.
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 'category' parameter fully described as 'Optional category to filter skills'. Description adds no additional parameter semantics, but baseline 3 is appropriate since schema requires no compensation.
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?
Description provides specific verb ('Lists') + resource ('DevOps skills') with concrete examples in parentheses (SAP Fiori documentation templates, code standards, best practices). The 'list' vs sibling 'fetch' naming pattern clearly distinguishes catalog retrieval from individual retrieval.
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?
Excellent temporal guidance with 'Use this tool BEFORE generating documentation or reading project content,' establishing clear workflow sequencing. Lacks explicit mention of sibling tool as alternative for specific skill retrieval, but provides strong positive guidance.
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.
v1.0.1fetch_skilllist_skillsThe two tools have clearly distinct purposes: 'fetch_skill' retrieves a specific skill for generating documentation or applying standards, while 'list_skills' enumerates all available skills to inform selection. There is no overlap or ambiguity between them.
Both tools follow a consistent verb_noun pattern ('fetch_skill', 'list_skills'), using snake_case throughout. The naming is predictable and aligns with common conventions for tool design.
With only 2 tools, the server feels thin for a 'DevOps MCP' scope, which typically involves broader operations like deployment, monitoring, or automation. This limited set may not adequately cover the expected domain.
The toolset is severely incomplete for DevOps, lacking essential operations such as managing deployments, configuring infrastructure, or handling CI/CD pipelines. It focuses narrowly on skills/templates, leaving significant gaps in core DevOps workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A MCP server built for developers enabling Git based project management with project and personal…
Devopness MCP server for DevOps happiness! Empower AI Agents to deploy apps and infra, to any cloud.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
The OpenZeppelin Stellar Contracts MCP server generates secure smart contracts for the Stellar blockchain based on OpenZeppelin templates. It integrates with AI assistants to automatically enforce OpenZeppelin's security best practices, style rules, and standards at every prompt, enabling developers to create production-ready Fungible Token, Non-Fungible Token, and Stablecoin contracts through AI-driven workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/devops-vesi/devops-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
