UML Forge

Overview Schema Source Related Servers Discussions Admin

umlforge_ai_agent

Read-only

Design and visualize AI agent pipelines and multi-agent orchestration systems, mapping LLM tool calls, handoffs, memory, and failure behavior.

Instructions

Design an AI agent pipeline or multi-agent orchestration system.

USE THIS WHEN:

You are building a system where LLMs call tools or hand off to other agents
You want to visualise a multi-agent workflow (planner ? researcher ? writer)
You need to document tool access, memory strategy, and failure behaviour

NOT FOR:

General system architecture ? use umlforge_stakeholder_arch
Standard synchronous API flows ? use umlforge_api_sequence
Event-driven pipelines without LLM agents ? use umlforge_event_driven

Produces:

Agent pipeline sequence: agents as participants with model names, tool calls as self-calls, human-in-the-loop gates, retry/fallback logic
Agent component map: agents, tool deps, memory, external integrations
Agent responsibility matrix: model, role, tools, inputs, outputs, failure behaviour
Risk & observability note: hallucination hotspots, validation gates, logging points
Tool overload flags (??) for agents with more than 5 tools
(report_mode=True) Agent Pipeline Analysis Notes: pipeline risks, coverage gaps, reliability quick wins

Args: pipeline_purpose: What the agent system does (e.g. "Research pipeline that queries the web and drafts a report"). agents: Agents and their roles (e.g. "Planner [claude-opus-4], Researcher [claude-sonnet-4]"). tools_available: Tools agents can call (e.g. "web_search, execute_code") (optional). orchestration_approach: Coordination strategy ? sequential, DAG, hierarchical, parallel fan-out (optional). memory_strategy: Memory approach ? shared context, vector memory, Redis, none (optional). report_mode: True ? also produce Agent Pipeline Analysis Notes. Pro/Team/Enterprise only.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`agents`	Yes
`report_mode`	No
`memory_strategy`	No
`tools_available`	No
`pipeline_purpose`	Yes
`orchestration_approach`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.9Jul 21, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations cover the safety profile (readOnlyHint, openWorldHint, destructiveHint), so the bar is lower. The description adds material value beyond that: the Produces list enumerates exactly what artifacts are generated, including the tool-overload flag for >5 tools and the report_mode-gated analysis notes. It does not disclose processing time or any limits, keeping it short of a 5.

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?

Front-loaded summary followed by clearly demarcated USE THIS WHEN / NOT FOR / Produces / Args sections. Each line earns its place; no filler prose.

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

Completeness5/5

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

An output schema exists, so return values need not be explained, and the Produces section nonetheless previews them. Usage scope, parameter examples, sibling routing, and feature gating are all present. Nothing an agent needs 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%, so the description must compensate. It does so with example-laden Arg descriptions for all six parameters, showing expected format for pipeline_purpose, agents, tools_available, orchestration_approach, and memory_strategy, and gating report_mode to Pro/Team/Enterprise. It even documents a hidden constraint (tool overload at >5 tools) that no schema field expresses.

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?

States a specific verb+resource ('Design an AI agent pipeline or multi-agent orchestration system') and explicitly distinguishes itself from siblings by naming umlforge_stakeholder_arch, umlforge_api_sequence, and umlforge_event_driven with their conditions. 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?

Explicit USE THIS WHEN section lists three concrete triggers, NOT FOR section names three sibling tools and the scenarios each should handle. This is textbook when/when-not/alternatives routing.

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

Deploy Server