Uplo Devops

AI-powered DevOps knowledge management. Search runbooks, infrastructure documentation, CI/CD pipelines, and incident response procedures with structured extr...

Security Scan

The skill's stated purpose (DevOps knowledge search) matches the runtime actions, but there are metadata inconsistencies and runtime behaviors (remote MCP via npx and exporting org context) that merit caution because they can expose sensitive organizational data.

Purpose & Capability

The name/description (DevOps knowledge management) aligns with the declared capabilities (search_knowledge, search_with_context, export_org_context, get_directives, etc.) and the SKILL.md workflows. The skill legitimately needs an UPLO instance URL and API key to function.

Instruction Scope

SKILL.md instructs the agent to call functions that will retrieve and (in some examples) export full organizational context (export_org_context), log incident summaries, and find knowledge owners. These actions are in-scope for a knowledge-management skill but can surface or transmit sensitive production and personnel data; ensure classification/access controls are enforced. The instructions do not request unrelated system files or extra credentials.

Install Mechanism

There is no separate install spec in the registry, but skill.json/README show runtime use of 'npx @agentdocs1/mcp-server --http' (the MCP server is fetched from npm at runtime). Fetching and running an npm package at runtime is a moderate-risk operation; the package source (@agentdocs1) should be verified before use. No arbitrary URL downloads or archive extraction were found.

Credentials

Registry metadata initially reported no required env vars, but skill.json declares required config: agentdocs_url and api_key (API key is secret). Those are appropriate for contacting an external UPLO instance, but the mismatch between the registry summary and skill.json is an incoherence that should be corrected. The skill will use those credentials to access possibly sensitive org data — this is expected but high-sensitivity.

Persistence & Privilege

The skill is not 'always:true' and does not request elevated platform-wide privileges. Model invocation is allowed (normal). The skill does not modify other skills or system-wide config based on the provided files.

What to consider before installing

This skill appears to do what it says (index and search DevOps/runbook data), but take precautions before enabling it: 1) Verify and supply a trusted agentdocs_url that points to your organization's UPLO instance (do not use a third-party endpoint you don't control). 2) Treat the API_KEY as a high-sensitivity secret and grant the minimum scope required; review who can use the key. 3) Confirm the npm package @agentdocs1/mcp-server is an expected, trusted component before allowing the skill to run npx (runtime package fetch executes third-party code). 4) Be aware export_org_context and logging operations can transmit full org context or incident details to the UPLO service — test in a non-production environment first and review access classifications. 5) Note the registry metadata omission (required env not listed): ask the publisher to correct the manifest. If you can't validate the npm package or the endpoint, consider running in a restricted environment or rejecting installation.

UPLO DevOps — Operational Memory for Infrastructure

It is 3 AM. PagerDuty is screaming. The on-call engineer who has seen this exact failure pattern left the company four months ago. The runbook exists somewhere, maybe in Confluence, maybe in a GitHub repo, maybe in a Notion page that someone bookmarked. UPLO DevOps eliminates this scramble by indexing runbooks, post-incident reviews, infrastructure documentation, CI/CD configurations, and architecture decision records into a single searchable layer that works when you need it most.

Session Start

get_identity_context

This loads your team assignments (platform, SRE, application), on-call rotation status, and access tier. Some production configurations and credentials documentation are restricted by clearance.

Grab active directives — these include change freeze windows, incident commander designations, and infrastructure migration deadlines:

get_directives

When to Use

• You are on-call, an alert fires for a service you have never touched, and you need the runbook immediately
• Investigating a production incident and need to find whether this failure mode has occurred before, including the root cause and fix
• Planning a migration and need to understand the current architecture, dependencies, and the last three ADRs (Architecture Decision Records) related to the affected service
• Setting up a new CI/CD pipeline and want to see how similar services in the org have configured their build, test, and deploy stages
• Preparing a post-incident review and need to compile the timeline, impacted services, and blast radius from multiple data sources
• A new team member needs to understand the infrastructure topology, deployment process, and escalation paths for their service area
• Evaluating whether a proposed infrastructure change conflicts with documented SLOs or capacity constraints

Example Workflows

Incident Response — Novel Failure Mode

The payments service is returning 503 errors. The on-call engineer has not worked on payments before.

search_knowledge query="payments service 503 error runbook troubleshooting steps"

Check for previous incidents with similar symptoms:

search_with_context query="payments service outage 503 timeout database connection pool previous incidents root cause"

If the runbook suggests checking the connection pool but the current configuration is unclear:

search_knowledge query="payments service database connection pool configuration pgbouncer settings production"

After resolving:

log_conversation summary="Resolved payments 503 outage; root cause was pgbouncer max_client_conn exceeded after traffic spike; matched PIR-2024-087 pattern; increased pool to 200" topics='["incident","payments","pgbouncer","connection-pool"]' tools_used='["search_knowledge","search_with_context"]'

Infrastructure Migration Planning

The platform team is moving from self-managed Kafka to a managed streaming service. The tech lead needs to scope the blast radius.

search_with_context query="Kafka consumers producers services dependencies topic configuration"

Find the ADRs that led to the original Kafka deployment:

search_knowledge query="architecture decision record ADR Kafka event streaming selection rationale"

Check current SLOs and whether the migration might violate them:

search_knowledge query="event streaming SLO latency throughput requirements Kafka p99"

export_org_context

Key Tools for DevOps

search_knowledge — Your go-to during incidents. When you need a specific runbook, a configuration reference, or a known procedure, this is the fastest path. Latency matters at 3 AM. Example: search_knowledge query="redis cluster failover runbook manual promotion steps"

search_with_context — For investigation and planning. "What services depend on this database?" or "Has this failure happened before?" require traversing relationships between services, incidents, and infrastructure components. Example: search_with_context query="auth-service dependencies upstream downstream database cache"

get_directives — Change freeze windows, incident escalation policies, and migration deadlines surface here. Checking before a production change can prevent a career-limiting mistake.

flag_outdated — Infrastructure documentation rots faster than any other type. The Kubernetes cluster version documented last quarter is wrong. The network diagram shows a load balancer that was decommissioned. The runbook references a CLI tool that was replaced. Flag these aggressively — someone will use them during an incident.

report_knowledge_gap — When a service has no runbook, no architecture diagram, or no documented owner, that is an operational risk. Reporting the gap creates a trackable item for the platform team.

Tips

• Service names are the most reliable search key. Use the exact service identifier from your deployment manifests (payments-api, auth-service-v2, order-processor) rather than casual descriptions.
• Post-incident reviews are the most valuable documents in your knowledge base. When writing PIRs, include structured fields: affected services, duration, blast radius, root cause category, and action items. These fields are indexed by the extraction engine.
• When on-call, start with search_knowledge for the runbook. Only escalate to search_with_context if the runbook does not exist or the failure mode is novel. Speed matters during incidents.
• Use log_conversation after every incident investigation, even false alarms. The pattern of false alarms is itself a signal that the monitoring team should investigate.