Skip to main content
Glama
dave1362

UML Forge

by dave1362
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

umlforge_event_driven

Read-only

Design event-driven messaging architectures with producers, brokers, and consumers. Model pub/sub flows, failure handling, and idempotency for reliable async systems.

Instructions

Design an event-driven or async messaging architecture (Kafka, SQS, RabbitMQ, etc.).

USE THIS WHEN:

  • Services communicate via events or messages (not direct API calls)

  • You are designing event sourcing, CQRS, or pub/sub patterns

  • You want to model producer → broker → consumer flows with failure handling

NOT FOR:

  • Synchronous REST/gRPC calls between services → use umlforge_api_sequence

  • Entity lifecycle (Order goes pending → active) → use umlforge_state_machine

  • Full system architecture overview → use umlforge_stakeholder_arch

Produces:

  • Event flow sequence: producers → broker → consumers with ack, retry loops (max N), dead-letter queue handling

  • Event catalogue table: name, producer, consumers, payload, idempotency, retention

  • Choreography vs orchestration assessment with coupling risk flags

  • Failure mode analysis: scenario, impact, detection, recovery

  • (report_mode=True) Event System Analysis Notes: reliability risks, idempotency gaps, resilience quick wins

Args: system_context: What this event-driven system does and why it uses messaging. producers: Services that emit events (e.g. "Order Service emits order.placed"). consumers: Services that consume events (e.g. "Notification, Inventory, Analytics"). broker: Message broker (e.g. "Kafka", "RabbitMQ", "AWS SQS/SNS") (optional). events: Named domain events (e.g. "order.placed, payment.failed") (optional). report_mode: True → also produce Event System Analysis Notes. Pro/Team/Enterprise only. Omit to use your saved account preference (dashboard toggle); False forces diagrams only.

Input Schema

NameRequiredDescriptionDefault
brokerNo
eventsNo
consumersYes
producersYes
report_modeNo
system_contextYes

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.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real context beyond that: the exact artifacts produced (sequence flow with ack/retry/DLQ, event catalogue, choreography-vs-orchestration assessment, failure mode table) and the plan gating for report_mode (Pro/Team/Enterprise plus the dashboard-preference default). It does not clarify whether output is persisted as a document or returned transiently, which is the remaining gap.

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?

Strongly front-loaded and header-scaffolded (USE THIS WHEN / NOT FOR / Produces / Args), so an agent can scan to the decision-relevant lines. It runs somewhat long overall, and the Produces list restates artifacts partly implied by output_schema, but nothing is padding.

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 six-parameter generative design tool with an output schema and read-only annotations, the definition covers purpose, routing, inputs and deliverables adequately. The one soft spot is that report_mode's relationship to the rest of the output and any plan/quota consequences are only partially spelled out.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the entire burden, and it does: every one of the six parameters is documented in the Args block with meaning plus concrete examples (e.g. producers: 'Order Service emits order.placed'; broker: 'Kafka', 'AWS SQS/SNS'). report_mode's optionality and null-default behavior (omit → saved preference, False → diagrams only) are explained in a way the bare anyOf/null schema cannot convey.

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 first sentence states a specific verb+resource: 'Design an event-driven or async messaging architecture', with concrete technology examples (Kafka, SQS, RabbitMQ). The NOT FOR block explicitly names and contrasts three sibling tools (umlforge_api_sequence, umlforge_state_machine, umlforge_stakeholder_arch), so an agent can disambiguate 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?

USE THIS WHEN lists three concrete triggering conditions (event/message-based communication, event sourcing/CQRS/pub-sub, producer→broker→consumer flows), and NOT FOR routes the three most likely confusions to named alternatives. This is the full when/when-not/alternatives pattern.

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