UI/UX Pro MCP Gives Landing Pages? Get a Dashboard Layout

If UI/UX Pro MCP gives you landing-page direction when you need a dashboard, inspect the actual get_design_system query before changing the design. Use one clear page intent, request output_format: "structured" for diagnosis, then check _meta.detected_intent and layout.source. A missing layout in the default output can be a formatting choice—not an empty design database.

This workflow is for developers who already have UI/UX Pro MCP connected and want a logged-in workspace: navigation, operational data and useful actions rather than a marketing hero. The worked example is a SaaS support queue. You will finish with an inspectable design brief before asking your coding agent to modify the application.

Source scope: checked on October 15, 2026 against repository revision 943385e. We executed its isolated query-classification function for the examples below; we did not run an MCP client session or build the resulting interface. Auto-Bot.io publishes this independent workflow guide; it is not a runtime error report from the project.

1. Identify which layer is actually wrong

Open the tool-call record in your MCP client. Read the arguments sent to get_design_system, not just the original chat message. An agent may compress “create the support dashboard” into a different query, and the server classifies the query it receives.

• The returned intent is landing: investigate the query keywords first.
• The intent is dashboard, but layout is null: check the output format before assuming the search failed.
• The intent and layout source are both dashboard, but the agent still adds a marketing hero: inspect the instructions or guide text the agent followed. Correct classification is not the same as correct implementation.
• The tool is missing or the call fails before returning data: resolve the connection or schema error first. Rewording a page brief cannot repair a disconnected server.

The registered tool definition exposes get_design_system with query, platform, mode and output_format parameters. Check your client's current tool schema if your installed version differs. Do not substitute similarly named tools from a different UI/UX skill or MCP wrapper.

2. Give the query one page intent

The pinned query classifier is keyword-based. It checks recognized multi-word phrases before scanning individual words. Among matching phrases, the earlier phrase wins; without a phrase match, it scans words from left to right.

That makes “put dashboard first” helpful but incomplete advice. A later recognized phrase such as landing page can take priority over the single word dashboard. Negating that phrase in ordinary English does not remove it from the query.

• Negation does not remove the phrase. Query: dashboard without a landing page. Result: landing, matching landing page. Remove the unwanted page type from the tool query; put exclusions in the agent's separate implementation brief.
• A surface keyword can win first. Query: web analytics for a SaaS product. Result: landing, matching web first. Lead with dashboard or admin panel and set the target platform separately.
• Keep the operational request focused. Query: dashboard SaaS support queue. Result: dashboard. Use this as the starting query for the logged-in screen.
• Marketing is a separate deliverable. Query: landing page for a dashboard product. Result: landing. This is appropriate for the public marketing page; treat it as a different request.

These are results from the isolated classifier at the cited revision, not complete design-system responses. The practical rule is to split two deliverables: request the public landing page in one call and the authenticated dashboard in another. Keep product context, but do not ask one query to select both page types.

3. Request inspectable dashboard output

For the support-queue example, ask your agent to call get_design_system with these arguments. This is the tool's arguments object, not a full JSON-RPC request:

{
  "query": "dashboard SaaS support queue",
  "platform": "web",
  "mode": "light",
  "output_format": "structured",
  "max_results": 1
}

Here, platform: "web" states the target surface without placing the word web ahead of the dashboard keyword in the query. Platform and page intent are separate decisions; setting the platform alone does not force dashboard classification.

The current output-filtering code explains a potentially confusing result: the default ai-optimized format deliberately returns layout: null. The minimal format also omits layout data. For this diagnostic task, structured keeps the layout object and implementation checklist while returning an empty markdown_guide. This is a targeted inspection choice, not a recommendation to make every request larger.

Read the returned fields together:

1. _meta.detected_intent: is it dashboard?
2. _meta.matched_keyword: did it match the page type you intended?
3. _meta.warnings: does the query contain conflicting intent signals or lack a recognized intent?
4. layout.source: did the layout come from the dashboard branch?
5. layout.pattern, section_order and grid_config: are they useful enough for your particular screen?

