Skip to main content
Glama
dave1362

UML Forge

by dave1362
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

umlforge_deployment

Read-only

Generate deployment topology and CI/CD pipeline diagrams to map cloud infrastructure, service connections, environments, gates, and rollbacks. Plan disaster recovery and DevOps handovers.

Instructions

Generate a deployment topology and CI/CD pipeline diagram.

USE THIS WHEN:

  • You want to visualise your cloud infrastructure and how services connect

  • You need to document your CI/CD pipeline from commit to production

  • You are planning infrastructure, disaster recovery, or a DevOps handover

NOT FOR:

  • Application-level architecture (how code is structured) → use umlforge_reverse_engineer

  • Security threat modelling → use umlforge_threat_model

  • How services call each other at the API level → use umlforge_api_sequence

Produces:

  • Deployment diagram: nodes, artefacts, network paths, protocol/port labels, internet-facing vs internal traffic distinction

  • CI/CD pipeline flow: commit → build → test → staging → production, automated gates, manual approvals, rollback paths

  • Deployment environment table: infrastructure, triggers, data classification, monitoring, rollback strategy per environment

  • Infrastructure risk note: SPOFs, missing redundancy, environment parity gaps

  • Observability gap flags (⚠️) for services without /health endpoints

  • (report_mode=True) Infrastructure Health Report: reliability score, observability score, deployment safety score (A–F)

Args: system_name: Name of the system (e.g. "UML Forge API"). cloud_provider: Cloud provider(s) (e.g. "AWS", "Railway + Vercel", "GCP"). environments: Deployment environments (e.g. "development, staging, production"). services: Services and infrastructure (e.g. "FastAPI API, Next.js, PostgreSQL, Redis"). cicd_tool: CI/CD tool (e.g. "GitHub Actions", "GitLab CI") (optional). report_mode: True → also produce an Infrastructure Health Report. Pro/Team/Enterprise only. Omit to use your saved account preference (dashboard toggle); False forces diagrams only.

Input Schema

NameRequiredDescriptionDefault
servicesYes
cicd_toolNo
report_modeNo
system_nameYes
environmentsYes
cloud_providerYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.3.0
    • addedInput schema / properties / report_mode / anyOf
      Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / report_mode / default
      Previous value: -falseNew value: +null
    • removedInput schema / properties / report_mode / type
      Removed value: -"boolean"
  2. Addedv0.2.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context: report_mode is gated to Pro/Team/Enterprise, omitting it falls back to a saved dashboard preference, and False forces diagrams only. It does not mention persistence of generated diagrams or latency, but the tier-gating detail is meaningful beyond the annotations.

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?

Well front-loaded: purpose sentence first, then when/when-not, then outputs, then args. The 'Produces' block runs six bullets and overlaps with the existing output schema, which is mild redundancy, but every section is scannable and labelled.

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 6-parameter generation tool, the definition covers purpose, alternatives, output contents, tier gating, and every argument with an example. The output_schema already exists, making the 'Produces' enumeration partly redundant, but nothing an agent needs in order to call this correctly is missing.

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?

Schema description coverage is 0% across 6 parameters, so the description carries the full burden — and it does, supplying an example value for every argument (cloud_provider: 'AWS', 'Railway + Vercel'; environments: 'development, staging, production'; cicd_tool: 'GitHub Actions'). It stops short of format rules such as delimiters or max lengths, but the examples are the operative guidance an agent needs.

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 opening sentence gives a specific verb+resource: generate a deployment topology and CI/CD pipeline diagram. The 'NOT FOR' section explicitly names three sibling tools and the neighbouring concerns they cover, so an agent can route without opening any schema.

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

Usage Guidelines5/5

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

Three 'USE THIS WHEN' bullets describe when the tool fits (infrastructure visualisation, pipeline documentation, DR/DevOps planning) and three 'NOT FOR' bullets name the alternatives (umlforge_reverse_engineer, umlforge_threat_model, umlforge_api_sequence) with the condition that selects each.

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

Deploy Server

Other Tools