Refine a System Blueprint with MCP guidance

A scan gives you a strong starting point for a System Blueprint. Your knowledge of the system turns that starting point into an accurate model of its boundaries, Components, Resources, and Execution flows. This guide shows you how to evaluate that model, investigate uncertainties, and use an MCP-capable coding agent to apply an evidence-backed correction when one is needed.

Before you begin

You will need:

• Model Monster MCP connected to your coding agent ( Connect Model Monster MCP)
• The saved System Blueprint and source from AI-Assisted Blueprint Modeling
• Member-or-higher content-edit access if you plan to apply a correction

Review the Blueprint against the real system

If you have closed the session with the agent that scanned your repo, re-open your session or make sure your fresh agent is examining the correct system. Double-check that the organization, team, and system names are correct and match what you expect.

As the engineer who knows the system, you are the authority on whether the Blueprint represents it accurately. Bring your knowledge of its architecture, deployment, and behavior to the review. Your agent can support you by organizing observations, comparing evidence, and investigating specific uncertainties.

Check the Blueprint through four lenses

• System boundaries: Identify what belongs inside the system and what belongs to an upstream dependency, downstream consumer, operator tool, or shared service. Check whether the trust, deployment, and ownership boundaries match the way the system operates.
• Components: Confirm that each material service, model, agent, processing step, and control point appears at the right level. Compare repeated deployments, aliases, and distinct products with how they exist in the real system.
• Resources: Check the databases, object stores, queues, APIs, model endpoints, files, management surfaces, and user inputs or outputs that Components can reach. Confirm that the recorded read, write, delete, execute, or grant Operations match real behavior.
• Execution flows: Trace important requests, responses, retrieved context, prompts, model outputs, logs, and persistence paths in their real direction. For a two-way interaction, confirm both directions.

Choose validation techniques

Start with the technique that best fits the question you want to resolve. Combine techniques when a finding needs more than one kind of evidence.

• Mental walkthrough: Narrate a familiar user or operational scenario from entry to outcome. Identify the Component, Resource, and Execution flow responsible for each transition. This is often enough to reveal whether the Blueprint reflects an architecture you know well.
• Boundary and inventory review: Compare the Blueprint with known deployment units, owners, integration boundaries, and reachable assets. This can reveal missing material elements, duplicates, or items that belong outside the system.
• End-to-end Execution flow tracing: Select one meaningful path and follow it hop by hop. Include return, retrieval, persistence, logging, and asynchronous paths when relevant. Use this to check direction, intermediate processing, and Resource Operations.
• Targeted source or configuration comparison: Inspect the authorized implementation, deployment configuration, architecture record, or runtime evidence that answers a specific question. Use this when implementation detail decides the answer.
• Agent-assisted investigation: Give your agent one concrete question. Ask it to compare the relevant part of the Blueprint with available classification choices, catalog information, or authorized source evidence, then weigh its findings against your knowledge of the system.

Keep a short review record of what you confirmed, the discrepancies you found, and any questions that remain unresolved. For each proposed correction, note the knowledge or evidence that supports it.

For example, the demo OPEA ChatQnA Blueprint classifies vLLM (Meta-Llama-3-8B-Instruct) as Unknown. OPEA's ChatQnA documentation identifies it as the LLM backend, while Model Monster's taxonomy describes it as a Model with the LLM subtype and API interface tag. Together, that evidence supports one focused correction: classify the vLLM Component as Model, LLM, and API while keeping its existing connections and risk tags unchanged.

If the Blueprint already matches your understanding of the system, you are done. Keep your review notes as the record of what you checked and the evidence you used.

Make and confirm an evidence-backed correction

When your review identifies a supported correction, use this short sequence. Keep evidence, prompts, and proposed changes focused on architecture and categories of sensitive data. Leave out credentials, tokens, actual personal data, customer content, and source excerpts containing secrets.

1. Propose and preview the change. Ask your agent to connect one confirmed finding to its evidence, propose the smallest coherent correction, explain its effect, and preview it without applying it. For a new item or connection, confirm that the preview adds the intended item and represents the connection in the correct direction.

   Based on this finding and evidence, propose the smallest correction, explain its expected effect, and preview it without applying it. Include any guidance returned by Model Monster.

2. Review and approve the proposal. Compare the proposal and predicted effect with your understanding of the system. Approve the exact proposal when it matches the evidence. Preview and approve again if it changes materially.

3. Apply and confirm the result. Ask your agent to apply the approved proposal. Review the result, then open the returned Model Monster System link or request a fresh snapshot to confirm that the saved Blueprint matches what you approved. If the Blueprint changed in the meantime, refresh it and repeat the preview.

You are finished when the same saved Blueprint contains the evidence-backed refinement in its editable Draft.

Next: Add use-case context

Continue with Add system context and check readiness. The next tutorial uses this same System Blueprint to add use-case context and check readiness.