UML Forge

Overview Schema Source Related Servers Discussions Admin

umlforge_onboarding

Read-only

Generate a day-one onboarding package for developers joining a team: system overview diagrams, key workflows, and gotchas to speed up ramp-up.

Instructions

Create a day-one knowledge-transfer package for a developer joining a team.

USE THIS WHEN:

A developer is joining a new team or project and needs to get up to speed
You are handing off a module or system to another team
You want gotchas, constraints, and workflow diagrams in one package

NOT FOR:

Analysing existing code for architectural problems → use umlforge_reverse_engineer
Designing a new system → use umlforge_stakeholder_arch
Documenting a specific API flow → use umlforge_api_sequence

Produces:

System overview (C4 Container): the lay-of-the-land on day one
Developer workflow sequence: local dev → test → CI → staging → production
- most common debugging path
Gotchas & constraints table: what the code does, why, what breaks if changed
(report_mode=True) Onboarding Analysis Notes: coverage assessment, knowledge gaps, documentation quick wins

Args: system_description: High-level description of the system. tech_stack: Technologies in the stack (e.g. "FastAPI, PostgreSQL, React, Railway"). key_workflows: 2–3 flows a new developer must understand first. pain_points: Known gotchas, non-obvious decisions (optional). report_mode: True → also produce Onboarding Analysis Notes. Pro/Team/Enterprise only. Omit to use your saved account preference (dashboard toggle); False forces diagrams only.

Input Schema

Name	Required	Description	Default
`tech_stack`	Yes
`pain_points`	No
`report_mode`	No
`key_workflows`	Yes
`system_description`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.3.0Oct 16, 2026
- 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"
```
Addedv0.2.0Sep 4, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the description's job is to add context it does. It does: it discloses the report_mode plan gating (Pro/Team/Enterprise only) and the saved-preference fallback when omitted, plus the concrete artifacts produced. It stops short of stating latency, cost, or whether report_mode changes output size materially, so not 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Structure is strong and front-loaded: one-line purpose, then USE WHEN, NOT FOR, Produces, Args. The Produces list is slightly longer than strictly necessary, but each bullet describes a distinct artifact the agent may need to reason about, so little is wasted.

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?

With an output schema present the description need not explain return values, yet its Produces section aligns cleanly with what is generated. Combined with the explicit when/when-not routing and complete arg documentation for a 5-param, 3-required tool, an agent has everything needed to invoke it correctly.

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 full parameter burden and does so: every one of the five params is documented in the Args block, with format examples for tech_stack, a cardinality constraint for key_workflows ("2–3 flows"), optionality flagged for pain_points, and full semantics plus plan/toggle interaction for report_mode.

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 line gives a specific verb+resource+audience: "Create a day-one knowledge-transfer package for a developer joining a team." The NOT FOR section explicitly names the sibling tools it must not be confused with (reverse_engineer, stakeholder_arch, api_sequence), so an agent can disambiguate without opening other schemas.

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 bullets cover the three triggering scenarios (new joiner, handoff, gathering gotchas/diagrams). The NOT FOR block routes three adjacent intents to the correct siblings, giving both positive and negative usage conditions with no inference required.

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

Deploy Server