Do not stop at a reassuring intent label. In the pinned implementation, the dashboard branch searches the product data for a layout; if it produces no layout, the code can fall back to the landing-pattern search. A dashboard intent with a landing layout source therefore deserves investigation, not automatic acceptance. A dashboard source is also provenance, not proof that every layout field is complete.

4. Keep the coding agent on the dashboard brief

There is another reason to distinguish returned data from generated guidance. At this revision, the markdown-guide builder includes a “Create Hero Section” step even though the structured implementation checklist has a separate dashboard branch. Seeing a hero instruction does not, by itself, prove that the classifier chose a landing page.

Use the inspected structured result to make a small, explicit handoff. For this example, give the coding agent the following implementation brief separately from the search query:

Build the authenticated support-queue dashboard.
Use the inspected UI/UX Pro MCP result as design guidance.
Keep our existing application shell, components and tokens.
Primary job: find an unassigned ticket and open its details.
Show queue filters, ticket rows, assignment status and actions.
Cover loading, empty, error and populated states.
Do not add public marketing, pricing or signup sections.
If a recommended layout field is empty, flag it before coding.
Return a local preview for review; do not deploy.

This brief is an editorial example, not output claimed from UI/UX Pro MCP. It turns recommendations into a task-specific contract while keeping the product's useful role: retrieving coordinated design guidance instead of asking the coding model to invent every visual decision. For general capabilities and setup context, see our UI/UX Pro MCP overview.

If only one part is weak, retrieve that part rather than regenerating the entire system. The registered search_components tool supports type: "chart"; search_patterns supports type: "ux"; search_stack accepts a framework name. For example, use search_patterns with:

{
  "query": "data table filtering empty state keyboard navigation",
  "type": "ux",
  "max_results": 3
}

Inspect the actual returned recommendations before incorporating them. A narrowly scoped search can fill a gap in the support-queue brief; it does not certify the implemented screen or authorize replacing your established design system.

5. Accept the local preview by the user's task

Once the intent and source are sensible, move from query diagnosis to application review. Do not spend the rest of the session tuning classifier wording while ignoring the screen.

• Operational purpose: can a support agent find an unassigned ticket and open it without passing through a marketing section?
• Layout fit: do navigation, filters and ticket actions remain usable on a narrow viewport?
• State coverage: are loading, no results and failed loading understandable, rather than replaced by invented ticket data?
• Interaction: can a keyboard user reach controls, see focus and operate filters? Check the implemented behavior, not a guideline label.
• Consistency: are approved components and tokens reused rather than silently replaced by a new palette?

Keep a compact record of the query, arguments, returned intent, layout source, selected recommendations and preview findings. If the agent will change files, the separate MCP Filesystem dry-run workflow explains how to inspect a proposed edit before applying it. Neither a design recommendation nor a file diff replaces rendered UI review.

FAQ

Why does “not a landing page” still affect the result?

The inspected classifier matches recognized phrases; it does not interpret negation as an instruction to exclude them. Keep the tool query affirmative and page-specific. Put “do not add marketing sections” in the implementation brief instead.

Does a null layout mean the design data is missing?

Not necessarily. First inspect output_format: both ai-optimized and minimal intentionally return a null layout at the cited revision. Use structured for this check, then investigate any genuinely absent or unsuitable fields.

Should I reinstall the server to change the page intent?

Not as the first step when the tool already returns valid data. Inspect the sent query, current tool schema and returned metadata. Revisit setup only if the connection, available parameters or installed version does not match the workflow.

Get one useful dashboard recommendation before coding

Start with a single affirmative dashboard query, inspect structured intent and layout data, then hand the coding agent a clear operational brief. Keep a separate call for the public landing page. That boundary makes the recommendation easier to evaluate and the local preview easier to accept.

Explore UI/UX Pro MCP for the product overview and repository, then try the support-queue query in your existing MCP client. The next success to look for is a relevant, inspectable recommendation—not an automatic deployment or a promise that the finished dashboard has passed accessibility review.